Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] Pushing bcprov and bcpkix 1.51 into Orbit

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

If JGit plans on using only bcprov 1.52 (not 1.51) and not for Mars then
I think we should be fine to ship without the JCE signature.

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

If we can ship without the JCE signature, then I could go ahead and name
the 2 bundles org.bouncycastle.prov (or just org.bouncycastle) and
org.bouncycastle.pkix.

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

Just the two-part version number, and Bundle-RequiredExecutionEnvironment:
listing more than just the minimum. As far as I can tell, I can add an
about.html, and remove IDEA* classes (as request by legal), and 'jarsigner
-verify' doesn't complain.

Cheers,
-- 
Roland Grunberg


Back to the top