Anti-REA Forge（底层工具名 Open Release Guard）v0.4 是 alpha 版本，尚未经过独立安全审计。它提供原生编译接入、选择性文字掩码、PE/ELF 发布检查、签名清单、离线授权、单向口令校验、外部密钥资产封装、原生敏感缓冲区和服务端请求能力凭证，不承诺防止反编译、阻止客户端补丁或让软件无法破解。测试通过和使用成熟密码库都不能替代对完整系统的安全评估。

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

2026-10-15 的 实际测试 已观察到这一限制：自有 Linux 样本的完整测试口令未以明文出现在文件中，但可从 Ghidra 伪代码和常量静态恢复，也可在动态比较边界恢复；恢复值被未修改的原程序接受。这是当前保护设计的边界，不是签名私钥恢复或 Ed25519 伪造实验。该逆向实验未覆盖 Windows；后续已有 Windows/MSVC EXE 构建与发布检查 CI 通过，Windows DLL ABI 和逆向抵抗仍未验证。REA 整合分析受环境限制未完成。

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 或日志中发布私钥、口令、仍可使用的授权、客户数据或尚未协调披露的完整利用细节。

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

The password verifier stores a salted Argon2id PHC record, not an encrypted reference password. Its fixed profile limits one operation; applications must add authentication rate and concurrency limits. Verifier integrity, password entropy and trusted server-side enforcement remain application responsibilities.

Sealed assets require a separately held 32-byte master key and trusted product/release/purpose/asset identifiers. They authenticate data, never execute code, and provide no freshness within identical context. Anyone holding the symmetric master key can create valid assets. Use the existing issuer-signed release manifest with a pinned public key for publisher authenticity; keep release/signing keys separate. Master keys, derived keys and decrypted data can appear in Python or native memory; zeroization and memory-dump resistance are not provided.

Release-root scans require a trusted, stable build directory and trusted ancestors. They detect configured names, hashes, file sets and literal bytes, not all secrets or archive contents. Ordinary identity/inventory changes fail closed; this does not guarantee safety against hostile parent-directory races or replacement after inspection. Continue to use trusted installation/loading/update controls.

Details: crypto integration. Functional crypto checks and earlier native recovery evidence are separate from a complete REA/provider/model evaluation.

The native secure_buffer reduces accidental exposure through swapping, owned-memory residue and (on Linux when enabled) core dumps. It does not block a debugger or in-process instrumenter, clear registers or caller/library copies, enforce object bounds inside page padding, or provide a TEE. Windows reports no dump exclusion. Required locking or dump protections fail closed; optional protections report their actual state. This buffer does not change the memory behavior of Python/pyca bytes or automatically move decrypted assets into native protected memory.

Capabilities are bearer credentials for one exact request and a bounded lifetime. The issuer must authenticate and authorize before signing; expected subject, audience, product, operation and executed request must come from trusted server state. A client-supplied expected value or public key does not establish authorization. Signing keys stay outside clients. Network authentication, TLS, rate limits, issuance policy and the business handler are application responsibilities, not provided services.

The replay database and its parent directory must remain trusted and stable. All instances of the same authority must share the same authoritative state. A missing or invalid database fails closed and is never silently recreated. Explicitly initializing a replacement, restoring an old snapshot, cloning independent stores or rolling back the server clock/state can invalidate replay guarantees. The persisted clock floor detects time moving backwards relative to that database; it is not trusted hardware time or a rollback-proof database.

Successful consumption is committed before authorization is returned. A subsequent handler failure or crash burns the capability. This is at-most-once authorization consumption, not exactly-once business execution; stronger semantics require a shared business transaction/outbox and idempotency design. An attacker who steals an unused valid capability and controls its authenticated subject can race to consume the same permitted request first. An actively controlled authorized client can still use its delegated rights.

See runtime integration and sources and v0.4 validation. No completed REA resistance rate, comprehensive side-channel defense or remote-attestation deployment is claimed.