Quelle est la méthode recommandée pour gérer une paire de clés de nom fort pour un projet open-source?

Question

Je gère un projet open-source et que vous souhaitez signer les binaires qui sont libérés dans le paquet binaire du projet. J'utilise les fichiers csproj et sln Visual Studio pour gérer et construire mon projet, et distribuer ces fichiers dans le cadre des paquets sources du projet.

Comment puis-je signer les binaires produits de ma construction et ne pas avoir à distribuer le fichier snk paire de clés? Si j'utiliser Visual Studio pour signer les assemblées, chaque dossier de projet maintenant besoin d'une copie de la paire de clés afin de construire. Je ne suis pas à l'aise avec la distribution de la paire de clés, même si elle est un mot de passe protégé.

Modifier :

Une autre mise en garde est que certaines assemblées dans la subvention du projet accès ami via InternalsVisibleToAttribute et construire ces amis via une référence de projet. Par conséquent, ces assemblées doivent utiliser un nom fort en se référant à un ensemble signé. Toutefois, si la paire de clés ne sont pas distribués alors comment les utilisateurs finaux peuvent construire les sources et maintenir les rapports de projet? Si un fichier temporaire paire de clés est utilisé, ne sera pas le jeton de clé publique du changement des assemblées signé, brisant les références InternalsVisibleToAttribute?

Answer 1

la solution de Sharptooth fonctionne bien si les seules références de montage dans le code sont celles codées dans les fichiers du projet. Si votre projet fait référence à d'autres assemblées via InternalsVisibleToAttribute ou d'autres moyens où une chaîne de nom fort est nécessaire, alors il est impossible de construire le référentiel-sources avec une clé temporaire. Cela changera les références clés publiques qui sont présents dans les chaînes nom fort et de briser le code.

Ceci est le cas dans ma demande si je devais adopter une approche différente.

Je essentiellement créé une copie des fichiers sln et csproj dans un dossier séparé et modifié les heirarchy fichiers csproj comme suit.

• Transformé toutes les références de fichiers à liens, pointant vers les sources originales.
• et modifié chaque Copié fichier AssemblyInfo.cs pour contenir les utilisations de InternalsVisibleToAttribute avec un nom fort.
• modifié chaque fichier csproj de sorte que la référence de fichier snk est un chemin relatif (supprime la nécessité de copier le fichier snk à chaque projet)

J'ai d'abord fait tout cela manuellement, mais alors réalisé que cela peut être automatisée de façon simple. Les première et troisième étapes peuvent être mises en oeuvre avec un XSLT, alors que la deuxième étape peut être mise en oeuvre avec une recherche / remplacement fonction regex.

Depuis que je dois maintenir deux solutions maintenant, il est logique d'automatiser cette tâche pour éviter des maux de tête futurs.

Les sources dans le référentiel ne pas construire des ensembles avec de solides noms, ce qui est bien, car je ne voudrais pas imposer des restrictions de construction ou de processus sur les utilisateurs finaux.

Answer 2

Vous ne devriez pas distribuer le keypair. Le StrongName est de vérifier que la nouvelle version de l'ensemble provient de la même éditeur.

Si un autre développeur veut ramifier votre projet, ils vont générer leur propre paire de clés et qui montrera efficacement que leur version est pas de vous afin que d'autres assemblées qui dépendent de la vôtre ne se charge plus à moins qu'ils ne soient recompilés. Ce n'est pas toujours pratique, mais il vous protège de quelqu'un délivrer une version malveillante de l'assemblage et la distribution en silence.

Answer 3

Ceci est une vieille question, mais la réponse actuellement la plus haute voté n'est pas exacte, donc je me suis dit qu'il vaut la peine de poster une nouvelle réponse.

Pour les projets open source, Microsoft recommande de vérifier dans votre clé privée dans votre référentiel. Ceci est en sécurité parce que les clés de nom fort sont utilisés pour l'identité, pas de sécurité.

Voir ici pour référence: https: //docs.microsoft.com/en-us/dotnet/framework/app-domains/strong-named-assemblies

  

Ne comptez pas sur des noms forts pour la sécurité. Ils fournissent une identité unique seulement.

Ils ont également traitent spécifiquement des projets open source:

  

Si vous êtes un développeur open-source et que vous voulez les avantages d'identité d'un ensemble nom fort, pensez à vérifier dans la clé privée associée à un ensemble dans votre système de contrôle de code source.

Si vous voulez la sécurité pour vos assemblées, alors vous devriez regarder dans Authenticode signature : https://blogs.msdn.microsoft.com/shawnfa/2005/12/13/authenticode-and-assemblies/