请用 GitHub 的 Private security vulnerability reporting（仓库页 Security → Report a vulnerability）提交， 不要开公开 Issue。
我会尽力在 7 天内回复确认。修复发布后，如你愿意，我会在公告里署名致谢。
SafeDrop 只在局域网内工作：没有账号、没有云端、没有第三方中继。设备之间用临时 X25519 密钥协商出 会话密钥，每个分块单独用 AES-256-GCM 封装，分块的序号、总块数和步长都在被认证的范围内。 配对码（6 位 PIN 或扫码得到的一次性 token）不经过网络传输，只作为密钥派生的输入， 双方各自算出 HMAC 证明来确认"我们派生出了同一把钥匙"。
这些不是"待办"，而是当前设计的边界。把它们当成已有防护来评估，会得出错误结论。
- 配对码不是强身份。 6 位数字不是 PAKE。能同时看到双方屏幕、又能在局域网上做中间人的人， 可以冒充" evil-twin "hub。指纹校验需要用户自己比对，目前没有带外信任锚。
- 桌面端自身与 hub 之间是明文 HTTP。 本机回环不加密——同一台机器上的不受信进程能看到这些流量。
- Web 门户只有走 HTTPS 才加密。 浏览器仅在安全上下文暴露 WebCrypto；用
http://打开门户时， 页面会拒绝配对而不是静默降级为明文。手机目前只提供 HTTP 门户，因此手机上的网页端无法配对。 - 限流是抑制，不是阻断。 同一来源 IP 连续 8 次配对失败封禁 5 分钟；换 IP 即可绕过， 这是局域网威胁模型下的取舍。
- 转发目标校验只保证不越出局域网。 允许 RFC1918、与本机同网段的地址，以及
SAFEDROP_RELAY_TARGETS显式列出的地址；回环、链路本地（含云元数据169.254.169.254）与公网地址一律拒绝。
- 传输协议由
protocol.json单一来源规定，当前为safedrop-e2e-v2。不同版本的客户端会在握手证明 阶段直接失败，不会静默兼容——这是有意为之，但意味着两端必须一起升级。 - 会话密钥只存在内存里，进程结束即失效；配对码本身从不写入磁盘或日志。
- 接收端只在收齐被认证的完整块集合、且字节数与块流推导一致后才落盘；不完整的数据留在
.part中并在一小时后清除。
只修复当前 main 与最近一个发布版本的问题。更早的版本请自行评估。