bundle starting twice

Hi all,

I have a client application in which I added a bundle ('loginscreen')
at start level 1 to display a login screen.
While this screen is presented to the user, the framework startup
continues as usually, with org.eclipse.update.configurator at level 3.
Now when modifications have occurred to the set of available bundles,
Package Admin will always stop my loginscreen bundle, and restart it.
In this case that means there will be two login screens...

The loginscreen bundle only depends on the framework, and no other
bundles depend on it, so I don't see why it would need to be
restarted.

Can I avoid this behaviour somehow ? I don't want to start the bundle
after org.eclipse.update.configurator.

Tom

Re: bundle starting twice

Equinox tagged for the next integration build.

Re: bundle starting twice

I was preparing a detailed bug report, when I noticed that I do have a
non-framework import, namely org.osgi.service.event. Didn't realize
that this was a separate bundle before. If I add this to the initial
bundles set, my problem disappears.

Sorry for the false alarm.

Tom

On Mon, Jan 5, 2009 at 9:51 PM, Thomas Watson <tjwatson@...> wrote:
> Are you updating the loginscreen bundle when you see the bundle get started
> twice or do you have multiple versions of the loginscreen bundle? If a new
> version of the loginscreen bundle is being provisioned then this is expected
> behavior. I would have expected the loginsreen bundle to bring down the
> first login screen when it is stopped and then a new loginscreen be
> displayed when it is started again.
>
> If you are not updating the loginscreen bundle and you are sure you do not
> depend on anything outside of the OSGi Framework then this is unexpected. If
> that is the case, can you open a bug against Equinox->Framework and provide
> a testcase to reproduce?
>
> Tom
>
>
>
> "Tom Huybrechts" ---01/05/2009 02:38:13 PM---Hi all,
>
>
> From:
> "Tom Huybrechts" <tom.huybrechts@...>
> To:
> "Equinox development mailing list" <equinox-dev@...>
> Date:
> 01/05/2009 02:38 PM
> Subject:
> [equinox-dev] bundle starting twice
> ________________________________
>
>
> Hi all,
>
> I have a client application in which I added a bundle ('loginscreen')
> at start level 1 to display a login screen.
> While this screen is presented to the user, the framework startup
> continues as usually, with org.eclipse.update.configurator at level 3.
> Now when modifications have occurred to the set of available bundles,
> Package Admin will always stop my loginscreen bundle, and restart it.
> In this case that means there will be two login screens...
>
> The loginscreen bundle only depends on the framework, and no other
> bundles depend on it, so I don't see why it would need to be
> restarted.
>
> Can I avoid this behaviour somehow ? I don't want to start the bundle
> after org.eclipse.update.configurator.
>
> Tom
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@...
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@...
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>

Verification of signed jars during bundle installation

Hi,

I've been looking into Equinox's support for dealing with signed jars and have a couple of queries with
which I'd be grateful for some pointers.

I've figured out that I can enable SignedBundleHook by starting Equinox with
-Dosgi.signedcontent.support=true. With the hook enabled I've then run the debugger through the
installation of a bundle. This bundle is packaged in a Jar that's been signed but has since been modified
such that the signatures are now wrong. I've observed SignedBundleHook.wrapBundleFile being invoked
and a GeneralSecurityException being thrown, caught, and swallowed, when the tampering is discovered.
Ideally I'd like the installation to fail at this point as the bundle's signatures are out of sync with its contents.

With this goal in mind I also looked at
org.eclipse.osgi.internal.signedcontent.BundleInstallListener and experimented with enabling
its policing of signed jars. I figured out that I can enable signed jar policing by starting Equinox with
-Dosgi.signedcontent.authorization.engine.policy=signed but this appears to make things too
restrictive as it requires every bundle that's installed to be signed, rather than just checking that
those that are signed are signed correctly.

Is there any way to configure Equinox for the middle ground that I'm looking for? I'd like unsigned jars to be
accepted, and signed jars to be accepted *unless* the signatures are incorrect in which case I'd like the
attempt to install the bundle to fail.

Thanks,
Andy

Re: Verification of signed jars during bundle installation

Move the equinox incubator to RT

Re: Verification of signed jars during bundle installation

Thanks, Tom.

Andy.

----- Original Message -----
From: "Thomas Watson" <tjwatson@...>
To: "Equinox development mailing list" <equinox-dev@...>
Sent: Tuesday, 6 January, 2009 4:24:31 PM GMT +00:00 GMT Britain, Ireland, Portugal
Subject: Re: [equinox-dev] Verification of signed jars during bundle installation

Hi Andy, 

During 3.4 we had a team working on building an authorization engine into the framework to do the signature
validation and content validation at install time (i.e. when calling BundleContext.install().
Unfortunately we ran out of time and found that it was rather limiting to bake policies directly into the
framework (your case is a perfect example!!). 

As a result the authorization engine became internal/provisional and is not promoted as the way to do
install time verification of signed content. Instead, install time verification should be performed by
the install agent (p2 in Eclipse). In Equinox, p2 is using the SignedContentFactory service to
interrogate the bundle content to determine if a bundle is signed, trusted, or tampered with before
installing the bundle into the framework. This allows for more customized policies to be implemented
outside of the framework and allows for UIs to do things like ask the user if they would like to allow an
untrusted signed bundle to be installed. 

Tom 

Inactive hide details for Andy Wilkinson ---01/06/2009 09:42:10 AM---Hi,Andy Wilkinson ---01/06/2009
09:42:10 AM---Hi, 

From: 	
Andy Wilkinson <andy.wilkinson@...> 

To: 	
equinox-dev@... 

Date: 	
01/06/2009 09:42 AM 

Subject: 	
[equinox-dev] Verification of signed jars during bundle installation 

Hi, 

I've been looking into Equinox's support for dealing with signed jars and have a couple of queries with
which I'd be grateful for some pointers. 

I've figured out that I can enable SignedBundleHook by starting Equinox with
-Dosgi.signedcontent.support=true. With the hook enabled I've then run the debugger through the
installation of a bundle. This bundle is packaged in a Jar that's been signed but has since been modified
such that the signatures are now wrong. I've observed SignedBundleHook.wrapBundleFile being invoked
and a GeneralSecurityException being thrown, caught, and swallowed, when the tampering is discovered.
Ideally I'd like the installation to fail at this point as the bundle's signatures are out of sync with its
contents. 

With this goal in mind I also looked at
org.eclipse.osgi.internal.signedcontent.BundleInstallListener and experimented with enabling
its policing of signed jars. I figured out that I can enable signed jar policing by starting Equinox with
-Dosgi.signedcontent.authorization.engine.policy=signed but this appears to make things too
restrictive as it requires every bundle that's installed to be signed, rather than just checking that
those that are signed are signed correctly. 

Is there any way to configure Equinox for the middle ground that I'm looking for? I'd like unsigned jars to be
accepted, and signed jars to be accepted *unless* the signatures are incorrect in which case I'd like the
attempt to install the bundle to fail. 

Thanks, 
Andy 
_______________________________________________ 
equinox-dev mailing list 
equinox-dev@... 
https://dev.eclipse.org/mailman/listinfo/equinox-dev 

_______________________________________________
equinox-dev mailing list
equinox-dev@...
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Starting all dependent bundles

RE: Starting all dependent bundles