Question

我在Ubuntu上使用Mono。

在过去的某个时刻（当我使用股票时，Ubuntu回购中的古代单一开发），以下方法有效：

private void RegiseterAutoBleachCommand() { commands.CreateCommand("bleach") .Do(async (e) => { while (true) { Thread.Sleep(1000); int randomBleachIndex = rand.Next(bestBleach.Length); string bleachToPost = bestBleach[randomBleachIndex]; await e.Channel.SendFile(bleachToPost); } }); }
在.csproj中，将sn -k mykey.snk设置为上述.snk
在同一个.csproj中，将<AssemblyOriginatorKeyFile>设置为<SignAssembly>
在运行时，通过使用此来源模仿the Mono sn tool来自我验证.exe：

true

现在，如果我尝试上述操作，即使已明确告知项目在构建上签名，sn.Verify（）也会返回false。

失败的代码在Mono.Security：

    private static bool IsStrongNameSigned(string fileName)
    {
        // For details see
        // https://github.com/mono/mono/blob/master/mcs/tools/security/sn.cs

        const int keySize = 12, blobSize = 148;

        var an = AssemblyName.GetAssemblyName(fileName);
        byte[] publicKey = an.GetPublicKey();

        if (publicKey == null ||
                publicKey.Length < keySize + blobSize)
            return false;
        using (RSA rsa = CryptoConvert.FromCapiPublicKeyBlob(
                                 blob: publicKey, offset: keySize))
        {
            var sn = new StrongName(rsa);
            return sn.Verify(fileName);
        }
    }

在调试时，似乎特定的失败点在StrongHash。确实读取了签名，但它包含一个128字节的全零数组。

我可以确认MonoDevelop 7.1 IDE告诉csc使用密钥;请注意$ dpkg -S /usr/lib/mono/4.5-api/Mono.Security.dll mono-devel: /usr/lib/mono/4.5-api/Mono.Security.dll $ apt-cache show mono-devel Package: mono-devel Source: mono Version: 5.0.1.1-0xamarin5+debian7b1 Architecture: all Maintainer: Debian Mono Group <pkg-mono-group@lists.alioth.debian.org> Installed-Size: 75560 ...和/publicsign+：

/keyfile

我的问题是：

Mono的变化现在阻止了这种方法的运作？
有更好的方法来验证装配吗？
是否未能签署程序集的构建版本或未能找到签名的验证码？是否有一些单独的工具可以确认是哪种情况？

Answer 1

公开签名（/publicsign+）是我认为的罪魁祸首。与延迟签名类似，它不使用私钥生成签名，因此对于.NET Framework项目，运行时强名称验证将失败。

根据您的观察，Mono项目的验证也会失败，我认为这是设计的。您不应该使用公共签名，然后它可能会开始工作。

单声道强名称验证失败

1 个答案: