笔记
0工具
0此页用于记录用户反馈问题后的每一次改进
关于
“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
不想公开、只想临时给人看：点“分享”生成一条带密码和有效期的链接，到期自动失效，你也能随时撤销。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
漏洞传闻即攻击：AI 时代开源安全响应的范式崩塌
一句话概括：AI 驱动的漏洞利用已让"漏洞传闻"成为攻击起点，开源安全响应必须从保密转向持续修复与信任网络。
引言：一次安全修复引发的"探针风暴"
2026 年，OCaml 生态的知名 HTTP 库 cohttp 维护者 Anil Madhavapeddy 发布了一个针对路径遍历（path traversal）漏洞的安全修复版本 6.3.0。按传统流程，这本应是一个低调的私密修复：先私下通知受影响用户，再发布公开公告。然而，这次他遭遇了截然不同的现实——在公开修复 PR 后的几分钟内，他的个人网站服务器日志中就出现了针对该漏洞模式的精确探测流量。
更令人不安的是，Anil 自己测试后发现：只需大致知道漏洞类别（例如"路径规范化问题"），他就能让自己的 AI 代理在本地复现并利用该漏洞，整个过程不到一分钟。这意味着，在公开补丁发布之前，攻击者完全有能力利用同样的 AI 手段提前数天甚至数周发起攻击。
核心结论： 在 AI 代理时代，"漏洞传闻"本身就构成了可利用的攻击情报。开源社区必须彻底重新思考安全响应流程。
时间线压缩：现代安全报告的真实节奏
事件本身的时间线
漏洞来源：该漏洞由 Jane Street 通过 Slack 私密渠道报告，最初由 Anthropic 的 Claude Fable 模型发现。这本身就压缩了传统漏洞发现的周期——AI 已经能主动审计代码并发现安全缺陷。
Anil 的自我验证：在正式修复前，Anil 将自己的 Claude 代理指向受影响代码，要求它调查"路径规范化"问题。Claude Fable 因安全限制拒绝了请求（他无法访问 Project Glasswing 的模型），但 DeepSeek V4 Pro 却欣然执行，并独立发现了多个相关问题。他的代理还在不到一分钟内轻松创建了一个针对本地服务器的可利用漏洞。
公开修复的代价：在与报告者讨论修复方案后，Anil 在 GitHub 上公开了
cohttp#1145PR 以获取更多审查。大约十分钟后，他的网站就开始收到针对百分号编码遍历序列（percent-encoded traversal sequences）的探测流量。这明确表明：有自动化监控系统正在实时跟踪公开代码仓库的变更。攻击窗口的量化：如果 Anil 自己用 AI 生成漏洞只需 1 分钟，那么公开 PR 后 10 分钟才出现自动探测，反而显得"迟钝"。一个决心坚定的攻击者，通过监控包仓库的提交，完全可以在数秒内完成漏洞利用。
行业数据：利用先于补丁已成常态
Anil 引用了 Fang 等人的研究：当给定 CVE 描述时，GPT-4 代理能在 15 个漏洞基准中成功利用 87%；而没有描述时，利用率骤降至 7%。这说明 AI 代理只需要一个"大致方向"就能自主完成漏洞挖掘与利用。
更关键的是 "平均利用时间"（Mean Time to Exploit） 的统计：
- 2018-2019 年：约 63 天（补丁发布后攻击者才跟进）
- 2024 年：跨越零点（利用时间与补丁时间持平）
- 2026 年：-7 天（利用先于补丁发布）
其他案例佐证了这一趋势：
- marimo 的 CVE-2026-39987：从公告发布到首次利用尝试仅 9 小时，且当时没有任何公开 PoC。
- Langflow 的 CVE-2026-33017：耗时 20 小时。
Anil 评论道："我们似乎已经跨过了自动漏洞生成的卢比孔河。"
Bugonomics：开源维护者的处境恶化
2026 年 5 月的一篇论文（Pesoli et al., Demystifying the Mythos or Disrupting Bugonomics）提出了 "bugonomics" 一词，指出瓶颈已从"漏洞发现"转移到"防御者修复吞吐量"。LLM 正在轻松生成漏洞利用代码，但维护者的验证、分类和发布速度并未同步提升。
Anil 作为 OSS 维护者的亲身体验与此完全吻合：
问题不在于前沿模型、开放权重模型或程序分析哪个"获胜"。问题在于如何编排它们，使稀缺的验证、优先级排序和发布能力用于持久修复，而非机械的搜索和报告起草。
防御者的核心机会在于技术债务修复：基于语义、经工具验证、模型辅助的工作流，帮助维护者在它们成为明天的被利用漏洞之前，发现、验证、排序并修复安全相关缺陷。
为什么维护者能力停滞不前？
模型访问不平等：Anil 指出，西方前沿模型（如 Claude Fable）有安全限制，商业可用版本无法用于此类安全研究。Project Glasswing 已扩展到 15 个国家的 150 个组织（包括关键基础设施运营商、云和金融提供商、Linux 基金会），但"夫妻店"级别的独立维护者仍被排除在外。Anil 坦言，2026 年 4 月他对此还持矛盾态度，但现在看来"这显然非常糟糕"。
修复工程本身的复杂性：一个不引入回归（regression）的安全补丁，本质上比生成一个漏洞利用代码要困难得多。AI 可以无限尝试生成攻击代码，但维护者必须保证修复的正确性、兼容性和长期稳定性。
应对策略：从保密到持续修复
Anil 提出了两条主要应对路径，并坦诚分析了各自的局限性。
策略一：超级私密的补丁开发
理论上，GitHub 的"临时私有分支"（temporary private forks）可以隔离修复过程。但实际效果不佳：
- CI 不可用：GitHub 出于安全考虑，禁止临时私有分支访问 CI 集成，这直接切断了维护者最依赖的自动化测试反馈循环。
- PR 限制：每个分支只能合并一个 PR，对于跨多个仓库的复杂问题（如 OCaml 生态中常见的依赖链）完全不适用。
- 审查者管理繁琐：审查者需要管理员逐一添加，而开源社区的审查者往往是"路过式"参与（尤其在欧洲 8 月假期期间，人员更难凑齐）。
更根本的问题在于：补丁保密不是关键，信息定向传递才是。Anil 强调，真正需要的是确保漏洞描述只到达"正确的人"手中，而不泄露给攻击者。当前 OSS 的讨论基础设施高度碎片化：有端到端加密的 Matrix，也有极度容易泄露的 Discord 和 Slack。他呼吁建立某种 "信任网络"（web-of-trust），在特定项目上下文中区分好人与坏人。
策略二：放弃保密，持续发布
另一种思路是彻底放弃保密假设：快速公开修复、持续发布、用自动化改善发布路径。
- Chrome 的范例：Google 已实现每周安全更新、每周两次发布（！），并通过动态补丁（将后台进程替换为更新二进制文件）实现无需重启的修复。Anil 提到，自己在 15 年前研究过将 Ksplice（Linux 内核热补丁）集成到 Xen，这并非全新概念。
- Linux 内核的做法：一旦修复就立即发布，不等待固定周期。
但 Anil 也承认，这种模式对 Docker 或 OCaml 这类项目并不完全适用：维护者不控制最终部署端点。Docker Desktop 可以强制更新，但下游发行版（如 Debian、Homebrew）会按自己的节奏和条款重新打包 OSS。对于小型项目，用户可能运行的是数月甚至数年前的旧版本，持续发布无法覆盖所有用户。
结论：开源安全需要根本性变革
Anil 的最终观点是：
传统安全保密流程（embargo）已失效。AI 代理只需要一个模糊的方向（一个邮件列表问题、一个孤立分支中的奇怪提交、一次上下文泄露）就能自主完成漏洞挖掘。
防御者必须转向"以 AI 对抗 AI"。维护者需要访问同等能力的前沿模型，否则将永远处于劣势。Project Glasswing 的扩展方向正确，但覆盖面远远不够。
发布流程必须自动化优先。从补丁生成、回归测试到发布签名，每个环节都应尽可能由工具辅助，释放维护者的认知带宽用于更高层次的决策。
信任网络是必要基础设施。在开源世界建立可验证的身份和权限机制，让敏感信息只流向可信的维护者和审查者。
正如 Anil 所说："我们显然需要相当快地适应。我不认为当前的手动分类流程应该消失，但自从 Fable 出现以来，我看到了不可持续的活动激增。我们才刚刚开始理解有多少传入的洪流是机器生成的，但显然数量巨大。"
开源安全不再是一场"修补漏洞"的竞赛，而是一场"修复速度 vs 利用速度"的军备竞赛。而目前，利用方正以压倒性优势领先。