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

[Roland Grunberg <rgrunber@xxxxxxxxxx>]

> 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.

> Even much more minor ... we do typically group "like bundles" together in
> the map file, even though that doesn't represent chronological order).

Good catch, I completely missed the 1.47 already there. I didn't see it in
the feature, or in any Orbit build and must have assumed it wouldn't be in
the maps file. I'll fix this.

> My concern (open to discussion) is that our typical rule of thumb is to
> name bundles after their main namespace ("org.bouncycastle").
> Is there a reason that wasn't done in this case?
> 
> A more minor issue, I see you have
> Bundle-RequiredExecutionEnvironment:
> J2SE-1.5,JavaSE-1.6,JavaSE-1.7,JavaSE-1.8
> 
> But I think only J2SE-15 is needed (since, BREE means *minimum* Java
> runtime required). Right? (There are occasional reasons to list more than
> one, but that's primarily for Java 4 or less). Any reason for it in this
> case?

> = = = =
> 
> On the 2 part version numbers ... we can always get an exception ... if
> there's a good reason for it.
> 
> = = = = =
> 
> 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.

Cheers,
-- 
Roland Grunberg