∞ PHP项目即将更换许可证 拟统一采用Modified BSD
PHP 项目多年来在许可证问题上一直属于“历史包袱”较重的项目，如今正准备进行一次重要而彻底的清理：由社区成员 Ben Ramsey 牵头的提案，计划废弃当前使用的两套自定义许可证——覆盖大部分代码的 PHP License 3.01 以及用于 Zend 目录代码的 Zend License 2.0——转而在未来版本中统一采用 BSD 三条款（Modified BSD）许可证。目前，PHP 社区正在就这一“PHP 许可证更新”RFC 进行投票，投票将持续到 2026 年 4 月 4 日。
在 PHP 的早期发展阶段，项目在许可证上的变更频率颇高：自 1995 年到 2006 年间，PHP 共进行了七次许可证变更或条款调整。最初，PHP 是在 GPLv2 下发布的；1998 年发布的 PHP 3 则采用了 GPLv2 与新 PHP License 的双重授权方式，这一新许可证以 Apache License 1.0 为基础，由 PHP 创始人 Rasmus Lerdorf 制定，目的是让 PHP 对商业用户更“友好”，同时仍保持自由软件属性。Lerdorf 当时表示，希望在确保 PHP 始终免费的前提下，让商业公司可以在不让主要贡献者感觉“被占便宜”的条件下尝试商业化版本。
不过，最初版本的自定义 PHP 许可证包含一条需要获得 PHP 开发团队书面许可才能进行商业再分发的条款，这在实践中被证明难以操作，最终在 PHP 3.0.14 版本中被删除。该版本附带的 LICENSE 文件甚至没有标明许可证版本号。
2000 年 5 月发布的 PHP 4.0 是一次重大重构，引入了由 Zeev Suraski 和 Andi Gutmans 编写的 Zend 引擎，这两人随后创办了 Zend Technologies，希望在独立于 PHP 的路径上商业化 Zend 引擎。Zend 向 PHP 项目提供授权，使其可以将 Zend 引擎集成进 PHP，并承诺相关代码将保持在 Zend 许可证或符合开源定义（OSD）的其他许可证之下，尽管 Zend License 本身并未获得开源促进会（OSI）正式批准。此后，PHP 源码树中 Zend 目录下的代码便采用 Zend 许可证；PHP 4.0 同时完全放弃了 GPLv2，转而采用 PHP License 2.02。
在随后的几年中，PHP License 继续被微调：PHP 3.0 版本的许可证曾获得 OSI 批准，但之后又做了一次小幅修改，形成了 PHP License 3.01。该次修改仅调整了版权年份以及对 PHP 和 Zend 致谢文字的表述方式，并未改变授权权利本身。然而，这个新版本从未再经过 OSI 审核。更麻烦的是，许可证文本表面上只适用于由“PHP Group”发布的软件，而这一“PHP Group”本身并非实际的法律实体，而是十名早期 PHP 开发者的列表。这一模糊性让部分人认为，其他主体发布的软件并不能合法地采用 PHP License 作为授权文本，从而对如 Debian 等项目造成了实际困扰。Ramsey 在 RFC 中专门梳理了这段历史背景。
在当前的 RFC 中，Ramsey 提出，自下一个主要版本起（最初写的是 PHP 9.0，后更新为“下一版本的 PHP”），用 BSD 三条款许可证统一替换目前的 PHP License 和 Zend License。他表示，在撰写这一提案时，自己已与 OSI 许可证委员会主席 Pamela Chestek 合作，处理相关法律问题与疑问。
Ramsey 称，他已经与所有 PHP Group 成员沟通过，每位成员都已表示支持这一变更。同时，他还获得了 Perforce Software 的许可——Perforce 于 2019 年通过收购 Rogue Wave 将 Zend 纳入旗下，而 Rogue Wave 在 2015 年收购了 Zend。有人可能会疑问：既然多年来有如此众多个人向 PHP 提交代码，是否需要每一位贡献者都同意才能更改许可证？在 RFC 中，Ramsey 的观点是：不需要。PHP 并未要求贡献者签署将版权转移给项目的 CLA，因此贡献者保留其贡献代码的版权；但在他们未明确声明其他授权条款的前提下，可以视为他们以项目当前的许可证向项目授予使用其贡献的权利。
换言之，贡献者对自己所提交代码享有版权，但在未指定其他许可证的情况下，其贡献是按项目所采用的许可证授权给项目使用的。Ramsey 进一步指出，通常在变更开源项目许可证时，需要取得所有版权方的同意，因为新许可证可能会改变授予用户的权利范围。但在此案例中，改用 BSD 三条款许可证并不会改变除 PHP Group 和 Perforce Software 外其他贡献者所授予的权利。因此，他认为项目并不需要逐一征求所有贡献者的明确许可。
尽管 RFC 指出从法律上并不强制要求逐一征得同意，但出于“礼貌”考虑，Ramsey 提议将讨论期至少维持六个月，以确保所有利益相关方有充分机会表达意见。自 2025 年 7 月提出 RFC 以来，他多次发布更新并提醒社区该议题仍在讨论中；截至目前，尚未出现实质性反对意见。
讨论中也出现了一些具体问题。例如，Derick Rethans 询问为何必须等到 PHP 9，而不是在 8.5 之后的“下一版本”就进行变更。Ramsey 回应称，这并无技术或法律上的硬性理由，只是出于版本节奏的直觉判断，如果社区认为在 PHP 8.6 中完成变更更合适，他也不反对。此后，RFC 便将实施时间从“PHP 9”调整为“下一版本”。
另一位开发者 Peter Kokot 则建议，应对与 GPL 的兼容性进行更清晰的说明，以便在未来与 GPL 授权软件协同时减少疑虑。他指出，PHP 在构建时可以选择链接两个 GPLv3 许可证的库：GNU Readline 和 GNU dbm (GDBM)。他希望逐步废弃在构建阶段链接这些 GPL 库的选项，以便让打包者不再为潜在的不兼容问题担忧，最终彻底移除对 GDBM 和 Readline 的链接可能性。Ramsey 回应称，在现有 PHP License 3.01 下，由于对用户附加了一些额外限制，该许可证与 GPL 不兼容，这种不兼容目前无法消除；然而若改用 Modified BSD 许可证，只要最终组合包整体以 GPL 条款发布，就不存在此类兼容性问题，这也将显著简化发行版打包工作。
2026 年 3 月 14 日，Ramsey 宣布对该 RFC 正式开启投票。投票结果以公开方式记录在 PHP Wiki 的 RFC 页面上。目前尚不确定拥有投票权的总人数——2019 年统计显示当时共有 180 名具有投票资格的开发者。投票开始后不久，已有 47 人投下赞成票，2 人选择弃权。从早期结果看，社区对该提议的态度高度正面，但在投票程序结束前，结果仍不能视为板上钉钉。无论最终结果如何，这次许可证清理和简化工作显然离不开 Ramsey 过去数年在幕后进行的沟通、协调与推进。
∞ 研究称六成MD5密码哈希可在一小时内被破解
在今年的“世界密码日”之际，安全厂商卡巴斯基发布的一项研究显示，使用单块高端 GPU，对通过 MD5 算法保护的密码哈希进行暴力破解时，有约 60% 的密码在一小时内就能被攻破，其中约 48% 甚至在一分钟内就可被破解，引发业内对传统密码安全性的再度担忧。
卡巴斯基在研究中选取了一个包含逾 2.31 亿个唯一密码的样本集，这些密码均来自暗网泄露数据库，其中有 3800 万条是较此前一轮研究新增的数据。 研究人员使用 MD5 对这些明文密码重新进行哈希处理，并在单块 NVIDIA RTX 5090 显卡上进行破解测试，结果表明，绝大多数密码在极短时间内就可以被恢复，这也在高性能硬件不断普及的背景下凸显出现代密码体系的脆弱性。
尽管 RTX 5090 并非普通桌面用户的主流显卡，而且价格不菲，但卡巴斯基指出，这并不构成实质门槛。 攻击者完全可以通过云服务低成本租用类似等级的 GPU，“按小时计费”进行密码破解，这意味着即便普通企业或网站在本地并未部署如此昂贵的硬件，其密码数据库一旦泄露，依然会在现实攻击场景中面临高强度破解能力。
研究报告强调，此次测试的结论并非针对明文密码本身，而是指向“快速哈希算法”的结构性风险：任何仅依赖 MD5 等高速哈希算法来存储密码的系统，在数据库被盗取后都不再具有足够的安全性。 卡巴斯基在报告中直言，“攻击者只需要一小时，就能从泄露列表中破解出五个密码中的三个”，在 GPU 性能持续提升的形势下，留给传统密码哈希的安全缓冲时间正在急剧缩短。
卡巴斯基分析认为，攻击效率提升的一个关键原因，在于人类密码选择本身的高度可预测性。 通过对逾 2 亿条泄露密码进行模式分析，研究人员发现，不少用户仍然采用常见单词、数字序列、键盘顺序组合等“套路”密码，而这类模式很容易被整合进字典攻击和规则优化的破解算法，极大缩短了穷举搜索所需的时间。
这项研究也与卡巴斯基在 2024 年开展的前一轮同类分析形成对比，结果显示，2026 年密码整体的可破解性相比两年前略有恶化，虽然幅度不大，仅提升了几个百分点，但趋势依然朝着“更容易被攻破”的方向发展。 卡巴斯基指出，攻击方“提速”的主要动力来自 GPU 性能的年年迭代，而用户在密码习惯上的改进却几乎停滞不前，使得攻防差距持续拉大。
在关于“世界密码日”的讨论中，多位安全专家认为，与其继续庆祝“密码节”，不如把这一天改成“告别密码日”，推动业界尽快摆脱对单一密码的依赖，或至少彻底重塑账号安全架构。 尽管“密码已死”的说法多年来屡被渲染，但现实是，大部分用户和企业依然在高度依赖密码登录，安全宣传邮件与市场推广活动年年不断，却未能从根本上扭转密码弱、复用多、保护差的现状。
托管服务提供商 Thrive 的“按需 CISO”Chris Gunner 在接受邮件采访时表示，没有必要完全抛弃密码，但它必须被纳入更广义的“身份安全战略”之中，而不是孤立存在。 他指出，即便是强密码，如果所在的身份与访问管理环境缺乏统一治理，同样可能因配置松散、会话劫持或权限滥用而形同虚设，因此密码最好与第二要素绑定使用，优先考虑生物识别等更难被绕过的因子。
Gunner 进一步建议，将多因素认证与身份治理和终端防护整合起来，构建更完整的零信任模型，通过精细化的访问控制和持续验证，降低单一账号被攻陷后横向移动的风险。 在他看来，组织应该假设“第一道门迟早会被打开”，并在门后再筑起多层防线，而不是将全部希望寄托在复杂密码和“正确哈希存储”上。
IEEE 高级会员、诺丁汉大学网络安全教授 Steven Furnell 则提醒，密码问题不能只停留在“教用户自救”的层面。 他表示，在未来相当长一段时间内，密码不会真正消失，而新一代安全技术（如无密码登录、Passkey 等）的部署也极不均衡，许多网站和服务尚未提供支持，导致用户不得不在传统密码和新方案之间来回切换，体验割裂且风险并存。
Furnell 指出，当前不少服务要么没有向用户清晰说明如何创建符合现代标准的高强度密码，要么干脆没有执行足够严格的密码策略，让用户轻松通过弱密码注册或修改流程，从源头埋下隐患。 在他看来，这个“世界密码日”真正应该发出的信号，并不是再一次要求用户“自觉增强安全意识”，而是敦促那些仍以密码为主要认证手段的网站和服务提供方，承担起应有的安全责任，推动更安全的登录选项和更合理的密码要求落地。
在多位专家看来，无论是采用更强的密码管理规则，还是转向多因素认证、Passkey 乃至“无密码化”方案，主动权都不应完全压在终端用户身上，而需要组织和服务提供方做出系统性的架构调整。 在 GPU 算力充裕、MD5 等快速哈希算法形同虚设的当下，任何自认为“复杂、随机并已哈希”的密码，都不应被视为最后一道防线，而只是门口的一把基础锁，真正决定安全底线的，是其背后那一整套身份与访问控制体系。
∞ 微软为VS Code推出AI代理浏览器共享与算力优化更新
微软近日向 Visual Studio Code 推送每周最新版 1.119，重点围绕代理与浏览器的交互能力、令牌（token）使用优化、OpenTelemetry 追踪、信任与开发效率以及 Markdown 预览体验进行升级。
在这次更新中，微软强化了内置浏览器与 AI 编码代理之间的协同方式，开发者可以更方便地将特定浏览器标签页“附加”到聊天窗口，让代理进入可共享状态，从而读取并与页面内容交互。 代理还可以获知当前有哪些浏览器标签页处于打开但未共享的状态，当其需要访问某个页面时，可以主动发出共享请求，由开发者选择同意或拒绝，以在人机协作和隐私控制之间取得平衡。
考虑到编码代理在使用上通常存在严格的调用与配额限制，微软此次将待办任务管理职能卸载给轻量级后台代理模型，让主模型尽可能专注于核心编程任务。 更小的后台模型占用更少令牌，有助于在配额不变的前提下延长整体使用时间，不过目前这一功能仍属实验性质，默认处于关闭状态，需要开发者手动启用后才能体验。
在可观测性方面，1.119 版本引入了对 OpenTelemetry 的支持，以应对代理会话越来越长、行为越来越自动化所带来的“黑箱”问题。 通过接入 OpenTelemetry，开发者可以追踪代理在一次会话中执行了哪些步骤、每一步耗时多久、令牌主要消耗在何处等细节，从而更好地评估与优化代理的使用成本和效率。 当前已支持该能力的模型与会话包括 Copilot Chat 代理会话、Copilot CLI 后台代理以及 Claude 代理等。
为进一步提升代理相关体验的流畅度，此次更新还增加了一个设置，用于移除网络域名级别的阻断提示，让开发者在依然处于沙盒保护的前提下，减少频繁的网络访问弹窗打断。 这意味着在安全边界不变的情况下，人机交互过程会更加顺滑，有利于代理在复杂任务链中保持连续执行。
在编辑体验方面，1.119 对 VS Code 中长期存在却相对“冷门”的 Markdown 预览功能进行了易用性改进，新增了更加醒目的按钮与命令，方便开发者在编辑视图与预览视图之间快速切换。 当用户打开 Markdown 文件时，可以在工具栏中找到带有“切换到预览视图”（Switch to Preview View）提示的按钮，从预览界面则可以通过对应按钮“切换到编辑视图”（Switch to Editor View）返回编辑模式，从而更直观地审阅文档排版与渲染效果。
与以往一样，VS Code 会在更新可用时主动提示用户进行升级，开发者也可以直接前往 Visual Studio Code 官方网站下载最新版本 1.119，以尽快体验新一轮 AI 代理与浏览器集成、令牌优化和可观测性增强带来的变化。
下载：
∞ 萨博推出新型反坦克弹药 专破高科技爆炸反应装甲
瑞典防务企业萨博公司近日发布一种专为应对当代主战坦克高科技装甲而设计的新型反坦克弹药 HEAT 758，该弹药用于萨博旗下“卡尔·古斯塔夫”84 毫米无后坐力炮系统，被称能够有效对付包括现代爆炸反应装甲在内的多种先进防护方案。
在过去一个多世纪里，装甲与反装甲技术之间一直进行着此消彼长的博弈，远比影视作品中“炮弹打铁疙瘩”的简单画面要复杂得多。一战时期，坦克采用的还是用铆钉固定的低碳钢装甲，强力步枪即可击穿。到了二战，随着钢材合金成分优化、冶金工艺提升以及装甲厚度增加，加之通过倾斜布置装甲来引导偏转弹丸、分散冲击能量，坦克防护能力显著增强。
相应地，反坦克武器也迅速进化，从德军“铁拳”“坦克杀手”到美军“巴祖卡”、英军 PIAT，陆续采用成型装药战斗部，将爆炸能量集中为高温金属射流，以较小口径穿透厚重钢板。随后又出现由钢、陶瓷和复合材料构成的复合装甲，用来对抗贫铀高速穿甲弹等新一代攻击手段。在这一演进过程中，爆炸反应装甲（ERA）成为坦克防护的关键一环：车体外部安装大量装有高能炸药的钢盒，当被成型装药命中时，炸药主动起爆，以反向冲击破坏和偏转来袭弹头或爆炸冲击波。
随着 ERA 技术不断升级，防务承包商也被迫同步“卷”向更高技术门槛。此次在瑞典卡尔斯科加公开展示的 HEAT 758，是为冷战时期服役至今的“卡尔·古斯塔夫”家族无后坐力炮研制的最新一代弹药，目标直指配备现代爆炸反应装甲的重型装甲目标，包括 Kontakt-1、Kontakt-5 和 Relikt 等主流系统。
HEAT 758 属于“串联破甲”反坦克弹药，但在工作机理上进行了重要改进。传统串联战斗部依靠前置小装药先引爆 ERA 盒体，剥去外层防护，再由后主装药对裸露钢装甲实施穿透。这一构型虽然理论清晰，但前一阶段爆炸本身也会扰乱后续主射流的成形与稳定。萨博此次采用所谓“非起爆前体”（NIP）方案，通过对第二阶段结构和作动过程的重新设计，试图利用 ERA 在起爆灵敏度上的“甜区”。
文章指出，实际应用中炸药并不如大众想象的那样轻易被引爆：甘油炸药掉落不会立刻爆炸，胶状炸药可以像橡皮泥一样被抛掷，甚至 TNT 在篝火中也可能只是燃烧而非剧烈爆炸。要让主装药起爆，往往需要由敏感度逐级递增的起爆链和雷管来“接力”。这对爆炸反应装甲提出了微妙要求：一方面必须对敌方弹药足够敏感，保证被命中时能可靠触发；另一方面又不能在坦克轻微碰撞、追尾民用车辆时误爆。HEAT 758 正是瞄准这一敏感度窗口，通过控制前体打击强度，使其足以穿透 ERA 盒体并打通成型装药射流通道，却又不足以触发盒内炸药爆炸，从而在不引爆 ERA 的情况下打开一条“干净”的破甲路径。
据萨博介绍，为找到这种临界条件，公司借助人工智能，对弹药命中目标过程进行了约 5 万次数字仿真推演，以优化各项参数。HEAT 758 还集成了 Firebolt 技术，通过弹药本体、“卡尔·古斯塔夫”M4 发射器和 558 型火控装置之间的数字通信链路，自动获取弹种信息和装药温度等数据，实时计算最佳弹道解以提升命中与杀伤效果。
在具体性能上，HEAT 758 可在有效射程 700 米内，以约 255 米/秒的初速，对厚度达 100 毫米的均质轧制装甲实施穿透。单发弹药重量约 7 千克，长度不足 1 米，外覆碳纤维复合材护套，并采用钛合金内衬以加强结构和耐热性。萨博透露，该型弹药已进入量产阶段，目前买家身份尚未公开。
萨博地面作战业务单元负责人迈克尔·霍格隆德表示，HEAT 758 是公司针对战场态势变化给出的回应，当爆炸反应装甲成为传统弹药难以克服的“门槛”时，新弹药通过技术升级再次降低了装甲车辆对一线士兵构成的威胁，这也体现了萨博持续在现役平台上挖掘潜力、提高作战效能的研发路线。
∞ Anthropic新模型Mythos重塑了Firefox的网络安全策略
当 Anthropic 在 4 月发布其新模型 Mythos 时，这家 AI 实验室同时向软件开发行业发出了强烈警告。 据称，这一模型在挖掘软件安全漏洞方面能力超强，已经发现了数以千计的高危漏洞，在这些问题修复完成之前，模型无法全面对外开放。
现在，Mozilla Firefox 浏览器的安全研究人员首次系统披露了这一过程在实际工程中的运作细节，并尝试解释 Mythos 对整体软件安全生态意味着什么。 Mozilla 在周四发布的一篇文章中表示，Mythos 已经在 Firefox 中挖掘出大量高危漏洞，其中一些缺陷在代码中潜伏时间已超过十年。
在短短半年内，AI 安全工具的实用性出现了明显飞跃。 过去一段时间，各类 AI 自动查错工具往往“噪声”极大，动辄给安全团队塞满质量堪忧的报告和大量误报，让工程团队疲于应付。 Mozilla 的研究人员认为，新一代工具已经“拐点已至”，尤其是在具备“代理式”能力之后，模型可以对自己的分析结果做二次评估与筛选，从而过滤掉大量不靠谱的输出。
“很难夸大这种变化在几个月内对我们的影响有多大。”研究人员写道。 “首先，模型本身的能力有了巨大提升；其次，我们在如何驾驭这些模型方面的技术栈也进步很快。”
具体到结果层面，变化尤为直观：2026 年 4 月，Firefox 共发布了 423 个漏洞修复补丁，而在一年前同月，这一数字只有 31 个。 研究团队还公开了其中 12 个漏洞的技术细节，既包括两处罕见的沙箱安全机制缺陷，也包括一个长达 15 年之久的 HTML 元素解析错误。
“这些工具现在真的突然变得非常好用了。”Mozilla 杰出工程师 Brian Grinstead 在接受 TechCrunch 采访时说。 “我们在内部扫描系统上看到了这一点，在外部提交的漏洞报告中也看到了同样的趋势，放眼整个行业也是如此。”
其中最引人注目的一点，是 Mythos 帮助发现了一批与浏览器“沙箱”机制相关的漏洞。 在业内，这类漏洞向来被视为最难挖掘、危害最高的缺陷之一：要成功找到并验证沙箱漏洞，模型不仅要能编写出带有恶意改动的补丁，还要在引入这段新代码后，设法攻击到浏览器中防护最严密的那部分组件。 这个过程需要在多步操作之间保持严密逻辑和足够创造力，难度远高于常规缺陷挖掘。
从经济激励上也能看出其价值。 Mozilla 的漏洞赏金计划对 Firefox 沙箱漏洞给出的最高奖金为 2 万美元，是所有漏洞类别中奖励上限最高的一档。 尽管如此，Grinstead 表示，Mythos 目前找到的沙箱相关问题数量，已经超过人类安全研究员过去通过悬赏挖掘出的同类漏洞总和。 “我们确实会收到沙箱漏洞的报告，”他说，“但从数量上讲，远远比不上我们利用这种新技术主动发现的规模。”
值得注意的是，尽管业界在 AI 代码生成工具方面进展明显，Firefox 团队目前仍不依赖 AI 来直接修复这些漏洞。 团队会让模型基于每个漏洞尝试生成补丁，但这些自动生成的代码通常无法直接合入主干，只能作为人类工程师编写修复方案的参考范本。
“在本文提到的这些漏洞中，每一个都是由一名工程师完成补丁编写，再由另一名工程师完成代码审核。”Grinstead 强调。 “我们至今没有找到让这一流程完全自动化的可靠方法。”
在更宏观的层面上，AI 能力的快速演进究竟会如何改变网络攻防之间的力量平衡，目前仍然没有定论。 自 Mythos 预览版发布过去一个多月，绝大多数被其发现的缺陷仍处于修复过程中，这也意味着外界尚难以全面评估其长期影响。 Anthropic 一直严格遵守负责任披露规范，逐步与相关项目沟通漏洞细节，但可以合理推测，一些恶意行为者也在私下尝试类似技术，即便他们所用的模型在能力上仍逊色一筹。
在近期的一场公开活动上，Anthropic 首席执行官 Dario Amodei 对这一趋势持相对乐观态度。 在他看来，如果行业能妥善管理这类工具的使用方式，最终防守方的处境可能会比今天更好。“如果我们处理得当，最终的局面有望比一开始更安全，因为我们会把这些漏洞一个个修掉。”Amodei 说。“漏洞的总量是有限的，所以在这之后有可能迎来一个更好的世界。”
相比之下，长期在一线与漏洞打交道的 Grinstead 则显得更为谨慎。 “这种工具对攻击者和防御者都同样有用，但它的普及至少在一定程度上把优势往防守一方那边稍微倾斜了一点。”他表示。 “更现实的说法是，现在没有人能真正给出这个问题的最终答案。”