Harden BLE pairing and actually revoke removed phones
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 34/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- rust
- Lĩnh vực
- embedded-iot, security
Hướng nghiên cứu
Read boards/esp/src/lib.rs:80 and the bond management and disconnect handling in ble/transport.rs, especially around line 521; trace how BondStore and the controller lists are updated. The issue identifies several separate security behaviors, including phone revocation, normal disconnect handling, and bond limits. Done means removed phones can no longer connect and ordinary disconnects do not erase bonds; pairing limits and the separate issue linked for Just Works pairing also need review.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
- Revocation doesn't work. On ESP,
RemovePairedPhone/ClearPairedPhones
(boards/esp/src/lib.rs:80) only edit the in-memoryPAIRED_PHONESlist,
which nothing on ESP uses for authorization. The real credentials (LTKs in
BondStoreflash plus the controller filter-accept/resolving lists) are
untouched, so a removed phone still connects. Remove the bond via
stack.remove_bond_information,BondStore::remove_bondand
remove_bond_from_controller(all exist inble/transport.rs), and drop the
separate registry or make it the source of truth. - Just Works pairing and the boot-time window on buttonless boards: https://github.com/OpenCarControls/firmware/issues/18.
- Auto-heal is too aggressive.
ble/transport.rs:521treats
REMOTE_USER_TERMINATED_CONN(a normal phone disconnect) as a security
failure, so any disconnect during the pairing window wipes that phone's bond. max_bonded_phonesisn't enforced on BLE bonds (the store is hard-capped at 8).- Later: LTKs are stored unencrypted in flash (flash encryption).
- Ngôn ngữ chính
- Rust
- Star
- 1
- Fork
- 0
- Merge trung bình
- 13 giờ 37 phút
- Pull request đã merge (30 ngày)
- 8
Chuẩn bị môi trường
Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Không có hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của OpenCarControls/firmware
-
Refresh stale docsĐang mở
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 67/100
OpenCarControls/firmware#35 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Clean up E-GMP leftoversĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
OpenCarControls/firmware#34 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
OpenCarControls/firmware#31 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
OpenCarControls/firmware#30 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
OpenCarControls/firmware#57 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của OpenCarControls/firmware
Issue tương tự
-
area: config effort: S good first issue P3 type: bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
ferenyl/azuredevopstui#63 ·
-
needs-triage O-Arm T-libs
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug CLI config mcp
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
documentation good first issue
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 88/100
yunaremaia/sandbox-ffi-layers#56 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
git-ai-project/git-ai#2434 ·
Maintainer thường phản hồi trong vòng 1 ngày