在 MSI 中解压、修改和重新打包文件？
我正在尝试找出在我的一个项目中对二进制文件进行 Authenticode 签名的最简单、最安全的方法。
我能看到的最简单的方法是获取编译结果——一个包含所有二进制文件的完整安装包——从中提取程序集，对它们进行签名，然后将这些签名的程序集重新打包到 MSI 中，然后再对其进行签名。
有很多关于从 MSI 解包文件的信息，但没有关于重新打包它们的信息。我该怎么做呢？
I'm trying to figure out the easiest and most secure way to Authenticode sign binaries in one of my projects.
The easiest way I can see to do this is to grab the result of compilation--a completed install package containing all my binaries--extract the assemblies from it, sign them, then repack these signed assemblies in the MSI which then gets signed.
Lots of information out there about unpacking files from an MSI, but nothing about re-packing them. How can I do it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
编辑我的原始回复...
如果您想将签名嵌入到无人值守的构建过程中，您只需使用 MSBuild SignFile 任务即可，该任务包装了authenticode 签名 API http://msdn.microsoft.com/en-us/library/ms164304.aspx
或者，只需调用 SignTool.exe。
您需要使用 certmgr.exe 或证书 mmc 管理单元将软件发布证书安装到计算机上。一旦将其安装到本地证书存储中，您只需使用 SHA 指纹来引用它，您可以在证书属性中找到该指纹，或者只需在 certmgr.exe 中列出证书即可。
我们必须定期更新我们的证书，因此我们在构建中需要执行额外的步骤，以便在构建开始时在本地重新导入证书，并提取证书哈希。我建议不要将哈希存储在源代码管理中，以防您必须返回并构建旧版本 - 它应该是您的环境配置的一部分，例如环境变量或其他可以与源代码分离的东西。
另外，不要忘记给签名文件加上时间戳，这样可以保证签名的有效性。我还建议您将签名与时间戳分离。时间戳是一种偶尔会出错的网络操作，因此能够区分签名失败和时间戳失败非常有用，因为时间戳失败只是可能公开发布的黄金版本的问题。
Editing my original response....
If you want to embed signing into your unattended build process, you can just use the MSBuild SignFile task, which wraps the authenticode signing APIs http://msdn.microsoft.com/en-us/library/ms164304.aspx
Alternatively just use a call to SignTool.exe.
You will need to install your Software Publishing certificate onto the machine using certmgr.exe or the certificates mmc snapin. Once it's installed into the local certificate store you just reference it using the SHA thumbprint, which you can find on the certificate properties or by just listing the cert in certmgr.exe.
We have to regularly update our certificates so we have additional steps in our build to re-import the certificate locally at the start of the build, and pull in the certificate hash. I would advise against storing the hash in source control in case you have to go back and build an old version - it should be part of your environmental configuration, e.g. an env var or something else that can be decoupled from your source code.
Also, don't forget to timestamp the signed files so that the validity of the signature can be guaranteed. I would also advise you to decouple signing from timestamping. Timestamping is a network operation that can occasionally go wrong, so it's useful to be able to discriminate between a signing failure and a timestamping failure, since a timestamping failure is only an issue for gold builds that might be released publicly.
您没有说明您的构建系统是什么，但我的项目经历的（过于简化的）流程如下（我对几乎所有内容都使用 nant 任务，从 CruiseControl.net 触发）
signtool.exe对所有相关文件（例如 exe、dll、ocx）进行签名如果在此过程中任何地方失败，只需向开发团队发送电子邮件即可。
您应该能够使用 MSBuild、Nant 或各种其他工具来完成此操作。它可能会在某些地方涉及一些自定义工作，但最终结果是一个可靠的构建系统，需要与构建进行零人工交互（除非有人想要“强制”构建，即使是这样只需单击网页上的按钮或其他内容）
You don't state what your build system is, but the (overly simplified) flow my projects go through are as follows (I use nant tasks for pretty much everything, triggered from CruiseControl.net)
signtool.exesign all relevant files (e.g. exe, dll, ocx)If it fails anywhere along the way, then just email the Dev team.
You should be able to do this with MSBuild, Nant, or a variety of other tools. It'll probably involve a little custom work in places, but the end result is a reliable build system that requires zero human interaction with the build (unless someone wants to 'force' a build, even that is just clicking a button on a webpage or something)