mono and snk key files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux