docker.dockercraft 仓库中的 Certificate Transparency：CT Log 构建、测试与部署运维完整指南

开发者工具【免费下载链接】docker.dockercraftDocker Minecraft Dockercraft项目地址https://gitcode.com/gh_mirrors/do/docker.dockercraft点击查看免费下载本文以 docker.dockercraft 仓库 vendor 树中随 Docker 依赖快照归档的 google/certificate-transparency README 为核心系统讲解 Certificate TransparencyCT技术体系CT Log 服务器的功能边界、基于 gclient GNU make 的构建流程、完整依赖清单、构建问题排查、测试方法以及分布式部署与运维要点。读完本文你将掌握从零构建一套 CT 软件并跑通自测的完整路径并理解 SCT、STH、Merkle 树、etcd 集群等核心概念在源码与数据模型中的落点。Certificate Transparency 是什么为 TLS 证书提供公开审计Certificate Transparency证书透明度CT的核心目标是解决 TLS 证书体系签发即信任的盲区当 CA证书颁发机构签发证书时公众无从知晓一旦 CA 被攻破或误发证书恶意证书可以在数月内不被察觉地投入使用。CT 通过一套公开、可追加、可审计的日志系统把每一张证书的签发记录暴露给所有人检查从而让异常签发被及时暴露。该 README 明确了本开源仓库覆盖的四大功能领域开源的分布式 CT Log 服务器实现其中还包含一个只读的mirror 服务器镜像日志用于仿效远端另一个 Log 的内容管理、维护该 Log 所需的辅助工具。多种编程语言的客户端工具与库用于与 CT Log 交互。一个实验性 DNS 服务器以 DNS 记录的形式返回 CT 证明。一个实验性的通用 Loggeneral Log允许记录任意数据而不仅是 TLS 证书。支持平台与版本前提README 明确列出的受支持平台如下平台说明Linux在 Ubuntu 14.04 上验证通过Fedora 22、CentOS 7 等其他发行版可能需要调整编译器选项OS X版本 10.10FreeBSD版本 10.*需要特别说明的是本仓库docker.dockercraft中只归档了该项目的部分文件README、README-MacOS、LICENSE、proto/ct.proto、cpp/version.h 及cpp/third_party下的少量第三方代码。从目录结构看它位于 vendor/github.com/docker/docker/vendor/ 之下属于随 Docker 源码一并归档的依赖快照仓库内检索也仅命中该 README 自身可推断此副本并未被 dockercraft 运行时直接调用。因此下文涉及的完整构建流程面向上游 CT 项目的完整源码树你在本仓库中能直接研读的是其协议数据模型与文档详见后文各节。快速开始用 gclient 与 GNU make 完成构建与自测CT 项目官方推荐的构建方式依赖 Chromium 项目的gclient来自 depot_tools由它负责拉取并构建 CT Log 所需的其他软件依赖。前置条件是构建机已装齐 构建依赖随后执行以下命令原文命令逐行注释export CXXclang CCclang # 统一使用 clang 作为 C/C 编译器 mkdir ct # 或任何你喜欢的目录 cd ct # 生成 gclient 配置以 certificate-transparency 为目录名拉取上游源码 gclient config --namecertificate-transparency https://github.com/google/certificate-transparency.git gclient sync # 拉取并构建全部依赖 # 若你的平台将 make 称为 gmake/gnumake请相应替换 make -C certificate-transparency check # 构建 CT 软件并运行自测命令要点说明CXXclang CCclang确保整个构建链使用 Clang 编译器这是该代码库的默认工具链构建依赖要求 clang 3.4。gclient config生成的是顶层.gclient配置gclient sync才是真正触发拉取依赖 构建依赖 配置 CT 构建的步骤。make -C certificate-transparency check中的check目标同时完成构建与自测是验证环境是否就绪的最快方式。代码布局按语言组织的源码目录README 指出该项目源码大体按实现语言组织在cpp、go、java、python四个子目录中。关键子目录及职责如下完整继承原文分布式 CT Log 本体cpp/log分布式 CT Log 主实现cpp/merkletreeMerkle 树实现cpp/server服务器实现的顶层代码cpp/monitoring导出 CT Log 运行期统计指标的代码。CT mirror Log 实现额外使用cpp/fetcher从另一个 Log 拉取条目的代码。访问 CT Log 实例的客户端代码cpp/clientC 版 CT Log 客户端go/clientGo 版客户端python/ctPython 版客户端java/src/org/certificatetransparency/ctlogJava 版客户端。其他工具go/fixchain修正证书链的工具go/gossip基于 gossip 协议同步证书信息的代码go/scannerCT Log 扫描工具go/merkletreeGo 版 Merkle 树实现。对照本仓库的 vendored 副本可以看到归档时保留了 cpp/version.h声明了cert_trans::kBuildVersion构建版本符号、proto/ct.proto协议数据模型以及cpp/third_party/curl/hostcheck.c、cpp/third_party/isec_partners/openssl_hostname_validation.cTLS 主机名校验的第三方实现。可以推断vendoring 依赖时只裁剪保留了构建产物所必需的头文件、协议定义与第三方补丁源码完整的 cpp/go/java/python 实现树仍需按上文流程从上游获取。构建体系依赖管理与静态链接策略构建策略本地副本 静态链接README 对构建策略给出两条明确建议使用依赖的本地副本而非系统安装包以避免版本不兼容将依赖库静态链接进 CT 二进制而非依赖部署环境中可能不同的动态库。为此官方支持的构建系统采用 Chromium 的gclient工具以保证可靠、可复现的构建。在顶层目录内gclient 依次完成为每个依赖生成子目录为 CT Log 代码本身生成子目录构建全部依赖将构建产物安装到本地install/子目录配置 CT 构建引用这些已构建的依赖。这一过程由两部分配置驱动顶层DEPS文件配置各依赖源码的位置与版本并挂钩hook后续构建动作build/子目录下的 makefile管辖每个依赖的构建流程确保静态库被构建、且安装到本地install/目录供 CT 代码使用。DEPS 与 build/ 均属于上游源码树未随本仓库 vendored。构建依赖工具链清单构建 CT 软件及其依赖所需的本机工具如下工具版本要求用途depot_tools—提供 gclientautoconf / automake—经典构建工具链libtool—库构建工具shtool—构建辅助工具clang 3.4默认 C 编译器cmake v3.1.2部分依赖的构建系统git—拉取源码GNU make—驱动构建部分平台称 gmake/gnumakeTcl—依赖构建所需pkg-config—依赖发现Python 2.7—构建脚本在 Debian 系系统上对应的安装包为apt-get install autoconf automake libtool shtool cmake clang git make tcl pkg-config python2.7软件依赖清单CT Log 主代码库使用的第三方软件依赖可分为四类Google 实用库gflags命令行参数处理glog日志基础设施同时需要 libunwindGoogle MockC 测试框架mock 框架Google TestC 测试框架Protocol Buffers语言无关的数据序列化库tcmalloc面向多线程优化的高效malloc替代实现。其他实用库libevent事件处理库libevhtplibevent 的 HTTP 服务器插件/替代json-cJSON 处理库libunwind生成栈回溯stack trace的库。密码学库通过SSL构建变量二选一OpenSSL默认密码学库BoringSSLGoogle 维护的 OpenSSL fork。数据存储默认且强烈推荐使用 LevelDBLevelDB快速键值存储依赖 Snappy 压缩库SQLite基于文件的 SQL 库。实验性项目额外依赖实验性 CT DNS 服务器依赖 ldnsDNS 库含依赖 OpenSSL 的 DNSSEC 功能实验性 general Log 依赖 objecthash语言/编码无关的对象哈希工具与 ICUUnicode 库用于规范化对象中的国际化文本。源码级佐证proto 数据模型与第三方 C 代码Protocol Buffers 在项目中的实际角色可以从本仓库保留的 proto/ct.proto 中直接印证。该文件开头即注明这些 protocol buffer 应与 I-D互联网草案保持对齐并定义了 CT 协议的核心消息DigitallySigned数字签名结构枚举了 MD5、SHA1、SHA224、SHA256、SHA384、SHA512 哈希算法与 RSA、DSA、ECDSA 签名算法LogEntryType日志条目类型包括X509_ENTRY、PRECERT_ENTRY、PRECERT_ENTRY_V2以及实验性的X_JSON_ENTRY源码注释明确Experimental, dont rely on this!SignedCertificateTimestampSCT包含版本、LogID、自 1970-01-01 起的 UTC 毫秒时间戳与数字签名是 Log 签发给证书的签名证书时间戳SignedTreeHeadSTH包含 tree_size、sha256_root_hash 与签名是 Log 当前树头状态的签名快照MerkleTreeLeaf被哈希进 Merkle 树叶子的内容MerkleAuditProof审计证明含 tree_size、leaf_index、path_node 路径节点与 tree_head_signature。这些消息与 README 提到的Protocol Buffers 语言无关序列化库依赖一一对应CT 客户端拿到 SCT、Log 对外发布 STH、审计方验证 Merkle 包含性证明全部建立在 proto 定义之上。此外cpp/third_party下的curl/hostcheck.c与isec_partners/openssl_hostname_validation.c表明项目在 TLS 连接校验如 mirror 拉取远端 Log 时验证主机名中内嵌了第三方实现。构建问题排查编译器警告与 -WerrorCT 的 C 代码库以 Clang 的-Werror标志构建从而保证代码库始终零警告。但副作用是使用更新/不同版本的 C 编译器时任何新产生的警告都会被当作错误导致构建失败。修复办法是向CXXFLAGS追加对应的-Wno-error警告名选项例如# 处理 unused variable 类错误 CXXFLAGS-O2 -Wno-errorunused-variable gclient sync # 若 glog 头文件中的 unused typedef 报错可叠加该选项 CXXFLAGS-O2 -Wno-errorunused-variable -Wno-errorunused-local-typedefs gclient sync注意修改CXXFLAGS后更稳妥的做法是删除现有构建目录以免部分依赖未被正确识别而重新构建若问题仍然存在请检查certificate-transparency目录下的 Makefile 是否包含了你传入的选项。分支构建如果你要从 CT 仓库的某个分支克隆代码需将上文快速开始中的gclient config命令替换为branch替换为目标分支名gclient config --namecertificate-transparency https://github.com/google/certificate-transparency.gitbranch切换 BoringSSL可用 BoringSSL 取代 OpenSSL注意实验性 CT DNS 服务器不支持此配置。在gclient config ...完成之后、gclient sync之前修改顶层.gclient加入custom_vars: { ssl_impl: boringssl } },然后继续执行gclient sync即可。测试单元测试与日志选项CT 代码的单元测试通过certificate-transparency/Makefile的make check目标运行。关于测试与日志README 给出如下要点多个测试会在磁盘上写文件临时 testdata 的默认目录是/tmp可通过为 make 设置TMPDIRtmpdir更改端到端测试还会在test/tmp中创建临时证书与服务器文件成功的测试运行结束后这些文件会被自动清理日志选项参见 glog 文档默认情况下单元测试只向 stderr 输出且仅输出 FATAL 级别即会导致程序异常终止的消息你可以用命令行参数覆盖这些默认值。部署一个分布式 CT Log前面的构建流程产出的是一批可执行文件但要搭建一套正在运行、对外提供服务的 CT Log还需要额外组件与配置。README 给出的架构要点如下在 CT Log 实例前方需要一组充当HTTPS 终结器terminator与负载均衡器的 Web 服务器还需要一组etcd 集群为 CT Log 实例提供复制与同步服务。原文此节配有一张系统架构图SystemDiagram.png该图属于上游文档未随本仓库 vendored此处以文字还原其要点。关于生产级分布式 Log 的配置与搭建细节上游项目在独立的 Deployment 文档中展开而这一架构在代码层面的落点可以从本仓库的 proto/ct.proto 中得到印证ClusterNodeState记录单个节点的node_id、newest_sth最新树头、current_serving_sth当前服务树头以及供其他节点联系本节点的hostname与log_port—— 源码注释明确说明这些字段主要用于复制ClusterControlaccept_new_entries控制节点是否接受新条目ClusterConfig定义集群如何选出当前服务的 STH包括minimum_serving_nodes一个 STH 至少须复制到多少个节点才能成为候选、minimum_serving_fraction可服务某 STH 的最小节点比例用于配置容量冗余以及etcd_reject_add_pending_threshold默认 30000当 etcd 一致性存储中待处理条目超过该值时Log 服务器拒绝add-[pre-]chain调用以自我保护。从这些字段可以清晰推断etcd 承担着节点状态协调与日志复制的基础设施角色而集群 STH 的最新且最大、且满足冗余约束的选举逻辑正是分布式 CT Log 高可用设计的核心。运维一个 CT LogREADME 强调运营一个成功且受信任的 certificate transparency Log远不止部署一组二进制程序。上游项目将运维建议单独成文而本仓库恰好保留了与其运维实践直接相关的 README-MacOS.md其中的信任根证书处理是所有平台运维都会遇到的问题CT 代码需要一组受信任的根证书用于两件事校验出站 HTTPS 连接对 Log 服务器而言决定是否接受某个证书链纳入日志。在 OS X 上系统自带的旧版 OpenSSL 会在链校验失败时截获并用系统钥匙串中的根重试而 CT 使用的更新且未打此补丁OpenSSL 不支持该行为因此必须提供一个包含受信任根证书的 PEM 文件。落地方式如下处理入站 inclusion 请求仅 ct-server设置--trusted_cert_file标志指向包含其链可被接受入 Log的根证书集合的 PEM 文件路径校验出站 HTTPS 连接ct-mirror设置--trusted_roots_certs标志或设置SSL_CERT_FILE环境变量指向用于校验出站连接的根证书 PEM 文件。如果需要从 OS X 钥匙串导出系统根证书用于开发/测试README-MacOS 给出了如下命令原文完整保留security find-certificates -a -p /Library/Keychains/System.keychain certs.pem security find-certificates -a -p /System/Library/Keychains/SystemRootCertificates.keychain certs.pem这两个标志分别对应 CT 服务器接收证书提交与 mirror 服务器拉取远端 Log两条路径与 proto/ct.proto 中 X509ChainEntryleaf 证书 到信任根的证书链等消息模型相互呼应信任根集合决定了哪些链可以被接受、哪些出站连接可以被信任是运维策略的直接体现。小结该文档在 docker.dockercraft 仓库中的定位在 docker.dockercraft 仓库中这份 README 位于 vendor/github.com/docker/docker/vendor/github.com/google/certificate-transparency/ 路径下是随 Docker 依赖快照一并归档的第三方项目副本。仓库内仅保留了该项目的文档、协议定义proto/ct.proto与少量第三方源码dockercraft 自身的 Lua/Go 代码未引用其中符号因此它更适合作为研究 CT 协议与工程实践的第一手文档而非运行时依赖。对开发者而言这份 README 的价值在于它用最精炼的方式串联起了 CT Log 从为什么需要TLS 证书审计到如何构建gclient make、如何测试make check TMPDIR、如何部署HTTPS 终结器 etcd 集群、如何运维信任根证书策略的完整链路而本仓库保留的 ct.proto 则提供了阅读其协议实现的最佳入口——从 SCT、STH、MerkleTreeLeaf 到 ClusterConfigCT 协议的核心数据模型尽在其中。赞分享开发者工具【免费下载链接】docker.dockercraftDocker Minecraft Dockercraft项目地址https://gitcode.com/gh_mirrors/do/docker.dockercraft点击查看免费下载相关推荐在 Windows 上构建与运行 CoreCLR 测试runtime 仓库 src\tests 完整实战指南在 Windows 上构建与运行 CoreCLR 测试runtime 仓库 src\tests 完整实战指南 导读 本文聚焦 .NET runtime 仓库语言运行时标准库JIT编译编译器Emscripten 仓库中的 LLVM libcWindows 平台完整构建与测试实战指南Emscripten 仓库中的 LLVM libcWindows 平台完整构建与测试实战指南 LLVM libc 是 LLVM 项目为 C 标准库提供的独立实编译器WebAssembly开发工具构建工具在 MNN 仓库中使用 FlatBuffers JavaScript 库读取、构建与测试完整指南在 MNN 仓库中使用 FlatBuffers JavaScript 库读取、构建与测试完整指南 导读 本指南以 MNN 仓库内 3rd_party/flat人工智能大模型推理引擎深度学习本地部署模型量化模型优化多模态计算机视觉嵌入式上一篇QQ空间历史数据备份用开源工具永久保存你的青春记忆下一篇Llama-3.1-8B-Instruct量化模型使用教程5步实现高效推理创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考