lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From digy digy <digyd...@gmail.com>
Subject Re: [Lucene.Net] Creating a Strong Named Assembly as part of our release
Date Tue, 22 Feb 2011 08:01:59 GMT
On Tue, Feb 22, 2011 at 3:04 AM, Troy Howard <thoward37@gmail.com> wrote:

> DIGY - Extracting the public key out is generally only used for delay
> signing.


In my senario, public key will not be used in delay signing. Just for
validating the assembly by comparing the public key in assembly with the
public key file in svn.


> 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.
>
>
An end user still has the choice of using assembly signed by Lucene.Net team
or signing it by compiling the source with his key.  Of course,He can not
sign the assembly with Lucene.Net team's private key and this is the
intented behaviour of "signing"


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

It would be a solution too, but users will have to learn more tools.



Thanks,
> Troy
>


DIGY

>
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message