You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by Stefan Bodewig <bo...@apache.org> on 2011/02/21 05:55:40 UTC
[Lucene.Net] Re: Signing Binary Releases
On 2011-02-20, Robert Jordan wrote:
> On 20.02.2011 07:49, Stefan Bodewig wrote:
>> If you talk about strong naming assemblies then I don't have any
>> experience how a well designed scheme of sharing the key between several
>> developers might work. As the maintainer of XMLUnit I'd be interested
>> in a good solution myself.
> Many open source projects are keeping the key pair (*.snk)
> together with the source code in their repository because
> the security significance of the key is zero.
> Given how .NET assembly signing was designed, no one
> would be able to generate a compatible Lucene.Net assembly
> from source code w/out having to update assembly
> references in all projects using Lucene.Net.
> This is hardly compatible with open source principles
> and should be avoided.
I agree but users have asked for a strong named version of XMLUnit in
the past so I was thinking about providing one as alternative. I've
seen similar user requests for log4net or NUnit as well.
Stefan
Re: [Lucene.Net] Re: Signing Binary Releases
Posted by Ayende Rahien <ay...@ayende.com>.
Okay, cool
On Mon, Feb 21, 2011 at 11:27 AM, Robert Jordan <ro...@gmx.net> wrote:
> On 21.02.2011 05:55, Stefan Bodewig wrote:
>
>> On 2011-02-20, Robert Jordan wrote:
>>
>> On 20.02.2011 07:49, Stefan Bodewig wrote:
>>>
>>>> If you talk about strong naming assemblies then I don't have any
>>>> experience how a well designed scheme of sharing the key between several
>>>> developers might work. As the maintainer of XMLUnit I'd be interested
>>>> in a good solution myself.
>>>>
>>>
>> Many open source projects are keeping the key pair (*.snk)
>>> together with the source code in their repository because
>>> the security significance of the key is zero.
>>>
>>
>> Given how .NET assembly signing was designed, no one
>>> would be able to generate a compatible Lucene.Net assembly
>>> from source code w/out having to update assembly
>>> references in all projects using Lucene.Net.
>>>
>>
>> This is hardly compatible with open source principles
>>> and should be avoided.
>>>
>>
>> I agree but users have asked for a strong named version of XMLUnit in
>> the past so I was thinking about providing one as alternative. I've
>> seen similar user requests for log4net or NUnit as well.
>>
>
> Yes, the last part of my mail was misleading. I was actually
> proposing to keep Lucene.Net's SNK key together with the
> source code and to sign the assembly during the build process.
>
> Robert
>
>
>
Re: [Lucene.Net] Re: Signing Binary Releases
Posted by Robert Jordan <ro...@gmx.net>.
On 21.02.2011 05:55, Stefan Bodewig wrote:
> On 2011-02-20, Robert Jordan wrote:
>
>> On 20.02.2011 07:49, Stefan Bodewig wrote:
>>> If you talk about strong naming assemblies then I don't have any
>>> experience how a well designed scheme of sharing the key between several
>>> developers might work. As the maintainer of XMLUnit I'd be interested
>>> in a good solution myself.
>
>> Many open source projects are keeping the key pair (*.snk)
>> together with the source code in their repository because
>> the security significance of the key is zero.
>
>> Given how .NET assembly signing was designed, no one
>> would be able to generate a compatible Lucene.Net assembly
>> from source code w/out having to update assembly
>> references in all projects using Lucene.Net.
>
>> This is hardly compatible with open source principles
>> and should be avoided.
>
> I agree but users have asked for a strong named version of XMLUnit in
> the past so I was thinking about providing one as alternative. I've
> seen similar user requests for log4net or NUnit as well.
Yes, the last part of my mail was misleading. I was actually
proposing to keep Lucene.Net's SNK key together with the
source code and to sign the assembly during the build process.
Robert
Re: [Lucene.Net] Re: Signing Binary Releases
Posted by Ayende Rahien <ay...@ayende.com>.
Educate my users?
That is hardly my role. They get the benefit of being able to run a patch
version without undue hassle.
NHibernate 1.x tried to have a secret snk, and that failed pretty miserably
On Mon, Feb 21, 2011 at 2:16 PM, Stefan Bodewig <bo...@apache.org> wrote:
> On 2011-02-21, Ayende Rahien wrote:
>
> > There are many situations where you _have_ to have a strong key, or
> > example, gac deployments. In those cases, anything in the chain also
> > have to have strong key.
>
> Yes, I knew that. Sorry if I sounded stupid. In most cases I try to
> avoid the GAC and my personal use-case (XMLUnit) is quite different from
> Lucene (i.e. it is less likely to end up as a dependency of something
> that gets deployed to the GAC).
>
> Fortunately my opinion is pretty unimportant here anyway 8-)
>
> > Most OSS in .NET have signed binary releases, and the snk is usually
> > in the source code.
>
> Do you educate your users that there is no security promise attached to
> the strong name in this case? I've always shied away from using strong
> names in OSS because of the illusion of verified-publisher they provide
> in such a setup.
>
> Thanks
>
> Stefan
>
Re: [Lucene.Net] Re: Signing Binary Releases
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-02-21, Ayende Rahien wrote:
> There are many situations where you _have_ to have a strong key, or
> example, gac deployments. In those cases, anything in the chain also
> have to have strong key.
Yes, I knew that. Sorry if I sounded stupid. In most cases I try to
avoid the GAC and my personal use-case (XMLUnit) is quite different from
Lucene (i.e. it is less likely to end up as a dependency of something
that gets deployed to the GAC).
Fortunately my opinion is pretty unimportant here anyway 8-)
> Most OSS in .NET have signed binary releases, and the snk is usually
> in the source code.
Do you educate your users that there is no security promise attached to
the strong name in this case? I've always shied away from using strong
names in OSS because of the illusion of verified-publisher they provide
in such a setup.
Thanks
Stefan
Re: [Lucene.Net] Re: Signing Binary Releases
Posted by Ayende Rahien <ay...@ayende.com>.
There are many situations where you _have_ to have a strong key, or example,
gac deployments.
In those cases, anything in the chain also have to have strong key. Most OSS
in .NET have signed binary releases, and the snk is usually in the source
code.
On Mon, Feb 21, 2011 at 6:55 AM, Stefan Bodewig <bo...@apache.org> wrote:
> On 2011-02-20, Robert Jordan wrote:
>
> > On 20.02.2011 07:49, Stefan Bodewig wrote:
> >> If you talk about strong naming assemblies then I don't have any
> >> experience how a well designed scheme of sharing the key between several
> >> developers might work. As the maintainer of XMLUnit I'd be interested
> >> in a good solution myself.
>
> > Many open source projects are keeping the key pair (*.snk)
> > together with the source code in their repository because
> > the security significance of the key is zero.
>
> > Given how .NET assembly signing was designed, no one
> > would be able to generate a compatible Lucene.Net assembly
> > from source code w/out having to update assembly
> > references in all projects using Lucene.Net.
>
> > This is hardly compatible with open source principles
> > and should be avoided.
>
> I agree but users have asked for a strong named version of XMLUnit in
> the past so I was thinking about providing one as alternative. I've
> seen similar user requests for log4net or NUnit as well.
>
> Stefan
>