后端内容协同【免费下载链接】core:cloud: ownCloud web server core (Files, DAV, etc.)项目地址https://gitcode.com/gh_mirrors/core84/core点击查看免费下载ownCloud web server core 通过resources/codesigning/目录承载应用代码签名的信任锚点、中间证书与证书吊销列表CRL支撑 Integrity Check 验证器对 first-party 与第三方应用的签名校验。本文以该目录的 README 为核心结合lib/private/IntegrityCheck/Verifier/下的TrustStore、CrlProvider实现与对应测试讲解 G1 遗留验证路径与 G2 新验证路径如何共存、证书与 CRL 如何按代际加载以及 G1 过渡期的兼容语义。读完本文你将掌握 ownCloud 代码签名信任库的目录布局、代际标记规则、CRL 获取的三级降级策略并能依据源码与测试用例理解 G1 迁移与 G2 上线的完整行为。信任库的目录布局resources/codesigning/是 ownCloud 代码签名验证的信任存储根目录采用roots / intermediates / crl三级分层结构与 G1、G2 两个证书代际一一对应resources/codesigning/ ├── roots/ # Trust anchors信任锚点 │ ├── root-g1.crt # 遗留 G1 根实际为中间权威为过渡期保留 │ └── root-g2.crt # G2 根锚点CA ceremony 产物 ├── intermediates/ # 中间证书 │ └── intermediate-g2.crt # G2 中间签发者CA ceremony 产物 ├── crl/ # 证书吊销列表 │ ├── legacy.crl # 冻结的 G1 CRL面向遗留应用 │ └── developers.crl # G2 叶子 CRLCA ceremony 产物通过 CRL_URL 刷新 └── core.crt # 核心叶子证书first-party 签名用验证器不使用上述文件均已在本仓库确认存在。实际证书信息可通过openssl x509查看root-g1.crt的主体为CN ownCloud Code Signing Intermediate Authority有效期 2016-02-03 至 2026-01-31root-g2.crt的主体为CN ownCloud Code Signing Root CA G2有效期 2026-07-15 至 2051-07-09intermediate-g2.crt的主体为CN ownCloud Code Signing Intermediate CA G2有效期 2026-07-15 至 2031-07-14core.crt的 CN 为core有效期 2016-02-03 至 2026-01-31。TrustStore 的加载行为按文件名标记代际OC\IntegrityCheck\Verifier\TrustStore见 TrustStore.php是加载信任锚点与中间证书的核心类其行为与 README 描述完全一致roots/ 全部加载为信任锚点getRoots()通过EnvironmentHelper::getServerRoot()拼接出resources/codesigning/roots路径逐文件读取 PEM 内容读取失败file_get_contents返回false的文件会被跳过。按 basename 前缀打代际标签文件名以root-g1开头则标记为g1遗留验证路径否则标记为g2新验证路径。对应源码为$generation \strpos($filename, root-g1) 0 ? g1 : g2;intermediates/ 作为非可信线索加载getBundledIntermediates()读取该目录下所有证书作为可能帮助叶子证书链接到可信根的提示不直接作为信任锚点。因为root-g1.crt存在roots/ 目录非空遗留 G1 应用可以正常走验证流程。TrustStoreMigrationTest见 TrustStoreMigrationTest.php对此做了显式约束断言roots/、intermediates/、crl/三个目录存在、roots/root-g1.crt与crl/legacy.crl存在、旧的扁平文件root.crt、intermediate.crl.pem已被移除并验证TrustStore至少加载到一个标记为g1的根。CrlProvider 的 CRL 获取策略G1 冻结、G2 三级降级OC\IntegrityCheck\Verifier\CrlProvider见 CrlProvider.php实现了 README 所描述的按代际区分 CRL 来源的逻辑getCurrentCrl(bool $isG1Chain)是入口G1 链$isG1Chain true跳过网络请求只读取捆绑的crl/legacy.crl冻结版本经CrlValidator::parseAndValidate校验签名后返回若捆绑 CRL 缺失或校验失败直接抛出CrlUnavailableExceptionNo valid G1 legacy CRL available。G2 链$isG1Chain false执行三级降级——先用CrlFetcher从网络获取VerifierConstants::CRL_URL指向的 CRL校验通过即返回网络失败或校验失败回退到捆绑的crl/developers.crl两者均不可用时fail-closed关闭式失败抛出CrlUnavailableExceptionNo valid CRL available (fetch and bundled both failed or invalid)。CRL 的远端地址定义在 VerifierConstants.phpCRL_URL https://owncloud.dev/developer-certificates/crl/developers.crl。该常量特意选择 owncloud.dev 而非 owncloud.github.io 路径——后者会 301 跳转而CrlFetcher不跟随重定向详见设计文档 §13。CrlProviderTest见 CrlProviderTest.php对这条降级链做了逐一验证testFetchedValidCrl覆盖网络 CRL 有效即采用testFallbackToBundledCrl覆盖fetch 返回 null 时回退捆绑 CRLtestFetchedInvalidFallbackToBundled覆盖网络 CRL 签名无效wrong-issuer时回退捆绑 CRLtestFailClosedNoCrl与testFailClosedExceptionReasonCode覆盖双源都不可用时抛CRL_UNAVAILABLE原因码testG1SkipsFetch则断言 G1 路径下CrlFetcher::fetch永远不会被调用。G1 过渡从扁平根迁移到roots/root-g1.crt生产环境的 ownCloud 10.x 生态此前依赖单一扁平信任锚点resources/codesigning/root.crt。README 明确指出该文件实际是G1 中间权威subject 为 ownCloud Code Signing Intermediate Authority它曾是遗留loadCA()验证器事实上的信任锚点。Task 13 将其迁移为roots/root-g1.crt目的是在建立新的多代际目录布局的同时保留遗留验证语义的完全一致性——使用 G1 证书签名的应用继续通过验证。迁移测试见 TrustStoreMigrationTest.php专门断言旧的扁平文件必须消失而非重复保留旧root.crt必须不存在已迁移至roots/root-g1.crt旧intermediate.crl.pem必须不存在已迁移至crl/legacy.crl。这保证了迁移是移动而非复制避免新旧两份文件在语义上产生分叉。遗留 G1 应用在过渡期与日落后的行为差异LegacyTransitionTest见 LegacyTransitionTest.php以参考时间注入的方式精确刻画了 G1 过渡期的行为矩阵与VerifierConstants::LEGACY_SUNSET 2026-12-31T23:59:59Z呼应场景参考时间期望行为过期 G1 日落前2026-06-01isLegacyWarntrue且isPassedtruewarnallow输出[LEGACY_ACCEPTED_WARN true]过期 G1 日落后2027-06-01抛出BadAlgorithmException算法门禁拒绝遗留算法硬性阻止过期 G1 但证书被吊销2026-06-01仍抛出RevokedException吊销检查优先于 warn过期 G1 但文件被篡改2026-06-01返回INVALID_HASHdiffisPassedfalse篡改绝不 warn未生效 G1now notBefore2019-01-01抛出BadChainException硬性阻止不进入 warn 分支无扩展、大写 CN 的遗留 G1 叶子2026-06-01完整管线通过isPassedtrue且非 legacy-warn保持旧验证器语义正常 G2 应用2026-07-12isPassedtrue、isLegacyWarnfalseG2 不受影响其中无扩展、大写 CN用例testLegacyG1ExtensionlessUppercaseCnPasses明确以resources/codesigning/core.crt与tests/data/integritycheck/SomeApp.crt的真实形态作为回归基准证明新验证器对旧格式叶子证书的向后兼容。G2 可用性真实 ceremony 产物与测试 PKI 的严格隔离README 强调 G2 代码签名已是live状态CA ceremony 已产生真实、离线持有的锚点并捆绑在仓库中roots/root-g2.crt—— G2 根锚点CN ownCloud Code Signing Root CA G2intermediates/intermediate-g2.crt—— G2 中间签发者crl/developers.crl—— G2 叶子吊销列表由 G2 中间签发。G2 在运行时能否通过验证取决于捆绑 CRL 能否用随附根证书验证通过而非目录槽位是否为空的静态条件。这些是真实的 ceremony 产物不是tests/data/integritycheck/verifier/pki/下的测试 PKI 证书。README 明确记录了一个安全教训Task 10把测试证书当作生产信任锚点下发是安全错误因此两套证书严格分离。VerifierTest等测试在临时 server root 中复制测试 PKI 与 CRL fixture如developers-empty.crl、developers-revoked.crl、intermediate-revoked.crl验证器在真实运行时路径上绝不清空此隔离。验证流程全景从验证器到信任库的调用链将上述组件串联起来ownCloud 的签名验证管线为Verifier::verify()接收签名文件signature.json、应用目录树与应用 ID依次经过ChainValidator借助TrustStore的根与中间线索构链、AlgorithmAllowlistG2 仅允许ecdsa-p384-sha384与rsa-pss-sha384见 VerifierConstants.php遗留rsa-pss-sha1仅限 G1 过渡期、ManifestVerifier用OnDiskHasher计算文件哈希比对清单、CrlProvider按代际获取并校验 CRL、AppIdResolver核对 CN 与应用 ID 一致与IntegrityDiffer。VerifierTest见 VerifierTest.php覆盖了完整链路的通过、篡改INVALID_HASH、叶子吊销RevokedException、中间吊销、坏签名BadSignatureException、CN 不匹配CnMismatchException与缺失签名MissingSignatureException等分支。参考与进一步阅读README 末尾给出的两条参考线索设计文档为 ownCloud G2 code-signing verifierdesign/core-g2-code-signing.md的 §2 与 §19涵盖链验证与 CRL 设计要点CA ceremony 材料位于 developer-certificates 仓库。在本文所讨论的代码库内可直接深入阅读的对照材料包括信任库加载实现 TrustStore.php、CRL 降级实现 CrlProvider.php、常量定义 VerifierConstants.php以及迁移合规测试 TrustStoreMigrationTest.php 与过渡期行为测试 LegacyTransitionTest.php。需要说明的是证书与 CRL 均为真实签名材料仅用于 ownCloud 服务端验证自身签名的应用包读者如需自行构建测试环境应使用tests/data/integritycheck/verifier/pki/下的测试 PKI 生成脚本如gen_g1_pki.sh、gen_g2_pki.sh、gen_crls.sh而不得将测试证书混入生产信任库。赞分享后端内容协同【免费下载链接】core:cloud: ownCloud web server core (Files, DAV, etc.)项目地址https://gitcode.com/gh_mirrors/core84/core点击查看免费下载相关推荐RabbitMQ 证书信任存储Certificate Trust Store插件深度指南白名单式 TLS 对端证书验证RabbitMQ 证书信任存储Certificate Trust Store插件深度指南白名单式 TLS 对端证书验证 本指南围绕 RabbitMQ 官方后端消息队列消息路由Asterinas数字签名代码签名与验证Asterinas数字签名代码签名与验证 概述 在当今数字化时代软件安全已成为系统开发的核心关注点。Asterinas作为一个用Rust编写的安全、快速、通操作系统内核驱动系统编程Zero Trust 架构深度解析从“信任但验证”到“永不信任始终验证”Zero Trust 架构深度解析从“信任但验证”到“永不信任始终验证” 导读 本文基于 Security 101 课程的第 1.5 课translat网络安全教程文档上一篇Artemis未来路线图探索下一代交互式学习平台下一篇突破QQ音乐加密限制qmcdump音频格式转换全攻略创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
