发帖
雷达卡
Geomys 维护标准
开源项目的专业化维护，使得我们作为专业团队能够系统性地投入资源来建立并执行一套高标准的维护规范。这不仅提升了项目的安全性与可靠性，也将原本对志愿者而言难以承担的责任转化为专业维护者的基准要求。
在制定 Geomys 维护标准 时，由于可参考的先例较少，我首先分析了近年来多起软件供应链安全事件，识别出其中可通过规范流程缓解的根本原因。[此处为图片1] 同时，我也广泛征求了来自 CI 安全、密码学及其他相关领域专家的意见，并结合其他 Geomys 维护者的实践经验进行综合评估。
目前的标准草案已发布于 geomys.org/standard-of-care，并将持续更新。该标准涵盖通用维护理念、稳定性保障、依赖管理、账户与 CI 安全机制、漏洞响应流程以及许可证合规等多个方面。
目标与承诺
我们的核心目标是实现项目维护的可持续性与可预测性。尽管部分支持来源于客户保留合同，但这些维护承诺面向的是整个开源社区，而不仅限于付费合作方。
适用范围
本标准适用于由 Geomys 独立或联合维护的所有项目，具体包括：
- Go 标准库中的 crypto/… 和 golang.org/x/crypto/… 模块，以及 FIPS 140-3 Go 加密模块（与 Go 团队共同维护）
- Staticcheck
- Gotraceui
- filippo.io/edwards25519
- filippo.io/csrf
- filippo.io/keygen
- filippo.io/intermediates
- filippo.io/{bigmod,nistec,mlkem768,hpke}（从标准库中独立出的模块）
- age 和 typage
- mkcert
- Sunlight 与 filippo.io/torchwood
- yubikey-agent
- bluemonday
对于非唯一维护的项目，我们注重与协作团队保持良好沟通与协调。此外，Geomys 成员可能拥有个人项目（如 mostly-harmless 系列），这些项目不强制遵循此标准。
代码审查机制
所有接受外部贡献的项目，均会对提交的代码进行严格审查，无论其来源是否为人工编写或由大型语言模型（LLM）生成。我们坚持对每一行变更进行人工判断，确保质量与安全性不受影响。
复杂性控制
维护者的关键职责之一是“拒绝”——我们主动限制功能膨胀，避免偏离项目初衷。在评估新特性时，始终依据明确的项目目标与非目标（例如参考 Go 密码学设计原则），以维持简洁、专注的架构方向。
静态分析实践
我们在持续集成（CI）流程中集成由 @dominikh 开发的 staticcheck 工具，用于检测潜在错误、性能问题和代码异味，提升整体代码质量。
稳定性保障
一旦 Go 包发布至 v1 版本，我们将严格遵守主版本内的向后兼容性原则，其承诺程度与 Go 标准库一致，确保用户升级过程平滑可靠。
持续维护策略
并非所有项目都处于高频活跃开发状态——有些可能已完成核心功能，或采用周期性维护模式。然而，除非项目被正式归档或标记为弃用，否则我们会持续响应新出现的问题，特别是那些可能导致原有使用场景失效的情况（例如与新操作系统版本的兼容性问题）。
依赖管理方法
我们不采用自动化的依赖更新工具（如 Dependabot）。这类工具在实际操作中常造成噪音干扰，并可能在生态系统尚未识别恶意模块前就引入新版本，从而增加供应链攻击风险。此外，Dependabot 存在身份冒充漏洞，易被用于社会工程攻击。
取而代之的是以下两种更可控的做法：
- 定期运行 govulncheck，获取针对当前项目真正受影响的高信噪比漏洞通知；
- 通过隔离的 CI 任务使用最新依赖版本执行测试（即在 go test 前运行 go get -u），以便提前发现破坏性变更，便于未来安全升级，同时了解下游项目可能面临的兼容性挑战。
防钓鱼认证体系
钓鱼攻击被视为对我们账户安全的最大威胁，进而直接危及用户信任。我们认识到，仅靠人为警惕无法系统性防御定向攻击，因此所有可能影响用户的敏感服务，均采用技术层面具备防钓鱼能力的认证机制。
防钓鱼认证 指使用通行密钥（Passkeys）或 WebAuthn 双因素认证，且凭证存储于以下安全载体之一：
- 平台认证器（如 iCloud 钥匙串）
- 可信密码管理器（如 1Password 或 Chrome 内建密码管理）
- 硬件安全密钥（如 YubiKey）
以下关键账户和服务必须启用上述认证方式，因其权限可直接影响项目与用户安全：
- GitHub
- 所有链接至 Gerrit 账户的 Google 账号
- CI/CD 平台
- 电子邮件账户
- 密码管理器主账户
- 通行密钥同步服务（如 Apple iCloud）
- Slack
- 网站托管服务
- 域名注册商
- DNS 托管服务
- 软件包注册表（若适用；Go 的去中心化包管理机制已在很大程度上规避了此类风险）
未来规划
接下来，我们计划逐步引入更多二进制透明性工具，并建立定期审查机制，覆盖浏览器扩展、授权的 Gerrit 与 GitHub OAuth 应用及访问令牌（仅 GitHub 就涉及四个独立的权限查看位置）。我们也欢迎社区就任何有助于提升安全性和可靠性的建议提供反馈。
我们始终启用严格的安全模式（如Google高级保护计划或Apple高级数据保护）。在必须配置备用认证或账户恢复机制时，优先采用防钓鱼的基于秘密的方法，例如TOTP或恢复代码。此类密钥生成后，我们会选择性地将其删除，或承诺除非经另一位Geomys维护者审查确认必要情况，否则绝不使用。若未实际部署TOTP，则其存在本身不会构成风险。
坚决不采用SMS作为任何形式的身份验证或账户恢复手段。由于SIM卡劫持可能在用户无感知的情况下发生，即便未主动操作，也存在被攻击的风险，因此该方式被视为不可接受。[此处为图片1]
长期凭据管理
我们尽可能避免使用长期有效的访问凭据，并努力确保任何持久化凭证具备不可提取性。例如，在与Gerrit交互时，优先使用git-credential-oauth而非保存cookie；向GitHub执行git推送时，采用由硬件绑定的SSH密钥配合yubikey-agent或Secretive工具，而不是依赖个人访问令牌。
尽管短期凭据更为理想，但目前尚难以全面推广。特别指出的是，现阶段仍无法在不依赖可导出的长期凭据的前提下，完整支持GitHub CLI的使用场景。
CI安全实践
我们在所有GitHub Actions工作流中运行zizmor进行静态检查，并避免使用存在安全隐患的触发器机制——尤其是那些允许攻击者通过pull_request_target等方式在特权上下文中执行工作流的操作。
默认情况下，GitHub Actions工作流以只读权限运行，且不加载任何敏感密钥。对于需要写入权限或访问机密信息的工作流，我们将禁用所有缓存功能（包括通过actions/setup-go等动作间接启用的缓存），以防范缓存投毒攻击。值得注意的是，即使只读工作流也被允许写入缓存条目，因此必须在使用缓存时同步实施防护措施。
第三方访问控制
针对仅由Geomys团队维护的项目，我们原则上不授予外部人员影响用户的权限（如代码推送或版本发布），并会对任何例外情况进行公开说明。
当决定不再维护某个项目时，优先选择将其归档并允许社区自行分叉发展，而非直接移交项目控制权。这种做法使下游使用者能够自主判断是否信任新的维护者。如有特殊安排，将在移交前进行充分沟通。
在任何情况下，均不会将曾归属于Geomys项目的域名、GitHub用户/组织名称或软件包标识重新开放注册或对外发布。
可用性监控机制
对关键的面向用户的服务端点（如Go模块导入路径的元数据页面）实施自动化的正常运行状态监测。
此类监控同时覆盖核心域名的有效期状态，有效预防因域名过期导致的服务中断及潜在的恶意接管风险。[此处为图片2]
透明度日志监控
通过订阅GopherWatch服务获取新版本发布通知，以便在未经授权的情况下向Go校验和数据库提交模块版本时及时收到警报。
利用Cert Spotter或Silent CT等工具持续监控关键域名（如Go导入路径所涉及的根域）的证书透明度日志记录。同时，在这些域名上配置CAA记录，将可颁发证书的CA机构限制为运营所必需的最小集合。
漏洞处理流程
每个项目均明确记录官方漏洞报告渠道，鼓励研究人员以协调方式披露问题，并对他们的贡献表示认可与感谢。
遵循最长90天的静默期政策，在漏洞细节公开之前，不会向与修复无关的个人或组织透露相关信息。付费客户亦无法获取未公开的漏洞详情——此举旨在履行我们对开源生态各方的责任，并尊重相关信息披露的边界。
一旦漏洞信息正式公开，确保其被准确录入Go漏洞数据库，包含完整的归属信息、元数据以及对应的CVE编号。
若发现指定的漏洞报告渠道失效，可通过发送邮件至security@geomys.org请求升级处理。
许可证策略
项目普遍采用宽松且广泛认可的开源许可证，包括：BSD-3-Clause、BSD-2-Clause、BSD-1-Clause、0BSD、ISC、MIT，以及在较少情况下使用的Apache-2.0。
免责声明
本文内容不具备法律约束力。您对各项目的使用仍受其各自适用的许可证条款和/或您与Geomys之间的具体合同所管辖，除非另有明文约定，否则本文件不构成其中一部分。
京公网安备 11010802022788号
