发布 nuget 包，其中包含可执行文件，nuget.org

Question

我是一个好人，希望为nuget.org做出贡献

我有一个无法使用 .NET 解决的任务（转换.pdf为.NET .html，但这不是要点，它可能是任何其他），但使用 Python 很容易处理。所以我编写了一个.py脚本，将其转换为单文件可执行文件，在 .NET 中编写了一些包装，然后它就可以工作了。

包装器基本上只是将可执行文件卸载到硬盘驱动器上的某个位置，通过命令行参数调用它并获取响应。

• 现在我该如何发布这个带有可执行文件的 nuget 呢？
• 这还被允许吗？
• 这个想法是否太糟糕了以至于我放弃了整个事情？
• 我是否以某种方式明确警告用户该库包含一个可执行文件，该可执行文件将被复制到他们的硬盘驱动器上？
• 提供 .py 脚本代码的链接（在哪里？）？
• 以及对这段代码实际上是可执行文件内部的内容进行某种验证（如何？）？

Answer 1

现在我该如何发布这个带有可执行文件的 nuget 呢？

这是常见的做法。NuGet 包允许各种工件，例如源文件、图像、XML 文件、MSBuild 的构建脚本、工具可执行文件、PowerShell 脚本以及任何类型的二进制文件，包括库和可执行文件。

这还被允许吗？

NuGet 是一个包管理器。至于包本身，微软的描述并不太清楚什么是有用的代码或内容。

任何现代开发平台的一个重要工具是一种机制，开发人员可以通过该机制创建、共享和使用有用的代码。通常，此类代码会捆绑到“包”中，其中包含已编译的代码（如 DLL）以及使用这些包的项目中所需的其他内容。

许多主流 NuGet 包都包含可执行文件，例如包含整个 Chromium 浏览器的CefSharp.Common ，甚至是 Microsoft 自己的CPPRestSDK，其中包含 OpenSSL、Boost 或 Brotli 的多个可执行文件，以及用于复制文件等的 PowerShell 脚本。顺便说一句，它是 MSDN 上构建本机 NuGet 包的主要示例。

这个想法是否太糟糕了以至于我放弃了整个事情？

不会。即使从一开始就不打算打包可执行文件，但它已经成为一种常见的做法。每个使用 NuGet 的人都应该意识到他们正在消耗库和其他可能有害的工件。您如何确保您使用的 DLL 是安全的？

我是否以某种方式明确警告用户该库包含一个可执行文件，该可执行文件将被复制到他们的硬盘驱动器上？

如果您查看上面的包，除了是本机包之外，没有任何关于内容的通知。您必须检查软件包或获取相应的项目站点才能自己找到答案。另外，包含不需要的工件的包可能会被一系列其他包依赖项所掩盖。

当然，您可以做的是通过descriptionNuSpec 文件中的标签提供包的全面描述。此描述将显示在nuget.org以及大多数客户端中。

提供 .py 脚本代码的链接（在哪里？）？

您可以通过标签提供指向项目网站的链接projectUrl，您可以在其中详细了解并提供来源。另一种选择是将其作为内容文件包含在内以供参考，但有人查看它的机会很小，并且它并不能证明您的可执行文件是根据该脚本构建的。

以及对这段代码实际上是可执行文件内部的内容进行某种验证（如何？）？

这一切都归结为一个问题：你如何信任一个包裹？你不能。

软件包可能会带来安全风险，因为它们可能会执行任意代码或将恶意代码携带到您的应用程序中。您可以作为消费者自行检查所有文件，也可以依赖您信任的来源或作者。提供信任的一种方法是对包进行签名，以防止内容篡改并确保包的完整性。同样，这并不能验证您的可执行文件是如何构建的。