Signed Assemblies

[inforithmics]

Is it possible to Sign the assemblies? (Strong Naming)
Because to avoid tampering and because of a Third Party Component. I sign my Assemblies, But this requires that all referenced Assemblies are signed.

Changes in the Project file (in Project):

<PropertyGroup>
    <AssemblyOriginatorKeyFile>Keyfile.snk</AssemblyOriginatorKeyFile>
    <SignAssembly>true</SignAssembly>
 </PropertyGroup>

Or Visual:

[manuelbl]

Can you be more specific why signing would be beneficial?

Because to avoid tampering and because of a Third Party Component

In what scenario do you need to prevent tampering?

And what do you mean with "because of a Third Party Component"?

[inforithmics]

Third party component:
The License of the Third Party component is bound to the Strong Named Assembly
Name of my Project. So every Reference has to be strongly Named.

Tampering:
When an assembly is strongly Named, you cannot change the contents anymore, without resigning them with the (Secret) Private Key. For Example all .Net Framework Assemblies are strongly signed. So that nobody could create his own mscorlib.dll (With malicious changes).

Workaround:

Is used this Tool to Strongly name the Nuget Assemblies and Reference them as Assemblies.

• (The nuget package won't work).

https://github.com/brutaldev/StrongNameSigner

.Net Doku:
https://docs.microsoft.com/en-us/dotnet/standard/assembly/enhanced-strong-naming

[manuelbl]

I'm not very familiar with signing assemblies. So it will take some time to experiment with it and weigh the advantages against the disadvantages.

So far, I hardly see any advantages. I understand that a third party component makes your life more difficult as it requires strong named assemblies. Have you ever contacted the vendor of that component and asked them to provide a more convenient solution?

The tampering aspect seems irrelevant. Users of this library are free to tamper the library in any way they want. I don't care. And if I'm going to sign the assembly, I'm likely to publish the key anyway (according to best practices for open source software).

[inforithmics]

Made two pull request

Needs to be merged first:
manuelbl/QrCodeGenerator#1
And Version Number needs to be upgraded (because it is a breaking change it needs to be 2.0).

Needs to be merged afterwards:
#20
And the referenced nuget package needs to be updated to the new QrCodeGenerator Package
Also the Version Number needs to upgraded maybe to 3.0 Because of the Breaking change.

[manuelbl]

Thank you very much. I'll look into it by the end of the week.

[manuelbl]

Both the QR Generator (v1.6.0) and the Swiss QR Bill (v2.4.0) are now strong-named.

The key is part of the respective repository. So everybody can easily create modified libraries (as to the spirit of open-source software).

In the future, I will only increase the package version number and not the assembly version number in order to reduce binding redirects.

This changes only affect the .NET Framework, not .NET Core and the like.