[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Bundle Verification using custom TrustEngine
- From: David LÃbbren - PRION Group <dluebbren@xxxxxxxx>
- Date: Mon, 19 Jan 2009 18:20:50 +0100 (CET)
- Delivered-to: email@example.com
- Organization: PRION GmbH
Am Mo 19.01.2009 17:21 schrieb Thomas Watson <tjwatson@xxxxxxxxxx>:
>The property osgi.signedcontent.trust.engine is used to limit the trust
>engine services that the SignedBundleFile will use to determine if a
>is trusted. When you set that property to CECKeyStoreTrustEngine then
>your trust engine will be used to establish trust. Do you know if your
>trust engine is called at all? Do you register your trust engine
>with the same service property set? (i.e.
Yes, the custom trust engine is registered with a property set including
and the external property
I confirmed the registration through console output and also trace
output of method "findTrustAnchor"
in the custom trust engine. Additionally I turned on tracing with an
.options file, with debug and security
turned on and I see the "Trust Anchor" output of the certificates.
The only difference in the launches is the property
If not set the default mechanism via KeyStoreTrustEngine is used and it
When set to the custom trust engine it doesn't.
The traces start differing at the point where
"org.eclipse.update.configurator" is installed ie.
Â"install from inputstream:
In the default KeyStoreTrustEngine prior to the above line the "Trust
Anchor" is printed out verbose wheras in the
custom trust engine it is not. For Bundles prior to this point "Trust
Anchor"s are printed out in both cases.
To me it feels like some kind of bootstrap/bundle/fragment load order
issue, as the only difference I see is that the
custom trust engine is registered from an osgi fragment, whereas
SignedBundleHook & Co are registered from the
system bundle itself. The trust engine code is exactly the same ie. a
copy & paste job (apart from trace output).
>You will notice the code in
>uses a ServiceTracker to find the trust engine services. A filter is
>when you set the osgi.signedcontent.trust.engine. property.
Yes, I did catch it.
>From: David LÃbbren - PRION Group <dluebbren@xxxxxxxx>
>Date: 01/19/2009 09:41 AM
>Subject: [equinox-dev] Bundle Verification using custom TrustEngine
>I am trying to use the signed content functionality in equinox to
>all bundles at load time.
>After patching Eclipse 3.4 org.eclipse.osgi system bundle to include
>I am able to this out of the box using the following properties:
>with a local keystore. All jars are signed in the exported product
>directory, so eclipse jars are signed (at least) twice, and my custom
>This seems to work fine now (I did a couple of tests replacing signed
>jars with unsigned ones etc...).
>My aim is to use a custom trust engine to be able to verify certificate
>trust independent of a local keystore.
>This is not working. Trying to track down why, I am using a copy of
>KeyStoreTrustEngine named CECKeyStoreTrustEngine. This Class is
>registered via a custom Adaptor Hook as an osgi service. I have
>that the service is registered and started via sysout and use the
>properties to activate it:
>Â-Dosgi.framework.extensions=cec.bundleverifierÂÂÂÂÂÂÂ (the custom hook
>Using this setup the application generates an exception:
>Âorg.osgi.framework.BundleException: The bundle could not be resolved.
>Reason: The bundle is disabled: "org.eclipse.equinox.security:null"
>When I remove the Property 'osgi.signedcontent.trust.engine' all
>TrustEngines are called and the verification works again.
>My Question is: Why does the KeyStoreTrustEngine registerd from the
>SignedBundleHook work, but the same copy from my own hook fails ?
>equinox-dev mailing list