Re: [equinox-dev] OSGi security manager in Equinox
Hi Borislav,
Your intuition is correct. The best place for setting the initial
conditional permission table is in the launcher after initializing the
framework (Framework.init()) with an empty storage area. But after that I
think using a normal bundle (configurator type bundle) to do the ongoing
management of the permission table is fine.
Tom
From: Borislav Kapukaranov b.kapukara...@gmail.com
To: Equinox development mailing list equinox-dev@eclipse.org,
Date: 12/07/2011 09:59 PM
Subject:Re: [equinox-dev] OSGi security manager in Equinox
Thanks Tom, that was really helpful.
At this point I wonder if the only way to configure a secure framework is
to make sure you start a bundle right after the framework has booted which
will configure the (C)PA?
Any other ways to achieve that in addition to having a custom launcher? I'm
looking for a best practice here :-)
Why custom launcher - I suppose that's safer because it won't be affected
by any provisioning mechanism that can reorder your bundles' start or
rewrite your config.ini.
Thanks,
Borislav
On Dec 7, 2011 8:56 PM, Thomas Watson tjwat...@us.ibm.com wrote:
The policy file (specified by java.security.policy) is only used by class
loaders that extend SecureClassloader. So things like the
URLClassLoader,
the application and extension class loader etc. A bundle's class loader
does not pay attention to the java.security.policy file.
The protection domains used by the OSGi bundle class loaders are only
configured by the ConditionalPermissionAdmin and the deprecated
PermissionAdmin services. By default if no permissions are set through
the
[Conditional]PermissionAdmin services then the bundles get AllPermission
by
default. Section 50.11 of the Core OSGi specification gives more details
on this.
Tom
From: Borislav Kapukaranov b.kapukara...@gmail.com
To: Equinox development mailing list equinox-dev@eclipse.org,
Date: 12/07/2011 11:18 AM
Subject: [equinox-dev] OSGi security manager in Equinox
Hi folks,
I'm playing with OSGi's security manager in Equinox and the
implementation
of the Conditional Permissions Admin called SecurityAdmin.
My setup is Equinox + some other bundles. This is launched by the
equinox.launcher and I've passed the following as system properties:
-Declipse.security=osgi
-Djava.security.policy=my.policy
The policy looks like that
keystore myKeystore;
grant signedBy myself {
permission java.security.AllPermission;
};
I have signed all bundles in /plugins with that keystore and granted them
all premissions with the policy.
The first thing I noticed is that without a policy file the framework
still
starts. That is because when we are in OSGi security mode the launcher
adds
all permissions to itself and the framework.
I created a simple bundle that in its Activator creates a directory at a
location different from it's data file. It doesn't have any local
permissions.
The call went into the EquinoxSecurityManager then started checking for
implied permissions at the AccessControlContext. The important point is
checking the Protection Domains. It went through two of them:
1. The system bundle's protection domain as the system bundle triggered
the
Activator of my bundle.
2. The bundle's protection domain, probably for local permissions.
1) has all permission as it is the framework and 2) doesn't have any
local
permission therefore by specification gets AllPermission.
So far so good.
My question is how the EquinoxSecurityManager is expected to be
configured?
From what I've seen the policy file syntax doesn't support the permission
syntax defined in the OSGi specification(ALLOW, DENY).
Does that mean OSGi's security manager is configured only by a bundle
interacting with the Conditional Permission Admin service?
Also does the policy file play any role at all in such setup? I suspect
it's relevant only
Re: [equinox-dev] OSGi security manager in Equinox
I agree, this is the best place and a regular bundle after that will do. The
trick is to initialize the table in the first place.
I couldn't find a documented way to do that. One pointer I think might be
relevant, judging on the code, is the .permdata file that is read when a new
BasePermissionStorage is created. I'm not really sure where this file should be
placed, but I assume in /configuration/org.eclipse.osgi?
Do you know of that's the right way to initialize the conditional permission
table? Also what should be the syntax of that file?
If there's another way I'm all ears :)
Also I got the impression this initialization can be achieved with the standard
launcher, right?
Thanks,
Borislav
-Original Message-
From: equinox-dev-boun...@eclipse.org [mailto:equinox-dev-boun...@eclipse.org]
On Behalf Of Thomas Watson
Sent: Thursday, December 08, 2011 4:26 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] OSGi security manager in Equinox
Hi Borislav,
Your intuition is correct. The best place for setting the initial
conditional permission table is in the launcher after initializing the
framework (Framework.init()) with an empty storage area. But after that I
think using a normal bundle (configurator type bundle) to do the ongoing
management of the permission table is fine.
Tom
From: Borislav Kapukaranov b.kapukara...@gmail.com
To: Equinox development mailing list equinox-dev@eclipse.org,
Date: 12/07/2011 09:59 PM
Subject:Re: [equinox-dev] OSGi security manager in Equinox
Thanks Tom, that was really helpful.
At this point I wonder if the only way to configure a secure framework is
to make sure you start a bundle right after the framework has booted which
will configure the (C)PA?
Any other ways to achieve that in addition to having a custom launcher? I'm
looking for a best practice here :-)
Why custom launcher - I suppose that's safer because it won't be affected
by any provisioning mechanism that can reorder your bundles' start or
rewrite your config.ini.
Thanks,
Borislav
On Dec 7, 2011 8:56 PM, Thomas Watson tjwat...@us.ibm.com wrote:
The policy file (specified by java.security.policy) is only used by class
loaders that extend SecureClassloader. So things like the
URLClassLoader,
the application and extension class loader etc. A bundle's class loader
does not pay attention to the java.security.policy file.
The protection domains used by the OSGi bundle class loaders are only
configured by the ConditionalPermissionAdmin and the deprecated
PermissionAdmin services. By default if no permissions are set through
the
[Conditional]PermissionAdmin services then the bundles get AllPermission
by
default. Section 50.11 of the Core OSGi specification gives more details
on this.
Tom
From: Borislav Kapukaranov b.kapukara...@gmail.com
To: Equinox development mailing list equinox-dev@eclipse.org,
Date: 12/07/2011 11:18 AM
Subject: [equinox-dev] OSGi security manager in Equinox
Hi folks,
I'm playing with OSGi's security manager in Equinox and the
implementation
of the Conditional Permissions Admin called SecurityAdmin.
My setup is Equinox + some other bundles. This is launched by the
equinox.launcher and I've passed the following as system properties:
-Declipse.security=osgi
-Djava.security.policy=my.policy
The policy looks like that
keystore myKeystore;
grant signedBy myself {
permission java.security.AllPermission;
};
I have signed all bundles in /plugins with that keystore and granted them
all premissions with the policy.
The first thing I noticed is that without a policy file the framework
still
starts. That is because when we are in OSGi security mode the launcher
adds
all permissions to itself and the framework.
I created a simple bundle that in its Activator creates a directory at a
location different from it's data file. It doesn't have any local
permissions
Re: [equinox-dev] OSGi security manager in Equinox
You should never edit the .permdata file directly. That file is an implementation detail for the framework that is used to persistently store the cond perm admin table as managed by the [Conditional]PermissionAdmin services. The launcher should configure the cond perm admin table the same way as a normal bundle, by using the [Conditional]PermissionAdmin service. The way your custom launcher figures out what to populate the [Conditional]PermissionAdmin service with is an implementation detail of your launcher. You could use your own file or some other mechanism to drive the code in your launcher to call the methods on the [Conditional]PermissionAdmin service. Tom From: Kapukaranov, Borislav borislav.kapukara...@sap.com To: Equinox development mailing list equinox-dev@eclipse.org, Date: 12/08/2011 10:37 AM Subject:Re: [equinox-dev] OSGi security manager in Equinox I agree, this is the best place and a regular bundle after that will do. The trick is to initialize the table in the first place. I couldn't find a documented way to do that. One pointer I think might be relevant, judging on the code, is the .permdata file that is read when a new BasePermissionStorage is created. I'm not really sure where this file should be placed, but I assume in /configuration/org.eclipse.osgi? Do you know of that's the right way to initialize the conditional permission table? Also what should be the syntax of that file? If there's another way I'm all ears :) Also I got the impression this initialization can be achieved with the standard launcher, right? Thanks, Borislav -Original Message- From: equinox-dev-boun...@eclipse.org [ mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Thomas Watson Sent: Thursday, December 08, 2011 4:26 PM To: Equinox development mailing list Subject: Re: [equinox-dev] OSGi security manager in Equinox Hi Borislav, Your intuition is correct. The best place for setting the initial conditional permission table is in the launcher after initializing the framework (Framework.init()) with an empty storage area. But after that I think using a normal bundle (configurator type bundle) to do the ongoing management of the permission table is fine. Tom From: Borislav Kapukaranov b.kapukara...@gmail.com To: Equinox development mailing list equinox-dev@eclipse.org, Date: 12/07/2011 09:59 PM Subject:Re: [equinox-dev] OSGi security manager in Equinox Thanks Tom, that was really helpful. At this point I wonder if the only way to configure a secure framework is to make sure you start a bundle right after the framework has booted which will configure the (C)PA? Any other ways to achieve that in addition to having a custom launcher? I'm looking for a best practice here :-) Why custom launcher - I suppose that's safer because it won't be affected by any provisioning mechanism that can reorder your bundles' start or rewrite your config.ini. Thanks, Borislav On Dec 7, 2011 8:56 PM, Thomas Watson tjwat...@us.ibm.com wrote: The policy file (specified by java.security.policy) is only used by class loaders that extend SecureClassloader. So things like the URLClassLoader, the application and extension class loader etc. A bundle's class loader does not pay attention to the java.security.policy file. The protection domains used by the OSGi bundle class loaders are only configured by the ConditionalPermissionAdmin and the deprecated PermissionAdmin services. By default if no permissions are set through the [Conditional]PermissionAdmin services then the bundles get AllPermission by default. Section 50.11 of the Core OSGi specification gives more details on this. Tom From: Borislav Kapukaranov b.kapukara...@gmail.com To: Equinox development mailing list equinox-dev@eclipse.org, Date: 12/07/2011 11:18 AM Subject: [equinox-dev] OSGi security manager in Equinox Hi folks, I'm playing with OSGi's security
Re: [equinox-dev] OSGi security manager in Equinox
Thanks for the clarification. I was really hoping this could be achieved with a standard launcher. Do you feel it would be beneficial to users if the equinox.launcher could optionally configure the [Conditional]PermissionAdmin with specified permissions? I'm willing to contribute :) Best Regards Borislav -Original Message- From: equinox-dev-boun...@eclipse.org [mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Thomas Watson Sent: Thursday, December 08, 2011 7:01 PM To: Equinox development mailing list Subject: Re: [equinox-dev] OSGi security manager in Equinox You should never edit the .permdata file directly. That file is an implementation detail for the framework that is used to persistently store the cond perm admin table as managed by the [Conditional]PermissionAdmin services. The launcher should configure the cond perm admin table the same way as a normal bundle, by using the [Conditional]PermissionAdmin service. The way your custom launcher figures out what to populate the [Conditional]PermissionAdmin service with is an implementation detail of your launcher. You could use your own file or some other mechanism to drive the code in your launcher to call the methods on the [Conditional]PermissionAdmin service. Tom From: Kapukaranov, Borislav borislav.kapukara...@sap.com To: Equinox development mailing list equinox-dev@eclipse.org, Date: 12/08/2011 10:37 AM Subject:Re: [equinox-dev] OSGi security manager in Equinox I agree, this is the best place and a regular bundle after that will do. The trick is to initialize the table in the first place. I couldn't find a documented way to do that. One pointer I think might be relevant, judging on the code, is the .permdata file that is read when a new BasePermissionStorage is created. I'm not really sure where this file should be placed, but I assume in /configuration/org.eclipse.osgi? Do you know of that's the right way to initialize the conditional permission table? Also what should be the syntax of that file? If there's another way I'm all ears :) Also I got the impression this initialization can be achieved with the standard launcher, right? Thanks, Borislav -Original Message- From: equinox-dev-boun...@eclipse.org [ mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Thomas Watson Sent: Thursday, December 08, 2011 4:26 PM To: Equinox development mailing list Subject: Re: [equinox-dev] OSGi security manager in Equinox Hi Borislav, Your intuition is correct. The best place for setting the initial conditional permission table is in the launcher after initializing the framework (Framework.init()) with an empty storage area. But after that I think using a normal bundle (configurator type bundle) to do the ongoing management of the permission table is fine. Tom From: Borislav Kapukaranov b.kapukara...@gmail.com To: Equinox development mailing list equinox-dev@eclipse.org, Date: 12/07/2011 09:59 PM Subject:Re: [equinox-dev] OSGi security manager in Equinox Thanks Tom, that was really helpful. At this point I wonder if the only way to configure a secure framework is to make sure you start a bundle right after the framework has booted which will configure the (C)PA? Any other ways to achieve that in addition to having a custom launcher? I'm looking for a best practice here :-) Why custom launcher - I suppose that's safer because it won't be affected by any provisioning mechanism that can reorder your bundles' start or rewrite your config.ini. Thanks, Borislav On Dec 7, 2011 8:56 PM, Thomas Watson tjwat...@us.ibm.com wrote: The policy file (specified by java.security.policy) is only used by class loaders that extend SecureClassloader. So things like the URLClassLoader, the application and extension class loader etc. A bundle's class loader does not pay attention to the java.security.policy file. The protection domains used by the OSGi bundle class loaders are only configured
Re: [equinox-dev] OSGi security manager in Equinox
Which launcher are you interested in particular? There is the standard OSGi launching API (org.osgi.framework.launch) which Equinox implements with the org.eclipse.osgi.launch.EquinoxFactory class. This API is meant to be used by a launcher implementation as a standard way of constructing and initializing an OSGi Framework instance. In my view it would not be correct to add anything to the standard OSGi launching API implementation for auto configuring permissions. This should be left in the hands of the code that invokes the standard OSGi launching API. So if you are using the standard OSGi launching API to launch Equinox I think you should place your logic for setting permissions in your own code which is constructing the Framework instance. There is also the equinox launcher (implemented with the org.eclipse.equinox.launcher jar). This jar is used by the native eclipse.exe launcher to startup the typical eclipse installation (IDE, RCP etc.). This jar ends up using the eclipse specific launching class org.eclipse.core.runtime.adaptor.EclipseStarter. We could consider adding an option to this launch path to setup the initial permissions. If this is what you are interested in then please open a bug. Tom | | From: | | --| |Kapukaranov, Borislav borislav.kapukara...@sap.com | --| | | To:| | --| |Equinox development mailing list equinox-dev@eclipse.org, | --| | | Date: | | --| |12/08/2011 11:28 AM | --| | | Subject: | | --| |Re: [equinox-dev] OSGi security manager in Equinox | --| Thanks for the clarification. I was really hoping this could be achieved with a standard launcher. Do you feel it would be beneficial to users if the equinox.launcher could optionally configure the [Conditional]PermissionAdmin with specified permissions? I'm willing to contribute :) Best Regards Borislav -Original Message- From: equinox-dev-boun...@eclipse.org [ mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Thomas Watson Sent: Thursday, December 08, 2011 7:01 PM To: Equinox development mailing list Subject: Re: [equinox-dev] OSGi security manager in Equinox You should never edit the .permdata file directly. That file is an implementation detail for the framework that is used to persistently store the cond perm admin table as managed by the [Conditional]PermissionAdmin services. The launcher should configure the cond perm admin table the same way as a normal bundle, by using the [Conditional]PermissionAdmin service. The way your custom launcher figures out what to populate the [Conditional]PermissionAdmin service with is an implementation detail of your launcher. You could use your own file or some other mechanism to drive the code in your launcher to call the methods on the [Conditional]PermissionAdmin service. Tom From: Kapukaranov, Borislav borislav.kapukara...@sap.com To: Equinox development mailing list equinox-dev@eclipse.org, Date: 12/08/2011 10:37 AM Subject:Re: [equinox-dev] OSGi security manager in Equinox I agree, this is the best place and a regular bundle after that will do. The trick is to initialize the table in the first place. I couldn't find a documented way to do that. One pointer I think might be relevant, judging on the code, is the .permdata file
Re: [equinox-dev] OSGi security manager in Equinox
The equinox launcher is what I had in mind. I've opened a bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=366123 to track that enhancement. Thanks for your help, Borislav On Thu, Dec 8, 2011 at 9:47 PM, Thomas Watson tjwat...@us.ibm.com wrote: Which launcher are you interested in particular? There is the standard OSGi launching API (org.osgi.framework.launch) which Equinox implements with the org.eclipse.osgi.launch.EquinoxFactory class. This API is meant to be used by a launcher implementation as a standard way of constructing and initializing an OSGi Framework instance. In my view it would not be correct to add anything to the standard OSGi launching API implementation for auto configuring permissions. This should be left in the hands of the code that invokes the standard OSGi launching API. So if you are using the standard OSGi launching API to launch Equinox I think you should place your logic for setting permissions in your own code which is constructing the Framework instance. There is also the equinox launcher (implemented with the org.eclipse.equinox.launcher jar). This jar is used by the native eclipse.exe launcher to startup the typical eclipse installation (IDE, RCP etc.). This jar ends up using the eclipse specific launching class org.eclipse.core.runtime.adaptor.EclipseStarter. We could consider adding an option to this launch path to setup the initial permissions. If this is what you are interested in then please open a bug. Tom | | From: | | --| |Kapukaranov, Borislav borislav.kapukara...@sap.com | --| | | To:| | --| |Equinox development mailing list equinox-dev@eclipse.org, | --| | | Date: | | --| |12/08/2011 11:28 AM | --| | | Subject: | | --| |Re: [equinox-dev] OSGi security manager in Equinox | --| Thanks for the clarification. I was really hoping this could be achieved with a standard launcher. Do you feel it would be beneficial to users if the equinox.launcher could optionally configure the [Conditional]PermissionAdmin with specified permissions? I'm willing to contribute :) Best Regards Borislav -Original Message- From: equinox-dev-boun...@eclipse.org [ mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Thomas Watson Sent: Thursday, December 08, 2011 7:01 PM To: Equinox development mailing list Subject: Re: [equinox-dev] OSGi security manager in Equinox You should never edit the .permdata file directly. That file is an implementation detail for the framework that is used to persistently store the cond perm admin table as managed by the [Conditional]PermissionAdmin services. The launcher should configure the cond perm admin table the same way as a normal bundle, by using the [Conditional]PermissionAdmin service. The way your custom launcher figures out what to populate the [Conditional]PermissionAdmin service with is an implementation detail of your launcher. You could use your own file or some other mechanism to drive the code in your launcher to call the methods on the [Conditional]PermissionAdmin service. Tom From: Kapukaranov, Borislav borislav.kapukara...@sap.com To: Equinox development mailing list equinox-dev@eclipse.org, Date: 12/08/2011 10:37 AM Subject:Re: [equinox-dev] OSGi security manager in Equinox I agree, this is the best place and a regular bundle after that will do. The trick is to initialize the table
Re: [equinox-dev] OSGi security manager in Equinox
The policy file (specified by java.security.policy) is only used by class
loaders that extend SecureClassloader. So things like the URLClassLoader,
the application and extension class loader etc. A bundle's class loader
does not pay attention to the java.security.policy file.
The protection domains used by the OSGi bundle class loaders are only
configured by the ConditionalPermissionAdmin and the deprecated
PermissionAdmin services. By default if no permissions are set through the
[Conditional]PermissionAdmin services then the bundles get AllPermission by
default. Section 50.11 of the Core OSGi specification gives more details
on this.
Tom
From: Borislav Kapukaranov b.kapukara...@gmail.com
To: Equinox development mailing list equinox-dev@eclipse.org,
Date: 12/07/2011 11:18 AM
Subject:[equinox-dev] OSGi security manager in Equinox
Hi folks,
I'm playing with OSGi's security manager in Equinox and the implementation
of the Conditional Permissions Admin called SecurityAdmin.
My setup is Equinox + some other bundles. This is launched by the
equinox.launcher and I've passed the following as system properties:
-Declipse.security=osgi
-Djava.security.policy=my.policy
The policy looks like that
keystore myKeystore;
grant signedBy myself {
permission java.security.AllPermission;
};
I have signed all bundles in /plugins with that keystore and granted them
all premissions with the policy.
The first thing I noticed is that without a policy file the framework still
starts. That is because when we are in OSGi security mode the launcher adds
all permissions to itself and the framework.
I created a simple bundle that in its Activator creates a directory at a
location different from it's data file. It doesn't have any local
permissions.
The call went into the EquinoxSecurityManager then started checking for
implied permissions at the AccessControlContext. The important point is
checking the Protection Domains. It went through two of them:
1. The system bundle's protection domain as the system bundle triggered the
Activator of my bundle.
2. The bundle's protection domain, probably for local permissions.
1) has all permission as it is the framework and 2) doesn't have any local
permission therefore by specification gets AllPermission.
So far so good.
My question is how the EquinoxSecurityManager is expected to be configured?
From what I've seen the policy file syntax doesn't support the permission
syntax defined in the OSGi specification(ALLOW, DENY).
Does that mean OSGi's security manager is configured only by a bundle
interacting with the Conditional Permission Admin service?
Also does the policy file play any role at all in such setup? I suspect
it's relevant only for pure Java security setup.
Thanks,
Borislav___
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] OSGi security manager in Equinox
Thanks Tom, that was really helpful.
At this point I wonder if the only way to configure a secure framework is
to make sure you start a bundle right after the framework has booted which
will configure the (C)PA?
Any other ways to achieve that in addition to having a custom launcher? I'm
looking for a best practice here :-)
Why custom launcher - I suppose that's safer because it won't be affected
by any provisioning mechanism that can reorder your bundles' start or
rewrite your config.ini.
Thanks,
Borislav
On Dec 7, 2011 8:56 PM, Thomas Watson tjwat...@us.ibm.com wrote:
The policy file (specified by java.security.policy) is only used by class
loaders that extend SecureClassloader. So things like the URLClassLoader,
the application and extension class loader etc. A bundle's class loader
does not pay attention to the java.security.policy file.
The protection domains used by the OSGi bundle class loaders are only
configured by the ConditionalPermissionAdmin and the deprecated
PermissionAdmin services. By default if no permissions are set through the
[Conditional]PermissionAdmin services then the bundles get AllPermission by
default. Section 50.11 of the Core OSGi specification gives more details
on this.
Tom
From: Borislav Kapukaranov b.kapukara...@gmail.com
To: Equinox development mailing list equinox-dev@eclipse.org,
Date: 12/07/2011 11:18 AM
Subject:[equinox-dev] OSGi security manager in Equinox
Hi folks,
I'm playing with OSGi's security manager in Equinox and the implementation
of the Conditional Permissions Admin called SecurityAdmin.
My setup is Equinox + some other bundles. This is launched by the
equinox.launcher and I've passed the following as system properties:
-Declipse.security=osgi
-Djava.security.policy=my.policy
The policy looks like that
keystore myKeystore;
grant signedBy myself {
permission java.security.AllPermission;
};
I have signed all bundles in /plugins with that keystore and granted them
all premissions with the policy.
The first thing I noticed is that without a policy file the framework still
starts. That is because when we are in OSGi security mode the launcher adds
all permissions to itself and the framework.
I created a simple bundle that in its Activator creates a directory at a
location different from it's data file. It doesn't have any local
permissions.
The call went into the EquinoxSecurityManager then started checking for
implied permissions at the AccessControlContext. The important point is
checking the Protection Domains. It went through two of them:
1. The system bundle's protection domain as the system bundle triggered the
Activator of my bundle.
2. The bundle's protection domain, probably for local permissions.
1) has all permission as it is the framework and 2) doesn't have any local
permission therefore by specification gets AllPermission.
So far so good.
My question is how the EquinoxSecurityManager is expected to be configured?
From what I've seen the policy file syntax doesn't support the permission
syntax defined in the OSGi specification(ALLOW, DENY).
Does that mean OSGi's security manager is configured only by a bundle
interacting with the Conditional Permission Admin service?
Also does the policy file play any role at all in such setup? I suspect
it's relevant only for pure Java security setup.
Thanks,
Borislav___
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
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
