lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Troy Howard <thowar...@gmail.com>
Subject Re: [Lucene.Net] Creating a Strong Named Assembly as part of our release
Date Tue, 22 Feb 2011 01:04:10 GMT
DIGY - Extracting the public key out is generally only used for delay
signing. I don't think delay signing would help our situation, because
it means an end user still needs our private key to make a complete
signed build.

As a side note, I just realized that the multiple-signers scenario I
described in my initial post wouldn't happen, since the public key
token is included in the fully qualified assembly name. A different
signer, using a different SNK, would create a DLL with a different
FQAN. Side-by-side installs of the same version of Lucene.Net, built
by different signers could function on the same machine, no problem.

Anyhow, so essentially the question that remains is: Publicly
distribute the SNK or not?

It seems like trying to keep track of the private SNK file via mailing
list may run into problems at some point.

I think Robert probably is right.. That we should just include it in
SVN publicly, and make sure we state clearly that even though an
assembly may be signed using our strong named signature, that unless
it validates via OpenPGP key, it is not an official build and
shouldn't be trusted as a ASF endorsed binary. Language to that effect
should be included in a README file for our binary releases.

Thanks,
Troy


On Mon, Feb 21, 2011 at 2:25 PM, Digy <digydigy@gmail.com> wrote:
> After we have two files,
>        one contaning public+private key(Lucene.Net.snk)
>                {sn -k Lucene.Net.snk}
>        and the other containing just public key(Lucene.Net.Public.snk)
>                {sn -p Lucene.Net.snk Lucene.Net.Public.snk}
> we can share Lucene.Net.snk via private mailing list  and put the Lucene.Net.Public.snk
to svn.
>
>
> Assuming that we create two binary releases(signed + unsigned), users have many alternatives
like source-code, signed release or unsigned release and free to choose any one of them.
>
> I don't think that some extreme cases(like one uses the signed-release in GAC and then
wants to compile and sign with his own key and forgets to remove the old one from GAC) should
be handled by Lucene.Net.
> At the end, all Lucene.Net users are developers.
>
> DIGY
>
>
> -----Original Message-----
> From: Troy Howard [mailto:thoward37@gmail.com]
> Sent: Monday, February 21, 2011 7:08 PM
> To: lucene-net-dev@lucene.apache.org
> Subject: [Lucene.Net] Creating a Strong Named Assembly as part of our release
>
> All,
>
> There was a request, in LUCENENET-389 [1], that our binary release be
> signed as a Strong Named Assembly (SNA). There are many compelling
> reasons to do this, however managing this as an open source project
> raises some questions.
>
> The main question is, how to manage the Strong Name Key (SNK) file?
>
> Since this file contains the private key in the strong-naming
> asymmetric encryption scheme, it is supposed to be kept privately by
> the signer. In this way, a given assembly can be verified as coming
> from that particular signer, because only they can make a build which
> is signed using that private key. If we include that in the source
> trunk, we are essentially allowing anyone to sign any assembly with
> the Lucene.Net naming key.
>
> This has many implications, not the least of which is that an end user
> could change the code in a malicious manner, and recompile, signing
> with our key, and create an assembly which seems like a valid build,
> and specifically seems to be *endorsed* by the Apache Lucene.Net
> brand.
>
>
> If we keep the key private, how do we then manage it? Is there a place
> to store these kinds of resources, where only the committers have
> access? Is this even reasonable considering the seeming philosophical
> disparity between this idea and the open source ideal?
>
>
> Another option, is to provide instructions for the end user on how to
> create their own SNA by building from source, using their SNK. This
> allows the publisher to establish trust based on their own name,
> rather than ours. Unfortunately this creates a different issue;
> multiple signers. Suppose there are two publishers; both creating
> products that use Lucene.Net, both creating their own differently
> signed SNA of the same version of Lucene.Net. Further suppose both
> products end up being installed on the same box. This would cause the
> second product to not be able to be installed correctly.
>
> So, really, the only way to create a SNA and avoid the "multiple
> signers" collision scenario I described above  is to use a single SNK
> file and always build the assembly using that file.
>
> So what does everyone think about this?
>
> Do we allow our SNK to be public and then run the risks of allowing
> anyone to create a DLL using our signature? or do we find a way to
> manage our private key privately?
>
> Suppose we use a private key, what happens when an end user wants to
> make a local modification to the Lucene.Net source but still wants the
> result to be a SNA? They would need to use their own key, but now run
> into the same problem of multiple signers if they weren't careful
> about changing the build number to reflect their local modifications.
>
> Perhaps we should not attempt to release a SNA?
>
> Thanks,
> Troy
>
> [1]: https://issues.apache.org/jira/browse/LUCENENET-389
>
>

Mime
View raw message