btd: net.connect does not travel over an authenticated link, and the comment said it did - #286
Merged
Merged
Conversation
…comment said it did The `NetConnect` arm justified routing a wifi passphrase over the radio by claiming the characteristic sets `encrypt_authenticated_write` and that the PIN agent makes the bond an authenticated one. Neither is true. `bluez.rs` sets `encrypt_write`, and sets it from `--require-pairing`, which is off by default — so on an ordinary board nothing on this link is encrypted. And the stronger flag could not be satisfied if it were set: the agent publishes as `NoInputNoOutput`, so the bond is just-works and unauthenticated by construction. `pairing.rs` already records why a headless robot cannot do better, and `bluez.rs` says the same thing a few lines from the flag. The route is unchanged and still correct — a robot with no network cannot be given one any other way. What changes is that the comment now names the PIN check and the radio range as what actually stands behind it, and points at §8.1 as the blocker rather than implying it is already closed. Found while testing `--require-pairing` against an iPhone. Assisted-by: Claude:claude-opus-5
Coverage72.09% lines on this branch, against a floor of 70%. Per-file |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
NetConnectarm inbtd/src/route.rsjustified routing a wifi passphrase over the radio like this:Both halves are wrong, and this is the arm that justifies putting a passphrase on a radio, so it should not claim a property we do not have.
bluez.rssetsencrypt_write, notencrypt_authenticated_write— and it sets it from--require-pairing, which is off by default. So on an ordinary board nothing on this link is encrypted at all.And the stronger flag could not be satisfied even if it were set. The agent leaves every handler
None, which BlueZ publishes asNoInputNoOutput, so the bond is just-works and therefore encrypted but unauthenticated, permanently.bluez.rssays exactly this a few lines from the flag, andpairing.rsrecords why a headless robot cannot do better — in LE passkey entry the roles follow from the declared IO capabilities, and a robot with no keyboard and no display can present neither side of it.The route does not change, and it is still right: a robot with no network cannot be given one any other way, which is what this transport exists for. What changes is that the comment now names what actually stands behind the route today — the PIN check in
session.rsand ten metres of radio range — says plainly that the passphrase crosses in clear, and points atapp-path-design.md§8.1 as the blocker rather than reading as though it were already closed.Found while testing
--require-pairingagainst an iPhone on olducky. Comment-only;cargo check -p btdandcargo fmtclean.🤖 Generated with Claude Code