New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strong naming #35

Closed
GoogleCodeExporter opened this Issue Mar 15, 2015 · 12 comments

Comments

Projects
None yet
2 participants
@GoogleCodeExporter

GoogleCodeExporter commented Mar 15, 2015

Eventually we'll want to have strong naming, but it'll take a little while to 
work out what the community needs (key only held by Jon? something else?) - 
suggest we make it post-v1.

Original issue reported on code.google.com by jonathan.skeet on 7 Feb 2012 at 8:06

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

Original comment by malcolm.rowe on 30 Jul 2012 at 7:45

  • Added labels: Milestone-unscheduled
  • Removed labels: V1-OutOfScope
@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

Issue 119 has been merged into this issue.

Original comment by jonathan.skeet on 9 Oct 2012 at 8:27

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

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/

Original comment by UncleTha...@googlemail.com on 9 Oct 2012 at 9:00

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

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 ;)

Original comment by UncleTha...@googlemail.com on 9 Oct 2012 at 9:04

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

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?

Original comment by UncleTha...@googlemail.com on 9 Oct 2012 at 9:16

Attachments:

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

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 :)

Original comment by jonathan.skeet on 9 Oct 2012 at 9:44

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

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

Original comment by malcolm.rowe on 23 Oct 2012 at 8:58

  • Added labels: Milestone-1.0, Type-Enhancement, Priority-High
  • Removed labels: Milestone-unscheduled
@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

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...

Original comment by jonathan.skeet on 23 Oct 2012 at 8:13

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

Original comment by jonathan.skeet on 23 Oct 2012 at 8:13

  • Changed state: Fixed
@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

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!


Original comment by UncleTha...@googlemail.com on 26 Oct 2012 at 11:39

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

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

Original comment by malcolm.rowe on 1 Nov 2012 at 12:08

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

Original comment by malcolm.rowe on 10 Nov 2012 at 10:20

  • Added labels: Milestone-1.0.0
  • Removed labels: Milestone-1.0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment