Repository navigation
gate GET_ADVERTISING_NAME on cmd_status - #58
Conversation
was decoding the strap-name reply unconditionally, so a failure/pending reply's stale body bytes could get decoded into a plausible-looking name and surfaced as strap_name. same pattern as the battery/hello/clock gates.
There was a problem hiding this comment.
Sorry @abdulsaheel, you've used your own review budget of 250,000 diff characters for the last 7 days.
You can request another review in 6 days and 17 hours by commenting @sourcery-ai review. Upgrade to get a review now.
|
Warning Review limit reachedNext included review available in 9 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Reviewer's GuideThe PR fixes stale-data leakage for GET_ADVERTISING_NAME by status-gating advertising-name decoding on successful responses, with regression tests covering failure, pending, and unsupported statuses across gen4 and gen5. Sequence diagram for status-gated advertising name decodingsequenceDiagram
participant Device
participant Parser as parseCommandResponse
participant Decoder as _decodeAdvName
participant Consumer as PairingOrSettings
Device->>Parser: GET_ADVERTISING_NAME response
alt status == 1
Parser->>Decoder: _decodeAdvName(payload)
Decoder-->>Parser: strap_name
Parser-->>Consumer: decoded advertising name
else status != 1
Parser-->>Consumer: no strap_name
end
Flow diagram for preventing stale advertising namesflowchart TD
A[GET_ADVERTISING_NAME response] --> B{status == 1?}
B -->|Yes| C["_decodeAdvName(payload)"]
C --> D[Expose strap_name]
B -->|No: failure, pending, or unsupported| E[Skip body decoding]
E --> F[Prevent stale bytes becoming strap_name]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
same bug as the battery/hello/clock reads, just on the adv-name opcode. getAdvertisingNameHarvard/getCustomAdvertisingName decoded the reply body unconditionally, no status check. on a failure/pending/unsupported reply the body is stale, and _decodeAdvName's printable-run fallback can turn stale bytes into a plausible name that gets surfaced as strap_name in pairing/settings.
fix is the same one-line gate the sibling opcodes already have (if status == 1). added a regression test covering status 0/2/3 on both gen4 and gen5.
Summary by Sourcery
Gate advertising-name decoding on successful command status to avoid reporting stale strap names.
Bug Fixes:
Tests: