On Fri, 2007-02-23 at 23:35 +0100, Martin van den Bemt wrote: > I prefer this vote to see where it should end up in Jakarta and based on that > result the path full > incubation / legal incubation is decided. > > So in my view the vote should be : > > [x] Jakarta should sponsor (which effectively states we like to see the code > end up here) > [ ] Jakarta shouldn't sponsor (which effectively means it will end up TLP) > > if accepted in Jakarta, it should end up in : > > [x] commons as a component > [ ] httpcomponents as a component > [ ] subproject directly under Jakarta > [ ] integrate / merge code into project xxx (please replace x) (so not a > subcomponent of a project!) > > And > > [ ] I am willing to mentor (you need to be on the Incubator PMC / Member of > the ASF) > [x] I want to get involved in coding > [ ] No interest in getting involved. >
Oleg > > Reasoning : > > 1) the first decides if Jakarta wants to sponsor this > 2) we need to know the place it should end up in Jakarta (at least have some > kind of direction) > 3) if no one is interested in getting involved or being a mentor (preferably > 3 mentors!), we can > easily see if option 1 and 2 are viable at all. > > The problem with the current vote is that I have to start yet another vote to > let us sponsor and > where it should end up, best to do it in one go in my opninion... > > So Martin and Ortwin could you please revote ? (Sorry for the inconvenience) > > 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/general@jakarta.apache.org/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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]