Perché utilizzare assembly con nome sicuro?

107

Quali sono i vantaggi dell'utilizzo di assembly con nome sicuro?

Quali sono le cose che non si possono fare con un normale assemblaggio?

c# .net

— sviluppatore
fonte

92

Vorrei prima elencare i vantaggi di una denominazione forte dell'assembly:

Una forte denominazione dell'assembly consente di includere l'assembly nella Global Assembly Cache (GAC). In questo modo ti consente di condividerlo tra più applicazioni.
La denominazione forte garantisce un nome univoco per quell'assembly. Quindi nessun altro può usare lo stesso nome di assembly.
Il nome sicuro protegge la derivazione della versione di un assembly. Un nome sicuro può garantire che nessuno sia in grado di produrre una versione successiva dell'assembly. Agli utenti dell'applicazione viene garantito che una versione dell'assembly che stanno caricando provenga dallo stesso editore che ha creato la versione con cui è stata creata l'applicazione.

Ulteriori informazioni sulla denominazione sicura di Microsoft sono disponibili in Strong-Named Assembly ( MSDN ).

— Kyle Rosendo
fonte

1

Sei sicuro dell'articolo 4? Penso che forse questo comportamento sia cambiato di recente. Ho provato a far fallire il caricamento di un assembly con nome sicuro modificandolo, ma è stato caricato senza incidenti.

— Jens

19

Per quanto riguarda il n. 4 non è corretto. Non è progettato per proteggere da manomissioni. Vedi blogs.msdn.com/b/shawnfa/archive/2005/12/13/… per ulteriori informazioni.

— Colin Bowern

1

@ RobV8R Il 90% delle nostre dipendenze sono opensource, le chiavi private sono nei repository git pubblici (secondo le raccomandazioni di Microsoft) e disponibili a chiunque le desideri.

— Trampster

1

@ RobV8R Non puoi usare la parola compromesso qui, ciò significherebbe che è inteso come un segreto in primo luogo. Le linee guida di Microsoft indicano che la chiave privata deve essere conservata nel repository di origine pubblica. Le chiavi private non sono compromesse, vengono pubblicate intenzionalmente. Dato che le chiavi private sono note e destinate ad essere utilizzate da persone che modificano il codice opensource dei progetti padre (altrimenti la licenza verrebbe violata in molti casi), le persone che lo fanno userebbero un numero di versione diverso ma la stessa chiave, in questo caso sarebbe richiesto un reindirizzamento vincolante.

— Trampster

1

@ RobV8R Quello che stavo cercando di capire è che molte persone credono che una denominazione forte garantisca che la tua dipendenza sia bloccata su una versione specifica di un assembly, e semplicemente non è così, un semplice reindirizzamento dell'associazione può cambiare la versione che usi purché è stato firmato con la stessa chiave privata. E come ho detto, le chiavi private vengono pubblicate intenzionalmente per la maggior parte delle nostre dipendenze.

— Trampster

9

Quali sono le cose che non si possono fare con un normale assemblaggio?

Poiché tutte le discussioni iniziate con l'ascesa di Nuget suggerivano di eliminare completamente gli assembly con nome forte, la mia azienda ci ha provato e ha riscontrato un cambiamento significativo nel comportamento quando si tratta di impostazioni dell'applicazione:

Se utilizzi l'app automatica o le impostazioni dell'applicazione con ambito utente fornite da VisualStudio (ereditando System.Configuration.ApplicationSettingsBase), un EXE con nome sicuro creerà esattamente 1 directory all'interno di% LOCALAPPDATA% denominata ad esempio "YourApplication.exe_StrongName_kjsdfzsuzdfiuzgpoisdiufzsdouif", indipendentemente da dove si trova l'EXE trova.

Ma senza il nome sicuro, la posizione (= percorso) dell'EXE verrà utilizzata per creare un valore hash che è già diverso tra DEBUG e RELEASE build, creando molte directory all'interno di% LOCALAPPDATA% denominate come "YourApplication.exe_Url_dfg8778d6fs7g6d7f8g69sdf". Ciò lo rende inutilizzabile per le distribuzioni ClickOnce in cui la directory di installazione cambia a ogni aggiornamento.

— springy76
fonte

5

Vorrei aggiungere che senza un nome sicuro non è possibile utilizzare i reindirizzamenti vincolanti nei file di configurazione.

Questo non funzionerà:

  <dependentAssembly>
    <assemblyIdentity name="MyAssembly.MyComponent" publicKeyToken="null" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
  </dependentAssembly>

Devi avere un token di chiave pubblica

  <dependentAssembly>
    <assemblyIdentity name="MyAssembly.MyComponent" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
  </dependentAssembly>

— tomasat
fonte

9

I reindirizzamenti vincolanti non sono necessari se non si utilizza un nome sicuro.

— Trampster

0

Solo un esempio: vorrei dare una risposta facendo più enfasi nella sicurezza . Nel caso in cui creiamo assembly con un codice sorgente che non vogliamo essere riutilizzato per una terza parte ma vogliamo che sia testabile, possiamo firmare fortemente un assembly e rendere visibili gli interni solo per quegli assembly con il stessa firma.

— Ricky Youssef
fonte