A PKI connection is needed in some of the files in this package. At the moment no secure comms are supported.

[JavaJoeS]

I see comments where people are asking for secure comms in ECF package, MY PKI package will work well in this case.

@scottslewis
After the addition of the SSLContextFactory it works well to trigger it and then reap the benefits of getting an
HttpsURLConnection.setDefaultSSLSocketFactory(socketFactory); The following packages contain url connections
that can be easily altered to get the benefits of the SSLContextFactory settings;
package org.eclipse.ecf.provider.filefransfer.browse
URLFileSystemBrowser.java
package org.eclipse.ecf.provider.filefransfer.retrieve
UrlConnectionRetrieveFileTransfer.java

[JavaJoeS]

Can I get an approve for my pull request?

[JavaJoeS]

@scottslewis
Here is what the prinln statements of my PKI package are;
`ENTRY org.eclipse.core.pki 2 0 2024-04-26 08:12:47.574
!MESSAGE A PKI file detected;/home/mydir/.eclipse/.pki

!ENTRY org.eclipse.core.pki 2 0 2024-04-26 08:12:47.789
!MESSAGE SecurityFileSnapshot - Loaded PKI System Properties

!ENTRY org.eclipse.core.pki 1 0 2024-04-26 08:12:47.819
!MESSAGE A Keystore and Password are detected.

!ENTRY org.eclipse.core.pki 1 0 2024-04-26 08:12:47.819
!MESSAGE A KeyStore and Truststore are detected.

!ENTRY org.eclipse.core.pki 1 0 2024-04-26 08:12:47.854
!MESSAGE Initialization PKIX Trust Manager Complete

!ENTRY org.eclipse.core.pki 1 0 2024-04-26 08:12:47.876
!MESSAGE PKISetup default SSLContext has been configured.
`

[JavaJoeS]

@scottslewis
I looked at SSLContextHelper.java and I think its a good place to just grab the default SSLContext that gets set by my PKI package. THoughts?

[scottslewis]

Hi @JavaJoeS

I don't have a problem with that...assuming there would be no changes to the existing ECF code. And if there are I'm OK to make them, but would have to make sure that new dependencies weren't added (if at all possible).

[scottslewis]

One other observation. Currently, the only usage of SSLContextHelper in ECF code is ECFSSLSocketFactory and ECFSSLServerSocketFactory classes also in org.eclipse.ecf.ssl. Might those be better to access?

[scottslewis]

@JavaJoeS question: is your PKI code going directly into an existing Eclipse plugin? And if so, which ones?

[JavaJoeS]

@scottslewis Originally I was targeting the eclipse-platform as suggested by some other eclipse Members, Mickael Istrea. Subsequently another member suggested just putting it in Marketplace as an easy win. The package is org.eclipse.core.pki and listed as PKI. Code changes needed to support PKI are simple JAVA code, since the PKI package sets the default SSLContext.
Since the pki package sets the default SSLContext, then all the code has to do is grab it as in SSLContext.getDefault().

[JavaJoeS]

@scottslewis Here is an example from SSLContextHalper.java that I am testing;
`public static SSLContext getSSLContext(String protocols) {
SSLContext resultContext = null;
try {
resultContext = SSLContext.getDefault();
} catch (NoSuchAlgorithmException pkiNotAvailableERR) {
// TODO Auto-generated catch block
// e.printStackTrace();

		if (protocols != null) {

			String[] httpsProtocols = protocols.split(",");
			// trim to make sure
			for (int i = 0; i < httpsProtocols.length; i++)
				httpsProtocols[i] = httpsProtocols[i].trim();
			// Now put into defaultProtocolsList in order of jreProtocols
			List<String> splitProtocolsList = Arrays.asList(httpsProtocols);
			List<String> defaultProtocolsList = new ArrayList();
			for (String jreProtocol : jreProtocols) {
				if (splitProtocolsList.contains(jreProtocol)) {
					defaultProtocolsList.add(jreProtocol);
				}
			}
			// In order of jre protocols, attempt to create and init
			// SSLContext
			for (String protocol : defaultProtocolsList) {
				try {
					resultContext = SSLContext.getInstance(protocol);
					resultContext.init(null, new TrustManager[] { new ECFTrustManager() }, new SecureRandom());
					break;
				} catch (Exception e) {
					// just continue to look for SSLContexts with the next
					// protocolName
				}

			}
		}
	}
	return resultContext;
}`

[JavaJoeS]

@scottslewis My implementation of PKI is not working with ECF . Technically once the SSLContext.setDefault(context) has been set,
then SSLContext should be available globally. NOT working in ECF, Ive tried a bunch of options, but nothing working yet. ANY IDEAs,
thoughts greatly appreciated. Im currently trying to implement and adapter that contains only SSLContext. Adapter seems to work
but SSL seems to be kaboshed somehow.

[scottslewis]

@scottslewis My implementation of PKI is not working with ECF . Technically once the SSLContext.setDefault(context) has been set, then SSLContext should be available globally. NOT working in ECF, Ive tried a bunch of options, but nothing working yet. ANY IDEAs, thoughts greatly appreciated. Im currently trying to implement and adapter that contains only SSLContext. Adapter seems to work but SSL seems to be kaboshed somehow.

Hi @JavaJoeS. I don't immediately know what's going on. My only thought is that since Eclipse is now using the (relatively new) jrefiletransfer provider:

https://github.com/eclipse/ecf/tree/master/providers/bundles/org.eclipse.ecf.provider.filetransfer.httpclientjava

rather than the httpclient 5 provider

https://github.com/eclipse/ecf/tree/master/providers/bundles/org.eclipse.ecf.provider.filetransfer.httpclient5

that perhaps something went wrong for the ssl support in the changeover. I just noticed recently that the .ssl code doesn't seem to being called at when the httpclientjava provider is being used.

My apologies, but without some support for me I'm not going to be able to look into this further as I didn't develop either the original ssl impl nor the httpclientjava provider and so don't really know how it handles ssl relative to httpclient5 and lower. I would suggest opening an issue against Eclipse IDE or maybe p2) IDE if you determine that this is something specific to httpclientjava. Another idea: since the httpclient5 code is still there (there are some other incomplete things about the httpclient java provider), maybe you can see if your ssl changes work with the httpclient5 in eclipse.

I'm sorry to say that I've personally had it with supporting the IDE's usage of filetransfer with nothing but disdain from EF and/or IDE people. So although I will respond to your questions (if I can actually help), I won't take this issue on for further diagnosis and/or fix.

For context, see here for the other outstanding issue with httpclientjava before the IDE working group:

https://gitlab.eclipse.org/eclipse-wg/ide-wg/ide-wg-dev-funded-efforts/ide-wg-dev-funded-program-planning-council-top-issues/-/boards/1208

[JavaJoeS]

First, thank you for the response. Very helpful. I appreciate any information I can get. I have a copy of ecf and a able to build it.
Perhaps I can help to facilitate some results. WIth your help and knowlege, and my ssl background, maybe we can get something
out to make EF happy. Whats the best way to contact you? My direct email is joe @ schiavone dot org

[JavaJoeS]

@scottslewis I have a java program to load in the internal/ssl dir WOuld You like to see it before I load?

package org.eclipse.ecf.internal.ssl;

import java.io.InputStream;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.security.KeyStore;
import java.security.SecureRandom;
import java.util.Optional;

import javax.net.ssl.KeyManagerFactory;
import javax.net.ssl.SSLContext;
import javax.net.ssl.TrustManagerFactory;

public enum ECFSSLContext {
SETUP;
public SSLContext get() {
SSLContext context=null;

	try {
		context=SSLContextHelper.getSSLContext("TLS");
	} catch (Exception e) {
		// TODO Auto-generated catch block
		e.printStackTrace();
	}
	
	Optional<String>keystoreContainer=null;
	Optional<String>truststoreContainer=null;
	Optional<String>keystoreContainerPw = null;
	Optional<String>keystoreContainerType = null;
	Optional<String>truststoreContainerPw = null;
	Optional<String>truststoreContainerType = null;
	KeyStore keyStore = null;
	KeyStore trustStore=null;
	
	try {
		keystoreContainer = Optional.ofNullable(System.getProperty("javax.net.ssl.keyStore"));//$NON-NLS-1$
		keystoreContainerType=Optional.ofNullable(System.getProperty("javax.net.ssl.keyStoreType"));//$NON-NLS-1$
		keystoreContainerPw = Optional.ofNullable(System.getProperty("javax.net.ssl.keyStorePassword"));//$NON-NLS-1$
		
		truststoreContainer=Optional.ofNullable(System.getProperty("javax.net.ssl.trustStore"));//$NON-NLS-1$
		truststoreContainerPw=Optional.ofNullable(System.getProperty("javax.net.ssl.trustStorePassword"));//$NON-NLS-1$
		truststoreContainerType=Optional.ofNullable(System.getProperty("javax.net.ssl.trustStoreType"));//$NON-NLS-1$
		
		//  If ALL of the PKI properties are not set, then return NULL
		if ((keystoreContainer.isEmpty()) || keystoreContainerType.isEmpty() ||
				keystoreContainerPw.isEmpty() || truststoreContainer.isEmpty() ||
				truststoreContainerPw.isEmpty() || truststoreContainerType.isEmpty() ) {
			return null;
		}
			
		
		String keyStoreLocation = (String) keystoreContainer.get();
		String keyStoreType = (String) keystoreContainerType.get();
		String keyStorePassword = (String) keystoreContainerPw.get();
					
		String trustStoreLocation = (String) truststoreContainer.get();
		String trustStorePassword = (String) truststoreContainerPw.get();
		String trustStoreType=(String) truststoreContainerType.get();
		
		try {
			InputStream ki = Files.newInputStream(Paths.get(keyStoreLocation));
			keyStore = KeyStore.getInstance(keyStoreType);
			keyStore.load(ki, keyStorePassword.toCharArray());
			KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
			kmf.init(keyStore, keyStorePassword.toCharArray());
			context = SSLContext.getInstance("TLS");
			
			
			InputStream is = Files.newInputStream(Paths.get(trustStoreLocation));
			trustStore = KeyStore.getInstance(trustStoreType);
			trustStore.load(is, trustStorePassword.toCharArray());
			
			TrustManagerFactory tmf = TrustManagerFactory.getInstance("PKIX");
			tmf.init(trustStore);
			
			context.init(kmf.getKeyManagers(), tmf.getTrustManagers(), new SecureRandom());
                            SSLContext.setDefault(context);
		} catch(Exception ex) {
			ex.printStackTrace();
		}
	} catch (Exception e) {
		// TODO Auto-generated catch block
		e.printStackTrace();
	}
	return context;
}

}

[scottslewis]

Hi @JavaJoeS

A couple of quick comments:

1. In your code, you pass tmf.getTrustManager() to the context.init(...) method call. Currently, the SSLContextHelper passes in an ECFTrustManager to the init call...I didn't write the ECFTrustManager code myself, and it has special code for X509 support...which may be needed. In any event, we don't want to break that ECFTrustManager support without at least verifying with the community that it's not needed by community/consumers.

2. I would suggest restructuring the try/catch blocks in your code to so that they are not nested...as basically neither actually does anything.

3. You have lookups with 'TLS', 'PKIX', 'SunX509' as constants. Is this going properly handle all users of Eclipse under all conditions? i.e. will it be at least necessary for these to be parameterized?

1 is probably more important than 2 or 3...as it was originally the IBM committers that put in the ECFTrustManager/X509 stuff.

Scott

[JavaJoeS]

@scottslewis I took a look at the ECFTrustManager. It is part of the plugin startup for the bundle. I think It is OK as is for
the purposes intended. My code is to support org.eclipse.core.pki implementation. Several exit points in there
in case a user did not set up their PKI correctly. It would be considered an unsuccessful PKI installation, no harm no foul and
code continues without a successful pki set up. In the case of the TrustManager setup then that is on the user to correctly
have the implementation setup correct. Both code sets work as intended, as needed, each does nothing until properly setup.
I am testing a live environment using org.eclipse.core.pki with a "testing" modified version of UrlConnectionRetrieveFileTransfer when used to install software from a site that requires PKI. My testing has been successful thus far. However, I was hoping for a solution that could also work for the P2 bundles/packages.
I modified the try catch blocks to log any meaningful pki scenarios. Any null output is not logged since we need to make sure PKI is NOT a requirement, but only an option.

...
} catch (Exception ex) {
// ex.printStackTrace();
final CertificateException ce = new CertificateException("Certificate setup is not valid"); //$NON-NLS-1$
ce.initCause(ex);
throw ce;
}
} catch (Exception e) {
// TODO Auto-generated catch block
// e.ECFSSLContext..printStackTrace();
final CertificateException ce = new CertificateException("PKI Properties setup is not valid"); //$NON-NLS-1$
ce.initCause(e);
throw ce;
}