FIBEMATE 系列。本系列另一篇《密码学时间账本》解决「证据在何时存在」;这一篇回答一个更日常的问题:
ml_kem768这个符号是哪天进仓的?X3DH的实现被改过几次?某次审计说「我们 6 月就支持了 SM3」,怎么一句话证实或证伪?答案是 git 历史本身——只是要能查。工具已开源:crypto-time-machine(github.com/Lennonhaha/fibemate-tools,纯 Python 标准库)。
git 本身能回答一半问题:git log -S / -G(pickaxe)可以找「一个字符串何时进入或离开代码库」。问题在工程侧:
crypto-time-machine 做的事:把 git log -S/-G 包成 CLI,结果写进 SQLite 的时间轴表(sha、日期、作者、主题、涉及文件),可查、可导出、可复现。
参数五个关键位:
--pattern:追踪的符号或字符串(ml_kem768、X3DH、3329、sm3_compress……)。--mode=-S / --mode=-G:直通 git 的两种 pickaxe 语义——-S 统计出现次数变化,-G 按正则比对新旧 diff。两种模式回答的问题不同,都保留。--db:SQLite 输出路径。--since / --until / --query-after:时间窗。扫 fibemate 主仓(2026-09-27 实测):
ml_kem768,-S 模式:6 个事件——从 initial commit(db81c7f,2026-07-06,v3.1-preview 开源)到 2026-09-19 换用 @noble/post-quantum 参考实现(cba1915,#115),每个事件带完整 sha、时间戳、作者、主题。X3DH,-S 模式:69 个事件。sm3_compress,-G 模式:0 个事件——当前主仓没有这个符号的变更记录,查询本身就证伪了一句「我们改过 SM3 底层」。注意这些数字会随仓库增长而漂移——X3DH 一周前还是 67,现在是 69。时间轴是活数据,引用时给查询日期。
直通 git pickaxe,不自建索引。 -S 和 -G 的语义差异(出现次数 vs diff 内容)是 git 十几年打磨出来的,自己重写一遍只会引入分歧。工具的价值在结构化输出和时间窗,不在重新发明搜索。
SQLite 单表。 timeline(id, sha, date, author, subject, files)——六个字段,够画时间轴、够做审计附件、够被别的脚本 join。多一层抽象都不加。
test/local_test.py:10 项(文件历史非空、不存在符号返回空等),对主仓实测 ALL PASS。test/ci_test.py:9 项(query 返回列表、条目含 files 等),ALL PASS。time-machine-ci workflow,截至 2026-09-27 累计 51 次成功运行。json / os / re / sqlite3 / subprocess / datetime,全标准库。ctime/core.py 当前 168 行。kyber → ml_kem768)会表现为一消一长两个事件,不会自动合并。系列至此四条线:可观测性管运行时,TLA+ 管协议逻辑,时间账本管存证锚定,时间机器管历史查询。四条线共同的出发点:审计的人不该信任何一句口头断言——每句话都应该能变成一条可执行的查询。
工具页:fibemate.net/tools/time-machine。
参考实践
crypto-time-machine/(19 项测试 = 10 local + 9 ci,全 PASS,零外部依赖)ml_kem768 6 事件 / X3DH 69 事件 / sm3_compress 0 事件(2026-09-27 实测).github/workflows/time-machine-ci.yml(51 次 success)词汇注释
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。