Skip to content

rustman: new package at 0.3.15-dev.51-1 - #61

Open
barnumbirr wants to merge 4 commits into
masterfrom
package-rustman
Open

barnumbirr wants to merge 4 commits into
masterfrom
package-rustman

Conversation

@barnumbirr

@barnumbirr barnumbirr commented Oct 20, 2026 •

Copy link
Copy Markdown
Contributor

A desktop API client for HTTP, WebSocket and GraphQL in the manner of Postman, with no account or cloud service: collections with environments, history, pre-request and test scripts, imports from curl, OpenAPI and Postman, and collection directories committed and pushed through git. Rust on iced, MIT.

Three commits: the package, staged; its packages.txt line, pushed after the staged run went green on all six legs; and a second lock patch for rustls.

Vetting

All three passes clear, checked today.

pass result
not in Debian absent from trixie, testing and unstable, all four components
no upstream .deb 41 releases, zero .deb assets
no third-party channel upstream documents its GitHub release assets and a source build, nothing else

Whole-fleet re-check at this addition: all 37 enrolled packages are still absent from Debian.

Build

  • --no-default-features, which upstream's Cargo.toml and README name as the build for package managers. It compiles out the in-app updater, so nothing in the binary can replace /usr/bin/rustman, and debian/rules fails the build if the updater's GitHub endpoint survives.
  • Debian's SQLite and zlib, asserted in the binary's NEEDED. libgit2 stays vendored: libgit2-sys wants 1.9.4 and trixie has 1.9.0.
  • The version is stamped into Cargo.toml and Cargo.lock from DEB_VERSION_UPSTREAM, as upstream's release job does from the tag, so the app reports 0.3.15-dev.51.
  • Two git dependencies, rustman-engine and upstream's fork of iced-code-editor, are pinned by commit in Cargo.lock and fetched from GitHub at build and rebuild time.

Three things found while packaging

Depends has to name the display libraries. winit dlopens all of them, so the binary links only libc, libgcc_s, zlib and SQLite, and ${shlibs:Depends} sees none. In a container holding only the package's Depends it panicked at startup on libX11.so.6, then libXcursor.so.1, libX11-xcb.so.1 and libXi.so.6 against a separate X server, and with NoWaylandLib against a headless Weston: winit picks Wayland whenever WAYLAND_DISPLAY is set and does not fall back. With the eight libraries now in Depends, the UI renders on both, on all three suites. DEP-8 cannot catch this class, because its own test Depends (xvfb, xdotool) install the same X libraries.

rust-i18n 3.1.2 made every build different. debrebuild failed twice with size differs, and the original and both rebuilds all differed from each other, by up to 384 bytes of .text. Building one tree twice and comparing every crate's rlib narrowed it to one crate, the editor widget, whose rust_i18n::i18n!("locales", fallback = "en") emits its translation tables by iterating a HashMap, seeded randomly in every process. rust-i18n-macro 3.1.3 and later iterate a BTreeMap. debian/patches/cargo-lock-rust-i18n-3.1.5.patch ships the lock resolved with 3.1.5 and the build stays --locked, the same shape as rathole's lock patch. Reaching 3.1.5 meant dropping proc-macro-crate 2.0.2, whose exact toml_datetime pin conflicts with the toml that 3.1.5 needs. Besides the three rust-i18n crates, the patch updates the toml crates, which are reached only through the proc macro, and removes serde_yml and libyml. With the patch, two builds of one tree give identical bytes for all 1,119 rlib and rmeta files and for the binary. The same change is proposed upstream as rust-man-org/rustman#65.

rustls 0.23.43 carries two TLS advisories that apply to a client. cargo audit on upstream's lock reports 15 vulnerabilities, and rustls is the one that reaches the binary: it is the TLS stack behind every HTTPS request. RUSTSEC-2026-0349 lets an unauthenticated ServerHello downgrade later connections to classical key exchange, and RUSTSEC-2026-0285 accepts TLS 1.3 handshake messages across encryption levels; its other two need the brotli feature, which is off, or code that formats session values with Debug. debian/patches/cargo-lock-rustls-0.23.46.patch moves it to the semver-compatible 0.23.46, which also brings aws-lc-rs 1.18.2, aws-lc-sys 0.46.0 and rustls-webpki 0.103.15, plus crossbeam-epoch 0.9.21 for RUSTSEC-2026-0204. It is a separate patch so each one maps to one upstream change and can be dropped on its own. Applied in order, the two give exactly the lock upstream would have with both changes merged, which cargo accepts unchanged under --locked. The 10 advisories left reach no code this build runs: quinn-proto is not compiled, quick-xml runs only at build time inside wayland-scanner, and zip's three concern extracting archives to disk, which neither calamine nor the compiled-in code does.

Verification

  • debrebuild: all OK on all four checksums, twice, trixie amd64, before enrolment and again with both lock patches. arm64 cannot run here, so that half falls to reproducible.pkg.haus after the merge.
  • CI's trixie and unstable amd64 .debs are byte-identical to the local builds.
  • DEP-8 passes under autopkgtest on trixie, testing and unstable. send-request types a URL into the window under Xvfb, then asserts that a local server received the request and that the 418 it answered is in rustman's SQLite history. Four mutations trip it on trixie and unstable: a stub window, no window, history writes broken in the binary, and libxkbcommon-x11 removed.
  • Lintian clean on trixie and testing; unstable adds only initial-upload-closes-no-bugs, as every package does. Two overrides: no-manual-page, since main() reads no arguments and there is no --help to generate a page from, and embedded-library for the YAML parser behind OpenAPI import.
  • Smoke-tested on trixie: an HTML response shown as text, with Open in browser handing xdg-open a temp file holding the full source; Settings with no Updates card.
  • TLS, on trixie and unstable with both lock patches: an HTTPS request to a server whose CA is not trusted fails without reaching it; once the CA is in the system trust store, requests complete against a TLS 1.3 server and against a server capped at TLS 1.2.
  • Build-Depends complete: a plain debian:trixie with only build-essential and apt-get build-dep builds it, with neither git nor cmake present. That build runs under dpkg's -O2 CFLAGS, which aws-lc-sys 0.46.0 handles: the jitterentropy failure monolith hit with 0.45.0 is fixed in this release.
  • Watch file verified at authoring time: uscan reports 0.3.15-dev.51, matching what is packaged.

Note on merging

release.yml fires on a push to master touching */debian/changelog, so merging builds every suite and arch, tags rustman/v0.3.15-dev.51-1, and dispatches the ingest. It publishes.

Upstream is five months old, with four contributors (one author holds 69 of 89 commits), 41 releases and 21 commits in the last month. Every release since 2026-06-14 is tagged X.Y.Z-dev.N; if upstream ever cuts a plain X.Y.Z after X.Y.Z-dev.N, dpkg sorts it lower and that bump needs a hand-written version.

A desktop API client for HTTP, WebSocket and GraphQL in the manner of
Postman, with no account: collections with environments, history,
pre-request and test scripts, imports from curl, OpenAPI and Postman,
and collection directories committed and pushed through git.

Clears all three vetting passes, checked today: absent from trixie,
testing and unstable in all four components; upstream releases carry
tarballs, a dmg and zips but no .deb; no third-party channel. The whole
fleet re-checked against Debian at this addition: all 37 still absent.

Built with --no-default-features, which upstream names as the distro
build. It compiles out the in-app updater, so nothing in the binary can
replace /usr/bin/rustman, and the build fails if the updater's GitHub
endpoint survives.

winit dlopens every display library, so the binary links only libc,
libgcc_s, zlib and SQLite and ${shlibs:Depends} sees none of them.
Depends names them by hand: libx11-6, libx11-xcb1, libxcursor1 and
libxi6 for X11, libwayland-client0 for Wayland, and both xkbcommon
libraries. Each was found missing, one per run, in a container holding
only the package's Depends, against a separate X server and against a
headless Weston; with all of them the UI renders on both.

debian/patches ships Cargo.lock resolved with rust-i18n 3.1.5. The
editor widget compiles its locales through rust-i18n-macro, and 3.1.2
emits the translation tables in HashMap order, seeded randomly in every
process, so no two builds of one tree matched. 3.1.3 and later iterate
a BTreeMap. Two release builds of one tree now give identical bytes for
all 1,119 rlib and rmeta files and for the binary.

Two git dependencies, pinned by commit in Cargo.lock, are fetched from
GitHub at build and rebuild time.

debrebuild reports all OK on all four checksums, twice. DEP-8 passes on
all three suites under autopkgtest, and four mutations trip it on
trixie and unstable. Lintian clean apart from the initial-upload warning
every package carries on unstable. A plain trixie container with only
build-essential and the declared Build-Depends builds it.
cargo audit on upstream's lock reports 15 vulnerabilities. The four in
rustls 0.23.43 reach the binary, the TLS stack behind every HTTPS
request, and two apply to a client: RUSTSEC-2026-0349 (a ServerHello
can downgrade later connections to classical key exchange) and
RUSTSEC-2026-0285 (TLS 1.3 handshake messages accepted across
encryption levels). 0.23.46 is semver-compatible; it moves aws-lc-rs
to 1.18.2, aws-lc-sys to 0.46.0 and rustls-webpki to 0.103.15.
crossbeam-epoch goes to 0.9.21 for RUSTSEC-2026-0204.

A second quilt patch, so each maps to one upstream change and can be
dropped on its own. Applied after the rust-i18n patch, the series gives
exactly the lock upstream has with both changes merged, which cargo
accepts unchanged under --locked. The rust-i18n patch now names its
upstream pull request.

The 10 advisories left reach no code this build runs: quinn-proto is
never compiled, quick-xml runs only at build time, and zip's three
concern extracting to disk, which neither calamine nor the compiled-in
code does.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant