projets OpenSource .NET et forts ensembles nommés?

Question

Je pense actuellement sur l'open-sourcing un de mes projets et je suis en train de préparer le code source et la structure du projet pour être diffusé au public. Maintenant, je suis arrivé à une question: comment dois-je gérer la clé de signature pour mes assemblées? Dois-je créer une nouvelle clé pour la version open-source et de le publier en même temps que les autres fichiers dans le dépôt SVN? Dois-je laisser la clé et tout le monde qui veut compiler le code doit générer sa propre clé?

Comment gérez-vous cela? Je me sens un peu mal à l'aise avec la libération d'une clé de signature au public.

Answer 1

Protocol Buffers , je libère la clé. Oui, cela signifie que les gens ne peuvent pas faire confiance en fait qu'il est le binaire d'origine -. Mais il rend la vie beaucoup plus facile pour tous ceux qui veulent modifier le code un peu, reconstruire, et être encore capable de l'utiliser d'une autre assemblée signé

Si quelqu'un veut vraiment une version de protocole qui buffers qu'ils peuvent faire confiance pour être sans aucun doute l'un légitime construit avec le code de GitHub, ils peuvent facilement construire eux-mêmes de la source qui ils ont confiance.

Je peux certainement voir des deux côtés bien. Je pense que si je devais écrire un projet Open Source qui tourne autour sécurité qui pourrait être une autre affaire.

Answer 2

Ne pas relâcher la touche.

Vous devriez vous sentir mal à l'aise libérer une clé de signature au public. Il n'est pas le la signature du projet . Il est Votre signature . L'intégrité de la signature sur le binaire est maintenue que si vous gardez votre clé secrète. Relâcher la touche subvertit le sens et l'intention des assemblées signées et nommer forte, qui introduit de nouvelles possibilités d'erreurs, et rend ainsi tous les systèmes moins fiables. Ne pas relâcher la touche .

DotNetZip , je ne libère pas la clé. Mais voici le point clé: La clé ne fait pas partie du projet; il est ma clé . Beaucoup de gens ont demandé la clé afin qu'ils puissent reconstruire le binaire signé, mais cela n'a pas de sens. J'utilise la clé pour signer plus de DotNetZip. Tout binaire signé avec cette clé est signée par moi, par définition. Tous les deux binaires qui ont le même nom fort en utilisant ma clé, sont garanties identiques. Clés supprime la libération de ces garanties, et défaites tout l'objet des noms forts et la sécurité qui les entoure.

Imaginez devs de choisir leurs propres numéros de version, et resigner un avec ma clé binaire modifiée. Maintenant, le monde aurait 2 assemblées avec le même nom fort, mais avec des contenus différents.

Imaginez si je pouvais signer tout ensemble avec la clé. Si vous avez sorti votre clé, je pourrais ajouter un code que j'ai aimé - même code malveillant - et le signer, et subrepticement remplacer tout « bon » binaire signé la vôtre avec un « mauvais ». Personne ne serait en mesure de faire la différence.

Ceci est cassé. partager librement clés élimine tout avantage à utiliser des assemblages signés du tout.

Si les gens veulent modifier le code dans un projet, puis ré-utiliser la version modifiée dans un assemblage fortement nommé, ils peuvent signer la version modifiée avec leur propre clé. Ce n'est pas difficile.

Answer 3

Je ne libérera pas la clé publique. Le point entier d'avoir un ensemble signé est que les gens peuvent avoir confiance que vous êtes le seul qui a touché le binaire, et donc s'il y a un code illégitime ajouté alors la signature est éteint et les gens savent ne pas faire confiance à l'Assemblée.

Signature assemblées vous protège d'autres personnes en ajoutant le code « mauvais » à votre binaire et faire semblant que c'est une version légitime.