Issue 119 has been merged into this issue.

Why not hold the key in the project source code for now, if you want to make 
the key more secure in future that would be fine, but at least it would allow 
strongly signed assemblies in the interim.

I have done the changes required for strong naming (the friend assemblies and 
commandline.dll added complexity) and submitted to
https://UncleThargy@code.google.com/r/unclethargy-1/

I went for 'least impact' approach, I'm sure you could probably get a strong 
named version of CommandLine (in fact I think it's a NuGet now), but I wanted 
to make the minimum number of changes to get it to build, to increase the 
chances of you accepting the pull request ;)

Attached is the unofficial signed version of the 1.0.0-beta2 NuGet, which I've 
renamed to NodaTimeSigned.1.0.0-beta2-Signed to prevent confusion with the 
official unsigned one.

I figure it will help anyone else out there who would like to use this in their 
signed projects until you release an official version.  Hope that's OK?

I don't want to sign with one key now, then require everyone to change which 
key they trust later on. I'd rather spend time (when I've got it) working out 
how we want to proceed, then do that once. Thanks for including the signed 
workaround for the moment for those who want it, but I won't pull just yet :)

Actually, per discussion, pulling this forward to 1.0, since there's a 
non-trivial developer impact of changing this afterwards.

Fixed in revision 919e23c73a55 and revision 9f446e1744fd.
At least, that's the hope... we'll see when we cut the RC and see what the 
NuGet package contains...

I've deleted the unofficial nupkg in anticipation of the pending release of the 
official one.

The implementation of having a separate build configuration relying on a 
private key that is not Open Source is a fair compromise between allowing 
builds and forks without compromising authority and package security.  This way 
if we come across a bad bug in production we can always add our own key and 
rebuild to hotfix, without any danger of contaminating the builds (as the 
public keys will be clearly different).  

This gives me piece of mind that we can release in production code, safe that 
if the project goes AFK we can still maintain.

I know the public key is included in the repo, however you might want to post 
it on the website as well for extra confidence, that way it will be easy to 
validate the NuGet/dlls.

Thanks for bumping this one up!

The public key is now also linked from the project front page.