[classlib] bouncy castle

[Geir Magnusson Jr <ge...@pobox.com>]

Ok, the thread re BC has gotten a bit confusing.

I thought the reason we needed to consider using a copy of the code is 
because we need to create our own signed JAR.  If this is incorrect, 
please say something.

I think there are a few ways to do this (and please, suggest others...) :

1) Rewrite the whole thing (certainly not ideal - noting here for 
completeness)

2) Get a copy of the BC source and put in our repository

3) "manufacture" our own signed JAR from their source JAR.

4) Other?


I'm uncomfortable w/ #3 because we're not really simply re-distributing 
someone else's code (because we re-package) nor are we publishing 
something with the standard ASF oversight.  I'd like to avoid #1.  Can 
we do #2 and then keep refreshing whenever they do an update, with us 
contributing to them if we find bugs?

Ideas?

geir

Re: [classlib] bouncy castle

[Mikhail Loenko <ml...@gmail.com>]

On 2/13/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>  . . .
> > 4.2) develop sources required to verify signature in the main BC JAR and
> > redistribute BC.JAR as is
>
> Hm.  That's interesting.  What does this really mean?
>

we need to implement SHA-1 message digest and SHA1withDSA signature.

see http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/%3c6e47b64f0602100251p298009d1g24cb83768f039ccc@mail.gmail.com%3e

It is not trivial, so might be good for mid-term solution.

> > 4.3) #2 but take only necessary classes
>
> Yes, it was always intended to just take the minimum amount necessary.

Sounds very reasonable.

Thanks,
Mikhail.

>
>
> >
> > If #3 is not legally pure, then I'd prefer #2
> >
> > Thanks,
> > Mikhail
> >
> > On 2/13/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >> Ok, the thread re BC has gotten a bit confusing.
> >>
> >> I thought the reason we needed to consider using a copy of the code is
> >> because we need to create our own signed JAR.  If this is incorrect,
> >> please say something.
> >>
> >> I think there are a few ways to do this (and please, suggest others...) :
> >>
> >> 1) Rewrite the whole thing (certainly not ideal - noting here for
> >> completeness)
> >>
> >> 2) Get a copy of the BC source and put in our repository
> >>
> >> 3) "manufacture" our own signed JAR from their source JAR.
> >>
> >> 4) Other?
> >>
> >>
> >> I'm uncomfortable w/ #3 because we're not really simply re-distributing
> >> someone else's code (because we re-package) nor are we publishing
> >> something with the standard ASF oversight.  I'd like to avoid #1.  Can
> >> we do #2 and then keep refreshing whenever they do an update, with us
> >> contributing to them if we find bugs?
> >>
> >> Ideas?
> >>
> >> geir
> >>
> >>
> >>
> >
> >
>

Re: [classlib] bouncy castle

[Geir Magnusson Jr <ge...@pobox.com>]

Mikhail Loenko wrote:
> IMHO
> 1) Might make sense for the second release :)
> 
> 2) The only problem I see here - BC contains classes that are not necessary
> for us. So, our repository will contain redundant files

Not necessarily - we'd just take what we needed, not the whole thing.

> 
> 3) It might be manufacturing our own UNsigned JAR from their JAR. If we do not
> modify sources in #2 then I do not see big legal difference. Though I'm not an
> expert in the legal area.

There is no legal issue - lets just focus on what makes 
project-management / engineering sense.

BTW, I didn't mean "source" really - I mean as them as the source of the 
code for our JAR.  Sorry.

With this, the problem is that we'd be redistributing software that 
isn't released by anyone (we wouldn't call it "bcprov") as a unit.

Anything that we create and distribute (and we'd be creating this) 
should be reproducible from our SVN, becuase

a) it's reproducible if there is a question

b) the project will have oversight on what it's releasing - when we 
[eventually] say "This is Apache Harmony", we want to be sure that 
everything that isn't just a repurposed dependency is something we can 
track the origin of...


> 
> 4.1) extract sources required to verify signature in the main BC JAR and
> redistribute BC.JAR as is
> 4.2) develop sources required to verify signature in the main BC JAR and
> redistribute BC.JAR as is

Hm.  That's interesting.  What does this really mean?


> 4.3) #2 but take only necessary classes

Yes, it was always intended to just take the minimum amount necessary.


> 
> If #3 is not legally pure, then I'd prefer #2
> 
> Thanks,
> Mikhail
> 
> On 2/13/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>> Ok, the thread re BC has gotten a bit confusing.
>>
>> I thought the reason we needed to consider using a copy of the code is
>> because we need to create our own signed JAR.  If this is incorrect,
>> please say something.
>>
>> I think there are a few ways to do this (and please, suggest others...) :
>>
>> 1) Rewrite the whole thing (certainly not ideal - noting here for
>> completeness)
>>
>> 2) Get a copy of the BC source and put in our repository
>>
>> 3) "manufacture" our own signed JAR from their source JAR.
>>
>> 4) Other?
>>
>>
>> I'm uncomfortable w/ #3 because we're not really simply re-distributing
>> someone else's code (because we re-package) nor are we publishing
>> something with the standard ASF oversight.  I'd like to avoid #1.  Can
>> we do #2 and then keep refreshing whenever they do an update, with us
>> contributing to them if we find bugs?
>>
>> Ideas?
>>
>> geir
>>
>>
>>
> 
> 

Re: [classlib] bouncy castle

[Mikhail Loenko <ml...@gmail.com>]

IMHO
1) Might make sense for the second release :)

2) The only problem I see here - BC contains classes that are not necessary
for us. So, our repository will contain redundant files

3) It might be manufacturing our own UNsigned JAR from their JAR. If we do not
modify sources in #2 then I do not see big legal difference. Though I'm not an
expert in the legal area.

4.1) extract sources required to verify signature in the main BC JAR and
redistribute BC.JAR as is
4.2) develop sources required to verify signature in the main BC JAR and
redistribute BC.JAR as is
4.3) #2 but take only necessary classes

If #3 is not legally pure, then I'd prefer #2

Thanks,
Mikhail

On 2/13/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> Ok, the thread re BC has gotten a bit confusing.
>
> I thought the reason we needed to consider using a copy of the code is
> because we need to create our own signed JAR.  If this is incorrect,
> please say something.
>
> I think there are a few ways to do this (and please, suggest others...) :
>
> 1) Rewrite the whole thing (certainly not ideal - noting here for
> completeness)
>
> 2) Get a copy of the BC source and put in our repository
>
> 3) "manufacture" our own signed JAR from their source JAR.
>
> 4) Other?
>
>
> I'm uncomfortable w/ #3 because we're not really simply re-distributing
> someone else's code (because we re-package) nor are we publishing
> something with the standard ASF oversight.  I'd like to avoid #1.  Can
> we do #2 and then keep refreshing whenever they do an update, with us
> contributing to them if we find bugs?
>
> Ideas?
>
> geir
>
>
>