Amp 对业界将“拉取请求”（PR）作为 SOC 2 合规标准提出了挑战。他们认为，审计人员更看重风险管理，而非特定的工作流程。通过关注合规的核心要求——即对变更进行授权、测试和记录，Amp 在没有使用 PR 的情况下，通过限制推送权限、强制提交签名以及自动化 CI/CD 流水线，依然维持了合规性。 Amp 不依赖强制性的人工代码审查，而是确保每一项变更都经过安全和基础设施检查，并留存将代码提交与项目讨论相关联的审计追踪。这种经过深思熟虑的高信任流程，使团队能够持续交付并保持敏捷。 Amp 承认，虽然他们的“直接推送到主分支”方案适用于当前的小型团队，但未必适用于所有规模。不过，他们认为各类企业都应重新审视自身的流程。企业不应默认采用为最高风险系统设计的“一刀切”式 PR 流程，而应评估每个项目的具体风险，并设计针对性的管控措施。归根结底，SOC 2 合规的本质在于证明你了解并能够降低风险，而拉取请求仅仅是实现这一目标的方式之一。
每日HackerNews RSS
Hacker News 上题为“那不符合 SOC 2 标准”的讨论，凸显了企业合规（特别是 SOC 2）与软件工程进度之间充满争议的矛盾。
许多贡献者批评正式的变更咨询委员会（CAB）和强制性的合规表演，指出它们往往会造成官僚瓶颈，助长“批量处理”高风险发布，并挫伤员工士气。几位评论者认为，这些流程往往只是流于形式，将文档工作置于实际安全之上。
相反，持怀疑态度的人警告称，为了追求“高信任”环境而放弃严格管控，会招致挪用公款或恶意内部威胁等重大风险。他们认为，如果这些控制措施可以轻易被绕过，仅依靠测试或同行评审是不够的。
归根结底，该讨论反映了行业中一个普遍的困境：如何在不抑制生产力的前提下，实施有效的安全与监管。尽管有人主张用自动化的产物证明或结对编程来替代传统的基于 PR 的把关方式，但其他人对于放弃既定且受审计员欢迎的协议仍持谨慎态度，即便这些协议被认为效率低下。
研究人员在波音 737 的航空电子系统中发现了一个关键漏洞，证明了具备物理接触权限的攻击者可以利用维护端口篡改飞行数据。通过注入错误信息（例如不准确的温度或重量数值，或进行细微的导航调整），攻击者可能危及飞行安全，导致飞行员困惑或使飞机偏离航线。 尽管经验丰富的飞行员理论上可以通过切换至手动控制来化解风险，但研究人员警告称，这些隐蔽的攻击手段极易在紧急情况下导致飞行员误判或反应迟缓。安全专家强调，这种威胁发生的可能性很高，因为攻击者可以在日常维护期间安装微型硬件设备。 研究团队提出了多种缓解措施，包括使用环氧树脂物理加固易受攻击的端口、实施更好的电气隔离，以及为系统通信增加加密认证。这一发现为航空业敲响了警钟，凸显了更新 20 世纪安全模型以防御现代复杂网络物理威胁的紧迫性。专家们一致认为，随着技术的进步，航空业必须改进其安全标准，以确保关键系统能够抵御高水平对手的攻击。
这篇 Hacker News 讨论聚焦于《连线》杂志的一篇报道，该报道详细介绍了一种硬币大小的设备，它能通过外部维护端口入侵波音 737 客机。
评论者们大多淡化了标题的“恐慌因素”，将其与汽车使用的 OBDII 扫描仪相提并论。共识是物理接触才是主要障碍；一旦有人能够物理接触到飞机的敏感内部系统，传统的安全性便“毫无意义”了。许多用户指出，授权的维护人员本就拥有对航空电子设备和线路的完全访问权限，因此该设备与其说是一个新的威胁，不如说是一种对现有物理脆弱性的演示。
讨论帖还强调了对机场安全的更广泛担忧，例如围栏防线不够严密以及内部威胁的风险。尽管波音公司坚称现有的设计层和运行环境能降低这些风险，但怀疑论者认为这只是业内“我们不认为黑客能搞定它”的托辞。参与者还讨论了分享付费内容的相关伦理，并呼吁在平台上采取更好的存档做法。
爱尔兰网络安全专业人士肖恩·伯恩（Sean Byrne）屡次被拒绝使用各类服务，最近一次是苹果公司的 App Store Connect。原因是他被美国政府的限制方名单误报。该名单中关于“肖恩·伯恩”的记录可追溯至 2009 年的一起涉及航空公司的出口管制案件，该公司当时虚构了员工信息。调查人员最终认定该姓名是共谋者使用的化名，但相关记录从未从政府的“综合筛查名单”中删除。
由于该记录缺乏出生日期等识别信息，任何名为“肖恩·伯恩”的人都会被系统自动标记。虽然纳斯达克（Nasdaq）和 DHL 等公司在审核伯恩提供的文件后消除了误报，但苹果公司拒绝进行沟通。伯恩警告称，随着远程招聘平台越来越多地将自动化的全网制裁筛查整合到招聘流程中，名字常见的合法求职者正面临被悄然列入黑名单的风险。问题的核心在于，这些系统优先考虑“多筛查”而非“精筛查”，且未能考虑到政府数据过时、虚假或不准确的情况。若无官方干预以删除这一“幽灵记录”，伯恩及其他有着相似遭遇的人，将因这一持续了 16 年多的文书错误而长期受到排挤。
Hacker News 上的一场讨论强调了“算法黑名单”日益严重的问题：由于与观察名单上的实体存在错误的“模糊匹配”，个人正遭受重大的经济损失。
一位用户分享了他们的经历，称自己因身份与他人混淆而被金融机构和服务平台封禁。尽管他们努力尝试申诉，但这些盲目依赖粗糙数据且缺乏人工监督的自动化系统仍持续将其标记为高风险。该用户指出，由于这些自动化过滤器通常基于“系统拒绝”的逻辑运作，且缺乏有效的核查机制，受害者几乎没有渠道来证明清白。他们警告称，随着这些系统日益普及，这场“缓慢发生的事故”将影响越来越多的无辜者。另一位参与者则建议，为了规避这类系统性错误，法律意义上的改名最终可能成为唯一的实际解决方案。
标准的 SSH 加固（使用密钥和 `fail2ban`）仍会将 22 端口暴露给扫描器和潜在的零日漏洞。要真正保障服务器安全，应在用户证明身份之前让 SSH 服务处于不可达状态。
作者建议使用 **fwknop**（防火墙敲门守护程序）并配合 **单包授权 (SPA)**。与容易受到数据包嗅探和重放攻击的传统端口敲门（Port Knocking）不同，SPA 会向服务器发送一个经过加密且带有 HMAC 验证的 UDP 数据包。验证通过后，服务器会动态更新防火墙，在有限时间内为特定客户端 IP 开放 22 端口。
从攻击者的角度来看，服务器保持完全静默；22 端口显示为“已过滤”（关闭），从而有效消除了日志冗余并防止了针对 SSH 的漏洞攻击。
**实现细节：**
* **自动化：** 服务器端的部署和防火墙规则通过 Ansible 管理。
* **无缝访问：** SSH 配置中的客户端 `ProxyCommand` 会自动执行敲门操作，使用户无需感知该过程。
* **冗余：** Tailscale 接口提供了一条独立的并行访问路径作为安全保障。
这种方法将 SSH 从面向互联网的服务转变为一种经过身份验证的“隐形”资源，显著减少了服务器的攻击面。
这篇 Hacker News 讨论探讨了关闭 SSH 22 端口并改用“端口敲门”（port knocking）或其他访问方式的利弊。
批评者认为，用定制且可能存在安全隐患的代码来取代“久经考验”的标准 SSH 服务，反而会引入新的漏洞。而支持者则提倡“纵深防御”策略，认为尽管 SSH 本身很稳健，但通过地理屏蔽、fail2ban、基于 HMAC 的端口敲门或将 SSH 运行在 443 端口等手段增加防护层，可以有效减小攻击面。
许多评论者指出，比起定制的端口敲门方案，WireGuard、Tailscale 等现代替代方案，或是通过 VPN 和防火墙限制 SSH 访问更为高效且易于管理。也有人认为，只要服务器配置得当，仅强制执行公钥认证就已足够。总的来说，目前的共识趋向于避免将服务直接暴露在公网，转而倾向于通过现代隧道协议或严格的网络级访问控制来实现受限访问。
Show HN：一个用于探索我所在城市历史照片的网站 Show HN: A website for exploring historical photographs of my city
16 小时前
弗吉尼亚联邦大学天鹅湖 · 里士满综合规划幻灯片集
一位用户在 Hacker News 上分享了“MapRVA”，这是一个致力于探索城市历史照片的网站。该项目受到了社区的好评，评论者将其与 OpenSFHistory 等类似的本地项目进行了比较，并赞赏其能够直观展示城市随时间演变的能力。
针对有关将项目扩展至全球并众包城市景观文档的建议，创作者确认了扩展计划。他们目前正与美国各地的多个团体合作，将该平台（他们称之为“Yesterdays”）扩展到其他地区。对路线图感兴趣的人可以在 GitHub 上跟踪开发进度。
### 任务尝试 “我的用户真的能完成这个操作吗？” 临时测试。当你正在构建一个新流程，且想在不安排研究会议的情况下了解它是否对真实用户有效时，只需写下任务，观察代理尝试执行，并查看它卡在哪一步的截图。 ### 实验 对比两个构建版本 “哪个设计方案胜出？” 针对你应用的两个构建版本运行同一个任务，并进行并排对比。在设计方案进入生产环境进行 A/B 测试之前，先看看用户能完成哪一个，以及哪一个会出错。
近期一篇 Hacker News 的讨论凸显了 AI 驱动软件测试这一新兴趋势，其中以旨在自主导航并评估移动应用用户体验的平台“Deltix”为代表。
该讨论串揭示了市场对端到端自动化日益增长的需求。一位评论者描述了一个复杂的架构：AI 代理从 Azure DevOps 获取用户故事，通过 Playwright 或浏览器执行测试，并通过 API 回报结果。然而，该评论者指出，全面自动化往往受到外包公司“人在回路”（human-in-the-loop）要求的阻碍，因为这些公司更看重工时收费而非效率。
其他用户也分享了各自的实验，例如使用通过 ADB（Android 调试桥）直接访问并物理操作测试手机的 AI 代理来识别漏洞。此次对话表明，尽管该技术足以实现复杂的 QA 工作流程自动化，但组织架构和商业模式的制约仍是其大规模普及的主要障碍。
发掘《海豚历险记》（Ecco the Dolphin）中隐藏了31年的彩蛋 Unearthing a 31 year old Easter egg in Ecco the Dolphin
17 小时前
虽然《海豚埃科》（Ecco the Dolphin）的 PC 版长期以来被认为缺少主机版的调试模式，但其实代码中依然隐藏着开发者留下的秘籍。 通过操作“关于 EccoWin”（About EccoWin）对话框，玩家可以解锁一个隐藏菜单。只需在关闭对话框时按住 Shift+Ctrl 键，即可进入关卡选择和无敌模式（无限生命与氧气）。 此外，还有一个更复杂的操作：按住 Shift+Ctrl+鼠标左键，并双击“关于”窗口的角落，可以将“确定”（OK）按钮变为“kO”，从而解锁更多虽然功能不太完善的调试工具。这些工具包括绕过 CD 检查、显示边框以及用于调整冲刺冷却时间的“简单”模式。这些隐藏菜单为那些苦于游戏极高难度的玩家提供了救命稻草，或许能让更多人最终达成游戏那难以企及的结局。
最近 Hacker News 上关于《海豚埃科》（*Ecco the Dolphin*）中一个 31 年前“复活节彩蛋”的讨论，引发了人们对现代游戏中隐藏功能和作弊码日渐式微的广泛探讨。
评论者指出了导致这一趋势的几个因素：
* **企业责任：** 《侠盗猎车手》（*Grand Theft Auto*）中“热咖啡”事件引发的丑闻，使得隐藏内容成为了潜在的法律和公关风险，促使游戏工作室必须对所有游戏资源进行严格审查。
* **成就系统：** 平台强制实施的成就系统（如 Xbox、PlayStation 和 Steam）抑制了开发者加入内置作弊码的意愿，因为这可能会破坏奖励系统的完整性，或违反平台的认证要求。
* **货币化：** 一些人认为，传统的作弊码已被微交易和付费 DLC 所取代，原本的“无敌模式”或道具解锁已变成了营收渠道。
尽管部分用户认为这些变化削弱了经典游戏中那种探索发现的乐趣，但另一些人则指出，游戏行业向标准化、可追踪进度的转型，使得平台整合和盈利能力已然凌驾于 90 年代那种“充满秘密”的文化之上。
所提供的内容详述了 IETF 内部关于在 TLS 中标准化“纯”ML-KEM 的持续争议，此举将移除传统 ECC 加密的“安全带”。 作者认为，IETF 已经背离了其“粗略共识”和透明度的核心原则。尽管在最近的投票期间，有 82 名（其中许多具备技术专长）人士正式反对该规范，但 TLS 工作组主席仍宣布达成共识，并将该提案提交至 IESG。作者指出，工作组主席通过不断变化且前后矛盾的理由，为无视这一重大且未解决的反对意见进行辩解。 文中强调了 IETF/IESG 领导层与美国防务部门相关实体（包括国家安全局、思科及各类军事承包商）之间存在系统的“旋转门”现象。作者认为，这些关系影响了标准制定过程，使流程偏向于供应商利益而非独立的工程判断。由于申诉程序也由存在防务相关利益冲突的人员把控，作者对 IETF 是否会遵守自身程序规则或维持其对公共利益安全的承诺深表怀疑，并总结称该流程似乎旨在无视社区异议，强行通过规范。
这次 Hacker News 的讨论聚焦于丹尼尔·J·伯恩斯坦（DJB）所指出的美国国家安全局（NSA）在 IETF 标准化进程中扮演的争议性角色。
一位评论者质疑了 NSA 的双重身份，指出该机构在进行“蓝队”防御工作与其历史上植入后门（如 DUAL_EC）的行径之间存在内在的利益冲突。他们认为，由于该机构的真实意图模糊不清，很难判断其贡献究竟是在加强还是在破坏加密标准。
相反，另一位用户批评了 DJB 对 IETF 治理所采取的激进做法。他们认为，DJB 最近成功阻挠某项 TLS 规范的行为属于“组织拉票”（brigading），即动员圈外人表达愤怒，而非进行真正的技术交流。这位批评者为 IETF 的流程辩护，指出这些规范的提议者并非“走狗”或反派，并谴责了在技术标准化周围制造对抗性和阴谋论文化的行为。
这场辩论反映出安全专家对政府影响力的警惕，与那些优先考虑既定制度流程而非基层反 NSA 运动的人士之间，长期存在的紧张关系。
对不起。