背景： nuget.org是微软旗下的一项服务，允许用户打包软件并上传到 NuGet，供其他用户下载。它主要面向 .NET 开发人员，但实际上对通过该服务提供的软件类型没有任何限制。
三年前，我曾报道过 NuGet 如何托管和提供陈旧、过时且不安全的 curl 软件包。一些不知名的人下载 curl 压缩包，编译 curl，然后将其上传到 NuGet，NuGet 便会将这些 curl 版本永久地提供给全世界。
为了好好庆祝那篇博客文章发表三周年，我回到nuget.org ，在搜索栏中输入curl ，然后查看了搜索结果。
我立即发现至少有七个软件包提供了严重过时的 curl 版本。其中最流行的rmt_curl软件包报告称，多年来已被下载近 10 万次，而且在过去几周里，每周的下载量仍然接近 1000 次。这种情况仍在发生。我三年前举报的那些软件包已经消失了，但现在又出现了一批同样糟糕的新软件包。看来他们并没有吸取教训。
rmt_curl 声称提供的是 curl 7.51.0 版本，这是我们在 2016 年 11 月发布的版本。目前该版本已知存在 64 个漏洞，自那时以来，我们已经修复了超过 9000 个有记录的漏洞。任何理智的人都不应该下载或使用此版本。
结论：NuGet 的现状和三年前一样糟糕，这让我再次感到网络上有人犯了错。我觉得我应该尽到自己的责任，再次指出他们的错误。这次他们一定会采取行动！他们一定会考虑用户的安全吧？
信任陌生人
NuGet 的整个概念就是如此设计的，也注定会是这样的结果：互联网上的普通用户随意拼凑一些东西，上传到 NuGet，然后全世界的人下载并使用这些东西——他们相信描述的内容都是准确无误且出于好意的。或许后台会进行一些额外的安全扫描，但我看不出任何人如何才能确定这些文件不包含任何后门、木马或其他恶意的蓄意攻击。
而且，一旦上传，所有内容似乎都会永久保留。
我再次举报了此事。
大约三年前，我在报告中列出了一堆严重过时的 curl 包。NuGet 说我可以发邮件给他们，但我收到一封退信，说他们不再接受邮件报告了。（唉，是的，我已经把这个问题单独报告过了。）
相反，我被引导到通用的微软安全报告页面，那里甚至没有“nuget”的下拉选项，所以我在提交报告时选择了“.NET”。
“这不是微软的问题。”
几乎和三年前一样，我的报告在不到48小时内就被关闭了。他们说这不是NuGet的问题。
再次感谢您向微软安全响应中心 (MSRC) 提交此报告。
经过仔细调查，此案例被评估为非漏洞，不符合微软立即提供服务的标准。这些软件包均非微软所有，您需要直接联系软件包所有者以获取已发布的补丁版本。开发者负责移除其软件包或更新依赖项。
换句话说：他们认为 NuGet 没有责任确保其托管的软件包对用户安全可靠。我应该逐一向每个过时的软件包提供商报告这些问题，如果他们真的关心用户安全，多年前就应该移除或更新这些软件包了。
而且，那样的话我就得一直玩打地鼠游戏了，因为显然人们会一直这么做。我觉得我人生中还有更重要的事情要做。
过时的做法
在我报告的案例中，这些软件包似乎曾经受到某人的关注和投入，他们曾持续一段时间保持软件包与 curl 版本同步更新，但后来停止了更新，从那以后，nuget 上的软件包就一直积满了灰尘，变得陈旧过时了。
不过，用户似乎仍在不断发现和下载它们，即使数量可能不算特别多。
每周有成千上万的用户受骗，这个数字太高了。
如何应对
上传用户完全可以合法地这样做，而根据 curl 许可证，nuget 也完全可以托管这些软件包。
我无法给出 NuGet 应该如何彻底解决这个问题的确切答案，但只要他们允许九年前上传的软件包今天仍然可以被下载，就等于是在自找麻烦。他们助长了用户被诱骗下载和使用不安全软件的行为，却对此漠不关心。
极少数九年前上传的应用程序可能仍然有效，但这极其罕见。
结论
上次我报告这个 NuGet 问题时，直到我在 Twitter 上发帖才有所进展。这次，一位知名的微软开发者（此处隐去其姓名）在 Bluesky 上看到了我Mastodon 上关于此问题的帖子，并向微软内部推动了此事——但即便如此也无济于事。
NuGet 管理层认为这样没问题。
如果我喜欢玩文字游戏，我大概会把他们叫做“鸡块”（chicken nuget），因为他们根本不愿解决这个问题。也许我们只要闭上眼睛假装它不存在，它就会消失？
绝对不应该使用 NuGet。