Who should own the private key used to sign a .NET assembly when its project is open-source? [closed]_问答_开发者

Closed. This question is opinion-based. It is not currently accepting answers. 开发者_如何学Go

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 7 years ago.

Improve this question

More specifically, a class library assembly. My initial thoughts:

Have some designated administrators do all the assembly signing. But then when bug fixes and new versions are written, the binaries would ultimately depend on them being around (even if its just a small change for private reasons).
The key could be publicly available. But that goes against public-key cryptography practices and you lose the advantage of trust and identity.
Allow end-developers and distributors to sign it with their own keys. But then you lose modularization since each new signing makes it incompatible with some of the other versions.

Sure, you could just not sign the assembly. But if another project that requires their assembly to be signed references your library, you get a compile error.

I've recently encountered the same problem in an open-source project that I maintain. Here is how I addressed this issue:

Sources are always available for dowload via the repository, but a release will consist of a snapshot of the sources, plus a compiled version.
Prior to making the compiled version available, I sign the assemblies with my private key.

So in your case, whoever is preparing the release should own the key. There is no need for the library developers to know about it at all.

If end-users want to recompile and sign with their own keys, that's fine. You can distinguish between the binaries of yours and others by comparing the public key that is present in the signed assemblies. Make the public key available and others can do the same.

Managing this process gets a bit cumbersome when the InternalsVisibleToAttribute is used to refer to strong-named assemblies. You can read about how I addressed that problem here.

I for one would not mind if more projects that you are probably going to just use as a refrence instead of edit and re-compile would offer a "signed" version of the dll. That would help in trusting a refrence to an existing .dll quicker than checking the code and compiling your own.

In a lot of open-source project there is kind of a "Parent" of the effort, think Linus or even John Gruber for examples. These people could hold the key or distribute one to a trusted admin for signing major releases.

Strong naming is not intended to provide authenticity, validation, protection, or anything else like that. Its sole purpose is to provide a unique ID to an assembly or series of assemblies. This is so that you can have many assemblies named "Library" in the GAC, and when your application asks the runtime to load "Library", the system knows this means your "Library" assembly and not someone else's.

In light of this, I would simply include the strong name key in the source tree. If for some reason your project wants to provide authenticity or any of those other things, then you probably want Authenticode signing, which is not free and really is probably unnecessary for an open source project. If you decide to go that route and are wondering who should own the code signing key, that becomes more of a political question.

The question really revolves around who decides what is a release, doesn't it? If that is so, I think the releases should be signed with a personal key of the one actually being responsible for the release. If there are multiple persons responsible for creating releases there is nothing wrong with them sharing the key, except for higher risks of having to revoke/re-issue the key if one of the members of this group leaves.

In a broader scope, one has to admit, that .net doesn't really cater for re-using assemblies between multiple installed applications. Look into your SxS folder! So another way would always be for the distributor of the assembly to sign it with his own key. e.g. if a project uses log4net, it should sign the log4net assembly with its own key to take responsibility for its contents.

In Open Source, the "source" is open. Binaries are usually provided only for commodity.

Source does not need to be signed, if the binary is signed then the generator of the binary is also the owner of the secret key (which shall be kept secret).

Store the private key outside the source control root but referenced with a relative path. That way others can make builds using their own key. They'll be strongly signed but not official builds.

Setup an automatic build which has the full source tree and the private key. The auto-build can make official signed builds which can be released nightly or whatever. That way making official builds is automatic, so the authorized person holding the private key doesn't necessarily have to be involved (although you should have some mechanism in place for validating community contributed patches before including in an official build, but that's a separate issue really).

As far as I can remember I've never run into a signed open source project. If I needed it signed for some reason, I signed it myself. I can't really see an advantage to signing an assembly as such. If you're worried about the pre-compiled binary version being signed, then I would say just project management should have that key. A person creating a signed project though should be fully capable of adding the source code to their project, or creating the project's necessary signing and compiling it for themselves.