Re: [orbit-dev] Pushing bcprov and bcpkix 1.51 into Orbit

[David M Williams <david_williams@xxxxxxxxxx>]

Ok ... so, sounds like we are in a waiting
pattern? Were these required for Mars? I'm asking since we need to promote
an Orbit for RC1 soon, and not sure if we should let these "out into
the wild" as they are? Or, fix first? 


My most immediate issue is the "bundle
naming". Even though, it sounds like, no one should use it in a "require
bundle" statement, it seems most consistent to name them after the
predominate package, just to be consistent and make things clearer. I tried
to find how else it might be named, by looking in maven repo's and didn't
seem consistent, or quite right there, either. (such as, had jar and ?java?
version in name as "artifact id", but "org.bouncycastle"
as "group id"). 

On the signature issues ... not sure
if a "wrapper" would work ... but, sort of doubt it. Though,
did see some stuff on web about "OSGi Adapters" for it, but almost
bet that was before it was "OSGi-ified"? 

If it helps, and if there is time, perhaps
we could ask the Eclipse Foundation to get a "JCE signing certificate"?


Not sure if "up to date",
but saw some old info in stack overflow that it doesn't take long ... 
http://stackoverflow.com/questions/1756801/how-to-sign-a-custom-jce-security-provider
along with pointers to directions ...

http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/HowToImplAProvider.html#Step6

What are the issues with "pre-built"?
 I assume you mean only two part version number, no "about.html"
file, and (probably) no pack200 compression possible, (unless we can verity
that the jar was "pre-conditioned" before signing, and which
VM used, and what parameters used. Otherwise it stays "unpacked".
(which isn't that bad). Were there others? 

I'll send separate note about our time
pressures ... for Mars. 




Roland Grunberg <rgrunber@xxxxxxxxxx> wrote
on 05/11/2015 10:45:31 AM:

> From: Roland Grunberg <rgrunber@xxxxxxxxxx>
> To: Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>,

> Cc: David M Williams/Raleigh/IBM@IBMUS, Matthias
Sohn <matthias.sohn@xxxxxxx>
> Date: 05/11/2015 10:45 AM
> Subject: Re: [orbit-dev] Pushing bcprov and bcpkix
1.51 into Orbit
> 
> > I see these have already been contributed, full 4 part versions,
and
> > signed by Eclipse.org. Is that what was expected?
> > (I don't see 'prebuilt' in the map file, but usually, if someone
does want
> > a 'prebuilt' bundle, there's a part of the build script I need
to update
> > .. just FYI).
> 
> I contributed both bcprov and bcpkix 1.51 for the time being as regular
> exploded jars so the JCE signature is broken for now. I wanted to
get a build
> working so the other plugins destined for CDT/Linux Tools could build
> correctly. I wouldn't mind trying preserving the JCE signature if
it's
> possible.
> 
> ....
>  
> > On the signing issue (I've not read original comment that was
referred to)
> > is it the case where there is basically a split package? So,
must be
> > signed by same certificate? If so, I think leaving unsigned is
best we
> > could do (if you are saying we provide framework, and others,
not us,
> > provide the implementation?)
> > 
> > = = = = =
> 
> I think this was the issue for another bundle (commonj.sdo ?) but
the bcprov
> issue (if I understood correctly) was that Orbit build signing broke
the JCE
> signature on the jar's class files/manifest/etc. Without this, the
jar cannot
> be used as a JCE provider. This is the reason I stuck with bcprov/bcpkix.
> Was there any success in using a wrapped jar ?
> 
> For com.spotify.docker.client, this isn't a problem because that uses
> bouncycastle API directly. At this point we'd probably need to know
how
> Matthias envisioned bcprov would be contributed because there still
seem to
> be some minor issues with the prebuilt approach.