安全政策

Herkos 处理私钥和加密消息，因此我们认真对待安全报告，宁愿尽早而不是太晚得知问题。

报告漏洞

请不要为安全问题创建公开 issue。

请通过 GitHub 的 私密漏洞报告 私下报告，或发送电子邮件至 security@herkos.email。

建议包含以下内容：问题是什么、如何复现、你测试的平台和版本，以及攻击者能够达成什么。 提供概念验证会很有帮助。

切勿在报告中附上你自己的 nsec、私钥或 bunker 密钥。

我们力求在几天内确认收到报告。由于 Herkos 是一个小项目，请在公开披露之前给我们留出 合理的修复时间。除非你另有意愿，我们很乐意在安全公告中致谢你。

适用范围

Herkos 应用本身：密钥的处理与存储、消息的加密与解密（包括 local_packages/nostr_mail 中的 NIP-59 发件人校验和密送（Bcc）隔离）、应用锁、与中继和桥接服务的通信、附件处理， 以及构建与发布流程。

不在范围内

• Nostr 协议及其 NIP 本身——请向上游报告。
• 由第三方运营的中继、桥接服务和 Blossom 服务器。 Herkos 自带默认配置，但并不运营 它们；请向其运营者报告问题。
• 上游项目 Nostr Mail Client， 除非问题特定于 Herkos 所做的修改。
• 我们已作为已知局限记录在案的加固缺失（见下文）。

已知局限，直言不讳

这些是设计上的取舍，而不是漏洞。我们宁愿把它们写下来，也不愿让别人吃了亏才发现：

• 发往传统地址的邮件不是端到端加密的。 Nostr 用户之间的消息使用 NIP-17 gift wrap， 是端到端加密的。当你给普通电子邮件地址写信时，桥接服务会转换消息，并能读取它。
• 应用锁（PIN 和生物识别）是便利性的屏障，而非静态加密。它能阻止拿起一台已解锁 设备的人；但无法防范能够完全访问设备或其存储的攻击者。
• 在 Windows 上无法强制只使用生物识别验证。 Windows Hello 不允许选择验证方式， 因此系统 PIN 始终可作为备用方式。
• 丢失密钥就意味着失去账户。 设计上就没有恢复机制。
• 元数据并未完全隐藏。 中继可以观察连接模式，而且每个中继都能看到你的 IP 地址， 即使它们无法读取消息内容。Herkos 不会泄露的（自 2026 年 9 月 30 日起）是：当中继要求 NIP-42 认证时，谁在给谁写信：
• 查询投递地址。 收件人的中继列表和 Blossom 列表是通过一条从不标识你身份的独立连接 查询的，并优先查询不要求认证的中继（purplepag.es、 user.kindpag.es、nos.lol、offchain.pub）。
• 个人资料与定时服务。 显示的其他任何人的名称和头像（kind 0），以及你定时发送或 取消定时邮件时定时 DVM 的中继列表，都以同样的方式查询：先匿名查询，如果中继坚持 要求，则使用下文所述的临时密钥，绝不使用你的密钥（自 2026 年 10 月 1 日起；在此之前， 要求认证的中继会得到你的密钥，并能得知你在查看谁的资料）。只有你自己的个人资料 仍以你的身份读取。
• 投递。 gift wrap 会通过同一条独立连接发往收件人的 DM 中继。如果其中某个中继 要求认证，Herkos 会使用一个专门为此生成、只保存在内存中的密钥来应答，绝不使用你的 密钥；设备上的每个账户都有各自的临时密钥。中继仍然可以看到，同一台设备（相同的 IP、相同的临时密钥）在一次会话中发送了多个信封。
• 大邮件。 超过 32 KB 的邮件，其加密副本会上传到 Blossom 服务器，包括收件人的服务器。 只有你自己的服务器（你的 Blossom 列表）会收到用你的密钥授权的上传。其他任何服务器 都以匿名方式收到上传；如果它坚持要求授权，则使用与上文相同的临时密钥签名的授权 （自 2026 年 10 月 1 日起；在此之前，每台服务器都会得到你的密钥）。只接受已知密钥的 服务器会拒绝上传，副本则保留在其他服务器上。
• 你自己的数据。 同步你的邮箱、标签、设置和草稿时，如果中继要求，会以数据所属的 账户身份进行认证，即使在切换账户期间也是如此。对你自己的中继来说，这并没有告诉 它们任何新信息：这些请求本来就写明了你的密钥。你自己的中继列表和 Blossom 列表是 公开的，查询时不会标识你的身份，邮件链接中提到的中继也是如此。
• 已读状态和文件夹是公开元数据（目前如此）。 将邮件标为已读、加星标、归档或移动时， 会发布一个与你的公钥关联、未加密的 NIP-32 标签事件，其中包括自定义文件夹的名称。 知道自己发给你的某封邮件 id 的发件人可以得知你何时对它进行了操作。我们计划对这些 标签加密；在此之前，请把文件夹名称视为公开信息。
• 推送通知和定时发送使用第三方服务。 推送服务器（默认为 api.nmail.li）会得知 你的公钥、推送令牌以及你何时收到邮件；定时 DVM 会得知你的公钥以及它需要发布的、 已加密的消息。两者都需要你主动开启，并在 PRIVACY.md 中有说明。推送通知的文本由 推送服务器决定，Herkos 只有在 UnifiedPush 以加密方式（RFC 8291）送达时才信任它； 未加密的内容只会唤醒应用，由应用自行获取邮件。
• 网页版把你的密钥保存在浏览器中，这是保管密钥最薄弱的地方。 已安装的应用会把 你的私钥交给操作系统的安全存储（Android Keystore、Windows 凭据管理器、libsecret、 iOS/macOS 钥匙串）。浏览器没有这些：密钥存放在该源（origin）的存储中，每次签名都会 经过 JavaScript，页面中运行的任何代码都能触及它——能访问所有网站的浏览器扩展、应用 或其依赖中的 XSS 漏洞、被篡改的部署——复制浏览器配置文件的任何窃密软件也能拿到它。 而且也不存在一个让你一次性验证代码的时刻：已签名的二进制文件在安装时接受检查，网页 则在每次访问时都下发新的代码。请使用远程签名器（NIP-46 bunker、Amber）登录网页版， 让密钥永远不进入浏览器；或者把它当作一次性身份，把你真正的密钥保存在已安装的应用中。
• 经桥接服务转发的邮件，其可信度取决于桥接服务本身。 Herkos 会验证标记为经桥接 服务转来的消息，确实是由你配置的某个桥接服务（或某个默认桥接服务）签名的。但它无法 对桥接服务转发的传统 From: 地址做任何验证。
• 附件由操作系统打开。 Herkos 从不启动可执行文件或脚本类型的文件，并且在把其他任何 无法预览的附件交给系统默认应用之前都会先询问你，但打开文件的应用不在我们的控制范围内。

受支持的版本

安全修复只应用于最新发布的版本。鉴于项目规模，旧版本不再维护——报告前请先更新。