Not a vote result, since it is just a conclusion from my side. <Jakarta hat on> Even though there are enough +1's to start sponsoring ssl, I think I want to see a lot more support than what I currently see (I mean active support). So at this stage I don't think it is wise that Jakarta should sponsor this project. Let's see where incubation takes ssl, without being destined for Jakarta and only decide if ssl requests to be part of Jakarta when it wants to or is ready to when it's time to leave the incubator. </Jakarta hat on>
<Personal hat on> Since there are more (Apache) projects interested in ssl, I think however we can get enough people on board to do a successful incubation, so I offered to Julius to help him out with incubation as the sponsor and the mentor. </Personal hat on> If you strongly disagree with my conclusion, please step up to get actively involved, if not I will start working with Julius on a personal basis to get this baby going. Mvgr, Martin Julius Davies wrote: > Hi, Jakarta-General, > > Let's vote on where to put this code! Here's the code right now: > > http://juliusdavies.ca/commons-ssl/ > > Forgive my newbieness; I hope these are the right options: > > [+1] Sub-module in Httpcomponents. > [+1] Sandbox. > [+1] Full Incubator. > [-1] "not-yet-commons-ssl" is not a good project for Apache because... > > I'm fine with majority rules, assuming there are no "-1" votes. > > Some background: > > http://wiki.apache.org/jakarta/JakartaBoardReport-February2007 > > "The code grant for the not yet commons SSL (formerly named > commons-ssl), has been completed, so we can progress to having a vote > where SSL should end up on general and based on that result take the > correct incubator path (legal / full incubation)." > > Let's just get this vote out of the way, and then we can move on to > other issues in the appropriate venue (HttpComponents, or Sandbox, or > Incubator). > > My original proposal to "jakarta-general" about the project is here: > http://www.mail-archive.com/[email protected]/msg12790.html > > Yesterday I released "not-yet-commons-ssl-0.3.7". Changes described > at the bottom of this email. My intention is for 0.3.7 to be the last > release outside of Apache. > > > By the way, there's one undocumented feature of common-ssl that's been > quite fun: > > http://juliusdavies.ca/commons-ssl/javadocs/org/apache/commons/ssl/OpenSSL.html > > > :-) > > > yours, > > Julius > > ps. My vote is: > > [+0] - Abstaining because I'm too much of a newb to really understand > what I'm voting for. > > > On 2/23/07, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: >> On Thu, 2007-02-22 at 10:20 -0800, Julius Davies wrote: >> > not-yet-commons-ssl-0.3.7 released! >> > >> > http://juliusdavies.ca/commons-ssl/download.html >> > >> > >> >> Hi Julius, >> >> What are your plans regarding not-yet-commons-ssl? Is there anything >> still blocking the incubation process? There are already two Apache >> projects (HttpComponents and Synapse) that can potentially benefit from >> collaboration with not-yet-commons-ssl. So, there is a lot of interest >> in seeing things moving forward. >> >> Oleg >> >> > > Features as of not-yet-commons-ssl-0.3.7: > > 1. useStrongCiphers() used by default. > ------------------------------------------------------------------------- > 40 bit and 56 bit ciphers are now disabled by default. To turn them > back on call useDefaultJavaCiphers(). > > > 2. addAllowedName() adds some flexibility to the CN verification. > ------------------------------------------------------------------------- > Here's a code example using "cucbc.com" to connect, but anticipating > "www.cucbc.com" in the server's certificate: > > SSLClient client = new SSLClient(); > client.addAllowedName( "www.cucbc.com" ); > Socket s = client.createSocket( "cucbc.com", 443 ); > > This technique is also useful if you don't want to use DNS, and want > to connect using the IP address. > > > 3. SSLServer can re-use a Tomcat-8443 private key if running from inside > Tomcat. > ------------------------------------------------------------------------- > SSLClient server = new SSLServer(); > server.useTomcatSSLMaterial(); > > > 4. RMI-SSL support improved. > ------------------------------------------------------------------------- > Attempts to re-use the Tomcat-8443 private key for all RMI SSL Server > sockets. Anonymous server-sockets (port 0) will always be set to port > 31099. Analyzes the server certificate CN field and tries to set > "java.rmi.server.hostname" to something compatible with that. Probably > the only free implementation around that does a good job on the > hostname verification! > > > 5. KeyMaterial constructor blows up earlier. > ------------------------------------------------------------------------- > If a JKS or PKCS12 file is provided that isn't going to work (e.g. no > private keys), the KeyMaterial constructor throws an exception right > away. > > > 6. getSSLContext() now available to help inter-op with Java 5 SSL-NIO > libraries. > ------------------------------------------------------------------------- > Oleg has been working hard on SSL-NIO for the Apache httpcomponents > library. Go check it out! > > > 7. Fixed bug where SSLClient couldn't be used with > javax.net.ssl.HttpsURLConnection on Java 1.4.x > ------------------------------------------------------------------------- > I was wrapping the SSLSocket, but Java 1.4.x guards against that > inside HttpsURLConnection and throws this exciting exception: > > java.lang.RuntimeException: Export restriction: this JSSE > implementation is non-pluggable. > at > com.sun.net.ssl.internal.ssl.SSLSocketFactoryImpl.checkCreate(DashoA6275) > at sun.net.www.protocol.https.HttpsClient.afterConnect(DashoA6275) > at > sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(DashoA6275) > > at > sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:560) > > at > sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(DashoA6275) > > > Silly Java - I'm still using your JSSE implementation, I'm just wrapping > it! > > > > The KeyStoreBuilder command-line utility can go both ways now (to jks, > and to pkcs8 in PEM format). So you can use it to convert a java > "keystore" file into an Apache-SSL compatible PEM file for your httpd > server! > > http://juliusdavies.ca/commons-ssl/utilities.html > ============================================ > $ java -cp commons-ssl-0.3.7.jar org.apache.commons.ssl.KeyStoreBuilder > KeyStoreBuilder: outputs JKS file (java keystore) as ./[alias].jks > [alias] will be set to the first CN value of the X509 certificate. > ------------------------------------------------------------------- > Usage1: [password] [file:pkcs12] > Usage2: [password] [file:private-key] [file:certificate-chain] > ------------------------------------------------------------------- > [private-key] can be openssl format, or pkcs8. > [password] decrypts [private-key], and also encrypts outputted JKS file. > All files can be PEM or DER. > ============================================ > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
