Qualcosa di sbagliato nel NON firmare un assembly .NET?

Uno dei miei colleghi è molto entusiasta di firmare le assemblee. Cerca letteralmente di firmare qualsiasi cosa. Anche quando usiamo assembly di Microsoft che non sono firmati, prenderà il codice sorgente, lo firmerà e poi chiederà ad altri sviluppatori di usare invece la sua copia.

Riesco a capire l'idea di base alla base della firma di un assembly: per garantire che un particolare assembly non venga compromesso da qualche malintenzionato hacker. Quindi, se siamo una società di sviluppo software, dobbiamo firmare il nostro assembly prima di rilasciare una libreria .NET ai nostri clienti.

Tuttavia, sviluppiamo principalmente applicazioni web per il nostro uso qui e non riesco a vedere il punto di firmare ogni singolo assembly che usiamo.

Mi manca qualcosa qui?

La firma di assembly utilizzati in un ambiente attendibile mi sembra eccessivo.

Un punto interessante sugli assembly firmati è che sono leggermente più lenti da caricare rispetto agli assembly non firmati, poiché devono essere verificati crittograficamente.

Per firmare un assembly, devono essere firmati anche tutti gli assembly da cui dipende. La mia ipotesi è che questo contribuisca al desiderio del tuo collega di firmare tutto - il compilatore lo richiede.

EDIT Da quando ho scritto questa risposta puoi vedere che sia il campo pro che quello contro hanno un supporto più o meno equivalente. Chiaramente non c'è una risposta giusta qui.

Il punto che ha costretto questa modifica, però, è che oggigiorno prendiamo così tante librerie open source da NuGet e molte di esse non sono affatto firmate. Se si desidera firmare l'assembly, è necessario che anche le dipendenze vengano firmate. Molte delle librerie open source firmate hanno le chiavi private utilizzate per la firma disponibili pubblicamente nei loro repository di origine.

Come per tutto, ci sono dei compromessi da fare. Nella mia esperienza di lavoro in ambienti privati, i vantaggi della firma sono per lo più teorici (o accademici, come cita @ user289100 ), a meno che tu non sia preoccupato per le agenzie governative che modificano il tuo codice, nel qual caso devi essere paranoico su così tanti livelli di la tua infrastruttura che la firma sembrerebbe un piccolo sforzo. Altrimenti la quantità di sfide che derivano dal dover firmare tutto non sembra valerne la pena. Tuttavia il tuo ambiente potrebbe avere requisiti diversi o potresti essere un masochista!

Vedere anche la risposta di Teun D per informazioni sulle sfide relative agli assembly di controllo delle versioni quando si utilizzano nomi sicuri.

Ho approfittato delle assemblee non firmate per aggirare i problemi prima e in contesti accademici ho mostrato alle persone perché è importante. Ho sostituito un file DLL che non era firmato (di nuovo in un ambiente accademico) con uno che avevo creato con lo stesso nome, stesse firme e ho utilizzato .NET Reflector per copiare e incollare il codice originale, ma nel mio ho inviato tramite e-mail nomi utente e password che venivano passati prima di chiamare il codice "reale".

Se firmato, puoi creare una corrispondenza della firma, ma non sostituirla. Contrariamente a quanto dice Zippy, ci sarà un errore di compilazione in fase di esecuzione.

La firma delle assemblee non è mai eccessiva. Ci vogliono 30 secondi. È come dire che chiudere le porte è eccessivo se vivi in ​​campagna. Se vuoi giocare d'azzardo con le tue cose, vai avanti, lascialo aperto. Basta una violazione della sicurezza per essere licenziato. Ci vogliono solo 30 secondi per firmare un'assemblea e non ci sono casi aziendali per non farlo. L'impatto sulle prestazioni è trascurabile.

Un altro punto: la firma degli assembly interrompe la compatibilità con le versioni precedenti. I tuoi riferimenti iniziano tutti a includere numeri di versione e le versioni con altri numeri di versione sono considerate non compatibili. Ciò impedisce l'aggiornamento a versioni più recenti di assembly distribuiti.

A mio parere, dovresti solo firmare il codice degli assembly se vedi qualche guadagno concreto da esso:

• se si distribuisce in ambienti in cui persone non attendibili potrebbero toccare i propri assembly
• in alcuni modelli di plug-in, in cui si desidera utilizzare il certificato come prova per l'aggiornamento del trust
• se il tuo codice dovrebbe essere richiamabile da un altro codice firmato (un progetto come, diciamo log4net, firma giustamente il loro codice per essere ampiamente utilizzabile; hanno incasinato enormemente la compatibilità perdendo la loro chiave segreta alcuni anni fa, un altro rischio di firma del codice) .
• se vuoi eseguire il deployment nel GAC

Il tuo collega ti ha dato indicazioni sul motivo per cui gli piace firmare le assemblee? Un vantaggio della firma che non è stato ancora discusso qui è che solo gli assembly firmati possono essere inseriti nella GAC ​​(cioè essere condivisi tra i processi gestiti), ma gli svantaggi sembrano superare gli aspetti positivi dal mio punto di vista (certamente inesperto).

Il tuo aneddoto sulla firma automatica del codice Microsoft mi sembra particolarmente sospetto. Se MS non ha firmato il codice, probabilmente c'è un motivo, giusto? E firmandolo, ti prendi la responsabilità quando non l'hai scritto - un'altra opportunità per il futuro di morderti.

Un altro aspetto della firma di un'assemblea è che non si può iniettare uno sbagliato al posto del tuo (anche tu per sbaglio). Ad esempio, se crei un programma che fa riferimento a un assembly Foo.dll, versione 1.0, qualcuno può creare un assembly, con la stessa versione, e sostituire il tuo, quando firmi la tua libreria, non sarà possibile (all'indirizzo almeno non credo sia facilmente possibile).

Le firme sono necessarie solo se gli assembly vengono inseriti nella GAC, nient'altro. Le assemblee firmate non impediscono a qualcuno di scherzare con loro. Un hacker può comunque rimuovere la firma e qualsiasi altro codice che controlla la firma.

Sono d'accordo, sembra un po 'uno spreco. È davvero necessario per garantire che il file sia quello che pensi che sia (e non sia stato manomesso). Ma se ti fidi dei confini della tua sicurezza di rete e del tuo server web, la firma dei tuoi web assembly sembra un passaggio ridondante.

Ma forse è questa la mia esperienza da piccola impresa a parlare. Se stai parlando di un sito Web di online banking mission-critical, allora esci.

Pensa a farlo se hai intenzione di spedire qualcosa e / o hai effettivamente un motivo per farlo. In ogni altro caso, è solo una seccatura. Chiederei al tuo compagno di lavoro cosa ne ricava realmente.

Ho già incontrato assemblaggi firmati in passato ed è un problema nel retro, soprattutto se si considera la quantità di persone che hanno poca o nessuna conoscenza di firmare assemblee, a cosa servono e come farlo. È solo un'altra cosa di cui non dovresti preoccuparti a meno che non sia assolutamente necessario.

È necessario firmare l'assembly quando viene utilizzato in un XBAP ClickOnce distribuito dal Web .

Inoltre, tutti gli assembly a cui si fa riferimento dovranno essere firmati.

Firmiamo i nostri assembly perché ci sono momenti in cui otteniamo errori come il seguente (questo proviene da test, ma può verificarsi durante l'esecuzione dell'applicazione):

System.IO.FileLoadException : Could not load file or assembly 'Latitude.Platform.Core, Version=1.0.5871.22518, Culture=neutral, PublicKeyToken=7926214d13e12325' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

TearDown : System.IO.FileLoadException : Could not load file or assembly 'Latitude.Platform.Core, Version=1.0.5871.22518, Culture=neutral, PublicKeyToken=7926214d13e12325' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Abbiamo scoperto che Visual Studio a volte sbaglia e esegue il vecchio codice .

Se desideri un errore se stai eseguendo un codice vecchio, firma i tuoi assembly.

Se stai scrivendo un pacchetto nuget , firma i tuoi assembly . Gli assembly non firmati sono scomodi per noi che vogliamo essere sicuri di eseguire l'ultima versione del nostro codice. Non riesco a riparare Visual Studio . Tutto quello che posso fare è rilevare che Visual Studio ha sbagliato. Quindi, per favore, firma le tue assemblee di nuget .