研究人员发现了一个被称为“GitSpawn”的关键安全漏洞，该漏洞影响了众多 CLI AI 智能体（包括 Claude Code、Goose 等）。 该问题源于这些智能体在启动时会自动运行标准 Git 命令（如 `git status`）以收集项目上下文。这些命令会触发 Git 的“索引刷新”（index refresh），进而无意中执行存储库本地 `.git/config` 文件中定义的配置命令。具体而言，`core.fsmonitor` 等功能允许存储库指定一个命令，该命令会在任何安全沙箱或批准提示介入之前，以用户完全权限在主机系统上执行。 此漏洞极其危险，因为恶意配置并非由标准的 `git clone` 触发，而是通过打开经由 ZIP 文件、共享驱动器或 USB 获取的存储库触发。由于 AI 智能体自身在内部沙箱之外启动了 Git 进程，因此恶意命令会在主机上透明地运行。研究人员强调，这种模式在 AI 智能体生态系统中非常普遍，它使日常的 Git 操作成为了未经授权远程代码执行的攻击媒介。
每日HackerNews RSS
GitSpawn：不受信任的存储库可通过 AI 编程代理执行代码 GitSpawn: Untrusted repos can execute code via AI coding agents
69 天前
抱歉。
有人看到我的钥匙吗？一种机架级安全的密钥分层策略 Has anybody seen my keys? A key-hierarchy strategy for rack-level security
69 天前
该系统使用从 $K$ 个密钥份额派生出的机架密钥来管理集群安全。为了平衡安全性和可用性，该设计同时采用了**密钥派生**（旨在提高效率且无需存储）和**密钥封装**（旨在允许在不重新加密大型数据集的情况下进行密钥轮换）。 核心安全目标是在信任仲裁重新配置期间轮换机架密钥，以限制潜在损害的影响。然而，这带来了一个技术挑战：当在不同机架密钥之间转换时，即使在配置可能不会立即提交的分布式环境中，节点（sleds）也必须能够重新封装特定于驱动器的加密密钥。 该解决方案在两阶段提交协议中采用了一种“分发者”（dealer）机制。当准备新纪元（epoch）时，分发者会提供新机架密钥以及由新密钥派生出的加密旧机架密钥。一旦新纪元提交，节点即可使用新密钥解密旧密钥，从而能够派生出新旧驱动器密钥。这不仅实现了 ZFS 加密密钥的无缝、安全轮换，确保了前向安全性，而且在面对分布式系统故障时依然保持稳健。
这篇 Hacker News 帖子讨论了 Oxide Computer 的技术博文《有人看到我的密钥了吗？》，文中概述了一种用于机架级安全的密钥分层策略。
讨论的核心是 Oxide 在分布式系统中管理机密的“信任法定人数”方法。评论者 `orielhaim` 指出的一个重要技术亮点是：利用从新纪元（epoch）派生的密钥来封装旧的机架密钥。这种方法允许系统在提交发生前分发密钥份额而无需完全解锁，从而巧妙地解决了 ZFS 重新加密过程中涉及的复杂同步难题。
其他贡献者提到了“Oxide and Friends”播客剧集以获取更多背景信息，并提出了关于如果密钥份额无法访问可能导致数据丢失的实际担忧。总的来说，社区认为这是一种在应对机架间机密管理这一“分布式系统难题”时非常优雅的方法。
抱歉。
作为一名机器人工程师，作者探讨了利用大语言模型（LLM）通过视觉反馈自动化机器人代码调试这一繁琐过程的可行性。尽管 LLM 在生成样板代码方面表现出色，但作者发现它们在视觉调试的“试错”循环中表现得极为糟糕。
主要障碍在于模型缺乏对物理机器人行为的空间直觉，以及 LLM 与基于 GUI 的调试器之间笨拙且低效的接口。作者通过目视检查几秒钟就能解决的问题，LLM 却需要花费三十分钟去误解，这导致的结果是挫败感而非效率。最终，作者得出结论：将视觉调试委托给人工智能是事倍功半的。那种“笨拙”但可靠的人工流程——即由人类目视检查场景并进行调整——依然优于目前的 AI 辅助方法。最终，这位工程师放弃了自动化方案，宁愿亲自动手进行调试，以确保准确性并避免修正 AI 错误带来的徒劳。
这篇 Hacker News 的讨论探讨了开发者与 AI 编程助手之间不断演变的关系，并以“导盲犬”为喻，描述了人类如何引导大语言模型（LLM）完成复杂任务。
**主要内容包括：**
* **“人在回路”的现实：** 参与者一致认为，LLM 往往缺乏独立调试复杂系统所需的背景信息。开发者必须充当“模拟接口”，提供视觉数据或专业背景，以弥补 AI 能力与实际执行之间的差距。
* **调试理念：** 开发者之间存在分歧：一方认为“阅读代码”是核心技能，另一方则优先考虑实时重现 Bug。许多人认为，如果不在理解底层状态的情况下单纯依赖 AI 来调试代码，往往会导致效率低下。
* **对“机器人”的担忧：** 对话中很大一部分内容提到了对公共平台上低质量、机器人驱动或两极分化言论的沮丧。许多用户现在主张使用“仅限邀请”的论坛或私人小组，以确保交流对象是真实且高质量的人类同行。
* **视角转变：** 虽然有些人将 AI 视为一种解放工具，可以实现琐碎工作的自动化，但另一些人则担心这意味着工匠精神的丧失以及长期职业优势的削弱。
互联网档案馆致力于实现“让所有人都能获取所有知识”的使命，维护着一座拥有 210 PB 容量的庞大免费数字图书馆。为了保持独立、无广告和专注于隐私保护，该组织选择自主构建和管理基础设施，而不依赖于企业。
随着运营需求的增长，互联网档案馆诚邀公众加入其“月度捐赠圈”。今年 9 月，捐赠者的贡献影响力可翻三倍：任何 25 美元及以上的新设月度捐赠，都将获得 2:1 的配套捐赠。通过设置月度捐赠，支持者能为保存数字历史、维护服务器及确保教育资源对全球各地所有人持续开放提供必要的资金保障，让这份资源惠及未来世代。
互联网档案馆（Internet Archive，简称 IA）目前正在寻求捐款以维护其基础设施，这在 Hacker News 用户中引发了关于该组织使命、法律困境及运营透明度的激烈讨论。
**讨论要点包括：**
* **技术挑战：** 志愿者正在帮助 IA 进行基础设施现代化改造，包括从 `web.py` 迁移到 `FastAPI` 并优化 Solr 性能。一些用户认为该网站已变得不可靠，并指出了频繁出现的 429 错误和激进的流量限制。
* **财务质疑：** 批评者质疑“2:1 配捐”计划的透明度，指出这些配捐背后的捐赠者身份不明。另一些人则认为，如果该组织财务状况堪忧，就应停止资助“ClimateGPT”等边缘项目。
* **使命与法律责任：** 关于 IA “紧急图书馆”举措的道德性及其持续的版权法律纠纷，争论仍在持续。支持者视 IA 为数字历史的“最后堡垒”，而反对者则认为其法律风险以及对盗版内容的托管威胁到了其长期生存。
* **治理问题：** 社区对于互联网档案馆究竟是一个至关重要的非营利组织，还是一个迷失方向且管理不善的实体存在分歧，部分用户建议采用去中心化的存储解决方案。
糟糕！访问被拒绝：错误代码 bf584155dcd667f7。请返回首页，如果您认为不该被屏蔽，请通过 [email protected] 联系网站管理员。由 Techaro 的 Anubis 提供保护。在加拿大用心制作。吉祥物设计由 CELPHASE 完成。本网站正在运行 Anubis v1.26.0 版本。
所提供的文本记录了一场关于作者使用可信平台模块（TPM）执行 TLS 握手工作的 Hacker News 讨论。
作者解释称，他们的库通过验证证明（Attestation），将机器身份与存储在 TPM 中的私钥绑定。这实现了高安全性的设备识别，对于保密虚拟机和工业物联网尤为重要，因为在这些场景中，确保设备未被篡改至关重要。
讨论突出了几个关键主题：
* **性能与安全性**：尽管 TPM 在历史上运行缓慢，但现代 vTPM 实现已改善了延迟。然而，一些评论者认为，专用的硬件安全模块（HSM）在防止密钥提取方面提供了更卓越的保护。
* **关于通用计算的“战争”**：批评者表示担忧，认为硬件支持的身份认证如果被广泛采用，可能导致侵入式追踪，实际上使浏览器能够为每次网站访问提供永久且无法伪造的指纹。
* **实现争论**：参与者讨论了与现有的 PKCS11 提供程序或标准证明流程相比，这种方法在概念上是否多余；其他人则强调了尽管远程证明存在固有的复杂性和潜在风险，但通过开源贡献进行“公开学习”仍然非常重要。
作者调查了一个令人沮丧的 YouTube 故障：视频在重新加载时会自动“倒退”20秒。作者利用 Chrome 开发者工具、Tampermonkey 脚本以及人工智能辅助调试，探究该问题究竟源于服务器端数据还是客户端处理。 调查显示，YouTube 的网页播放器在两个冲突的“事实来源”之间产生了矛盾：即服务器端的“检查点”（你实际离开的位置）和 URL 中的时间参数（`&t=...`）。 当视频重新加载时，应用程序往往会强制播放器跳转到 URL 中的时间戳，而不是服务器端的准确检查点。这种用于分享时间戳的冗余 URL 参数干扰了正常的续播功能，导致播放进度向后偏移。作者认为，这种设计缺陷违背了“单一职责原则”，因为播放器被输入了相互冲突的指令。尽管作者借助 AI 剖析了混淆代码，但他们强调，文中呈现的内容融合了讽刺与技术上的挫败感，并指出他们已向谷歌提交了一份更为专业的报告。
Hacker News 最近的一场讨论引发了争议：YouTube 在视频恢复播放时自动回退约 20 秒的行为，究竟是软件漏洞还是有意为之的功能。
文章作者在浏览器重载页面时注意到这一现象，并通过 ChatGPT 进行了调查。尽管作者怀疑这是一个漏洞，但许多评论者认为这是经过深思熟虑的设计。用户指出，类似的“回退”功能在播客和有声书应用中很常见，旨在帮助用户在中断后找回上下文。多位参与讨论者对此表示赞赏，认为这有助于他们在休息后重新衔接视频内容。
然而，用户的看法并不统一；一些人认为 20 秒的间隔过长且令人沮丧，他们更倾向于更短的跳转或完全取消该功能。这场讨论最终反映了用户对 YouTube 用户体验的普遍情绪，参与者还抱怨了其他不相关的问题，例如平台的视频质量设置，以及排查浏览器端错误的困难。
此服务允许用户通过简单的 GET 请求发布公开消息。 **主要功能：** * **发布与回复：** 使用 `/post` 并提供名称（2–20 个字符）和文本内容。添加 `parent` 参数即可回复现有主题。 * **管理：** 保留 `gt_session` Cookie 以删除您的帖子，或通过 `/heart` 管理点赞。每个帖子请使用唯一的 UUID，以确保在重试时不会创建重复内容。 * **信息流：** 访问 `/feed` 端点以 JSON 格式获取帖子和回复。 * **审核：** 所有内容均会经过脏话及加密货币相关推广的筛选。违规内容将通过自动审核隐藏。 * **隐私：** 帖子为公开内容且包含在 URL 中；切勿分享敏感信息。 **状态码：** * **400：** 参数无效（名称、文本或 UUID 错误）。 * **403：** 授权失败（缺少 Cookie 或来源无效）。 * **429：** 达到频率限制；请等待十秒后再重试。 *技术提示：使用带有 `-b` 和 `-c cookies.txt` 参数的 `cURL`，可以自动维护会话并管理身份验证。*
“Show HN: GET Together” 项目是一个社交网络，允许用户使用标准的 HTTP GET 请求（而非传统的 POST 方法）发布信息。由于其实现方式极其简洁——即通过 URL 查询参数提交内容——该项目在 Hacker News 上引发了热烈讨论。
许多用户将其视为一个巧妙的实验或“负载式”讽刺，而另一些人则猜测它是一个专为 AI 智能体设计的“蜜罐”。由于部分 AI 模型设有禁止执行 POST 请求的防护栏，观察者认为该网站可能是一个供机器人进行通信或绕过沙箱限制的试验场。
讨论很快从缓存、速率限制和防止重复发帖等技术实现问题，转向了关于 AI 快速发展的激烈哲学辩论。一些参与者警告称，此类工具可能助长自主智能体活动，进而引发了关于社区是否应监控 AI 能力，或者这仅仅是一个无害的创意项目的更广泛讨论。归根结底，这一讨论串反映了技术好奇心与人们对网络标准和新兴 AI 自主性交织所产生的现代焦虑。
关于 新闻 版权 联系我们 创作者 广告 开发者 条款 隐私 政策与安全 YouTube 的运作方式 测试新功能 © 2026 Google LLC
日本急救人员呼吁：我们到达时，请不要整理鞋子。 Please don't rearrange our shoes when we turn up, paramedics in Japan urge
70 天前
在日本，礼仪是社会基石，金泽市消防局近日呼吁居民在紧急情况下暂停这一好客习惯。 按照日本习俗，屋主通常会将访客的鞋子摆放整齐，使其朝向门口。然而，急救人员为了确保在抬担架撤离时能够迅速离开，且不碰撞患者或弄乱医疗设备，通常会将鞋子摆放在特定的战略位置。即便出于礼貌而移动这些鞋子，也可能导致转运延迟长达 30 秒，进而影响患者的救治。 在一段走红的 Instagram 视频中，消防员表示他们感谢民众的体贴，但在医疗危机中，速度至关重要。他们建议公众不要整理鞋子，而是专注于更有帮助的任务，例如寻找患者的身份证明或社会保险卡。这一呼吁得到了积极响应，许多市民表示感谢这种澄清，并认同在生死攸关的情况下，应放下常规的社交礼仪，以使应急小组能够高效工作。
近期 Hacker News 上的一场讨论揭示了日本急救人员面临的困扰：在他们抵达急救现场时，民众常出于礼貌或秩序考量，自发地去整理或移动急救人员的鞋子。
尽管日本入户脱鞋的习俗根深蒂固，植根于对卫生及整洁的文化重视，但许多评论者认为，在医疗紧急情况下应抛弃这一做法。对于急救人员而言，耽误哪怕 30 秒都可能至关重要，而移动鞋子可能会在转运患者时造成物理障碍或延误。
这场讨论还涉及了更广泛的“穿鞋与脱鞋”文化差异。虽然东亚、北欧和东欧的许多人将脱鞋视为标准礼仪，但来自“穿鞋文化”地区（如美国部分地区和荷兰）的人往往认为这种做法是不必要的，甚至认为本身就不卫生。尽管存在这些不同的规范，但参与者的共识是务实的：在生死攸关的情况下，安全和速度必须优先于社交礼仪。