[equinox-dev] Problem trying to verify signed bundles at installation time
Hi, I have been looking information about how I can sign a bundle and put on Equinox framework. If I am not wrong, it just need to sign a bundle using jarsigner tool and launch Equinox using next options: java -Djava.security.manager=org.eclipse.osgi.framework.internal.core.FrameworkSe curityManager -Djava.security.policy=policy.policy -Dosgi.framework.keystore=falseCA.keystore -Dosgi.signedcontent.support=authority -Dosgi.signature.support.verify=true -jar org.eclipse.osgi_3.4.3.R34x_v20081215-1030.jar -console where falseCA.keystore is a java keystore built with Java Keytool where is saved the Certification Authority certificate from another signer different to the actual Certification Authority certifícate with which bundles were signed, I do this just for checking that the signature veryfing process run fine. If I do that , and I launch Equinox in this way, If I write osgiss command in console I just get Equinox bundle system, I guess because It is the only one who was signed. But If I tried install again bundles, I do not get any exception at all, so I can install modified bundles who were signed, unsigned bundles, signed bundles by other Certification Authority different from the Certification Authority which I fix when I launch Equinox, or whatever that I want to install. My questions is: Is the initial verification the only one? I mean, if I launch Equinox how I wrote before, the only change is that all unsigned previous installed bundles are removed? Why isnt there any signature checking process when I try to install unsigned bundles? I read that there is no verification process in installing time in email list, because this should be done by an agent like a bundle, but I am not sure what the next command change from the normal options: Djava.security.policy=policy.policy -Dosgi.framework.keystore=falseCA.keystore -Dosgi.signedcontent.support=authority -Dosgi.signature.support.verify=true Am I missing anything? I am supposing that if I launch Equinox with those options then I should not be able to install unsigned bundles or signed bundles who signer I do not trust in. Thank you in advance David ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] ClassLoader leak caused by EventManager's EventThread creation
Hi, I've been looking into a PermGen leak and have identified what looks to be an undesirable side-effect of org.eclipse.osgi.framework.eventmgr.EventManager's creation of an EventThread instance. In my particular situation the EventManager instance is MRUBundleFileList's bundleFileCloserManager. I'm running on 3.5.0.v20090311-1300. When the EventThread is lazily created, it gets its context class loader from the current thread. In my situation it's a call from a non-Equinox owned thread that's triggered the lazy creation of the EventThread instance. In this case at least, it doesn't seem right for this Equinox-owned thread to be holding a reference to this foregin class loader, particularly as it's not easy to update the EventThread's context classloader in application code. The reference to the classloader leads to a PermGen leak as the classloader doesn't become eligible for garbage collection. With the caveat that I don't know if there is some expectation about what the event thread's context class loader should be, I wonder if it would be better if EventManager was updated to explicitly set an EventThread's context class loader, possibly to Equinox's classloader, i.e. EventManager.class.getClassLoader()? Regards, Andy ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] ClassLoader leak caused by EventManager's EventThread creation
Andy, Can you file a bug on this? -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 From: Andy Wilkinson andy.wilkin...@springsource.com To: equinox-dev@eclipse.org Date: 2009/05/06 09:22 Subject: [equinox-dev] ClassLoader leak caused by EventManager's EventThread creation Sent by: equinox-dev-boun...@eclipse.org Hi, I've been looking into a PermGen leak and have identified what looks to be an undesirable side-effect of org.eclipse.osgi.framework.eventmgr.EventManager's creation of an EventThread instance. In my particular situation the EventManager instance is MRUBundleFileList's bundleFileCloserManager. I'm running on 3.5.0.v20090311-1300. When the EventThread is lazily created, it gets its context class loader from the current thread. In my situation it's a call from a non-Equinox owned thread that's triggered the lazy creation of the EventThread instance. In this case at least, it doesn't seem right for this Equinox-owned thread to be holding a reference to this foregin class loader, particularly as it's not easy to update the EventThread's context classloader in application code. The reference to the classloader leads to a PermGen leak as the classloader doesn't become eligible for garbage collection. With the caveat that I don't know if there is some expectation about what the event thread's context class loader should be, I wonder if it would be better if EventManager was updated to explicitly set an EventThread's context class loader, possibly to Equinox's classloader, i.e. EventManager.class.getClassLoader()? Regards, Andy ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] ClassLoader leak caused by EventManager's EventThread creation
Hi BJ, Can you file a bug on this? Sure, here it is: https://bugs.eclipse.org/bugs/show_bug.cgi?id=275166 Thanks, Andy ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Conditional Permission are not being checked
Hi,
I am trying to check Conditional Permssion Admin SErvice in Equinox. For
this reason, I create a Bundle consumer, another one called service and
another called PermissionManager who will implement the Conditional
Permissions for the consumer.
The problem is that I do not get any exception when I try to get the service
from another location different from my allowed one.
My PermissionManager implements BundleActivator and get the service
ConditionalPermissionAdmin from the framework in the start method, finally
is shown below:
private ConditionalPermissionAdmin cpa;
condPermRef =
context.getServiceReference(ConditionalPermissionAdmin.class.getName());
cpa =(ConditionalPermissionAdmin) context.getService(condPermRef);
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
cpa.addConditionalPermissionInfo(new ConditionInfo[]{
new
ConditionInfo(BundleLocationCondition.class.getName(),
new
String[]{context.getBundle().getLocation()})
},
new PermissionInfo[]{
new PermissionInfo(
AllPermission.class.getName(), , )
});
cpa.addConditionalPermissionInfo(
new ConditionInfo[]{
new ConditionInfo(
BundleLocationCondition.class.getName(),
new
String[]{file:C:\\equinoxv34\\clientserviceconditional.jar})
},
new PermissionInfo[]{
new PermissionInfo
(ServicePermission.class.getName(),dconde.osgi.serviceconditional.ServiceCo
nditional,GET)
});
// Add other permissions
return null; // nothing to return
}
});
If I try to get the Service from another consumer in another location no
exception is thrown, and I do not really know what I am missing. What do I
need to apply Conditional Permission?
I am not applying as the same time Local Permission with permissions.perm,
Does this have something to do with my results?
I am launching Equinox in this way:
java
-Djava.security.manager=org.eclipse.osgi.framework.internal.core.FrameworkSe
curityManager -Djava.security.policy=policy.policy -jar
org.eclipse.osgi_3.4.3.R34x_v20081215-1030.jar -console
Any advice will be helpful
Thanks in advance
David
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Conditional Permission are not being checked
Can you try this on 3.5? The OSGi R4.2 specification (implemented in
Equinox 3.5) made a clarification about when the default permissions from
PermissionAdmin are used in the presence of the ConditionalPermissionAdmin
service.
The default default permissions for PermissionAdmin is AllPermissions. In
Equinox 3.4 we would fall back to the PermissionAdmin default permissions
if none of the conditions from the ConditionalPermissionAdmin table were
satisfied for a particular bundle. The OSGi R4.2 specification has been
clarified such that the PermissionAdmin default permissions are ONLY used
if the condition table is COMPLETELY empty. Once you add a single
condition to the table then bundles must not be granted the PermissionAdmin
default permissions.
In 3.4 you should set the PermissionAdmin default permissions to a
restricted set of permissions or you could set another condition with
ConditionalPermissionAdmin which restricts the permissions for all bundle
locations.
Tom
|
| From: |
|
--|
|David Conde dco...@citic.es
|
--|
|
| To:|
|
--|
|equinox-dev@eclipse.org
|
--|
|
| Date: |
|
--|
|05/06/2009 11:08 AM
|
--|
|
| Subject: |
|
--|
|[equinox-dev] Conditional Permission are not being checked
|
--|
Hi,
I am trying to check Conditional Permssion Admin SErvice in Equinox. For
this reason, I create a Bundle consumer, another one called service and
another called PermissionManager who will implement the Conditional
Permissions for the consumer.
The problem is that I do not get any exception when I try to get the
service from another location different from my allowed one.
My PermissionManager implements BundleActivator and get the service
ConditionalPermissionAdmin from the framework in the start method, finally
is shown below:
private ConditionalPermissionAdmin cpa;
condPermRef = context.getServiceReference(ConditionalPermissionAdmin.class
.getName());
cpa =(ConditionalPermissionAdmin) context.getService(condPermRef);
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
cpa.addConditionalPermissionInfo(new ConditionInfo[]{
new ConditionInfo(BundleLocationCondition.class
.getName(),
new
String[]{context.getBundle().getLocation()})
},
new PermissionInfo[]{
new PermissionInfo(
AllPermission.class.getName(), , )
});
cpa.addConditionalPermissionInfo(
new ConditionInfo[]{
new ConditionInfo(
BundleLocationCondition.class.getName(),
new
String[]{file:C:\\equinoxv34
\\clientserviceconditional.jar})
},
new PermissionInfo[]{
new PermissionInfo
(ServicePermission.class.getName(),
dconde.osgi.serviceconditional.ServiceConditional,GET)
});
// Add other permissions
return
[equinox-dev] Transforms from equinox incubator did not get moved to rt.equinox.incubator
Just an FYI. We forgot to include some of the transforms examples from the equinox incubator we we moved the incubator projects to rt.equinox.incubator. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=275172 They now live in their rightful place under cvsroot/rt: org.eclipse.equinox/incubator/components/bundles Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
