【问题标题】:Code-Signing: which file types should I sign and why?代码签名:我应该签署哪些文件类型,为什么?
【发布时间】:2011-01-16 05:42:14
【问题描述】:

我有一个全新的代码签名证书,一直在想我应该签署哪些文件。

显然,应该对 setup .msi 包和所有运行提升的 .exe 进行签名以避免“未知发布者”警告,但我应该签署其他可执行文件,例如.exe 不需要提升,.dll 或 .oxc?

微软自己似乎对此处理不一致:

  • 在 Office 2007 中,所有可执行文件都已分配
  • 在 Visual Studio 2008 中,所有 .exe 和许多 .dll 都已签名,但是,也有许多未签名的 DLL(显然是强命名程序集,也许他们认为强命名就足够了)
  • 在 Windows (7) 中,可执行文件和 dll 都没有签名(甚至不需要 UAC 的可执行文件,比如 mmc.exe!)

【问题讨论】:

  • Windows 7 可执行文件和 DLL 由 Microsoft 签名,但在 CAB 文件中,而不是在文件本身上,因此当您右键单击文件时没有“数字签名”选项卡,但如果您运行像 sigcheck 这样的工具会为你找到签名。

标签: code-signing


【解决方案1】:

我认为您回答了自己的问题,只在需要的地方签名以避免提示。

我会考虑签署所有文件的原因只有几个。

  1. 它可能有某种优势 与反病毒供应商处理 您的文件更值得信赖, 因此较少的支持/安装 麻烦。
  2. 它将文件标记为对普通用户更值得信赖,例如,当我使用 MS 的自动运行程序清理受病毒感染的系统时,我倾向于寻找没有签名的伪劣文件,它会突出一英里。李>
  3. 您希望看起来更专业。

我不知道检查签名的开销是多少,所以旧系统可能会更慢。此外,如果您的证书来自便宜的证书供应商,那么根 CA 可能不包含在旧平台(XP pre SP2 等)中。

哦,是的,我也只会将其作为构建的一部分(集成到 MSBuild 或构建服务器中),因为它可能会变得乏味。

请记住不要让其他任何人访问您的密钥,否则您将被撤销,并且安装可能会突然停止工作。因此,请为开发人员使用自签名证书,并将真实密钥锁定在构建服务器上。

有点乱七八糟,但我认为没有正确的答案。

【讨论】:

  • 叹息 - 我希望有一个更明确的答案,也许是我忽略的一些 Microsoft 指导。但由于微软本身显然并没有始终如一地处理这个问题,所以我似乎不能指望这一点。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2015-06-14
  • 1970-01-01
  • 2013-02-06
  • 2020-06-10
  • 2012-04-19
  • 1970-01-01
相关资源
最近更新 更多