mono November 2009

mono@lists.fedoraproject.org

1 participants
2 discussions

mono and snk key files
by Kalev Lember 29 Nov '09

29 Nov '09

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

1 0

mono-bouncycastle and itextsharp
by Kalev Lember 13 Nov '09

13 Nov '09

Hello, I have submitted two new Mono library review requests: mono-bouncycastle [1] and itextsharp [2]. This is my first time of dealing with Mono packaging in Fedora. Could someone please be so kind and take a quick look at those spec files to see if I didn't make any serious mistakes? Thanks! -- Kalev Lember [1] https://bugzilla.redhat.com/show_bug.cgi?id=537431 [2] https://bugzilla.redhat.com/show_bug.cgi?id=537437

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mono November 2009