On 12/11/2013 1:35 PM, Thomas Watson wrote:
> From: Scott Lewis <sle...@composent.com>
>
> Hi Tom,
>
>> On 12/11/2013 5:47 AM, Thomas Watson wrote:
>> We may be able to put org.eclipse.osgi.service.security package in
>> supplemental, but would it be possible to have others supply a
>> different fragment that implements ECFTrustManager in another way?
>
> Possibly. Could you explain what you have in mind?
>
>> Even if we move the org.eclipse.osgi.service.security API to the
>> supplement bundle you would still need an implementation of
>> TrustEngine to plug into ECFTrustManager.
>
> Yes...where (what bundle) is the equinox TrustEngine implementation(s)?
>
A TrustEngine which is backed by a keystore is implemented by the
Equinox framework [1]. By default the framework registers a
TrustEngine that is backed by the CA certs usually provided by the VM
installation, but the framework can be configured to use a different
keystore if desired. I'm not sure if in your ssl scenarios some other
entity is also registering a TrustEngine service.
No, no ECF code is currently registering a TrustEngine service.
My thought was that some other fragment could be implemented that
provides an alternative implementation of ECFTrustManager that simply
looks at the CA certs keystore themselves instead of using a
TrustEngine service to do that work for them.
I see. Another alternative: if the TrustEngine service interface
(only) were added to the supplemental, I (or contributors/consumers)
could look into providing a non-Equinox TrustEngine implementation as
part of ECF's ssl support.
Thanks,
Scott
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev