On 2/13/06, Geir Magnusson Jr <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 > >> > >> > >> > > > > >
