mono and snk key files

[Kalev Lember]

Hello,

I'm writing this to fedora-devel list and also cross-posting to 
fedora-mono, as the latter seems rather dead but might be useful for 
archiving purposes.

I am not very familiar with Mono and .NET technology, so if I get 
something wrong, please correct me. I'm also neither nant's nor 
log4net's maintainer; I just saw that a large part of Mono is currently 
broken in rawhide and tried to figure out the root cause.

Mono assemblies that get installed into GAC need to be 
strongname-signed. The resulting public key token gets placed into the 
assembly (DLL), and uniquely identifies a series of assembly releases 
that are all API/ABI compatible. When the assembly manufacturer releases 
an API-compatible updated version, they would strongname-sign the update 
with the same snk key as the previous release. This is supposed to 
prevent DLL hell: applications reference the public key token, and if 
there's an updated DLL with the same public key available, then 
applications are automatically redirected to the new version.

There are several Mono source packages in Fedora that don't ship an .snk 
key file. The reason why the file sometimes isn't shipped with the 
source is probably this: upstream developers want to be able to create 
binary releases which are guaranteed to be API compatible, and don't 
want anyone else to sign non-compatible versions with the same key.

However, since assemblies installed into the GAC need to be signed, 
several Fedora packages generate the public key files during build time. 
With this approach every single build gets signed with a DIFFERENT snk 
file, making every new build incompatible with the previous one.

Right now nant is broken [1] in Fedora because someone rebuilt log4net. 
During the rebuild a new strong name key was generated, and log4net was 
signed with the new key. However, since nant was built against the 
previous log4net build, it is no longer able to find the rebuilt log4net 
assembly which is signed with a new key. Result: nant breaks, and with 
that also log4net breaks [2], because it uses nant for building itself. 
This situation not only applies for log4net, but for many different Mono 
libraries.

Historically nant appears to have been fixed with bootstrapping [3]. 
Nant's source distribution contains a bunch of binary dll files. Someone 
has to flip a switch in the spec file so that nant uses those binary 
files to build itself. After that bootstrapping is disabled and nant is 
rebuilt against the assemblies from the system.

However, this approach doesn't scale if every single update / rebuild 
needs to have nant manually bootstrapped/debootstrapped.

I'd suggest to fix this changing the way snk files are generated. 
Instead of automatically generating a new key at build time, it should 
instead be generated once, and stored in cvs / lookaside cache. It would 
then be at a package maintainer's discretion to regenerate the snk file 
whenever an API incompatible update is made. However, casual rebuilds 
would be done with the same strongname key, making sure that everything 
depending on the assembly doesn't get automatically broken with each 
rebuild.

Comments?


[1] https://bugzilla.redhat.com/show_bug.cgi?id=538908
[2] https://bugzilla.redhat.com/show_bug.cgi?id=539189
[3] 
https://www.redhat.com/archives/fedora-devel-list/2009-October/msg01399.html

-- 
Kalev