Claudio Brotto

Key Path negli assembly del CLR

Ogni volta che faccio un giro con Reflector/ILDASM scopro qualcosa di nuovo.

L'ultima, in ordine di tempo, è il percorso della chiave con la quale gli assembly del CRL/FCL (v1.1) sono stati firmati da Microsoft sulla(e) macchina(e) di build.

Ecco un breve (!!) e parziale elenco:

  • mscorlib.dll --> E:\com99\bin\EcmaPublicKey.snk
  • system.dll   --> E:\DNA\public\tools\common\security\EcmaPublicKey.snk 
  • system.configuration.install.dll   --> E:\DNA\public\tools\common\security\FinalPublicKey.snk
  • system.data.dll   --> E:\DNA\public\tools\common\security\EcmaPublicKey.snk
  • system.data.oracleclient.dll   --> E:\DNA\public\tools\common\security\EcmaPublicKey.snk
  • system.design.dll --> E:\DNA\public\tools\common\security\FinalPublicKey.snk
  • system.directoryservices.dll --> E:\DNA\public\tools\common\security\FinalPublicKey.snk
  • system.drawing.dll --> E:\DNA\public\tools\common\security\FinalPublicKey.snk
  • system.drawing.design.dll --> E:\DNA\public\tools\common\security\FinalPublicKey.snk
  • system.enterpriseservices.dll --> E:\com99\bin\FinalPublicKey.snk
  • system.management.dll --> FinalPublicKey.snk
  • system.messaging.dll --> E:\DNA\public\tools\common\security\FinalPublicKey.snk
  • system.remoting.dll --> E:\com99\bin\EcmaPublicKey.snk
  • system.runtime.serialization.formatters.soap.dll --> E:\com99\bin\FinalPublicKey.snk
  • system.security.dll --> E:\com99\bin\FinalPublicKey.snk
  • system.serviceprocess.dll --> E:\DNA\public\tools\common\security\FinalPublicKey.snk
  • system.web.dll --> E:\DNA\public\tools\common\security\FinalPublicKey.snk
  • system.web.mobile.dll --> E:\DNA\public\tools\common\security\FinalPublicKey.snk
  • system.web.regularexpressions.dll --> E:\DNA\public\tools\common\security\FinalPublicKey.snk
  • system.web.services.dll --> E:\DNA\public\tools\common\security\FinalPublicKey.snk
  • system.windows.forms.dll --> E:\DNA\public\tools\common\security\EcmaPublicKey.snk
  • system.xml.dll --> E:\DNA\public\tools\common\security\EcmaPublicKey.snk

Vista in un altro modo, MS ha usato le seguenti copie:

  • E:\com99\bin\EcmaPublicKey.snk
  • E:\com99\bin\FinalPublicKey.snk
  • E:\DNA\public\tools\common\security\EcmaPublicKey.snk
  • E:\DNA\public\tools\common\security\FinalPublicKey.snk
  • FinalPublicKey.snk (path relativo !!)

di due chiavi differenti, il cui hash (aka PublicKeyToken) riporto qui sotto:

  • b77a5c561934e089 (EcmaPublicKey)
  • b03f5f7f11d50a3a (FinalPublicKey)

Due cose mi hanno colpito.

La prima: date due chiavi, ciascuna è caricata da almeno due file differenti (in un caso, system.management.dll, essa addirittura risiede in un path relativo rispetto al file che contiene l'attributo AssemblyKeyFileAttribute). Il che fa presupporre (non è detto, comunque) l'utilizzo di due macchina di build distinte.

La seconda: hanno usato chiavi prelevate da file, invece che da un container (soluzione, quest'ultima, un po' più sicura ...).

Non capisco bene la ragione di queste scelte.

Cosa mi sono perso ?

Update: se non lo avete letto, il commento di Marco Russo chiarisce questo comportamento.

powered by IMHO 1.2

Posted: apr 02 2005, 02:55 by devlizard | with 2 comment(s)
Filed under:

Comments

devlizard said:

Claudio,
in Microsoft per evitare di compromettere la chiave privata usano il Delay Signing: in compilazione mettono solo la chiave pubblica (lasciando vuota la firma digitale, quindi l'assembly non sarebbe verificabile) e solo quando l'assembly viene distribuito passa da una macchina in cui viene firmato digitalmente con la chiave privata, che risiede su una smart card esterna.
I percorsi che vedi sono relativi alla sola chiave pubblica, che serve durante la compilazione (e copie di quel file possono essercene milioni).
# aprile 2, 2005 11:30

devlizard said:

Ecco cosa mi ero perso !
Grazie Marco !
# aprile 3, 2005 11:34