5

I have an open source C# project, Succint<T>, for which I wish to create a strongly typed assembly version. I plan on making the key file for this public, by adding it to the GitHub repository, in order to keep the whole thing open source.

The obvious consequence of this is that someone else could modify the code in a malicious way, sign it with that key file, and naive users who think that a signed assembly somehow implies security could be tricked into using it.

Whilst I'd not wish that to happen to anyone, my concern is that the affected user might try to hold me responsible. So my question is, does the MIT licence wording absolve me of responsibility in such an eventuality?

  • 1
    I don't have time for a full answer right now, but please don't do it until you get some more feedback – Martijn Nov 18 '15 at 22:58
  • @Martijn, no worries, I shall await that further feedback. – David Arno Nov 18 '15 at 23:32
6

I'd add instructions for somebody else to cook up their own key, and sign (and verify) with that. Also publish somewhere you have total control the key to check the signature. The signing key should not be distributed in any way, as that just would void any protection the "signed by the original developer" could provide.

  • 1
    I think this is probably my best option. The code is covered by the MIT licence, so they are free to copy it and build it themselves, applying a key in the process. Thanks. – David Arno Nov 19 '15 at 12:44
5

It's better not to sign an assembly at all than to make the signing key public. Publishing the signing key accomplishes nothing and does have downsides.

A strong-named assembly has as advantage over a non-strong-named assembly that you can be sure that two assemblies with the same strong name are identical. To provide this guarantee, the private key has to be just that: private.

Once the private key leaks, all guarantees a strong-named assembly offers are lost. It effectively becomes as useful as a non-strong-named assembly, but gives a false sense of security.

From an open source perspective, there is nothing wrong with keeping the signing key private. People are still able to fork, and sign the assembly themselves, if they want to do so. End users lose the flexibility to dynamically link against a different version of the assembly if the person who linked against the work used a strong named assembly.

This is intentional. If the software that incorporates the singed assembly is open source as well, the user can change the combination themselves. If it's propriety, this may be a problem for end users, but a problem with the propriety software, not with the open-source parts.

Also, publishing the private key will not help you in this scenario. The publisher of the propriety software could just as well build and sign the dependency with their own private key, which you don't have and can't publish, leaving end users in the same predicament.

  • 1
    Thanks for your answer. I do not want to get involved in maintaining a secret private key, so @vonbrand's suggestion of letting the user sign it if they need to seems the best option to me. – David Arno Nov 19 '15 at 12:45
  • 1
    @DavidArno off-topic: you may want to reach out to Tony Morris of github.com/NICTA/xsharpx to see if collaboration is possible. – Martijn Nov 19 '15 at 13:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.