Re: [net] FTPS client auth required
Niklas Gustavsson wrote:
Rory Winston wrote:
Hi Niklas
Done. Thanks
Thanks! The build seems broken at the moment as
org.apache.commons.net.PrintCommandListener is missing. COuld you fix
this or do you produce binaries somewhere?
The attached patch fixes the broken build (still can't get tests to run
but I could build myself a binary :-).
For some reason the PrintCommandListener was deleted in rev 437767 so it
you don't want it in the code, please ignore this patch :-)
/niklas
Index: src/main/java/examples/nntp/ExtendedNNTPOps.java
===
--- src/main/java/examples/nntp/ExtendedNNTPOps.java(revision 480955)
+++ src/main/java/examples/nntp/ExtendedNNTPOps.java(working copy)
@@ -18,12 +18,13 @@
import java.io.IOException;
import java.io.PrintWriter;
-import org.apache.commons.net.PrintCommandListener;
import org.apache.commons.net.nntp.Article;
import org.apache.commons.net.nntp.NNTPClient;
import org.apache.commons.net.nntp.NewsgroupInfo;
+import examples.PrintCommandListener;
+
/**
* Simple class showing some of the extended commands (AUTH, XOVER, LIST
ACTIVE)
*
Index: src/main/java/examples/nntp/post.java
===
--- src/main/java/examples/nntp/post.java (revision 480955)
+++ src/main/java/examples/nntp/post.java (working copy)
@@ -23,13 +23,14 @@
import java.io.PrintWriter;
import java.io.Writer;
-import org.apache.commons.net.PrintCommandListener;
import org.apache.commons.net.io.Util;
import org.apache.commons.net.nntp.NNTPClient;
import org.apache.commons.net.nntp.NNTPReply;
import org.apache.commons.net.nntp.SimpleNNTPHeader;
+import examples.PrintCommandListener;
+
/***
* This is an example program using the NNTP package to post an article
* to the specified newsgroup(s). It prompts you for header information and
Index: src/main/java/examples/nntp/MessageThreading.java
===
--- src/main/java/examples/nntp/MessageThreading.java (revision 480955)
+++ src/main/java/examples/nntp/MessageThreading.java (working copy)
@@ -20,13 +20,14 @@
import java.io.PrintWriter;
import java.net.SocketException;
-import org.apache.commons.net.PrintCommandListener;
import org.apache.commons.net.nntp.Article;
import org.apache.commons.net.nntp.NNTPClient;
import org.apache.commons.net.nntp.NewsgroupInfo;
import org.apache.commons.net.nntp.Threader;
+import examples.PrintCommandListener;
+
public class MessageThreading {
public MessageThreading() {
}
Index: src/main/java/examples/PrintCommandListener.java
===
--- src/main/java/examples/PrintCommandListener.java(revision 0)
+++ src/main/java/examples/PrintCommandListener.java(revision 0)
@@ -0,0 +1,49 @@
+/*
+ * Copyright 2001-2006 The Apache Software Foundation
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package examples;
+
+import java.io.PrintWriter;
+import org.apache.commons.net.ProtocolCommandEvent;
+import org.apache.commons.net.ProtocolCommandListener;
+
+/***
+ * This is a support class for some of the example programs. It is
+ * a sample implementation of the ProtocolCommandListener interface
+ * which just prints out to a specified stream all command/reply traffic.
+ * p
+ ***/
+
+public class PrintCommandListener implements ProtocolCommandListener
+{
+private PrintWriter __writer;
+
+public PrintCommandListener(PrintWriter writer)
+{
+__writer = writer;
+}
+
+public void protocolCommandSent(ProtocolCommandEvent event)
+{
+__writer.print(event.getMessage());
+__writer.flush();
+}
+
+public void protocolReplyReceived(ProtocolCommandEvent event)
+{
+__writer.print(event.getMessage());
+__writer.flush();
+}
+}
\ No newline at end of file
Property changes on: src\main\java\examples\PrintCommandListener.java
___
Name: svn:eol-style
+ native
Index: src/main/java/examples/FTPExample.java
===
--- src/main/java/examples/FTPExample.java (revision 480955)
+++ src/main/java/examples/FTPExample.java (working copy)
@@ -22,7 +22,6 @@
import java.io.OutputStream;
import
Re: Re: [net] FTPS client auth required
Oops! Looks like you are correct, indeed. It didnt get removed from my local working copy, which explains why my builds still work. I suspect I may have made an errant click in the SVN commit dialog. Thanks for the spot - I'll put it back in. Rory - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [net] FTPS client auth required
Oops! Looks like you are correct, indeed. It didnt get removed from my local working copy, which explains why my builds still work. I suspect I may have made an errant click in the SVN commit dialog. Thanks for the spot - I'll put it back in. Rory - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTPS client auth required
Thanks, making that settable makes a lot of sense. Would you mind doing
the same thing for the KeyManager as that would make client auth
possible? At least I'm not able to get it working without one :-)
I'm attaching the patch I use for the client auth tests in FtpServer.
/niklas
Rory Winston wrote:
Niklas
The current FTPSTrustManager implementation is a little bit sketchy -
maybe we could default to a more comprehensive validity check. I have
added the facility to plug in a custom trust manager to the FTPSClient,
as follows:
FTPSClient client = new FTPSClient();
client.setTrustManager(new X509TrustManager() {
public void checkClientTrusted(X509Certificate[] chain,
String authType) throws CertificateException {
...
}
public void checkServerTrusted(X509Certificate[] chain,
String authType) throws CertificateException {
...
}
public X509Certificate[] getAcceptedIssuers() {
...
}
});
Thanks for the patch, by the way.
Cheers
Rory
Niklas Gustavsson wrote:
Hi
I'm trying to create tests for client authentication for Apache
FtpServer. For this I'm using commons-net as the client but is running
into problems with the client auth support in FTPSClient. I'm setting
setNeedClientAuth(true) but still get problems due to FTPSClient
sending a null certificate chain. How should I set up my keystore so
that FTPSClient finds it and can use it to send the correct
certificate to the server for authentication? I've tried with the
javax.net.ssl.keyStore system property but to no avail.
Also, if I understand the current implementation of FTPSClient and
FTPSTrustManager. From what I can understand, the implementation only
checks if the service certificate is valid, not if it's trusted. Is
this correct? If so, this would probably be a security issue in that a
fake server serving up any valid certificate would be trusted by the
client. Is this the intended behavior?
/niklas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index: src/main/java/org/apache/commons/net/ftp/FTPSClient.java
===
--- src/main/java/org/apache/commons/net/ftp/FTPSClient.java(revision
479111)
+++ src/main/java/org/apache/commons/net/ftp/FTPSClient.java(working copy)
@@ -23,6 +23,7 @@
import java.security.KeyManagementException;
import java.security.NoSuchAlgorithmException;
+import javax.net.ssl.KeyManager;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLException;
import javax.net.ssl.SSLServerSocketFactory;
@@ -80,6 +81,9 @@
/** The FTPS [EMAIL PROTECTED] TrustManager} implementation. */
private TrustManager trustManager = new FTPSTrustManager();
+/** The [EMAIL PROTECTED] KeyManager} */
+private KeyManager keyManager;
+
/**
* Constructor for FTPSClient.
* @throws NoSuchAlgorithmException A requested cryptographic algorithm
@@ -194,10 +198,10 @@
planeSocket = _socket_;
try {
- context.init(null, new TrustManager[] {
getTrustManager() } , null);
- } catch (KeyManagementException e) {
- e.printStackTrace();
- }
+context.init(new KeyManager[] {keyManager}, new TrustManager[] {
getTrustManager() } , null);
+} catch (KeyManagementException e) {
+e.printStackTrace();
+}
SSLSocketFactory ssf = context.getSocketFactory();
String ip = _socket_.getInetAddress().getHostAddress();
@@ -479,6 +483,22 @@
this.trustManager = trustManager;
}
+/**
+ * Get the currently configured [EMAIL PROTECTED] KeyManager}.
+ *
+ * @return the keyManager
+ */
+public KeyManager getKeyManager() {
+return keyManager;
+}
+
+/**
+ * Set a [EMAIL PROTECTED] KeyManager} to use
+ *
+ * @param keyManager The KeyManager implementation to set.
+ */
+public void setKeyManager(KeyManager keyManager) {
+this.keyManager = keyManager;
+}
-
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTPS client auth required
Hi Niklas
Done. Thanks
Rory
Niklas Gustavsson wrote:
Thanks, making that settable makes a lot of sense. Would you mind
doing the same thing for the KeyManager as that would make client auth
possible? At least I'm not able to get it working without one :-)
I'm attaching the patch I use for the client auth tests in FtpServer.
/niklas
Rory Winston wrote:
Niklas
The current FTPSTrustManager implementation is a little bit sketchy -
maybe we could default to a more comprehensive validity check. I have
added the facility to plug in a custom trust manager to the
FTPSClient, as follows:
FTPSClient client = new FTPSClient();
client.setTrustManager(new X509TrustManager() {
public void checkClientTrusted(X509Certificate[]
chain, String authType) throws CertificateException {
...
}
public void checkServerTrusted(X509Certificate[]
chain, String authType) throws CertificateException {
...
}
public X509Certificate[] getAcceptedIssuers() {
...
}
});
Thanks for the patch, by the way.
Cheers
Rory
Niklas Gustavsson wrote:
Hi
I'm trying to create tests for client authentication for Apache
FtpServer. For this I'm using commons-net as the client but is
running into problems with the client auth support in FTPSClient.
I'm setting setNeedClientAuth(true) but still get problems due to
FTPSClient sending a null certificate chain. How should I set up my
keystore so that FTPSClient finds it and can use it to send the
correct certificate to the server for authentication? I've tried
with the javax.net.ssl.keyStore system property but to no avail.
Also, if I understand the current implementation of FTPSClient and
FTPSTrustManager. From what I can understand, the implementation
only checks if the service certificate is valid, not if it's
trusted. Is this correct? If so, this would probably be a security
issue in that a fake server serving up any valid certificate would
be trusted by the client. Is this the intended behavior?
/niklas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index: src/main/java/org/apache/commons/net/ftp/FTPSClient.java
===
--- src/main/java/org/apache/commons/net/ftp/FTPSClient.java(revision
479111)
+++ src/main/java/org/apache/commons/net/ftp/FTPSClient.java(working copy)
@@ -23,6 +23,7 @@
import java.security.KeyManagementException;
import java.security.NoSuchAlgorithmException;
+import javax.net.ssl.KeyManager;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLException;
import javax.net.ssl.SSLServerSocketFactory;
@@ -80,6 +81,9 @@
/** The FTPS [EMAIL PROTECTED] TrustManager} implementation. */
private TrustManager trustManager = new FTPSTrustManager();
+/** The [EMAIL PROTECTED] KeyManager} */
+private KeyManager keyManager;
+
/**
* Constructor for FTPSClient.
* @throws NoSuchAlgorithmException A requested cryptographic algorithm
@@ -194,10 +198,10 @@
planeSocket = _socket_;
try {
- context.init(null, new TrustManager[] {
getTrustManager() } , null);
- } catch (KeyManagementException e) {
- e.printStackTrace();
- }
+context.init(new KeyManager[] {keyManager}, new TrustManager[] {
getTrustManager() } , null);
+} catch (KeyManagementException e) {
+e.printStackTrace();
+}
SSLSocketFactory ssf = context.getSocketFactory();
String ip = _socket_.getInetAddress().getHostAddress();
@@ -479,6 +483,22 @@
this.trustManager = trustManager;
}
+/**
+ * Get the currently configured [EMAIL PROTECTED] KeyManager}.
+ *
+ * @return the keyManager
+ */
+public KeyManager getKeyManager() {
+return keyManager;
+}
+
+/**
+ * Set a [EMAIL PROTECTED] KeyManager} to use
+ *
+ * @param keyManager The KeyManager implementation to set.
+ */
+public void setKeyManager(KeyManager keyManager) {
+this.keyManager = keyManager;
+}
-
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTPS client auth required
Rory Winston wrote: Hi Niklas Done. Thanks Thanks! The build seems broken at the moment as org.apache.commons.net.PrintCommandListener is missing. COuld you fix this or do you produce binaries somewhere? /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTPS client auth required
Niklas
The current FTPSTrustManager implementation is a little bit sketchy -
maybe we could default to a more comprehensive validity check. I have
added the facility to plug in a custom trust manager to the FTPSClient,
as follows:
FTPSClient client = new FTPSClient();
client.setTrustManager(new X509TrustManager() {
public void checkClientTrusted(X509Certificate[] chain,
String authType) throws CertificateException {
...
}
public void checkServerTrusted(X509Certificate[] chain,
String authType) throws CertificateException {
...
}
public X509Certificate[] getAcceptedIssuers() {
...
}
});
Thanks for the patch, by the way.
Cheers
Rory
Niklas Gustavsson wrote:
Hi
I'm trying to create tests for client authentication for Apache
FtpServer. For this I'm using commons-net as the client but is running
into problems with the client auth support in FTPSClient. I'm setting
setNeedClientAuth(true) but still get problems due to FTPSClient
sending a null certificate chain. How should I set up my keystore so
that FTPSClient finds it and can use it to send the correct
certificate to the server for authentication? I've tried with the
javax.net.ssl.keyStore system property but to no avail.
Also, if I understand the current implementation of FTPSClient and
FTPSTrustManager. From what I can understand, the implementation only
checks if the service certificate is valid, not if it's trusted. Is
this correct? If so, this would probably be a security issue in that a
fake server serving up any valid certificate would be trusted by the
client. Is this the intended behavior?
/niklas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[net] FTPS client auth required
Hi I'm trying to create tests for client authentication for Apache FtpServer. For this I'm using commons-net as the client but is running into problems with the client auth support in FTPSClient. I'm setting setNeedClientAuth(true) but still get problems due to FTPSClient sending a null certificate chain. How should I set up my keystore so that FTPSClient finds it and can use it to send the correct certificate to the server for authentication? I've tried with the javax.net.ssl.keyStore system property but to no avail. Also, if I understand the current implementation of FTPSClient and FTPSTrustManager. From what I can understand, the implementation only checks if the service certificate is valid, not if it's trusted. Is this correct? If so, this would probably be a security issue in that a fake server serving up any valid certificate would be trusted by the client. Is this the intended behavior? /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
What JDK are you using?
M wrote:
Hi.
Oddly enough, I took out the code where you pass the login and password, in
my FTPSClient (i.e. //client.login(test,test);) and got connected.
However, whenever I did a command listing, it will just hang like before.
so anything to do like
//client.cwd(temp);
//client.list();
will hang..
btw. I took the latest FTPSClient code from Apache too.
M wrote:
Hi.
Yes I did generate the certificate and tested using filezilla client. It
worked from filezilla client though.
I updated apache's secure code..
meaning commented:
//this.sendCommand(PBSZ, pbsz);
//this.sendCommand(PROT, prot);
It got connected but not the login now..
220-FileZilla Server version 0.9.18 beta
220-written by Tim Kosse ([EMAIL PROTECTED])
220 Please visit http://sourceforge.net/projects/filezilla/
AUTH SSL
234 Using authentication type SSL
**1
**2
**3
**4
**5
*** Connected
Is Connected:true
USER test
Exception in thread main
org.apache.commons.net.ftp.FTPConnectionClosedException: Connection closed
without indication.
at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:267)
at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:460)
at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:520)
at org.apache.commons.net.ftp.FTP.user(FTP.java:670)
at org.apache.commons.net.ftp.FTPClient.login(FTPClient.java:637)
at TestFTPS.main(TestFTPS.java:31)
FTPSClient client = new FTPSClient(JKS,SSL,password,0,P);
//FTPSClient client = new FTPSClient();
//client.setReaderThread(false);
client.addProtocolCommandListener(new PrintCommandListener(new
PrintWriter(System.out)));
client.connect(127.0.0.1);
System.out.println(*** Connected );
System.out.println(Is Connected: + client.isConnected());
client.login(test, test);
System.out.println(Is Connected: + client.isConnected());
System.out.println(*** Passed Login );
Appreciate any advise.
regards,
Rory Winston wrote:
I've tried this with Filezilla server, and it worked fine for me. Some
initial issues I had:
1. Home dirs not being set up correctly (Filezilla will complain about
this)
2. Have you generated the server certificate yourself?
M wrote:
Hi.
Thanks for your reply. I did try that but still dont see anything more
that
would be helpful. I see an entry in the filezilla server but says not
logged in.
FTPSClient client = new FTPSClient();
//client.setReaderThread(false);
client.addProtocolCommandListener(new PrintCommandListener(new
PrintWriter(System.out)));
client.connect(127.0.0.1, 990);
regards,
Rory Winston wrote:
Can you attach a PrintCommandListener to the client, so you can see the
commands being passed over the wire?
FTPSClient client = new FTPSClient( ... );
client.addProtocolCommandListener(new PrintCommandListener(new
PrintWriter(System.out)));
Then you can see what is actually happening.
Cheers
Rory
M wrote:
Hi Rory.
I tried the apache Jakarta FTPSClient to connect to filezilla ftps
listening
on port 990.
When I use ftps.connect(localhost, 990); it does not get connected.
FTPSClient client = new FTPSClient(JKS,SSL,password,0,P);
System.out.println(*);
client.connect(127.0.0.1,990);
System.out.println(*);
client.getStatus();
System.out.println(*);
Appreciate any tips. Thanks.
Here's the code I downloaded from Apache Jakarta:
/*
* Copyright 2001-2005 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.net.InetAddress;
import java.net.Socket;
import java.net.SocketException;
import java.security.KeyStore;
import javax.net.ssl.KeyManagerFactory;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSocket;
import javax.net.ssl.TrustManager;
import org.apache.commons.net.SocketFactory;
import org.apache.commons.net.ftp.FTPClient;
/**
*
* This class extends [EMAIL PROTECTED] org.apache.commons.net.ftp.FTPClient} to
add
* the necessary methods that implement SSL/TLS-FTPS.
*
*/
public class FTPSClient extends FTPClient {
// Represent the method to the FTP command AUTH...
private String
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
/KeyManagerFactory.html) com.sun.net.ssl.SSLContext (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/SSLContext.html) com.sun.net.ssl.TrustManager (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/TrustManager.html) This classes in JSSE are only in the package com.sun.net.ssl, and although in JSSE 1.0.3 there are a packege javax.net.ssl, it doesn't contain this classes, it contains javax.net.ssl.SSLSocket, a classes soon used, to implement FTPS. And the commons-net team would prefer to go that way because Sun says that com.sun.net may go away with some future release, but not javax.net. Yes, this would be a small inconvenience for java 1.3 users, but the stability is worth it. This three classes in JDK 1.4.2, were move to javax.net.ssl.KeyManagerFactory (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/KeyManagerFactory.html) javax.net.ssl.SSLContext (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLContext.html) javax.net.ssl.TrustManager (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/TrustManager.html) But if you download for example JDK 1.4.2 and look inside of (jre/lib) you'll find jsse.jar, the jar where still are com.sun.net.ssl. Sun, still mantain compatiblity with JDK 1.3. And still in JDK 1.5, you'll find jre/lib/jsse.jar. But when jsse.jar desapear, i offer to modified code... In other way if use javax.net.ssl.KeyManagerFactory , javax.net.ssl.SSLContext, javax.net.ssl.TrustManager, ftps don't work under JDK 1.3. I hope explain better, this time. Then, make that you consider appropiate... Thanks all, for your time. -- The whole purpose of places like Starbucks is for people with no decision-making ability whatsoever to make six decisions just to buy one cup of coffee. Short, tall, light, dark, caf, decaf, low-fat, non-fat, etc. So people who don't know what the hell they're doing or who on earth they are can, for only $2.95, get not just a cup of coffee but an absolutely defining sense of self: Tall. Decaf. Cappuccino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-net--JSSE-classes-in-FTPS-WAS-Re%3A--net--FTPS-submission---legal-issues-tf1019716.html#a6328324 Sent from the Commons - Dev forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Hmmm, Well if there is a problem somewhere, its got to be recorded *somehow*. There are three places it could be: 1. The FileZilla interface 2. The FileZilla logs 3. The output from the FTP Client (i.e. any JSSE exceptions thrown) So there is nothing in any of these that gives you any clues? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
it. Since these are new classes for us, I think it makes little sense to tie into backward compatibility from the start, when that backward compatibility is already out of date. I don't think there is a clean way to have one code base that will work the way we'd like it for both cases. Therefore, I think the solution for this is for Jakarta Commons Net to take Rory Winston's suggestion and start a new branch of Commons Net for JDK 1.4 only (for this and other reasons) and maintain two branches for awhile, the current HEAD branch for 1.3 compatibility and the new branch for 1.4. The new branch can use the javax.ssl.net classes, the old one can use com.sun.net. Jose Juan Montiel wrote: Hi Steve, What I think you're missing is that if you put jsse.jar on your classpath, you can use javax.net.ssl with java 1.3. maybe i don't explain well, sorry. The three classes of com.sun.net.ssl that are used for implement FTPS (in the way that Paul did and I modified, maybe there is another...) are... com.sun.net.ssl.KeyManagerFactory (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/KeyManagerFactory.html) com.sun.net.ssl.SSLContext (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/SSLContext.html) com.sun.net.ssl.TrustManager (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/TrustManager.html) This classes in JSSE are only in the package com.sun.net.ssl, and although in JSSE 1.0.3 there are a packege javax.net.ssl, it doesn't contain this classes, it contains javax.net.ssl.SSLSocket, a classes soon used, to implement FTPS. And the commons-net team would prefer to go that way because Sun says that com.sun.net may go away with some future release, but not javax.net. Yes, this would be a small inconvenience for java 1.3 users, but the stability is worth it. This three classes in JDK 1.4.2, were move to javax.net.ssl.KeyManagerFactory (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/KeyManagerFactory.html) javax.net.ssl.SSLContext (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLContext.html) javax.net.ssl.TrustManager (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/TrustManager.html) But if you download for example JDK 1.4.2 and look inside of (jre/lib) you'll find jsse.jar, the jar where still are com.sun.net.ssl. Sun, still mantain compatiblity with JDK 1.3. And still in JDK 1.5, you'll find jre/lib/jsse.jar. But when jsse.jar desapear, i offer to modified code... In other way if use javax.net.ssl.KeyManagerFactory , javax.net.ssl.SSLContext, javax.net.ssl.TrustManager, ftps don't work under JDK 1.3. I hope explain better, this time. Then, make that you consider appropiate... Thanks all, for your time. -- The whole purpose of places like Starbucks is for people with no decision-making ability whatsoever to make six decisions just to buy one cup of coffee. Short, tall, light, dark, caf, decaf, low-fat, non-fat, etc. So people who don't know what the hell they're doing or who on earth they are can, for only $2.95, get not just a cup of coffee but an absolutely defining sense of self: Tall. Decaf. Cappuccino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-net--JSSE-classes-in-FTPS-WAS-Re%3A--net--FTPS-submission---legal-issues-tf1019716.html#a6313989 Sent from the Commons - Dev forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Can you attach a PrintCommandListener to the client, so you can see the
commands being passed over the wire?
FTPSClient client = new FTPSClient( ... );
client.addProtocolCommandListener(new PrintCommandListener(new
PrintWriter(System.out)));
Then you can see what is actually happening.
Cheers
Rory
M wrote:
Hi Rory.
I tried the apache Jakarta FTPSClient to connect to filezilla ftps listening
on port 990.
When I use ftps.connect(localhost, 990); it does not get connected.
FTPSClient client = new FTPSClient(JKS,SSL,password,0,P);
System.out.println(*);
client.connect(127.0.0.1,990);
System.out.println(*);
client.getStatus();
System.out.println(*);
Appreciate any tips. Thanks.
Here's the code I downloaded from Apache Jakarta:
/*
* Copyright 2001-2005 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.net.InetAddress;
import java.net.Socket;
import java.net.SocketException;
import java.security.KeyStore;
import javax.net.ssl.KeyManagerFactory;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSocket;
import javax.net.ssl.TrustManager;
import org.apache.commons.net.SocketFactory;
import org.apache.commons.net.ftp.FTPClient;
/**
*
* This class extends [EMAIL PROTECTED] org.apache.commons.net.ftp.FTPClient} to add
* the necessary methods that implement SSL/TLS-FTPS.
*
*/
public class FTPSClient extends FTPClient {
// Represent the method to the FTP command AUTH...
private String sslContext;
// Secure context (can be TLS or SSL)
private SSLContext context;
private String pbsz;
private String prot;
private BufferedReader _controlInput_;
private BufferedWriter _controlOutput_;
/**
* Default constructor that selects some default options (TLS
encryption)
*
*/
public FTPSClient() {
this(JCEKS, TLS, password, 0, P);
}
/**
*
* Constructor that initializes the secure connection.
*
* @param keyStoreName Type of instance KeyStore, JKS for Java 1.3 y JCEKS
for Java 1.4
* @param sslContext Type of the instance SSLContext, can be SSL or TLS.
* @param password The password to access the KeyStore.
* @param pbsz Protection buffer size (Use 0 to indicate streaming)
* @param prot The protection level for the data channel
*/
public FTPSClient(String keyStoreName, String sslContext, String
password,
String pbsz, String prot) {
this.sslContext = sslContext;
this.pbsz = pbsz;
this.prot = prot;
try {
KeyStore keyStore = KeyStore.getInstance(keyStoreName);
keyStore.load(null, password.toCharArray());
KeyManagerFactory keyManagerFactory =
KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
keyManagerFactory.init(keyStore,
password.toCharArray());
this.context = SSLContext.getInstance(sslContext);
this.context.init(
keyManagerFactory.getKeyManagers(),
new TrustManager[] { (TrustManager) new FTPSTrustManager() }, null
);
} catch (Exception e) {
e.printStackTrace();
}
}
/**
* @see
org.apache.commons.net.SocketClient#connect(java.net.InetAddress,
int, java.net.InetAddress, int)
*/
public void connect(InetAddress address, int port, InetAddress
localAddress, int localPort) throws SocketException, IOException
{
System.out.println(* In 1 );
super.connect(address, port, localAddress, localPort);
this.secure(this.pbsz,this.prot);
}
/**
* @see
org.apache.commons.net.SocketClient#connect(java.net.InetAddress,
int)
*/
public void connect(InetAddress address, int port) throws
SocketException,
IOException
{
System.out.println(* In 2 );
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
I've tried this with Filezilla server, and it worked fine for me. Some
initial issues I had:
1. Home dirs not being set up correctly (Filezilla will complain about this)
2. Have you generated the server certificate yourself?
M wrote:
Hi.
Thanks for your reply. I did try that but still dont see anything more that
would be helpful. I see an entry in the filezilla server but says not
logged in.
FTPSClient client = new FTPSClient();
//client.setReaderThread(false);
client.addProtocolCommandListener(new PrintCommandListener(new
PrintWriter(System.out)));
client.connect(127.0.0.1, 990);
regards,
Rory Winston wrote:
Can you attach a PrintCommandListener to the client, so you can see the
commands being passed over the wire?
FTPSClient client = new FTPSClient( ... );
client.addProtocolCommandListener(new PrintCommandListener(new
PrintWriter(System.out)));
Then you can see what is actually happening.
Cheers
Rory
M wrote:
Hi Rory.
I tried the apache Jakarta FTPSClient to connect to filezilla ftps
listening
on port 990.
When I use ftps.connect(localhost, 990); it does not get connected.
FTPSClient client = new FTPSClient(JKS,SSL,password,0,P);
System.out.println(*);
client.connect(127.0.0.1,990);
System.out.println(*);
client.getStatus();
System.out.println(*);
Appreciate any tips. Thanks.
Here's the code I downloaded from Apache Jakarta:
/*
* Copyright 2001-2005 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.net.InetAddress;
import java.net.Socket;
import java.net.SocketException;
import java.security.KeyStore;
import javax.net.ssl.KeyManagerFactory;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSocket;
import javax.net.ssl.TrustManager;
import org.apache.commons.net.SocketFactory;
import org.apache.commons.net.ftp.FTPClient;
/**
*
* This class extends [EMAIL PROTECTED] org.apache.commons.net.ftp.FTPClient} to add
* the necessary methods that implement SSL/TLS-FTPS.
*
*/
public class FTPSClient extends FTPClient {
// Represent the method to the FTP command AUTH...
private String sslContext;
// Secure context (can be TLS or SSL)
private SSLContext context;
private String pbsz;
private String prot;
private BufferedReader _controlInput_;
private BufferedWriter _controlOutput_;
/**
* Default constructor that selects some default options (TLS
encryption)
*
*/
public FTPSClient() {
this(JCEKS, TLS, password, 0, P);
}
/**
*
* Constructor that initializes the secure connection.
*
* @param keyStoreName Type of instance KeyStore, JKS for Java 1.3 y
JCEKS
for Java 1.4
* @param sslContext Type of the instance SSLContext, can be SSL or TLS.
* @param password The password to access the KeyStore.
* @param pbsz Protection buffer size (Use 0 to indicate streaming)
* @param prot The protection level for the data channel
*/
public FTPSClient(String keyStoreName, String sslContext, String
password,
String pbsz, String prot) {
this.sslContext = sslContext;
this.pbsz = pbsz;
this.prot = prot;
try {
KeyStore keyStore = KeyStore.getInstance(keyStoreName);
keyStore.load(null, password.toCharArray());
KeyManagerFactory keyManagerFactory =
KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
keyManagerFactory.init(keyStore,
password.toCharArray());
this.context = SSLContext.getInstance(sslContext);
this.context.init(
keyManagerFactory.getKeyManagers(),
new TrustManager[] { (TrustManager) new FTPSTrustManager() }, null
);
} catch (Exception e) {
e.printStackTrace();
}
}
/**
* @see
org.apache.commons.net.SocketClient#connect(java.net.InetAddress,
int, java.net.InetAddress, int)
*/
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
... In other way if use javax.net.ssl.KeyManagerFactory , javax.net.ssl.SSLContext, javax.net.ssl.TrustManager, ftps don't work under JDK 1.3. I hope explain better, this time. Then, make that you consider appropiate... Thanks all, for your time. -- The whole purpose of places like Starbucks is for people with no decision-making ability whatsoever to make six decisions just to buy one cup of coffee. Short, tall, light, dark, caf, decaf, low-fat, non-fat, etc. So people who don't know what the hell they're doing or who on earth they are can, for only $2.95, get not just a cup of coffee but an absolutely defining sense of self: Tall. Decaf. Cappuccino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-net--JSSE-classes-in-FTPS-WAS-Re%3A--net--FTPS-submission---legal-issues-tf1019716.html#a6316503 Sent from the Commons - Dev forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
at the code instead of making assumptions, which is what I have been doing. The JSSE's jar does not provide javax.net.ssl versions of the com.sun.net.ssl interfaces And, after doing a little research, I find that there are differences between JSSE 1.0.3 and the packages in JDK 1.4, such that there is no backward compatibility. Basically, JSSE 1.0.x is a prototype, a hack through which Sun worked out the bugs, culminating in the better implementation that they released in 1.4. They did not just move the JSSE.jar code into JDK 1.4. They also improved it. Since these are new classes for us, I think it makes little sense to tie into backward compatibility from the start, when that backward compatibility is already out of date. I don't think there is a clean way to have one code base that will work the way we'd like it for both cases. Therefore, I think the solution for this is for Jakarta Commons Net to take Rory Winston's suggestion and start a new branch of Commons Net for JDK 1.4 only (for this and other reasons) and maintain two branches for awhile, the current HEAD branch for 1.3 compatibility and the new branch for 1.4. The new branch can use the javax.ssl.net classes, the old one can use com.sun.net. Jose Juan Montiel wrote: Hi Steve, What I think you're missing is that if you put jsse.jar on your classpath, you can use javax.net.ssl with java 1.3. maybe i don't explain well, sorry. The three classes of com.sun.net.ssl that are used for implement FTPS (in the way that Paul did and I modified, maybe there is another...) are... com.sun.net.ssl.KeyManagerFactory (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/KeyManagerFactory.html) com.sun.net.ssl.SSLContext (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/SSLContext.html) com.sun.net.ssl.TrustManager (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/TrustManager.html) This classes in JSSE are only in the package com.sun.net.ssl, and although in JSSE 1.0.3 there are a packege javax.net.ssl, it doesn't contain this classes, it contains javax.net.ssl.SSLSocket, a classes soon used, to implement FTPS. And the commons-net team would prefer to go that way because Sun says that com.sun.net may go away with some future release, but not javax.net. Yes, this would be a small inconvenience for java 1.3 users, but the stability is worth it. This three classes in JDK 1.4.2, were move to javax.net.ssl.KeyManagerFactory (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/KeyManagerFactory.html) javax.net.ssl.SSLContext (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLContext.html) javax.net.ssl.TrustManager (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/TrustManager.html) But if you download for example JDK 1.4.2 and look inside of (jre/lib) you'll find jsse.jar, the jar where still are com.sun.net.ssl. Sun, still mantain compatiblity with JDK 1.3. And still in JDK 1.5, you'll find jre/lib/jsse.jar. But when jsse.jar desapear, i offer to modified code... In other way if use javax.net.ssl.KeyManagerFactory , javax.net.ssl.SSLContext, javax.net.ssl.TrustManager, ftps don't work under JDK 1.3. I hope explain better, this time. Then, make that you consider appropiate... Thanks all, for your time. -- The whole purpose of places like Starbucks is for people with no decision-making ability whatsoever to make six decisions just to buy one cup of coffee. Short, tall, light, dark, caf, decaf, low-fat, non-fat, etc. So people who don't know what the hell they're doing or who on earth they are can, for only $2.95, get not just a cup of coffee but an absolutely defining sense of self: Tall. Decaf. Cappuccino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-net--JSSE-classes-in-FTPS-WAS-Re%3A--net--FTPS-submission---legal-issues-tf1019716.html#a6315924 Sent from the Commons - Dev forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
1.4.2 and look inside of (jre/lib) you'll find jsse.jar, the jar where still are com.sun.net.ssl. Sun, still mantain compatiblity with JDK 1.3. And still in JDK 1.5, you'll find jre/lib/jsse.jar. But when jsse.jar desapear, i offer to modified code... In other way if use javax.net.ssl.KeyManagerFactory , javax.net.ssl.SSLContext, javax.net.ssl.TrustManager, ftps don't work under JDK 1.3. I hope explain better, this time. Then, make that you consider appropiate... Thanks all, for your time. -- The whole purpose of places like Starbucks is for people with no decision-making ability whatsoever to make six decisions just to buy one cup of coffee. Short, tall, light, dark, caf, decaf, low-fat, non-fat, etc. So people who don't know what the hell they're doing or who on earth they are can, for only $2.95, get not just a cup of coffee but an absolutely defining sense of self: Tall. Decaf. Cappuccino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-net--JSSE-classes-in-FTPS-WAS-Re%3A--net--FTPS-submission---legal-issues-tf1019716.html#a6317306 Sent from the Commons - Dev forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] FTPS...
Hi... ...Steve Cohen, Rory Winston, and all the people that contribute to Jakarta Commons. I just known, that all are very busy with JIRA migration, and many proyects: personal, from work and other jakarta proyect. My question is, when jakarta commons net 1.5 or 2.0... with FTPS in his distint aproximation (incluiding Satoshi Ishigami patch), will be release... Again, i offer my help if yours need, for this proyect, or other. Thanks to all. -- The whole purpose of places like Starbucks is for people with no decision-making ability whatsoever to make six decisions just to buy one cup of coffee. Short, tall, light, dark, caf, decaf, low-fat, non-fat, etc. So people who don't know what the hell they're doing or who on earth they are can, for only $2.95, get not just a cup of coffee but an absolutely defining sense of self: Tall. Decaf. Cappuccino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Hi Steve, What I think you're missing is that if you put jsse.jar on your classpath, you can use javax.net.ssl with java 1.3. maybe i don't explain well, sorry. The three classes of com.sun.net.ssl that are used for implement FTPS (in the way that Paul did and I modified, maybe there is another...) are... com.sun.net.ssl.KeyManagerFactory (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/KeyManagerFactory.html) com.sun.net.ssl.SSLContext (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/SSLContext.html) com.sun.net.ssl.TrustManager (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/TrustManager.html) This classes in JSSE are only in the package com.sun.net.ssl, and although in JSSE 1.0.3 there are a packege javax.net.ssl, it doesn't contain this classes, it contains javax.net.ssl.SSLSocket, a classes soon used, to implement FTPS. And the commons-net team would prefer to go that way because Sun says that com.sun.net may go away with some future release, but not javax.net. Yes, this would be a small inconvenience for java 1.3 users, but the stability is worth it. This three classes in JDK 1.4.2, were move to javax.net.ssl.KeyManagerFactory (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/KeyManagerFactory.html) javax.net.ssl.SSLContext (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLContext.html) javax.net.ssl.TrustManager (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/TrustManager.html) But if you download for example JDK 1.4.2 and look inside of (jre/lib) you'll find jsse.jar, the jar where still are com.sun.net.ssl. Sun, still mantain compatiblity with JDK 1.3. And still in JDK 1.5, you'll find jre/lib/jsse.jar. But when jsse.jar desapear, i offer to modified code... In other way if use javax.net.ssl.KeyManagerFactory , javax.net.ssl.SSLContext, javax.net.ssl.TrustManager, ftps don't work under JDK 1.3. I hope explain better, this time. Then, make that you consider appropiate... Thanks all, for your time. -- The whole purpose of places like Starbucks is for people with no decision-making ability whatsoever to make six decisions just to buy one cup of coffee. Short, tall, light, dark, caf, decaf, low-fat, non-fat, etc. So people who don't know what the hell they're doing or who on earth they are can, for only $2.95, get not just a cup of coffee but an absolutely defining sense of self: Tall. Decaf. Cappuccino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Thank you for this explanation. It is good to actually look at the code instead of making assumptions, which is what I have been doing. The JSSE's jar does not provide javax.net.ssl versions of the com.sun.net.ssl interfaces And, after doing a little research, I find that there are differences between JSSE 1.0.3 and the packages in JDK 1.4, such that there is no backward compatibility. Basically, JSSE 1.0.x is a prototype, a hack through which Sun worked out the bugs, culminating in the better implementation that they released in 1.4. They did not just move the JSSE.jar code into JDK 1.4. They also improved it. Since these are new classes for us, I think it makes little sense to tie into backward compatibility from the start, when that backward compatibility is already out of date. I don't think there is a clean way to have one code base that will work the way we'd like it for both cases. Therefore, I think the solution for this is for Jakarta Commons Net to take Rory Winston's suggestion and start a new branch of Commons Net for JDK 1.4 only (for this and other reasons) and maintain two branches for awhile, the current HEAD branch for 1.3 compatibility and the new branch for 1.4. The new branch can use the javax.ssl.net classes, the old one can use com.sun.net. Jose Juan Montiel wrote: Hi Steve, What I think you're missing is that if you put jsse.jar on your classpath, you can use javax.net.ssl with java 1.3. maybe i don't explain well, sorry. The three classes of com.sun.net.ssl that are used for implement FTPS (in the way that Paul did and I modified, maybe there is another...) are... com.sun.net.ssl.KeyManagerFactory (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/KeyManagerFactory.html) com.sun.net.ssl.SSLContext (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/SSLContext.html) com.sun.net.ssl.TrustManager (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/TrustManager.html) This classes in JSSE are only in the package com.sun.net.ssl, and although in JSSE 1.0.3 there are a packege javax.net.ssl, it doesn't contain this classes, it contains javax.net.ssl.SSLSocket, a classes soon used, to implement FTPS. And the commons-net team would prefer to go that way because Sun says that com.sun.net may go away with some future release, but not javax.net. Yes, this would be a small inconvenience for java 1.3 users, but the stability is worth it. This three classes in JDK 1.4.2, were move to javax.net.ssl.KeyManagerFactory (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/KeyManagerFactory.html) javax.net.ssl.SSLContext (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLContext.html) javax.net.ssl.TrustManager (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/TrustManager.html) But if you download for example JDK 1.4.2 and look inside of (jre/lib) you'll find jsse.jar, the jar where still are com.sun.net.ssl. Sun, still mantain compatiblity with JDK 1.3. And still in JDK 1.5, you'll find jre/lib/jsse.jar. But when jsse.jar desapear, i offer to modified code... In other way if use javax.net.ssl.KeyManagerFactory , javax.net.ssl.SSLContext, javax.net.ssl.TrustManager, ftps don't work under JDK 1.3. I hope explain better, this time. Then, make that you consider appropiate... Thanks all, for your time. -- The whole purpose of places like Starbucks is for people with no decision-making ability whatsoever to make six decisions just to buy one cup of coffee. Short, tall, light, dark, caf, decaf, low-fat, non-fat, etc. So people who don't know what the hell they're doing or who on earth they are can, for only $2.95, get not just a cup of coffee but an absolutely defining sense of self: Tall. Decaf. Cappuccino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Stevw
I think that's a great suggestion. It moves us forward without
necessarily sacrificing backwards compatability.
I have had a look at the classes written by Jose and Paul, and
incorporated them into my local branch copy. I had to make one minor
change to get them to work, but other than that they seem to work well.
I set up a test FTPS server using FileZilla on my local machine and
wrote some client code:
FtpsClient client = new FtpsClient();
client.connect(127.0.0.1);
client.addProtocolCommandListener(new
PrintCommandListener(new PrintWriter(System.out)));
client.login(user, pass);
client.cwd(test);
for (FTPFile file : client.listFiles()) {
System.out.println(file.getName());
}
OutputStream out = new FileOutputStream(c:\\temp\\test.war);
client.retrieveFile(test.war, out);
client.disconnect();
and it seems to work a treat. If we are agreed that we should go down
this parallel branch route, then I can move the JDK_1_4_BRANCH to
something more sensible (i.e. Daniel's suggestion a while back to make
the 1.4+ branch version 2), maybe NET_2_0_0. We can use the com.sun.*
stuff for the 1.3 branch (which will probably be our 1.5.0 release)?
Rory
Steve Cohen wrote:
Thank you for this explanation. It is good to actually look at the
code instead of making assumptions, which is what I have been doing.
The JSSE's jar does not provide javax.net.ssl versions of the
com.sun.net.ssl interfaces And, after doing a little research, I find
that there are differences between JSSE 1.0.3 and the packages in JDK
1.4, such that there is no backward compatibility. Basically, JSSE
1.0.x is a prototype, a hack through which Sun worked out the bugs,
culminating in the better implementation that they released in 1.4.
They did not just move the JSSE.jar code into JDK 1.4. They also
improved it.
Since these are new classes for us, I think it makes little sense to
tie into backward compatibility from the start, when that backward
compatibility is already out of date. I don't think there is a clean
way to have one code base that will work the way we'd like it for both
cases.
Therefore, I think the solution for this is for Jakarta Commons Net to
take Rory Winston's suggestion and start a new branch of Commons Net
for JDK 1.4 only (for this and other reasons) and maintain two
branches for awhile, the current HEAD branch for 1.3 compatibility and
the new branch for 1.4. The new branch can use the javax.ssl.net
classes, the old one can use com.sun.net.
Jose Juan Montiel wrote:
Hi Steve,
What I think you're missing is that if you put jsse.jar on your
classpath, you can use javax.net.ssl with java 1.3.
maybe i don't explain well, sorry.
The three classes of com.sun.net.ssl that are used for implement FTPS
(in the way that Paul did and I modified, maybe there is another...)
are...
com.sun.net.ssl.KeyManagerFactory
(http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/KeyManagerFactory.html)
com.sun.net.ssl.SSLContext
(http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/SSLContext.html)
com.sun.net.ssl.TrustManager
(http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/TrustManager.html)
This classes in JSSE are only in the package com.sun.net.ssl, and
although in JSSE 1.0.3 there are a packege javax.net.ssl, it doesn't
contain this classes, it contains javax.net.ssl.SSLSocket, a classes
soon used, to implement FTPS.
And the commons-net team would prefer to go that way because Sun
says that
com.sun.net may go away with some future release, but not
javax.net. Yes, this
would be a small inconvenience for java 1.3 users, but the stability
is worth it.
This three classes in JDK 1.4.2, were move to
javax.net.ssl.KeyManagerFactory
(http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/KeyManagerFactory.html)
javax.net.ssl.SSLContext
(http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLContext.html)
javax.net.ssl.TrustManager
(http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/TrustManager.html)
But if you download for example JDK 1.4.2 and look inside of (jre/lib)
you'll find jsse.jar, the jar where still are com.sun.net.ssl. Sun,
still mantain compatiblity with JDK 1.3.
And still in JDK 1.5, you'll find jre/lib/jsse.jar.
But when jsse.jar desapear, i offer to modified code...
In other way if use javax.net.ssl.KeyManagerFactory ,
javax.net.ssl.SSLContext, javax.net.ssl.TrustManager, ftps don't work
under JDK 1.3.
I hope explain better, this time.
Then, make that you consider appropiate...
Thanks all, for your time.
--
The whole purpose of places like Starbucks is
for people with no decision-making ability
whatsoever to make six decisions just to buy
one cup of coffee. Short, tall, light, dark, caf,
decaf, low-fat, non-fat, etc. So people who
don't
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
I'm living in the timewarp of digest mode subscription, so please forgive me for having made obsoleted comments. In message [EMAIL PROTECTED], Rory Winston writes: I think that's a great suggestion. It moves us forward without necessarily sacrificing backwards compatability. ... Steve Cohen wrote: Thank you for this explanation. It is good to actually look at the code instead of making assumptions, which is what I have been doing. ... Therefore, I think the solution for this is for Jakarta Commons Net to take Rory Winston's suggestion and start a new branch of Commons Net for JDK 1.4 only (for this and other reasons) and maintain two branches for awhile, the current HEAD branch for 1.3 compatibility and the new branch for 1.4. The new branch can use the javax.ssl.net classes, the old one can use com.sun.net. +1 Since we're going to branch anyway and in light of Steve's discoveries about JSSE 1.0.3, this seems like the easiest way to handle the situation. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Daniel F. Savarese wrote: I'm living in the timewarp of digest mode subscription, so please forgive me for having made obsoleted comments. In message [EMAIL PROTECTED], Rory Winston writes: I think that's a great suggestion. It moves us forward without necessarily sacrificing backwards compatability. ... Steve Cohen wrote: Thank you for this explanation. It is good to actually look at the code instead of making assumptions, which is what I have been doing. ... Therefore, I think the solution for this is for Jakarta Commons Net to take Rory Winston's suggestion and start a new branch of Commons Net for JDK 1.4 only (for this and other reasons) and maintain two branches for awhile, the current HEAD branch for 1.3 compatibility and the new branch for 1.4. The new branch can use the javax.ssl.net classes, the old one can use com.sun.net. +1 Since we're going to branch anyway and in light of Steve's discoveries about JSSE 1.0.3, this seems like the easiest way to handle the situation. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Daniel, before we vote, I think we need a formal motion to vote on, especially in light of your obsoleted comments in the other thread. I think the proposal on the floor is to do two things A) a commons-net 1.5 containing fixes for any outstanding bugs and incorporating Josejuan Montiel and Paul Ferraro's FTPS code. This code would depend on com.sun.ssl.net classes. It would be the last release supporting JDKs 1.4 B) a commons-net 2.0 (possibly a different project) that would require jdk 1.4 compatibility, including modifying the FTPS code to use javax.ssl.net, the nio extensions, and using java 1.4's regex which would have the one small advantage of reducing dependency on other jars which periodically rears its head as an issue. While I'm generally in favor of this, I still don't think its ready for a vote because of possibly a different project, which is too vague. One more thing, we would need Paul Ferraro to sign a Software Grant which was mentioned about a week ago by Cliff Schmidt. I am trying to get details on this. Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
In message [EMAIL PROTECTED], Steve Cohen writes: Daniel, before we vote, I think we need a formal motion to vote on, especially in light of your obsoleted comments in the other thread. My +1 wasn't intended to reflect a vote. It was just shorthand for I concur. While I'm generally in favor of this, I still don't think its ready for a vote because of possibly a different project, which is too vague. +1 :) daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Hi, first of all, thanks for your attention, and your time to improve Jakarta Commons Net. Then I would like to finish this point. When you had to choose the way to implement FTPS, you propose: 3. Maybe. use the javax.net.ssl classes but document that if used with JDK 1.4, jsse.jar must be on the classpath. And I said: The 3º option it not possible, because, don't work under 1.3, although import jsse.jar... need change the import in source code... And you ask: Well if option 3 won't work, that changes things, but can you tell us how it fails? I said that option don't work under JDK 1.3, because javax.net.ssl its only in JDK 1.4. In those days, the list ask about the JDK that you use... I think that Jakarta support JDK 1.3, its a good idea, because although 1.3 its too old... thera are a lot of servers that run on this In this case i think, that implement FTPS using com.sun its the best option because, it run on 1.3 (importing JSSE) and 1.4 (where you dont need any aditiona jar import) And finally, what will be the choice...? Thanks for all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Jose Juan Montiel wrote: Hi, first of all, thanks for your attention, and your time to improve Jakarta Commons Net. Then I would like to finish this point. When you had to choose the way to implement FTPS, you propose: 3. Maybe. use the javax.net.ssl classes but document that if used with JDK 1.4, jsse.jar must be on the classpath. And I said: The 3º option it not possible, because, don't work under 1.3, although import jsse.jar... need change the import in source code... And you ask: Well if option 3 won't work, that changes things, but can you tell us how it fails? I said that option don't work under JDK 1.3, because javax.net.ssl its only in JDK 1.4. In those days, the list ask about the JDK that you use... I think that Jakarta support JDK 1.3, its a good idea, because although 1.3 its too old... thera are a lot of servers that run on this In this case i think, that implement FTPS using com.sun its the best option because, it run on 1.3 (importing JSSE) and 1.4 (where you dont need any aditiona jar import) And finally, what will be the choice...? Thanks for all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] What I think you're missing is that if you put jsse.jar on your classpath, you can use javax.net.ssl with java 1.3. And the commons-net team would prefer to go that way because Sun says that com.sun.net may go away with some future release, but not javax.net. Yes, this would be a small inconvenience for java 1.3 users, but the stability is worth it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Just use jsse. I didn't have any problems with them under jdk1.3. Running that stuff under jdk1.3 should also work like charm. Mvgr, Martin Steve Cohen wrote: Rory Winston wrote: Ive come across the com.sun.* issue before. They are part of the JVM, just not officially documented for public use. Usually, they are convenience classes written by Sun programmes who develop the JDK. AFAIK, Sun says that you can use them if you wish, but their use is not recommended, purely on the basis that they may disappear from one JDK release to the next. What are the com.sun.* classes being used here for, specifically? It may be possible to use official classes for this functionality. Rory From what I've been able to gather there are official classes as of jdk 1.4. Prior to that these were a separate package, the JSSE. So I guess there are three possibilities: 1. Use the javax.net.ssl classes. (Out of the question because of our mandate to support 1.3) 2. Do what Paul and Josejuan did - use the com.sun classes 3. Maybe. use the javax.net.ssl classes but document that if used with JDK 1.4, jsse.jar must be on the classpath. Has anyone on this list had experience with these type of issues? (technical, not legal). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
In message [EMAIL PROTECTED], Rahul Akolkar writes: No, haven't had to deal with such a situation. But doesn't this mean that the code will only work on a subset of the 1.3 JDKs (Sun)? If so, maybe (3) isn't all that bad? In general, I am biased against introducing dependencies on com.sun packages for the very reason stated. The code will work only with the Sun JDK or JVMs incorporating sublicensed parts of the JDK that include those packages. For that matter, it will work only with a particular version of the Sun JVM should the classes not appear in a future release. If JSSE will work and is usable with JDK 1.3 as an add-on jar, I don't see any reason why it should be avoided (i.e., I'm +1 for option 3 and -1 for 2). daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
1. Use the javax.net.ssl classes. (Out of the question because of our mandate to support 1.3) 2. Do what Paul and Josejuan did - use the com.sun classes 3. Maybe. use the javax.net.ssl classes but document that if used with JDK 1.4, jsse.jar must be on the classpath. Hi, i'll use the second option, because if commons-net implements SSL-FTPS under JDK 1.3, its necesary import JSSE, and if use JDK 1.4, the source code, don't need any change. When commons-net, upgrde to JDK 1.4, if want remove JSSE, the modifications in source code will be simples. I'll do it :) The 3º option it not possible, because, don't work under 1.3, although import jsse.jar... need change the import in source code... Its my opinion. Thanks for all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Jose Juan Montiel wrote: 1. Use the javax.net.ssl classes. (Out of the question because of our mandate to support 1.3) 2. Do what Paul and Josejuan did - use the com.sun classes 3. Maybe. use the javax.net.ssl classes but document that if used with JDK 1.4, jsse.jar must be on the classpath. Hi, i'll use the second option, because if commons-net implements SSL-FTPS under JDK 1.3, its necesary import JSSE, and if use JDK 1.4, the source code, don't need any change. When commons-net, upgrde to JDK 1.4, if want remove JSSE, the modifications in source code will be simples. I'll do it :) The 3º option it not possible, because, don't work under 1.3, although import jsse.jar... need change the import in source code... Its my opinion. Thanks for all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Well if option 3 won't work, that changes things, but can you tell us how it fails? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTPS submission - legal issues
Ive come across the com.sun.* issue before. They are part of the JVM, just not officially documented for public use. Usually, they are convenience classes written by Sun programmes who develop the JDK. AFAIK, Sun says that you can use them if you wish, but their use is not recommended, purely on the basis that they may disappear from one JDK release to the next. What are the com.sun.* classes being used here for, specifically? It may be possible to use official classes for this functionality. Rory Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: Looks like you're in moderation there. I'll send the below when I see the email there: Are Paul and Josejuan the only contributors to the work? Usually you need to have the permission of every committer (contributor?) to the work to allow relicencing. That part is all about copyright law I think. Does the com.sun bit mean that a separate jar is needed, or is it part of the JVM? In the latter case I think we'll find out that things are legally okay; if the former then the current policy is that that is okay (depends on licence, but we're shipping lots of Sun licenced works), but it's likely to require some hoops in the near future. Hen On 1/22/06, Steve Cohen [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: Steve - While there are multiple people on this list who are probably well-informed enough to answer the questions below definitively, I'd also ping legal-discuss@ which might have a better demographic for these kind of posts. -Rahul On 1/22/06, Steve Cohen [EMAIL PROTECTED] wrote: Josejuan Montiel ([EMAIL PROTECTED]) has submitted some code that would implement an FTPS protocol as an addition to commons-net. This submission takes the form of a patch submitted as a bug via http://issues.apache.org/bugzilla/show_bug.cgi?id=3D38309. Apparently this code was submitted as part of an existing project under SourceForg= e ( http://sourceforge.net/projects/ufsc). That project was originally und= er the LGPL, although its owner, Paul Ferraro has apparently agreed to swit= ch it to the Apache License. Can some of the licensing gurus comment on this, and provide feedback? = I would like to see this happen if it's possible. However, Mr. Montiel ha= s more work to do before the team would accept the submission, and I am reluctant to suggest tha= t he do it if some licensing issue that I am not aware of would kill the id= ea. Additionally. the submission depends on classes in the com.sun.net.ssl package. Are these legal imports for jakarta? Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] thanks, I've cross-posted there now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTPS submission - legal issues
Ive come across the com.sun.* issue before. They are part of the JVM, just not officially documented for public use. Usually, they are convenience classes written by Sun programmes who develop the JDK. AFAIK, Sun says that you can use them if you wish, but their use is not recommended, purely on the basis that they may disappear from one JDK release to the next. What are the com.sun.* classes being used here for, specifically? It may be possible to use official classes for this functionality. Rory Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: Looks like you're in moderation there. I'll send the below when I see the email there: Are Paul and Josejuan the only contributors to the work? Usually you need to have the permission of every committer (contributor?) to the work to allow relicencing. That part is all about copyright law I think. Does the com.sun bit mean that a separate jar is needed, or is it part of the JVM? In the latter case I think we'll find out that things are legally okay; if the former then the current policy is that that is okay (depends on licence, but we're shipping lots of Sun licenced works), but it's likely to require some hoops in the near future. Hen On 1/22/06, Steve Cohen [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: Steve - While there are multiple people on this list who are probably well-informed enough to answer the questions below definitively, I'd also ping legal-discuss@ which might have a better demographic for these kind of posts. -Rahul On 1/22/06, Steve Cohen [EMAIL PROTECTED] wrote: Josejuan Montiel ([EMAIL PROTECTED]) has submitted some code that would implement an FTPS protocol as an addition to commons-net. This submission takes the form of a patch submitted as a bug via http://issues.apache.org/bugzilla/show_bug.cgi?id=3D38309. Apparently this code was submitted as part of an existing project under SourceForg= e ( http://sourceforge.net/projects/ufsc). That project was originally und= er the LGPL, although its owner, Paul Ferraro has apparently agreed to swit= ch it to the Apache License. Can some of the licensing gurus comment on this, and provide feedback? = I would like to see this happen if it's possible. However, Mr. Montiel ha= s more work to do before the team would accept the submission, and I am reluctant to suggest tha= t he do it if some licensing issue that I am not aware of would kill the id= ea. Additionally. the submission depends on classes in the com.sun.net.ssl package. Are these legal imports for jakarta? Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] thanks, I've cross-posted there now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTPS submission - legal issues
Henri Yandell wrote: Looks like you're in moderation there. Yeah. I realized after I sent it that I have no right to post there. I've tried subscribing, but unlike the other apache lists, approval does not seem to come automatically. I'm still waiting for approval. Looking at the Mail List Archives for that list, we see the following from Cliff Schmidt: -- If Paul Ferraro is the sole copyright owner of all the code of interest, then there shouldn't be a problem. Assumuning this is the case, the next question is whether the code is to be hacked on going forward within the Jakarta Commons community or whether it is just being dropped into some external/third-party directory. If the former, then Paul should sign a Software Grant. If the latter, Paul should simply create a new release of the code explicitly licensed under the Apache License, and the the Jakarta PMC can choose to allow that to be included in the Jakarta Commons distribution. --- Yes, the code is to be hacked on. Already there are suggestions for new features, etc. Cliff - any information on how to sign a Software Grant? I'll send the below when I see the email there: Are Paul and Josejuan the only contributors to the work? Usually you need to have the permission of every committer (contributor?) to the work to allow relicencing. That part is all about copyright law I think. This would seem to be so. Going over the whole Source Forge site for this project, there doesn't seem to be a single file committed there by anyone other than Mr. Ferraro. It looks like he removed the LPGL from every file on Friday, Jan 20. If there's anyone else he needs approval from to remove the LPGL, I didn't find it. The Source Forge site doesn't provide a list of developers for the project. However, in my due diligence, I did discover one item that might require some further comment. A previous version (1.1) of net.sf.ufsc.UserInfo.java contains the following copyright notice: /* * Copyright (c) 2004, Identity Theft 911, LLC. All rights reserved. */ Was this Paul Ferraro's company? If not, did he have permission to take it to LPGL? I don't think this would be a huge impediment anyway, at its worst. This is a very simple class for which a clean-room implementation, if needed, would be very simple to do. Does the com.sun bit mean that a separate jar is needed, or is it part of the JVM? It's apparently part of the JVM. The reason they used this class rather than the javax.net.ssl class of the same name is to preserve jdk 1.3 compatibility. Since that is an issue with commons-net as well, this is a good thing. These classes were originally part of the Java Secure Socket Extension (JSSE), which was incorporated into JDK 1.4. I'm not sure if the best way wouldn't be to require the use of this jar on the classpath for jdks 1.4, but this is now more a technical question than a legal one. In the latter case I think we'll find out that things are legally okay; if the former then the current policy is that that is okay (depends on licence, but we're shipping lots of Sun licenced works), but it's likely to require some hoops in the near future. Hen On 1/22/06, Steve Cohen [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: Steve - While there are multiple people on this list who are probably well-informed enough to answer the questions below definitively, I'd also ping legal-discuss@ which might have a better demographic for these kind of posts. -Rahul On 1/22/06, Steve Cohen [EMAIL PROTECTED] wrote: Josejuan Montiel ([EMAIL PROTECTED]) has submitted some code that would implement an FTPS protocol as an addition to commons-net. This submission takes the form of a patch submitted as a bug via http://issues.apache.org/bugzilla/show_bug.cgi?id=38309. Apparently this code was submitted as part of an existing project under SourceForge ( http://sourceforge.net/projects/ufsc). That project was originally under the LGPL, although its owner, Paul Ferraro has apparently agreed to switch it to the Apache License. Can some of the licensing gurus comment on this, and provide feedback? I would like to see this happen if it's possible. However, Mr. Montiel has more work to do before the team would accept the submission, and I am reluctant to suggest that he do it if some licensing issue that I am not aware of would kill the idea. Additionally. the submission depends on classes in the com.sun.net.ssl package. Are these legal imports for jakarta? Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] thanks, I've cross-posted there now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands,
[net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Rory Winston wrote: Ive come across the com.sun.* issue before. They are part of the JVM, just not officially documented for public use. Usually, they are convenience classes written by Sun programmes who develop the JDK. AFAIK, Sun says that you can use them if you wish, but their use is not recommended, purely on the basis that they may disappear from one JDK release to the next. What are the com.sun.* classes being used here for, specifically? It may be possible to use official classes for this functionality. Rory From what I've been able to gather there are official classes as of jdk 1.4. Prior to that these were a separate package, the JSSE. So I guess there are three possibilities: 1. Use the javax.net.ssl classes. (Out of the question because of our mandate to support 1.3) 2. Do what Paul and Josejuan did - use the com.sun classes 3. Maybe. use the javax.net.ssl classes but document that if used with JDK 1.4, jsse.jar must be on the classpath. Has anyone on this list had experience with these type of issues? (technical, not legal). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
On 1/23/06, Steve Cohen [EMAIL PROTECTED] wrote: Rory Winston wrote: Ive come across the com.sun.* issue before. They are part of the JVM, just not officially documented for public use. Usually, they are convenience classes written by Sun programmes who develop the JDK. AFAIK, Sun says that you can use them if you wish, but their use is not recommended, purely on the basis that they may disappear from one JDK release to the next. What are the com.sun.* classes being used here for, specifically? It may be possible to use official classes for this functionality. Rory From what I've been able to gather there are official classes as of jdk 1.4. Prior to that these were a separate package, the JSSE. So I guess there are three possibilities: 1. Use the javax.net.ssl classes. (Out of the question because of our mandate to support 1.3) 2. Do what Paul and Josejuan did - use the com.sun classes 3. Maybe. use the javax.net.ssl classes but document that if used with JDK 1.4, jsse.jar must be on the classpath. Has anyone on this list had experience with these type of issues? (technical, not legal). snip/ No, haven't had to deal with such a situation. But doesn't this mean that the code will only work on a subset of the 1.3 JDKs (Sun)? If so, maybe (3) isn't all that bad? -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] FTPS submission - legal issues
Josejuan Montiel ([EMAIL PROTECTED]) has submitted some code that would implement an FTPS protocol as an addition to commons-net. This submission takes the form of a patch submitted as a bug via http://issues.apache.org/bugzilla/show_bug.cgi?id=38309. Apparently this code was submitted as part of an existing project under SourceForge ( http://sourceforge.net/projects/ufsc). That project was originally under the LGPL, although its owner, Paul Ferraro has apparently agreed to switch it to the Apache License. Can some of the licensing gurus comment on this, and provide feedback? I would like to see this happen if it's possible. However, Mr. Montiel has more work to do before the team would accept the submission, and I am reluctant to suggest that he do it if some licensing issue that I am not aware of would kill the idea. Additionally. the submission depends on classes in the com.sun.net.ssl package. Are these legal imports for jakarta? Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTPS submission - legal issues
Steve - While there are multiple people on this list who are probably well-informed enough to answer the questions below definitively, I'd also ping legal-discuss@ which might have a better demographic for these kind of posts. -Rahul On 1/22/06, Steve Cohen [EMAIL PROTECTED] wrote: Josejuan Montiel ([EMAIL PROTECTED]) has submitted some code that would implement an FTPS protocol as an addition to commons-net. This submission takes the form of a patch submitted as a bug via http://issues.apache.org/bugzilla/show_bug.cgi?id=38309. Apparently this code was submitted as part of an existing project under SourceForge ( http://sourceforge.net/projects/ufsc). That project was originally under the LGPL, although its owner, Paul Ferraro has apparently agreed to switch it to the Apache License. Can some of the licensing gurus comment on this, and provide feedback? I would like to see this happen if it's possible. However, Mr. Montiel has more work to do before the team would accept the submission, and I am reluctant to suggest that he do it if some licensing issue that I am not aware of would kill the idea. Additionally. the submission depends on classes in the com.sun.net.ssl package. Are these legal imports for jakarta? Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTPS submission - legal issues
Rahul Akolkar wrote: Steve - While there are multiple people on this list who are probably well-informed enough to answer the questions below definitively, I'd also ping legal-discuss@ which might have a better demographic for these kind of posts. -Rahul On 1/22/06, Steve Cohen [EMAIL PROTECTED] wrote: Josejuan Montiel ([EMAIL PROTECTED]) has submitted some code that would implement an FTPS protocol as an addition to commons-net. This submission takes the form of a patch submitted as a bug via http://issues.apache.org/bugzilla/show_bug.cgi?id=38309. Apparently this code was submitted as part of an existing project under SourceForge ( http://sourceforge.net/projects/ufsc). That project was originally under the LGPL, although its owner, Paul Ferraro has apparently agreed to switch it to the Apache License. Can some of the licensing gurus comment on this, and provide feedback? I would like to see this happen if it's possible. However, Mr. Montiel has more work to do before the team would accept the submission, and I am reluctant to suggest that he do it if some licensing issue that I am not aware of would kill the idea. Additionally. the submission depends on classes in the com.sun.net.ssl package. Are these legal imports for jakarta? Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] thanks, I've cross-posted there now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTPS submission - legal issues
Looks like you're in moderation there. I'll send the below when I see the email there: Are Paul and Josejuan the only contributors to the work? Usually you need to have the permission of every committer (contributor?) to the work to allow relicencing. That part is all about copyright law I think. Does the com.sun bit mean that a separate jar is needed, or is it part of the JVM? In the latter case I think we'll find out that things are legally okay; if the former then the current policy is that that is okay (depends on licence, but we're shipping lots of Sun licenced works), but it's likely to require some hoops in the near future. Hen On 1/22/06, Steve Cohen [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: Steve - While there are multiple people on this list who are probably well-informed enough to answer the questions below definitively, I'd also ping legal-discuss@ which might have a better demographic for these kind of posts. -Rahul On 1/22/06, Steve Cohen [EMAIL PROTECTED] wrote: Josejuan Montiel ([EMAIL PROTECTED]) has submitted some code that would implement an FTPS protocol as an addition to commons-net. This submission takes the form of a patch submitted as a bug via http://issues.apache.org/bugzilla/show_bug.cgi?id=38309. Apparently this code was submitted as part of an existing project under SourceForge ( http://sourceforge.net/projects/ufsc). That project was originally under the LGPL, although its owner, Paul Ferraro has apparently agreed to switch it to the Apache License. Can some of the licensing gurus comment on this, and provide feedback? I would like to see this happen if it's possible. However, Mr. Montiel has more work to do before the team would accept the submission, and I am reluctant to suggest that he do it if some licensing issue that I am not aware of would kill the idea. Additionally. the submission depends on classes in the com.sun.net.ssl package. Are these legal imports for jakarta? Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] thanks, I've cross-posted there now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] FTPS or...
...why in org.apache.commons.net.ftp.FTP the variables BufferedReader _controlInput; BufferedWriter _controlOutput; aren't declare protected? Hi everybody, i'm newbee in this list, and i'm trying to impliments SSL-FTPS over Java 1.3.1, using http://sourceforge.net/projects/ufsc implementation of FTPS, with some minor modification to adapt 1.3 and solve some fix with PASV transfer (modification and fix, that i comunicate to the author), but the problem i find, was i couldn't implement FTPSClient in diferent package of org.apache.commons.net.ftp because, this variables, that UFSC use, to implement securety connection to SSLSocket this._controlInput = new BufferedReader(new InputStreamReader(socket.getInputStream(), getControlEncoding())); this._controlOutput = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream(), getControlEncoding())); haven't a getter... and its visibility is to the package Then, i have to create FTPClient and FTP, and extends FTPSClient, from my own FTPClient, to make it in a difetent pakage... Could devoloper make getter for this properties or protected, for simplify the extension of api? Thanks for all... -- The whole purpose of places like Starbucks is for people with no decision-making ability whatsoever to make six decisions just to buy one cup of coffee. Short, tall, light, dark, caf, decaf, low-fat, non-fat, etc. So people who don't know what the hell they're doing or who on earth they are can, for only $2.95, get not just a cup of coffee but an absolutely defining sense of self: Tall. Decaf. Cappuccino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
