Anti-REA Forge（底层工具名 Open Release Guard）v0.2 是 alpha 版本，尚未经过独立安全审计。它提供原生编译接入、选择性文字掩码、PE/ELF 静态发布检查、签名发布清单和离线授权基础能力，不承诺防止反编译、阻止客户端补丁或让软件无法破解。测试通过和使用成熟密码库都不能替代对完整系统的安全评估。

RG_TEXT 是可以恢复的静态文字掩码，不是加密保密边界。种子可从产物和解码逻辑中恢复；新种子只是改变静态载荷，不能视为私钥或防破解秘密。解码文字在对象存活期间位于内存中，调用者复制、寄存器、标准库和操作系统缓冲不属于析构擦除范围。REA 等工具可以分析解码器或观察运行时。

2026-10-15 的 实际测试 已观察到这一限制：自有 Linux 样本的完整测试口令未以明文出现在文件中，但可从 Ghidra 伪代码和常量静态恢复，也可在动态比较边界恢复；恢复值被未修改的原程序接受。这是当前保护设计的边界，不是签名私钥恢复或 Ed25519 伪造实验。REA 整合分析受环境限制，Windows EXE/DLL 尚未实测。

gate 只证明本次检查的文件符合指定的静态规则；未配置的文字、未知编码、算法逻辑、运行行为及公共导出不在文字扫描保证范围内。PE 标记及相关目录存在不代表完整 CFG 插桩或操作系统已实施缓解措施，也不验证 Authenticode 信任。ELF 名称与 section 表缺失时，默认严格元数据策略拒绝作出“已清除”的结论。文件修改可绕过或移除构建 hook，因此发行流程必须由可信构建环境控制。

PE 的调试目录按条目进行有界解析，保留 debug_directory_present 与 debug_directory_types 原始证据，并另报 debug_metadata_present。只有规范空载荷 REPRO（type 16）及已识别位值的四字节扩展 DLL 特征（type 20）可归为非调试记录；CodeView、COFF/POGO、未知类型或未验证字段仍受默认禁止调试元数据策略约束。分类不证明操作系统实际实施了相关安全特征。

本项目没有测得针对 REA 的破解概率或通用语言覆盖率。CMake/编译器的兼容性、共享库 ABI、优化副作用和性能需要在具体业务上验证；Linux -z now 会改变延迟绑定行为。共享库和模块库不自动隐藏公开导出；Linux 可执行目标默认设置 hidden visibility，可能影响由 dlsym 或插件查找的可执行文件符号，需要验证这些接口。

• Ed25519 签名用于验证数据的完整性和签名者持有私钥这一事实，不用于加密程序、清单或授权内容。不要把密码、服务端凭据或其他秘密放入这些公开数据。
• 私钥应只存在于受控签发环境，使用访问控制、加密备份和适当的密钥管理措施。不要将私钥、私钥口令或代码签名证书加入仓库、客户端、构建日志、测试 fixture 或 GitHub Actions artifact。
• 验证方必须从可信来源固定公钥或公钥指纹。若攻击者可以同时替换文件、清单、公钥和验证程序，单独一份成功的签名校验无法建立发布者身份。密钥轮换需要由既有可信机制或独立渠道授权。
• 本项目的清单签名密钥与 Authenticode 代码签名证书相互独立。清单验签不等于验证 Windows 代码签名证书链、撤销状态或发行商信誉。
• PE 审计读取文件元数据，不会执行被分析的 EXE 或 DLL。审计结果只描述所检查的属性，不代表文件无恶意行为、没有漏洞或所有依赖均已加固。对不可信文件的分析仍应放在隔离环境中。
• 客户端运行在用户控制的机器上。验证程序、嵌入的公钥、授权判断和本地状态均可被修改。关键权限、服务凭据和高价值业务逻辑应由受控服务端执行。

离线授权依赖验证时看到的本地时间和状态。拥有本机控制权的人可能修改时钟、回拨本地状态、恢复旧备份或修改校验代码，因此仅靠离线文件不能彻底解决到期绕过、撤销和授权回滚。即便旧版本清单仍有有效签名，也不意味着它是最新的、仍受支持的或没有已知漏洞；可信更新策略应另行处理最低版本和撤销信息。

文件从校验完成到实际加载之间可能被替换，这是 TOCTOU（检查与使用之间的时间差）问题。一次命令行验签只证明校验当时读取的内容。部署时需要结合可信安装路径、访问权限、原子更新、可信启动过程和受控加载机制设计；本工具不能单独保证后续加载的字节未发生变化。

清单、公钥或授权文件只要可以被降级到旧的可信版本，就可能重放旧状态。需要及时撤销、可信时间或严格防回滚的产品，应评估在线验证和受保护状态存储的适用性，并明确断网行为。客户端补丁、时钟回拨和回滚不能由本项目的离线验证彻底消除。

仅丢失私钥时，既有签名不会自动失效，但你无法再用同一把私钥签发或更新数据。使用受控备份恢复，或生成新密钥并通过可信渠道更新验证方固定的公钥。不要为了继续签发而从公开仓库或他人提供的密钥“恢复”身份。

怀疑私钥泄漏时，应立即停止使用旧私钥，限制受影响签发环境的访问，保留调查记录，并检查近期清单和授权签发记录。生成新密钥后，通过可信发布渠道分发新的信任配置，通知使用方停止信任旧密钥。离线客户端只有收到并采用可信撤销或更新信息后，才有机会拒绝旧密钥；删除 GitHub 文件、替换服务器公钥或宣布轮换，不会自动撤销已分发的离线授权。将私钥从当前 Git 文件中删除也不会消除它在提交历史、日志、缓存或备份中的副本。

请先查看仓库的 Security → Advisories → Report a vulnerability 是否可用；只有仓库启用了 GitHub 私密漏洞报告功能时，才能通过该入口提交敏感报告。本项目目前不提供预设的私密报告邮箱，也不承诺固定的响应时限。

如果私密报告入口未启用，可以开一个不含敏感细节的一般 issue，请维护者提供私密沟通方式。不要在公开 issue、讨论、pull request 或日志中发布私钥、口令、仍可使用的授权、客户数据或尚未协调披露的完整利用细节。

有助于定位问题的信息包括：受影响版本或提交、运行环境、最小复现、预期与实际行为，以及不包含真实秘密的测试数据。请使用临时生成的测试密钥复现，描述你认为跨越的信任边界，并区分实现缺陷与上述已经说明的客户端信任限制。