Ask which advisories apply, without sending the boot log

[Zenofex]

The client half of a design whose server half already shipped. The applicability endpoint and the terminal login that reaches it both existed; nothing in the CLI called them.

$ bootintel scan bootintel-9.txt --applicability --dry-run
{
  "inventory": [
    { "name": "linux", "version": "3.3.8" },
    { "name": "busybox", "version": "1.19.4" }
  ]
}

2 component(s) would be sent to https://bootintel.com. The boot log would not.

The guarantee is structural, not a promise. The payload is built from a fixed map of three detector labels to three product names, every value is re-validated against the server's own limits before it leaves, and there is no field a log could occupy. A test asserts that adding one breaks the build.

Verified against sample_logs/bootintel-24.txt, which carries androidboot.serialno=, vbmeta.device_state=unlocked and androidboot.selinux=permissive. It yields two version strings and nothing else.

--dry-run is a headline capability, not a debug switch. It is how a consultant shows a client what leaves the machine.

The translation is the part that would have failed silently. The server matches lowercase product names, so sending Bootloader or U-Boot 2020.10 returns nothing while looking like a server fault. Only U-Boot, Linux and BusyBox map to something the catalog holds; the other eleven detectors are not CVE-tracked products and are deliberately absent.

A 422 is reported as a bug in this client rather than user error, since the same rules are enforced here first. A 403 says local identification still works and how.

Verified live: bootintel login against the running server, then scan --applicability sending 2 components and receiving 67 verdicts, every one bounded_range. Probe account removed afterwards.

308 tests pass, clippy clean under -D warnings, rustfmt clean, cargo deny check all ok.