密钥管理是一个日益增长的挑战,尤其是在人工智能代理兴起的情况下。虽然大型组织可以使用集中式密钥管理服务,但它们会增加运营复杂性。小型团队通常依赖 API 密钥,这本身就存在风险——容易泄露,有时会被敏感模型拒绝,并且即使在撤销后也容易被滥用。
核心问题并非针对代理*才出现*;API 密钥本身就过于强大。更好的方法是避免直接存储密钥。作者建议使用 HTTP 代理将密钥作为头部注入,从而有效地将密钥从配置文件和代码中移除。这适用于许多 API,例如 Stripe,通过内部服务管理密钥来路由请求。
exe.dev 通过提供“集成”来简化此过程——通过标签分配的云端管理的 HTTP 代理,自动应用于虚拟机。对于 GitHub 等服务,他们构建了一个专门的应用程序来处理 OAuth,从而消除了手动密钥轮换。这种方法以相对简单的形式提供了显著的安全价值,将密钥管理的负担转移到云提供商。
## DOS 网络与一个 34 年的漏洞
这篇文章详细描述了在设置 SLIP(串行线路互联网协议)连接——允许通过串行端口进行 TCP/IP 传输——在 DOS PC 和 Linux 之间时发现的一个数十年历史的漏洞。作者使用 EtherSLIP,一个模拟以太网连接的数据包驱动程序,来利用现有的 mTCP 程序。
测试发现了一个“检测到 NULL 赋值”错误,该错误是由 Open Watcom 编译器检测到的堆损坏引起的。调查发现问题在于 EtherSLIP 的 ARP(地址解析协议)处理中的一个错误的内存复制。EtherSLIP 模拟 ARP 响应,但一个编码错误错误地复制了数据,从而破坏了数据段中的内存。
该漏洞源于 ARP 响应创建过程中段寄存器操作位置的错误,导致数据被写入错误的内存位置。由于小型内存模型以及典型的 TCP/IP 协议栈中缺乏 ARP 标头验证等因素,该漏洞被掩盖了。
修复方法是删除错误的段寄存器移动。作者强调了解决编译器警告的重要性,以及旧系统中漏洞的惊人寿命,并赞扬 EtherSLIP 开发人员创建了在 34 年后仍然有用的代码。
## 追溯采样:一种新的分布式追踪方法
VictoriaMetrics 团队在 KubeCon Europe 2026 上展示了“追溯采样”,作为 OpenTelemetry 中传统“尾部采样”的一种更高效的替代方案。尾部采样通过缓冲 spans,并在收集到所有数据*之后*决定是否保留 trace 来减少 trace 数量,但这需要大量的内存和 CPU 资源。追溯采样可以大幅降低这些成本。
它不是缓冲完整的 spans,而是仅将必要的属性(trace ID、时间戳、状态码)发送到中央收集器进行初始采样决策。原始 span 数据在边缘代理上缓冲,只有在 trace 被采样时才会被检索。这最大限度地减少了网络流量、CPU 使用率和收集器内存占用。基准测试显示,与尾部采样相比,**出站流量减少了 70%,CPU/内存节省了 60-70%**。
进一步的优化包括在代理上使用磁盘 FIFO 队列进行缓冲,以及“本地 + 追溯”方法,其中代理根据易于获得的数据做出决策,从而减少收集器的负载。虽然不是完美的解决方案,但追溯采样为更具可扩展性和成本效益的分布式追踪提供了一条引人注目的途径,VictoriaMetrics 计划将其实现开源,用于 OpenTelemetry 和他们自己的代理 (vtagent)。