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

Answer 1

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).

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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).

Answer 6

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.