Why no code signing? about packetnet HOT 10 CLOSED

Hi @Tra5is!

How does code signing work? Do we need a certificate of some kind? Do we enable it through appveyor?

Chris

from packetnet.

This looks like a pretty thorough walkthrough - https://natemcmaster.com/blog/2018/07/02/code-signing/

But I'm not sure that the Azure Key Vault is really needed if using an encrypted PFX. The password for the PFX would go into an appveyor secret and used during the code signing step.

It looks like you'll need a cert that's trusted by MS, and will cost some $$.

from packetnet.

Hi @Tra5is. Yeah it looks like the certs are hundreds yearly. I'd be happy for the funding to purchase and maintain such a key but this is an open source project so there isn't much motivation to do so at this point :-)

from packetnet.

No one wants to pay for a cert to sign the library so closing this ticket out.

from packetnet.

Reopening, I don't think you actually need to purchase a certificate. All that's required is a snk file which you can generate yourself for free. https://docs.microsoft.com/en-us/dotnet/standard/assembly/sign-strong-name There are several projects that just have this snk file commited in repository. I think we can do the same.

from packetnet.

Be aware that strong naming the assembly prevents the possibility to "swap in" API-compatible newer versions of the assembly into the larger systems - but making that possible is required by the LPGL. Effectively, .NET strong naming is incompatible with LPGL.

from packetnet.

The key file can be added to the repository (it doesn't need to be kept a secret). Quite a lot of packages do that nowadays, this way it should also be possible to create builds manually (as a drop-in replacement).

from packetnet.

But the licensing problem remains even when the key file is public. Whenever somebody references an assembly that is strong named, that assembly file cannot be exchanged for a new version of it (unless you want to keep the version number always the same) - when you attempt to do so, the assembly will reject to load. This means that you cannot swap in a newer version, even when signed with the same key. And that means you cannot fulfill the LGPL conditions.

from packetnet.

The version number issue also exists without a public key; if you reference an unsigned assembly with version x.x.x.x and then copy unsigned x.x.x.y in then you'll need to use assembly redirection. You can also redirect assemblies with a publicKeyToken, it would only break cases when you're currently having binding redirects defined for non-signed and then start using the signed version, but that's acceptable for this change.

from packetnet.

Oh... you are right. It is not possible to redirect to an assembly signed with a different key, but it is possible to redirect to a different version of that assembly - when the same key is used for signing. My fault.

from packetnet.