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 > > [X] I am willing to mentor (you need to be on the Incubator PMC / Member of > the ASF) > [ ] I want to get involved in coding > [ ] No interest in getting involved. > > > 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/[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] > > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
