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
The packages that run "sn -k" from .spec file and thus affected by the problem are:
mono-sharpcvslib mono-cecil-flowanalysis mono-ndoc mono-nunit22 log4net
2009/11/29 Kalev Lember kalev@smartlink.ee:
Hello,
<snip>
Comments?
I'm the maintainer for log4net but unfortunately not for nant. I've finally gotten around to looking at this.
Debian have a policy[1] of using a standard mono.snk which is provided by a package (I guess we just then BuildRequires this) and I think this seems like a good solution but have no experience of this.
Paul Johnson looks after a good deal of the mono stuff so happy to be guided by him really.
I imagine Spot will want to have a say as it looks like he has been doing the heavy-lifting when each rebuild takes place and this is clearly a pain[2]:
Thanks for raising this Kalev!
Cheers
On 11/29/2009 11:29 AM, Christopher Brown wrote:
2009/11/29 Kalev Lember kalev@smartlink.ee:
Hello,
<snip>
Comments?
I'm the maintainer for log4net but unfortunately not for nant. I've finally gotten around to looking at this.
Debian have a policy[1] of using a standard mono.snk which is provided by a package (I guess we just then BuildRequires this) and I think this seems like a good solution but have no experience of this.
We should definitely use Debian's key, right? Otherwise some Fedora CLI libraries would be unnecessarily incompatible with Debian, and whoever else uses Debian's key.
The whole business of not shipping code-signing keys is a little contrary to open source. I think this is something that GPLv3 would prohibit. We should use a single well-known signing key for any package that we don't have the keys for, I think.
Adam
2009/12/11 Adam Goode adam@spicenitz.org:
On 11/29/2009 11:29 AM, Christopher Brown wrote:
2009/11/29 Kalev Lember kalev@smartlink.ee:
Hello,
<snip>
Comments?
I'm the maintainer for log4net but unfortunately not for nant. I've finally gotten around to looking at this.
Debian have a policy[1] of using a standard mono.snk which is provided by a package (I guess we just then BuildRequires this) and I think this seems like a good solution but have no experience of this.
We should definitely use Debian's key, right? Otherwise some Fedora CLI libraries would be unnecessarily incompatible with Debian, and whoever else uses Debian's key.
The whole business of not shipping code-signing keys is a little contrary to open source. I think this is something that GPLv3 would prohibit. We should use a single well-known signing key for any package that we don't have the keys for, I think.
You're right.
This has already been resolved in devel by added mono.snk to the mono-devel package. I'm just waiting on commit access to make the required changes to F-11 and F-12 unless someone else wants to do it.
Best
On 12/13/2009 06:16 AM, Christopher Brown wrote:
2009/12/11 Adam Goode adam@spicenitz.org:
We should definitely use Debian's key, right? Otherwise some Fedora CLI libraries would be unnecessarily incompatible with Debian, and whoever else uses Debian's key.
The whole business of not shipping code-signing keys is a little contrary to open source. I think this is something that GPLv3 would prohibit. We should use a single well-known signing key for any package that we don't have the keys for, I think.
You're right.
This has already been resolved in devel by added mono.snk to the mono-devel package. I'm just waiting on commit access to make the required changes to F-11 and F-12 unless someone else wants to do it.
It looks like spot generated a new mono.snk. I was arguing to use Debian's mono.snk, for cross-distro compatibility. Shouldn't everyone should use Debian's key unless a package provides its own?
Adam
2009/12/15 Adam Goode adam@spicenitz.org:
On 12/13/2009 06:16 AM, Christopher Brown wrote:
2009/12/11 Adam Goode adam@spicenitz.org:
We should definitely use Debian's key, right? Otherwise some Fedora CLI libraries would be unnecessarily incompatible with Debian, and whoever else uses Debian's key.
The whole business of not shipping code-signing keys is a little contrary to open source. I think this is something that GPLv3 would prohibit. We should use a single well-known signing key for any package that we don't have the keys for, I think.
You're right.
This has already been resolved in devel by added mono.snk to the mono-devel package. I'm just waiting on commit access to make the required changes to F-11 and F-12 unless someone else wants to do it.
It looks like spot generated a new mono.snk. I was arguing to use Debian's mono.snk, for cross-distro compatibility. Shouldn't everyone should use Debian's key unless a package provides its own?
Ideally we (Fedora and Debian) should use a single key generated by upstream but as this issue is only problematic due to cyclic dep problems in the build process I think that using our own is enough. Unfortunately I don't care enough to chase this issue further.
On 12/19/2009 11:03 AM, Christopher Brown wrote:
2009/12/15 Adam Goode adam@spicenitz.org:
On 12/13/2009 06:16 AM, Christopher Brown wrote:
2009/12/11 Adam Goode adam@spicenitz.org:
We should definitely use Debian's key, right? Otherwise some Fedora CLI libraries would be unnecessarily incompatible with Debian, and whoever else uses Debian's key.
The whole business of not shipping code-signing keys is a little contrary to open source. I think this is something that GPLv3 would prohibit. We should use a single well-known signing key for any package that we don't have the keys for, I think.
You're right.
This has already been resolved in devel by added mono.snk to the mono-devel package. I'm just waiting on commit access to make the required changes to F-11 and F-12 unless someone else wants to do it.
It looks like spot generated a new mono.snk. I was arguing to use Debian's mono.snk, for cross-distro compatibility. Shouldn't everyone should use Debian's key unless a package provides its own?
Ideally we (Fedora and Debian) should use a single key generated by upstream but as this issue is only problematic due to cyclic dep problems in the build process I think that using our own is enough. Unfortunately I don't care enough to chase this issue further.
Yeah, I think there is very little merit in giving any amount of trust to that key, nor is there any real value in picking up mono bits built for Debian and putting them on Fedora and expecting them to work (or vice versa).
~spot
-
Adam Goode -
Christopher Brown -
Kalev Lember -
Tom Callaway