mono and snk key files
by 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
14 years, 5 months
- 1
- 0
mono-bouncycastle and itextsharp
by Kalev Lember
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
14 years, 5 months
- 1
- 0
- ← Newer
- 1
- Older →