标签: strongname

所以问题在于:我们已经决定购买代码签名证书,我们从Godaddy购买了一个p12格式的证书.

经过研究,我发现p12和pfx是不同扩展名的同一个东西,因此我将其重命名为pfx.我也有spc和p7c文件,但我不知道如何处理它们.

无论如何,我试图将我的证书添加到我的Visual Studio 2013解决方案中,这是我得到的:

• 首先我得到一个密码提示,输入密码后我收到错误说

  "An attempt was made to reference a token that does not exist."
  

  Run Code Online (Sandbox Code Playgroud)

• 在我第二次尝试安装pfx时,我没有得到任何提示或错误消息,但是当我构建时,我收到了错误

  "Cannot import the following key file: something.pfx 
  The key file may be password protected.
  To correct this, try to import the certificate again or 
  manually install the certificate to the Strong Name CSP with the following
  key container name: VS_KEY_33FA18307607ECFB"
  

  Run Code Online (Sandbox Code Playgroud)

• 所以我正在使用它

  sn -i something.pfx VS_KEY_33FA18307607ECFB
  

  Run Code Online (Sandbox Code Playgroud)

  这完成没有错误,但当我再次尝试构建时,我得到完全相同的错误与相同的容器名称.

  "Cannot import the following key file: something.pfx ....
  

  Run Code Online (Sandbox Code Playgroud)

我试图使用Goddady支持推荐的signtool作为替代方案但是虽然它标志着组件它不提供我需要的强大功能.

我还试图将证书从pfx提取到snk使用

    sn -p something.pfx key.snk

并选择延迟签名,但项目没有再次构建,错误更多. …

试图了解authenticode代码签名和强命名.

我是否正确地认为,如果我对引用一些dll(不是强名称)的exe进行代码签名,恶意用户可以替换我的DLL并以一种看起来像是由我签名但正在运行的方式分发应用程序他们的代码？

假设这是真的,看起来你真的不想在没有强烈命名整个事情的情况下签署.NET应用程序,否则你会让人们能够在你编写的应用程序的幌子下执行代码？

我不确定的原因是,我在网上找到的文章(包括使用SN + Authenticode的MSDN文档)似乎都没有提到这一点,这似乎是一个相当重要的理解点(如果我理解正确) ？

我有一个具有1个引用程序集的应用程序(test.exe,test.dll)

我想要的是在test.exe运行时,它应该将发布者名称显示为"TestCompany".

为此,我对它进行了数字签名,它就是我想做的.如果我改变test.exe发布者名称的一个字节是"未知".这很好.

但是,如果我改变了test.dll,应用程序运行时没有任何反应,并将发布者名称显示为"TestCompany".哪个对我不好.

所以我把强名称放在app.config中test.dll并添加<bypassTrustedAppStrongNames enabled="false" />.

再一次,没有区别.所以我再次搜索并发现bypassTrustedAppStrongNames只检查程序集是否具有强名称.不是验证.这对我来说再好不过了.

我真正想要的是保护用户,而不是我的应用程序.如果用户运行我的应用程序并且它从我这里说出来,它必须来自我的每个字节.如果应用程序被更改,即使是单个字节,它也必须通知用户,而不是来自我.这是数字签名与强名称一起做的,但它们似乎都不是那么好.或者我错过了什么？

我能想到的最后一种可能的方法是手动检查程序集的强名称.

PS:目标.net框架是2.0

我一直在阅读MSDN,强名称程序集和相关的Stack Overflow问题中的正确文章,检查程序集的强名称.

1. 在何种程度上可以验证强名称的装配以避免篡改？
2. 是否可以使用强命名来验证程序集作者？

第一个问题出现在阅读CSharp411文章.NET程序集常见问题 - 第3部分 - 强名称和签名之后,其中提到了这一点,以及使用强名称的其他问题:

" 无法完全替换.强名称不能阻止黑客删除强名称签名,恶意修改程序集,用自己的密钥重新签名,然后将你的程序集作为你的程序. "

第二个问题旨在找出强命名和其他签名方案之间的差异,例如Authenticode.同样的MSDN文章提到了早期的状态:

"但请注意,强名称本身并不意味着一定程度的信任,例如通过数字签名和支持证书提供的信任. "

我是否尝试使用强命名,而不是创建它？创建强命名是为了避免名字冲突还是一种新的"GAC DLL Hell"？

在我的组织中,我们使用具有强名称程序集的snk文件.我们自己生成snk.

此外,我们在二进制文件上使用代码签名签名.我们从Verisign获得了pfx.

• 这两个过程有什么区别？
• 是不是从Verisign也没有收到snk的问题？

是否可以检查动态加载的程序集是否已使用特定的强名称签名？

比较AssemblyName.GetPublicKey()方法返回的值是否足够/安全？

Assembly loaded = Assembly.LoadFile(path);

byte[] evidenceKey = loaded.GetName().GetPublicKey();

if (evidenceKey != null)
{
    byte[] internalKey = Assembly.GetExecutingAssembly().GetName().GetPublicKey();

    if (evidenceKey.SequenceEqual(internalKey))
    {
        return extension;
    }
}

这不能被欺骗吗？我不确定SetPublicKey()方法是否对构建的程序集有任何影响,但即使是MSDN文档也显示了如何在动态生成的程序集(反射发射)上使用它,这意味着你可以从中提取公钥.托管应用程序并将其注入您自己的程序集并运行恶意代码,如果以上是安全防范,或者我错过了什么？

有更正确和安全的方法吗？我知道如果相反的情况是这种情况,也就是说,我想要保护程序集只被签名主机调用,那么我可以使用StrongNameIdentityPermission属性标记程序集.

好吧,这真的很烦人,之前我注意到WPF生成的用于加载XAML资源的代码似乎没有使用强名称,因此在需要支持并行版本的WPF程序集的情况下可能会出现问题.

事实证明是这样的,它现在给我带来了问题 - 我有一个插件系统,应该支持插件的并排安装,这些插件的版本号(它们的组装版本)不同.这当然可以由.NET支持,因为即使它们具有相同的DLL文件名,也确定程序集具有不同的标识,只要它们具有强名称并且具有不同的公钥/私钥或具有不同的程序集版本号.

现在,如果我们查看visual studio为windows和usercontrols生成的代码,我们会在自动生成的文件中看到以下内容:

/// <summary>
/// InitializeComponent
/// </summary>
[System.Diagnostics.DebuggerNonUserCodeAttribute()]
public void InitializeComponent() {
    if (_contentLoaded) {
        return;
    }
    _contentLoaded = true;
    System.Uri resourceLocater = new System.Uri("/Sensormatic.AMK1000.Panel;component/views/servicepanelui.xaml", System.UriKind.Relative);

    #line 1 "..\..\..\Views\ServicePanelUI.xaml"
    System.Windows.Application.LoadComponent(this, resourceLocater);

    #line default
    #line hidden
}

注意创建资源定位符的行 - 它使用的是相对URI,它不指定强名称或包含xaml资源的程序集的版本.

我想也许LoadComponent会检查调用程序集的标识并使用它的公钥和版本细节,或者可能检查包含'this'参数类型的程序集的标识.

看起来情况并非如此 - 如果您有两个具有不同版本号(但文件名相同)的程序集,那么您可以获得一个IOException,其中包含"无法找到资源X"的消息(对于上面的示例"无法找到资源"视图/ servicepanelui的.xaml".

更糟糕的是,我很确定这也意味着具有相同文件名但不同公钥/私钥的程序集(即来自不同的发布者)也会导致此错误.

那么,有谁知道怎么解决这个问题？如何使WPF强名称兼容.

请注意,就我而言,这是一个WPF错误.您不应该仅使用Appdomain隔离来避免这种情况.

例如,在这里阅读了.NET中的强名称后,我有以下问题:

我们有一个Authenticode代码签名证书,我们用它来签署所有EXE,DLL和MSI文件.这样做的好处是,Windows知道MSI来自可靠的来源,并且如果需要,还可以验证每个文件的真实性.

我们目前不使用.NET强名称.我已经读过,强命名文件本质上意味着它使用自签名证书进行数字签名.我对此的看法是,由受信任的证书颁发机构签名的Authenticode证书比自签名证书更有价值,该证书的真实性无论如何都无法验证,因为它们缺少根证书(我们不打算将其分发给最终用户,是我们!？).

问题:如果已使用Authenticode签名,是否还有其他强命名程序集的值？

我正在编写一个需要SQL Server SMO库的.NET工具.我不在乎它是Server 2005(9.0),2008(10.0)还是2008 R2(可能是10.5,没有检查)的版本.SMO库与SQL Server一起安装,因此我可以放心地假设在安装了SQL Server的任何系统上,也可以使用某些版本的SMO库.

不幸的是,SMO库名称很大:如果我在项目中添加对SMO 9.0的引用,FileNotFoundException如果客户系统上只有SMO 10.0 ,则会失败(),反之亦然.

有没有办法告诉编译器任何版本的库对我来说都没问题？或者我是否真的必须分发3个相同版本的工具,每个版本都编译为不同版本的SMO？

免责声明:我知道可以重新分发SMO库(以及SMO库所需的库).但是(a)一个超薄的100KB独立EXE和(b)安装了大量先决条件的完整安装包之间存在很大差异.

免责声明2:我知道以下重复:

• c# - 你可以对强名称程序集进行"弱"程序集引用
• 需要一个C#程序集来松散地引用一个强命名的程序集

但是,所提供的解决方案并不合适.在问题1中,开发人员可以控制引用的DLL(我没有); 在问题2中,开发人员可以控制目标系统(我也没有).

我们有一个在.Net 4上运行的混合模式汇编应用程序(MFC + WinForms),Windows 2008 R2在一个线程上不断使用100%cpu.

使用ProcessExplorer,我们在忙线程上看到以下堆栈.我们还可以看到另外10个线程只使用0.01%的CPU运行clr.dll!StrongNameSignatureVerification.

旋转线程不会阻止应用程序的其余部分运行,但会浪费CPU时间.

繁忙线程的堆栈跟踪如下:

ntoskrnl.exe!IoAcquireRemoveLockEx+0xe7
ntoskrnl.exe!memset+0x22a
ntoskrnl.exe!KeWaitForSingleObject+0x2cb
ntoskrnl.exe!KeDetachProcess+0x120d
ntoskrnl.exe!PsReturnProcessNonPagedPoolQuota+0x3a3
ntoskrnl.exe!CcSetDirtyPinnedData+0x433
mscorlib.ni.dll+0x2b066a
mscorlib.ni.dll+0x2317ac
mscorlib.ni.dll+0x2b066a
mscorlib.ni.dll+0x2317ac
mscorlib.ni.dll+0x26ccf7
mscorlib.ni.dll+0x237fc4
mscorlib.ni.dll+0x26cc3c
clr.dll+0x21bb
clr.dll!CoUninitializeEE+0xee9b
clr.dll!CoUninitializeEE+0x11463
clr.dll!CoUninitializeEE+0x114dc
clr.dll!CoUninitializeEE+0x1154b
clr.dll!StrongNameErrorInfo+0xa638
clr.dll!StrongNameSignatureVerification+0x144fb
clr.dll!StrongNameSignatureVerification+0x1457d
clr.dll!StrongNameSignatureVerification+0x14638
clr.dll!StrongNameSignatureVerification+0x146d2
clr.dll!StrongNameErrorInfo+0x9977
clr.dll!StrongNameErrorInfo+0xa5bc
clr.dll!StrongNameErrorInfo+0xa553
clr.dll!StrongNameErrorInfo+0xa517
clr.dll!StrongNameErrorInfo+0xa151
clr.dll!StrongNameErrorInfo+0x9501
clr.dll!StrongNameErrorInfo+0xad67
clr.dll!StrongNameSignatureVerification+0x164d9
ntdll.dll!RtlCreateUserProcess+0x8c
ntdll.dll!RtlCreateProcessParameters+0x4e

我能找到的唯一类似帐户就是这个问题:clr.sll!StrongNameSignature验证CPU耗尽虽然线程似乎已经冷了.

我们不签署我们的程序集并且愿意信任它们,有没有办法完全禁用强名称验证？