On 2011-08-08, Johannes Gustafsson wrote: > There are a few bugfixes in the trunk that I need and since there has been > no new release for a very long time, I tried to compile it myself. I created > a key and have successfully compiled it with no problems. However, I have > quite a few 3rd party dependencies that themselves are dependent on log4net. > These dependencies can't find load the new assembly that I have created > because they require that it is signed with a key that I dont have access > to. So this means that I can't use my own version of log4net without > recompiling all my dependencies.
> Do you have any suggestions to how I can solve this? For your current situation I don't have one, sorry. Helping to get log4net 1.2.11 released by verifying fixes might be an option ;-) For future releases I'd suggest to take a different approach - and this likely is a discussion point for the dev list. Therefore the cross-post, please let us keep the discussion there. I happen to be one of the ASF Incubator mentors for Lucene.NET and the question of whether they should strong name their assembly at all and if they should keep the signing key secret came up there for their last release - well, they didn't really question it, I did. Several people had good arguments towards strong naming - there are deployment situations where it is simply necessary to use the GAC, think BizTalk. And several people had good arguments to simply give the signing key away to everyone, this would help you in your case. This seems to be consensus by now by pretty much all Open Source projects in the .NET space. Just hand out your signing key so people can create their own patch builds - as they can do for any other platform as well. There is absolutely zero security attached to that key if used that way, but that doesn't matter since our releases are signed using OpenPGP and we provide hashes of everything. I'd propose to not keep the signing key of future releases secret but simply keep the full keypair inside the source tree. Stefan
