[fastrevmd-lab]

Changelog

Changed

• rustnetconf 0.17 → 0.18. Bumped the rustnetconf dependency requirement in rustez, rustez-cli, and rustez-py from "0.17" to "0.18" to track rustnetconf v0.18.0 (tagged and published on crates.io — verified below). rustez re-exports HostKeyVerification from rustnetconf::transport::ssh, and 0.18.0 added the AcceptNew TOFU variant to that enum, so it now flows through to rustEZ callers. HostKeyVerification is not #[non_exhaustive], so exhaustive matches downstream need a new arm — hence the minor bump (0.18.0 → 0.19.0), consistent with the same reasoning used for Personality in the 0.18.0 changelog entry. No other API changes in rustez itself.

Versions bumped in lockstep (per scripts/check_versions.py): rustez 0.18.0→0.19.0, rustez-py (crate) 0.18.0→0.19.0, rustez-py (pyproject) 0.18.0→0.19.0. rustez-cli stays at 0.1.0 (independently versioned, publish = false); only its rustnetconf pin moved to "0.18".

Step 1 verification (rustnetconf v0.18.0)

Before opening this PR I verified the upstream release this depends on:

• Tag v0.18.0 in mechubsec/rustnetconf is a signed (SSH, verified: true) annotated tag pointing at 45a483c8b6fc7d11e31f6e5df7f213f6ee1dc3a9, which is exactly PR mechubsec/rustnetconf#120's merge commit (mergedAt 2026-09-30T18:12:51Z).
• All CI checks on that commit are green (fmt, clippy, build, tests, yang-codegen-drift, cargo-audit, cargo-deny, security/secrets scans).
• rustnetconf 0.18.0, rustnetconf-yang 0.5.0, and rustnetconf-cli 0.5.0 are all live on crates.io (checked via the crates.io API).

Verification for this PR (rustez v0.19.0)

Repo cloned and built fresh against crates.io (not a path override), so cargo check/cargo test pulling in rustnetconf v0.18.0 from the registry is itself proof the registry version resolves correctly:

$ python3 scripts/check_versions.py
  rustez (crate)      0.19.0
  rustez-py (crate)   0.19.0
  rustez (python)     0.19.0
All manifests agree on version 0.19.0.

$ cargo check
   Checking rustnetconf v0.18.0
   Checking rustez v0.19.0 (.../rustez)
   Checking rustez-py v0.19.0 (.../rustez-py)
   Checking rustez-cli v0.1.0 (.../rustez-cli)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 16.68s

$ cargo test -p rustez
test result: ok. 59 passed; 0 failed; 0 ignored
Doc-tests rustez: test result: ok. 4 passed; 0 failed
(7 vsrx integration tests correctly skipped — require a live device)

$ cargo clippy -p rustez -- -D warnings      # clean
$ cargo clippy -p rustez-py -- -D warnings   # clean
$ cargo fmt --all -- --check                 # clean
$ cargo doc -p rustez --no-deps              # 2 pre-existing broken-intra-doc-link warnings,
                                              # confirmed present on main too (not CI-fatal, unrelated to this change)
$ cargo audit
    Scanning Cargo.lock for vulnerabilities (234 crate dependencies)   # 0 found

$ cargo deny check bans sources licenses
bans ok, licenses ok, sources ok   # (2 unrelated "license not encountered" warnings for unused allowances)

$ cargo publish --dry-run -p rustez
    Packaging rustez v0.19.0 ... Packaged 17 files, 191.0KiB (50.7KiB compressed)
    Verifying rustez v0.19.0 ... Finished `dev` profile ...
warning: aborting upload due to dry run   # success

# Python bindings (rustez-py), mirroring the `python-bindings` CI job:
$ maturin develop
    Compiling rustnetconf v0.18.0
    Compiling rustez v0.19.0
    Compiling rustez-py v0.19.0
    Installed rustez-0.19.0
$ pytest -q
20 passed in 0.03s

MSRV (1.86) job not run locally — no 1.86.0 toolchain installed in this environment; this release touches only dependency version requirements and a changelog, not code, so MSRV risk is low. rustez-cli isn't published to crates.io (publish = false), so no dry-run for it; rustez-py publishes to PyPI via the existing publish-pypi.yml, which already uses trusted publishing (OIDC, id-token: write, triggered on v* tags) — no workflow changes needed.

No mecmcp-pinned reusable workflow SHAs in this repo's workflows (its only reusable workflow reference is mechubsec/.github's gitleaks workflow), so the "reusable workflow reachable from mecmcp" check from the v0.27.0 lesson doesn't apply here.

Cargo.lock is gitignored in this repo (confirmed), so there's nothing to refresh there.

Post-merge: tag and publish

Tag the merge commit of this PR explicitly (not main's tip) once merged:

git fetch origin
git tag -s v0.19.0 -m "rustez 0.19.0, rustez-py 0.19.0" <MERGE_COMMIT_SHA>
git push origin v0.19.0

Pushing the tag triggers publish-pypi.yml (OIDC trusted publishing) to build and publish the rustez PyPI wheel automatically — no manual cargo publish step needed for that. rustez (the crate) publishing to crates.io: same manual cargo publish -p rustez convention as prior releases (no crates.io trusted-publishing workflow exists yet for this repo, unchanged from rustnetconf's situation, flagged not blocking).

I will verify the tag and both published artifacts (PyPI wheel + crates.io crate) once tagged, then move to step 3: mecmcp.

🤖 Generated with Claude Code