Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should "not-yet-commons-ssl" go?

[Oleg Kalnichevski <ol...@apache.org>]

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 <ol...@apache.org> 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: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org