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:thowar...@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
