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 : [ ] 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 : [ ] 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) [ ] 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/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]
