You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Julius Davies <ju...@gmail.com> on 2007/02/23 18:57:42 UTC
[Vote] Where should "not-yet-commons-ssl" go?
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.
============================================
--
yours,
Julius Davies
416-652-0183
http://juliusdavies.ca/
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [Vote] Where should "not-yet-commons-ssl" go?
Posted by Julius Davies <ju...@gmail.com>.
Hi, David,
What do you mean, exactly?
Do you have several certificates? If so, then no, can't share several
certificates on one socket. There isn't enough information available
to the plain socket (source ip, source port, target ip, target port is
all we have!) to decide on a certificate to use when building up the
SSL.
Do you have a single certificate with several domain names listed
inside it? If so, then standard Java JSSE as far back as Java 1.3
should work just fine on the server or the client.
Not-yet-commons-ssl is also fine with this. (Verisign is clever,
though, and they charge full price for each domain added to the
certificate).
Do you have a wildcard in your certificate's CN field? (e.g.
CN=*.credential.com)? Then, again, Java JSSE as far back as Java 1.3
is fine with that. Same for not-yet-commons-ssl.
When acting as a client, not-yet-commons-ssl (by default) is more lax
compared to java.net.URL with hostname verification:
CN=*.foo.com
java.net.URL will complain when connecting to "a.b.c.foo.com" (similar to IE6).
Not-Yet-Commons-SSL doesn't complain (similar to Curl and Firefox).
Mind you, that behaviour can be changed:
SSLClient client = new SSLClient();
client.setHostnameVerifier( HostnameVerifier.STRICT );
Here's the Javadoc explaining how Hostname Verification works in
Not-Yet-Commons-SSL:
http://juliusdavies.ca/commons-ssl/javadocs/org/apache/commons/ssl/HostnameVerifier.html
Hope this helps!
yours,
Julius
On 2/23/07, David Fisher <df...@jmlafferty.com> wrote:
> Hi Julius -
>
> I have a question. Does "not-yet-commons-ssl" allow me to "virtual
> host" multiple domain ssl certificates on a single socket on a Tomcat
> 4.1.31 server?
>
> That would be awesome if it does.
>
> Unofficial "+1"
>
> Regards,
> Dave Fisher
>
> On Feb 23, 2007, at 11:57 AM, 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.
> > ============================================
> >
> >
> > --
> > yours,
> >
> > Julius Davies
> > 416-652-0183
> > http://juliusdavies.ca/
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
yours,
Julius Davies
416-652-0183
http://juliusdavies.ca/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [Vote] Where should "not-yet-commons-ssl" go?
Posted by David Fisher <df...@jmlafferty.com>.
Hi Julius -
I have a question. Does "not-yet-commons-ssl" allow me to "virtual
host" multiple domain ssl certificates on a single socket on a Tomcat
4.1.31 server?
That would be awesome if it does.
Unofficial "+1"
Regards,
Dave Fisher
On Feb 23, 2007, at 11:57 AM, 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.
> ============================================
>
>
> --
> yours,
>
> Julius Davies
> 416-652-0183
> http://juliusdavies.ca/
>
> ---------------------------------------------------------------------
> 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
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where
should "not-yet-commons-ssl" go?
Posted by Martin van den Bemt <ml...@mvdb.net>.
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/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
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should "not-yet-commons-ssl" go?
Posted by Martin Cooper <ma...@apache.org>.
On 2/24/07, Martin van den Bemt <ml...@mvdb.net> wrote:
>
> >>
> >> Let's keep this statement your personal opinion on the fact that it is
> >> not
> >> relevant. I still like to
> >> know the opinion of others.
> >
> >
> > If you want opinions, don't use a vote to collect them. This is a vote
> > thread, not an opinion thread. Votes within the ASF are for decision
> > making,
> > not opinion polls. Jakarta is well known, in a negative way, for being
> > overly vote-happy, so we should be doing our best to confine our use of
> > voting to things that really need to be voted on. That includes neither
> > opinion polls or consensus building.
> >
> > My statement was that the final destination of a project is not relevant
> > for
> > a vote on whether or not it should be accepted into the incubator. I
> > consider that to be a simple fact about the way the incubator works, not
> an
> > opinion.
> >
>
> The difference of opinion here is that you see this as a vote about
> incubating ssl, which is simply
> not our call.
Not true. There are two basic requirements for entry into incubation: a
Champion and a Sponsor. Once both are found, the project is accepted. That's
it. So by stepping up and being a Sponsor, the Jakarta PMC could play a
pivotal role in the incubation of this SSL project, because without a
Sponsor, incubation is not going to happen, and once it has one, and a
Champion, entry into incubation is a done deal.
We can vote however on accepting ssl into Jakarta, which has the consequence
> that
> Jakarta is going to be actively involved as a champion / sponsor role to
> have the Incubator accept
> ssl.
Those things are not quite as connected as you make them out to be. Yes, we
could decide that Jakarta would be happy to have the SSL project land here
after incubation. But that does not imply any particular involvement in the
incubation process, and in the absence of a decision to be the project's
Sponsor, it is meaningless.
So the real decision to be made is whether or not the Jakarta PMC is willing
to step up and be the Sponsor for the SSL project. That basically means two
things:
1) Do we believe that this project would make a worthy addition to the ASF?
This is regardless of where it might land after incubation.
2) Would we be willing to accept the project as part of Jakarta once
incubation is completed successfully?
Note that #2 says that we are _willing_ to accept it, and makes no statement
about whether the project will, in fact, end up as part of Jakarta, or go
somewhere else.
So let's restart the vote (again - sorry) and make it very clear that we are
voting to be the Sponsor of the SSL project, and thus voting on whether it
should enter into incubation or not.
Say if the target is commons, we probably should have commons-ssl end up in
> the website of
> commons, have Julius participate on the commons website, instead of having
> separate lists, separate
> website and a separate PPMC and learning the commons way is pretty hard
> when you are actually not
> integrated into the commons community to begin with.
> We are talking about around 20 classes here and 1 new committer (afaik).
> What makes this case
> special compared to eg webwork (came across this while wading through the
> incubator archives to find
> similar scenario's) ?
>
> Maybe it's just a different definition of the meaning of full incubation.
> Things I want see solved during incubation here is (assuming commons is
> the target) :
>
> - IP clearance (paperwork is done by the way)
> - It contains crypto, so we probably need some legal advice on this
> (currently a discussion on legal
> btw)
> - Making sure Julius is here to stay (so preventing a new dead commons
> project)
> - Getting enough support in commons, so it's not a one man project
Commons is not the issue here. Building a community around the code, within
the ASF, is the issue. Without that, incubation will fail. This is, IMHO,
the single most important criterion for any ASF project.
- Everything takes place on the commons mailinglists (user and dev)
> - Release votes needs to be the same as any other commons component, with
> the addition of an extra
> incubator vote.
> - Reuse of commons infrastructure, probably with the exception of svn (eg
> incubator svn and have
> separate permissions, with the whole of jakarta being able to work there)
Agreed on these last three, with the proviso that they apply to whatever
environment the project might land in after successful incubation, be it
Jakarta or elsewhere.
--
Martin Cooper
Thoughts welcome...
>
> Mvgr,
> Martin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where
should "not-yet-commons-ssl" go?
Posted by Martin van den Bemt <ml...@mvdb.net>.
>>
>> Let's keep this statement your personal opinion on the fact that it is
>> not
>> relevant. I still like to
>> know the opinion of others.
>
>
> If you want opinions, don't use a vote to collect them. This is a vote
> thread, not an opinion thread. Votes within the ASF are for decision
> making,
> not opinion polls. Jakarta is well known, in a negative way, for being
> overly vote-happy, so we should be doing our best to confine our use of
> voting to things that really need to be voted on. That includes neither
> opinion polls or consensus building.
>
> My statement was that the final destination of a project is not relevant
> for
> a vote on whether or not it should be accepted into the incubator. I
> consider that to be a simple fact about the way the incubator works, not an
> opinion.
>
The difference of opinion here is that you see this as a vote about incubating ssl, which is simply
not our call. We can vote however on accepting ssl into Jakarta, which has the consequence that
Jakarta is going to be actively involved as a champion / sponsor role to have the Incubator accept
ssl. Say if the target is commons, we probably should have commons-ssl end up in the website of
commons, have Julius participate on the commons website, instead of having separate lists, separate
website and a separate PPMC and learning the commons way is pretty hard when you are actually not
integrated into the commons community to begin with.
We are talking about around 20 classes here and 1 new committer (afaik). What makes this case
special compared to eg webwork (came across this while wading through the incubator archives to find
similar scenario's) ?
Maybe it's just a different definition of the meaning of full incubation.
Things I want see solved during incubation here is (assuming commons is the target) :
- IP clearance (paperwork is done by the way)
- It contains crypto, so we probably need some legal advice on this (currently a discussion on legal
btw)
- Making sure Julius is here to stay (so preventing a new dead commons project)
- Getting enough support in commons, so it's not a one man project
- Everything takes place on the commons mailinglists (user and dev)
- Release votes needs to be the same as any other commons component, with the addition of an extra
incubator vote.
- Reuse of commons infrastructure, probably with the exception of svn (eg incubator svn and have
separate permissions, with the whole of jakarta being able to work there)
Thoughts welcome...
Mvgr,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should "not-yet-commons-ssl" go?
Posted by Martin Cooper <ma...@apache.org>.
On 2/23/07, Martin van den Bemt <ml...@mvdb.net> wrote:
>
>
>
> Martin Cooper wrote:
> > On 2/23/07, Martin van den Bemt <ml...@mvdb.net> 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 :
> >>
> >> [ ] Jakarta should sponsor (which effectively states we like to see the
> >> code end up here)
> >
> >
> > +1
> >
> > [ ] Jakarta shouldn't sponsor (which effectively means it will end up
> TLP)
> >
> >
> > No, it means that it still needs to find a Sponsor before it can be
> > accepted
> > into incubation. It says nothing about where it will end up after
> > incubation
> > or even if it will start incubation.
> >
> > if accepted in Jakarta, it should end up in :
> >
> >
> > This is not relevant. The final location of a project is not decided
> until
> > it is ready to _exit_ incubation, so it's more than a little premature
> > to be discussing this here.
>
> Let's keep this statement your personal opinion on the fact that it is not
> relevant. I still like to
> know the opinion of others.
If you want opinions, don't use a vote to collect them. This is a vote
thread, not an opinion thread. Votes within the ASF are for decision making,
not opinion polls. Jakarta is well known, in a negative way, for being
overly vote-happy, so we should be doing our best to confine our use of
voting to things that really need to be voted on. That includes neither
opinion polls or consensus building.
My statement was that the final destination of a project is not relevant for
a vote on whether or not it should be accepted into the incubator. I
consider that to be a simple fact about the way the incubator works, not an
opinion.
--
Martin Cooper
Main reason : it is very interesting to see to figure out what the exit
> criteria should be for a small component like ssl (besides the IP stuff).
> Would be nice to get Robert's view on this (I will start a discussion
> after the vote, so the vote
> doesn't get too polluted). Could be that I am the only one seeing the
> difference during incubation
> depending on the target within Jakarta, so if that's the case it's
> probably best for SSL that other
> people step up as mentors and champions.
>
> Mvgr,
> Martin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where
should "not-yet-commons-ssl" go?
Posted by Martin van den Bemt <ml...@mvdb.net>.
Martin Cooper wrote:
> On 2/23/07, Martin van den Bemt <ml...@mvdb.net> 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 :
>>
>> [ ] Jakarta should sponsor (which effectively states we like to see the
>> code end up here)
>
>
> +1
>
> [ ] Jakarta shouldn't sponsor (which effectively means it will end up TLP)
>
>
> No, it means that it still needs to find a Sponsor before it can be
> accepted
> into incubation. It says nothing about where it will end up after
> incubation
> or even if it will start incubation.
>
> if accepted in Jakarta, it should end up in :
>
>
> This is not relevant. The final location of a project is not decided until
> it is ready to _exit_ incubation, so it's more than a little premature
> to be discussing this here.
Let's keep this statement your personal opinion on the fact that it is not relevant. I still like to
know the opinion of others. Main reason : it is very interesting to see to figure out what the exit
criteria should be for a small component like ssl (besides the IP stuff).
Would be nice to get Robert's view on this (I will start a discussion after the vote, so the vote
doesn't get too polluted). Could be that I am the only one seeing the difference during incubation
depending on the target within Jakarta, so if that's the case it's probably best for SSL that other
people step up as mentors and champions.
Mvgr,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should "not-yet-commons-ssl" go?
Posted by Martin Cooper <ma...@apache.org>.
On 2/23/07, Martin van den Bemt <ml...@mvdb.net> 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 :
>
> [ ] Jakarta should sponsor (which effectively states we like to see the
> code end up here)
+1
[ ] Jakarta shouldn't sponsor (which effectively means it will end up TLP)
No, it means that it still needs to find a Sponsor before it can be accepted
into incubation. It says nothing about where it will end up after incubation
or even if it will start incubation.
if accepted in Jakarta, it should end up in :
This is not relevant. The final location of a project is not decided until
it is ready to _exit_ incubation, so it's more than a little premature to be
discussing this here.
[ ] 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
> [X] No interest in getting involved.
--
Martin Cooper
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
>
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where
should "not-yet-commons-ssl" go?
Posted by Roland Weber <ht...@dubioso.net>.
Since there is no stated end date to this vote: Please let
it (or it's replacement) run until at least March 4th.
Oleg will be working through a mail backlog that week-end.
If this vote thread should be replaced next week, I will not
be able to re-cast my vote until the week-end of March 10/11.
> [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)
> [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!)
> [ ] I am willing to mentor (you need to be on the Incubator PMC / Member of the ASF)
> [ ] I want to get involved in coding
> [X] No interest in getting involved.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote]
Where should "not-yet-commons-ssl" go?
Posted by 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
[VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where
should "not-yet-commons-ssl" go?
Posted by Martin van den Bemt <ml...@mvdb.net>.
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 <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
Re: [vote][conclusion] Re: [Vote] Where should "not-yet-commons-ssl"
go?
Posted by Martin van den Bemt <ml...@mvdb.net>.
Martin van den Bemt wrote:
> Not a vote result, since it is just a conclusion from my side.
>
>
> <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>
Correction : the sponsor will be the incubator PMC in this scenario.
Mvgr,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
[vote][conclusion] Re: [Vote] Where should "not-yet-commons-ssl"
go?
Posted by Martin van den Bemt <ml...@mvdb.net>.
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/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
Re: [Vote] Where should "not-yet-commons-ssl" go?
Posted by Martin Cooper <ma...@apache.org>.
On 2/23/07, Julius Davies <ju...@gmail.com> 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:
>
> [] Sub-module in Httpcomponents.
IMO it would have to pass through incubation before this could happen
anyway.
[] Sandbox.
The sandbox is open only to ASF committers. IIRC, you're not (yet) a
committer.
[+1] Full Incubator.
+1. IMO this is the correct and appropriate path.
--
Martin Cooper
[-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.
>
Re: [Vote] Where should "not-yet-commons-ssl" go?
Posted by Ortwin Glück <od...@odi.ch>.
[+1] Full Incubator.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org