Eclipse Security

[JavaJoeS]

@tjwatson @scottslewis
Im seeking an eclipse home for an eclipse security project to provide SSLContext. I have 2 base bundles that currently reside in
Eclipse Marketplace called PKI and they provide a basis for an SSLContext instance with PKCS11 or PKCS12 protocol.
Scott has developed an OSGI SSLContext interface that utilizes a default context that can be created via PKI bundles.

[scottslewis]

To clarify @JavaJoeS posting...wrt the OSGi SSLContext interface...the service interface is SSLContextFactory. ECF then has an OSGi service-based implementation of this interface that supports using the OSGi service registry to support dynamically adding and removing SSLContext providers (e.g. ones @JavaJoeS has created).

The SSLContextFactory service interface (and impl if desired) could/would be contributed to the project willing to take it (e.g. osgi spec, equinox impl, Eclipse platform). Interface and impl are open to modification of course.

The current usage of it is to set the ECF JRE provider's SSLContext when constructing an HttpClient:

[merks]

This is a really challenging topic. Who has the time and the skills to evaluate something like this? Where are the details that need to be evaluated? Who will maintain it 4 years from now? I have no clue why we need this or what it would do for me... 😢

[scottslewis]

What would it do for the Eclipse dev (and product) communities to have something new wrt platform security? Maybe time for a team/community effort?

[merks]

I don't know what it would do for the communities to have something new with respect to platform security. I don't know what this thing brings specifically, who would use it, how they would use it, what the benefit would be of using it over and above what the communities are using now. Is this something the platform itself ought to use, or is this something that the platform could provide for others to use? I don't even know if this is the highest priority desire of the community. So many open questions. Where to find answers?

Definitely a team of experts would be great. Unfortunately teams are very hard to come by as you and I both know all too well. Or do you have in mind people with expertise in this area who are available to contribute to open source? I fear additional people will not just show up here. I also feel it would be rude to just ignore this discussion entirely. That being said, I'm at a loss of what I can bring to the table. I'm swamped and I suspect most people reading this are swamped...

[JavaJoeS]

Here is an analogy of Security vice None. Apologies if anyone is offended.. Think of the internet as a war zone.
If you enter into the internet without your kevlar and helmet you may survive. However, if you have an opportunity to
put that helmet and kevlar on, your chances to survive are greatly increased. Similarly accessing internet endpoints without any security
may cause you to be hacked. There are too many packages that I have found in eclipse to list them all, but here is the short list
EPP, P2, EQUINOX, MPC, M2E, ECF, and the list goes on. ALL have internet endpoints that are not secured. I know of many corporations that fix this problem by adding an "AIRGAP" to their networks.

[laeubi]

Similarly accessing internet endpoints without any security
EPP, P2, EQUINOX, MPC, M2E, ECF, and the list goes on. ALL have internet endpoints that are not secured.

This is something that is often claimed regarding this topic but it is completely wrong.

P2 since a while ONLY supports HTTPs so the claim that no security is used is wrong. Next P2 checks the checksums and certificates and PGP keys, so gain claiming it is used "without any security" is simply confusing.

All this can already be configured by standard java and within the IDE...

The only case where I would need such think is when using client certificates, what is a very very uncommon setup and indeed would maybe require some extensions to P2, but this is about server-security and not client-security...

[JavaJoeS]

Securing the data on the wire, is not securing the wire itself.

[laeubi]

Securing the data on the wire, is not securing the wire itself.

On top of this endpoint security established, P2 uses PGP and/or codesigning to even verify the integrity of the data implementing data security.... while here it is state it does not use any security.

You are talking in mystery again... P2 uses SSL what is an standard technique "designed to provide communications security over a computer network" also know as "the wire" and you are talking about you need an SSLContext so I'm completely lost what you wanted to express.

Looking at the code it more looks like you want to manage the truststore (what is fine) and support e.g. encrypted private keys but that's a completely different topic.

[scottslewis]

Maybe you/Ed/I don't need to know...as it could/would benefit other dev community members. Maybe its a new way of identifying the experts from the dev community that's needed. As for answers to your (and others) questions: again seems like bottom up/dev community consensus/open collaboration/respect cooperation...in the OSS tradition would be worth trying over same ol'. Wrt expertise...me (eg SSLContext/OSGi and 15 years providing transport for eclipse install. You. Joe. Thomas. Other new and old devs. I have little doubt that there are plenty of potential stewards with relevant expertise and experiences...given resources and access...ie not being swamped/starved.

[laeubi]

In any way I think it would help to

• Link the marketplace (seems to be here https://marketplace.eclipse.org/content/eclipse-pki )
• Source code (can't find it right now)
• Explain what code explicitly should be hosted by Equinox (maybe even open a PR)
• How it looks like in the IDE before/after
• What features can be used only with this and so on

From the recent discussions the main problem was that this seems to be a very specific area, and most people either don't need it or have other (maybe java standard?) ways to accomplish the goal, if I look at the marketplace metrics it show 15 installs and 5 click in this year (not sure if there is more details available)

[JavaJoeS]

After reading the OSGI docs, paragraph 2 is "SECURITY". Subparagraph 2.2.2 is "OPTIONAL SECURITY". In eclipse at this moment we dont have an option. We do have lots of internet endpoints without ANY regard for security. My PKI at least will provide those that wish to use it, that option. Simply put, eclipse will have the option of an SSLContext as specified in JAVA SECURITY ARCHITECHTURE JSA, documented in the OSGI spec. Build it and they will come!

[laeubi]

@JavaJoeS it would really help if you would give links to thing you are referencing, at least I can't follow what this mean or how it is related. I can only guess you mean 2 Security Layer what has nothing to do with SSLContext and even if it is optional Equinox already does supports it.

And I must confess this mixing of things makes it very hard to convince people something should be added here, this topic came up not the first time here (also at P2 and Platform) and every-time one asks for concrete details it ends up in a wild mixture of concerns that do not clarify why it is needed where it is needed and how is is supposed to solve the problem.

[JavaJoeS]

https://github.com/JavaJoeS/PkiBundle/tree/main/pki

Where should these bundles live?

Update Site:

https://idetoolsio.github.io/core/updatesite/site.xml

[laeubi]

Just a quick review of the code:

1. Repository is missing a readme describing the intend, purpose and usage of the code.
2. I see almost no javadoc
3. Many TODO printouts commented code
4. Git history is hardly readable

1-3 is at at lest mandatory to move code inside Eclipse Projects code-base. Maybe you can extract a minimal value increment so not all code needs to be migrated at once.

[scottslewis]

This issue has gone quickly off the rails.

@JavaJoeS is suggesting some directional improvements wrt Eclipse Security strategy...e.g. support for new client-server encryption protocols, new trust models...yes client auth but also e2e encryption/communitcation/trust, UI for Eclipse user and security configuration/trust mgmt of non client-server and client server, other things). He has done work in these directions that he is willing to contribute.

The reception here has so far been akin to: where is the completed-ready-to-merge fix from our existing bug list?...and why would you want to add anything to that list? While I understand as @merks says that everyone is permanently swamped...as that is the default now for remaining active long-time committers...I would hope for more latitude when members of the dev community try to begin a public discussion about areas for innovation wrt Eclipse Security.

[mickaelistria]

The discussion is actively going on. The proposal is not rejected at all so far.
But as you understand, security is critical and difficult, we cannot just take a contribution as good for granted, and we do need to evaluate more than the intention before the project can handle such new security feature. For example, such new feature would probably have to go through a security audit, and will require the contributor to commit on some maintenance if necessary after the feature is in Equinox.
Those questions are important, and it's too bad if they seem to be missing "latitude", but security is too critical to just handle it with "latitude", we have to build trust, to set up plans, audit, to commit to immediate maintenance... It's much more than just fixing a typo.

[JavaJoeS]

Understood and expected. Everything you mention screams team work. Im on board. My intent is not to replace anything. The idea is more complementary than competing. Always nice to have options. Thank you for the opportunity to entertain my security option.

[scottslewis]

On Mon, Dec 16, 2024, 10:19 PM Mickael Istria ***@***.***> wrote: The discussion is actively going on.

Where? Can the actual devs (users and committers) be involved rather than dictated to?

Those questions are important, and it's too bad if they seem to be missing "latitude", but security is too critical to just handle it with "latitude",

Geez. Yeah sure..that's what I (or anyone) is suggesting...just accept anything. Maybe its too crtical (to the community) to be left to the usual players and process. we have to build trust, to set up plans, audit, to commit to immediate

maintenance...

The question is: who is we? Are you/anyone buillding trust with the os dev community? If so, how? It's much more than just fixing a typo.

Oh really? I didn't know that.

[mickaelistria]

What about welcoming this contribution into ECF ?

[JavaJoeS]

The security package needs to be higher up the food chain. Are you just yanking Scotts chain! lol...

[scottslewis]

It's a possibility for parts. Since ECF's scope in Eclipse is limited to p2/install update, it would still result in a very fragmented Eclipse security story wrt...e.g...support for other encryption protocols as Joe points out. Also, ECF/p2/install update currently has no UI contributions (the proxy API/UI is Platform), and so the config/pref/UI part of things would be awkward to add and should...IMHO not be in ECF. However, ECF filetransfer has it's own maintenance issues atm, and I can't currently commit to adding functionality more than I've already done (see above).

[mickaelistria]

Some questions that the description doesn't answer and that leave use unsure are:

• Are you aware of actual usage or need for PKI support on Equinox? Can you build a user-story for it?
• What are the specific parts it secures? p2 ? Networking access in general?...
• Why does it have to be part of Equinox? Aren't those more or less just JVM settings and configuration? Most code doesn't seem to be so specific to Equinox and the integration seems to be mostly about setting system properties.
• Equinox usually has no UI in the repo. The preference page are in Eclipse Platform.
• What is the issue with keeping this plugin external, as long as it is "niche" and maybe consider it for inclusion in Eclipse later, when the use-cases for it mature?

[JavaJoeS]

I am not stuck on equinox. Scott seemed to think it was a good home since its higer up food chain, Im thinking runtime may work too.

The basic part is to provide an SSLContext which needs to be done on start up. Subsequently, all wire transfers can be locked down.

Two parts of the pki are headless part and then UI piece.

Scott and I decided it is not a good idea to access PKI methods via reflection. Neither of us like it. Hence it needs home.

[scottslewis]

Answers to some of the 'why OSGi/Equinox/Eclipse' questions from @mickaelistria

I am not stuck on equinox. Scott seemed to think it was a good home since its higer up food chain, Im thinking runtime may work too.

By 'Scott seemed to think it was a good home' this is what was meant:

In the ECF httpclient provider (and others), the way to configure the HttpClient is via HttpClient.Builder.sslContext method, which takes a non-null SSLContext instance for security configuration of the HttpClient upon construction.

How does one get/create/configure an SSLContext instance? Currently it's via static methods on the vm SSLContext class. The point of the SSLContextFactory is to make the retrieval of an SSLContext instance dynamic and extensible by using the OSGi service registry...and to allow new Provider implementations (like Joe's). The usage of this service is now in the httpclient provider.

However, declaring the SSLSocketFactory service interface in ECF means that

a) that ECF has to create/configure the service implementation...without accessing any Eclipse UI;
b) there is no way for other bundles (e.g. Eclipse Platform) to do so without depending on ECF core. Thus the incentive to move the service interface and/or impl to Eclipse, Equinox, or OSGi. And, of course, there will be other ideas about how to make SSLContext lookup, config and creation dynamic and extensible. That's fine by me.
c) As said by @JavaJoeS above, it would also be valuable and more secure to have some Eclipse-wide configuration of the default SSLContext, as currently there are many plugins that 'write over' one another by calling static method SSLContext.setContext, making it very hard to say what SSLContext is being used as the default at the application and/or product level across individual installations.

[mickaelistria]

All this story seems similar to proxy settings to me, isn't it?
If so, then a solution should probably mimic the proxy settings implementation: the core part with a service as API in org.eclipse.core.net with an internal implementation in it and some UI in org.eclipse.ui.net.
However, on current issue is that it seems like ECF would be the only consumer so far, and a single consumer is usually not enough to derive a good enough API that can serve more cases. So as long as ECF is the only requestor for it, I think it's preferrable to keep the related code on ECF, until there is actual value in sharing it upstream in Platform. There are some other consumers of IProxyService in Platform (org.eclipse.help.internal.base.util.ProxyUtil, org.eclipse.jsch.internal.core.JschCorePlugin) which can probably leverage such a proposed SSLContextService. If the proposed service can serve both + ECF efficiently, then it would build a story where the proposal becomes valuable for Platform, and it would seem more interesting to start hosting the related code.

[laeubi]

@scottslewis I would have been much easier explicitly state that only SSLContextFactory is to be added somewhere, I'm not sure all the discussions here really had lead to that because of all this PKI, Equinox no using security at all stuff and so on.

In the light of this, I think the URL Handlers Service Specification is probably a much better place or some kind of new specification if you want general adoption not only in Equinox.

But given that @mickaelistria mentions ECF is the only consumer of the interface it seems better to maybe host is there so you can easier evolve that. Regarding your concerns platform can for sure depend on an ECF bundle (and already does) so it only would be a matter to maybe provide that interface in a bundle that has no direct dependencies to any other stuff. Such bundle can then also much easier be migrated elsewhere and has much less potential of confusion what actually is desired.

[JavaJoeS]

AS previously mentioned, many eclipse packages suffer from inability to handle a complete PKI solution. Some simply need to not step on a previously set SSLContext default. @scottslewis has provided a mechanism that probably needs to be adopted by ALL offending packages that may want PKI. Not mandatory, but optionally as described by equinox Security doc 2.2.2

[scottslewis]

Where to start?

First, my apologies to @JavaJoeS, as I think I've derailed the conversation about Eclipse security again (this time with SSLContextFactory specifics). My suggestion is, that the 'what to do about SSLContext to make the JCA dynamic and extensible for Eclipse' be moved to a new Platform issue. I'm not going to open that issue myself, however, as I'm not on the Platform, Equinox, or OSGi teams.

All this story seems similar to proxy settings to me, isn't it?

In some ways, yes. Long ago there was no API for the vm-level proxy config, and there was only JRE-level proxy config UI. At that time, the Eclipse IDE team decided to create the proxy API, so that they could create in Eclipse UI/preferences the UI (config write) and then required/forced ECF to use that API for p2 filetransfer (config read). As ECF consumers are not just the Eclipse IDE, we even had put in a hack to use reflection so that the proxy API could be optionally present for other ECF consumers. All this was done at the 'request' of the Platform. One thing to add, however: the proxy API was never used by other Eclipse projects...as for a long time they had their own proxy config/persistence mechanisms (e.g. m2e, lots of other tooling that downloaded other resources), and then...after years of user pain, the JRE introduced a new proxy API, and lots of projects started using that instead of the platform proxy API. And proxy config is still a mess, because of the OS-level-vs.-Java-level eccentricities/leakiness.

Back to JCA dynamics and extensions and SSLContext. Most of what I'm suggesting with SSLContextFactory service could be accomplished by making the JCA dynamic and extensible at the app-level (just as the vm-spec did). If that's what the community wants, then be my guest...and maybe it's already happening. Great.

In the mean time...

In the light of this, I think the URL Handlers Service Specification >is probably a much better place or some kind of new specification if you want general adoption not only in Equinox.

I say: agreed. Please make it so or provide resources to make it so and I'll help. But I've already been to that fight more than once (e.g. Remote Services), and am not volunteering for that any more. I do agree, however, that as a 'fix' for a the static nature of the JCA at present, it would be attractive to use the OSGi service registry, already in Eclipse, etc as it's obviously mature, open, specified, secure, yada, yada.

If I had my way, something like the SSLContextFactory interface would be specified...similar to the URL Handlers Service Specification...which I/ECF know very well...as ECF obviously has had to deal with URLs and URL handlers. If the service interface was specified then it could be implemented in multiple locations...e.g Equinox, Platform, ECF etc. Which was 'best' would depend on desired scope of config/UI, extensibility, and crypto security guarantees...e.g. Equinox/OSGi/Eclipse Platform/Eclipse IDE. For example, ECF intends to add support for e2e encryption whether the IDE uses it or not, and this helps with that.

As for ECF hosting. We have a solution that works for ECF filetransfer as described above. As @JavaJoeS rightly points out, it would make sense to have the other eclipse IDE packages be covered by the same Platform mechanism, but that's not currently my or ECF's concern/scope, and we're not able or willing to do the work on behalf of other projects. as was done ~15 years ago with the proxy api. I'm completely willing to donate this already-done work to whatever project(s)/orgs/etc are willing to take it on. I'm also willing to take on contributions (e.g. from @JavaJoeS and others) that make sense within ECF's scope with proper dependencies), but obviously such contributions have to be developed, tested, maintained, secured, maybe specified, legally compliant, etc. and ECF is currently not in a position or inclination to do that.

@scottslewis I would have been much easier explicitly state that only SSLContextFactory is to be added somewhere, I'm >not sure all the discussions here really had lead to that because of all this PKI, Equinox no using security at all stuff and so on.

I don't particularly care what's easier for you to understand, and I ask that you not presume to tell me or anyone what is being proposed. As stated repeatedly, this Eclipse Security issue is more general than where to put SSLContextFactory, but it seems to keep getting hijacked with overly-specific technical discussions. If further discussion about enhancing, simplifying, moving SSLContextFactory or implementation is desired, then please open a new Equinox and/or Platform issue and we'll discuss further there.

[JavaJoeS]

EclipsePKI.pdf