[vote][conclusion] Re: [Vote] Where should not-yet-commons-ssl go?
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 [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
Re: [vote][conclusion] Re: [Vote] Where should not-yet-commons-ssl go?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should not-yet-commons-ssl go?
On Fri, 2007-02-23 at 23:35 +0100, Martin van den Bemt wrote: I prefer this vote to see where it should end up in Jakarta and based on that result the path full incubation / legal incubation is decided. So in my view the vote should be : [x] Jakarta should sponsor (which effectively states we like to see the code end up here) [ ] Jakarta shouldn't sponsor (which effectively means it will end up TLP) if accepted in Jakarta, it should end up in : [x] commons as a component [ ] httpcomponents as a component [ ] subproject directly under Jakarta [ ] integrate / merge code into project xxx (please replace x) (so not a subcomponent of a project!) And [ ] I am willing to mentor (you need to be on the Incubator PMC / Member of the ASF) [x] I want to get involved in coding [ ] No interest in getting involved. Oleg Reasoning : 1) the first decides if Jakarta wants to sponsor this 2) we need to know the place it should end up in Jakarta (at least have some kind of direction) 3) if no one is interested in getting involved or being a mentor (preferably 3 mentors!), we can easily see if option 1 and 2 are viable at all. The problem with the current vote is that I have to start yet another vote to let us sponsor and where it should end up, best to do it in one go in my opninion... So Martin and Ortwin could you please revote ? (Sorry for the inconvenience) Mvgr, Martin Julius Davies wrote: Hi, Jakarta-General, Let's vote on where to put this code! Here's the code right now: http://juliusdavies.ca/commons-ssl/ Forgive my newbieness; I hope these are the right options: [+1] Sub-module in Httpcomponents. [+1] Sandbox. [+1] Full Incubator. [-1] not-yet-commons-ssl is not a good project for Apache because... I'm fine with majority rules, assuming there are no -1 votes. Some background: http://wiki.apache.org/jakarta/JakartaBoardReport-February2007 The code grant for the not yet commons SSL (formerly named commons-ssl), has been completed, so we can progress to having a vote where SSL should end up on general and based on that result take the correct incubator path (legal / full incubation). Let's just get this vote out of the way, and then we can move on to other issues in the appropriate venue (HttpComponents, or Sandbox, or Incubator). My original proposal to jakarta-general about the project is here: http://www.mail-archive.com/general@jakarta.apache.org/msg12790.html Yesterday I released not-yet-commons-ssl-0.3.7. Changes described at the bottom of this email. My intention is for 0.3.7 to be the last release outside of Apache. By the way, there's one undocumented feature of common-ssl that's been quite fun: http://juliusdavies.ca/commons-ssl/javadocs/org/apache/commons/ssl/OpenSSL.html :-) yours, Julius ps. My vote is: [+0] - Abstaining because I'm too much of a newb to really understand what I'm voting for. On 2/23/07, Oleg Kalnichevski [EMAIL PROTECTED] wrote: On Thu, 2007-02-22 at 10:20 -0800, Julius Davies wrote: not-yet-commons-ssl-0.3.7 released! http://juliusdavies.ca/commons-ssl/download.html Hi Julius, What are your plans regarding not-yet-commons-ssl? Is there anything still blocking the incubation process? There are already two Apache projects (HttpComponents and Synapse) that can potentially benefit from collaboration with not-yet-commons-ssl. So, there is a lot of interest in seeing things moving forward. Oleg Features as of not-yet-commons-ssl-0.3.7: 1. useStrongCiphers() used by default. - 40 bit and 56 bit ciphers are now disabled by default. To turn them back on call useDefaultJavaCiphers(). 2. addAllowedName() adds some flexibility to the CN verification. - Here's a code example using cucbc.com to connect, but anticipating www.cucbc.com in the server's certificate: SSLClient client = new SSLClient(); client.addAllowedName( www.cucbc.com ); Socket s = client.createSocket( cucbc.com, 443 ); This technique is also useful if you don't want to use DNS, and want to connect using the IP address. 3. SSLServer can re-use a Tomcat-8443 private key if running from inside Tomcat. - SSLClient server = new SSLServer(); server.useTomcatSSLMaterial(); 4. RMI-SSL support improved. - Attempts to re-use the Tomcat-8443 private key for all RMI SSL Server sockets. Anonymous server-sockets (port 0) will always be set to port 31099. Analyzes the server certificate CN field and tries to set java.rmi.server.hostname to
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should not-yet-commons-ssl go?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should not-yet-commons-ssl go?
On 2/24/07, Martin van den Bemt [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should not-yet-commons-ssl go?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Where should not-yet-commons-ssl go?
On 2/23/07, Julius Davies [EMAIL PROTECTED] 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?
[+1] Full Incubator. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Where should not-yet-commons-ssl go?
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 [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
Re: [Vote] Where should not-yet-commons-ssl go?
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 [EMAIL PROTECTED] 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 [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
[VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should not-yet-commons-ssl go?
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.
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should not-yet-commons-ssl go?
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 [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.
[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 [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
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should not-yet-commons-ssl go?
On 2/23/07, Martin van den Bemt [EMAIL PROTECTED] 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?
Martin Cooper wrote: On 2/23/07, Martin van den Bemt [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should not-yet-commons-ssl go?
On 2/23/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Martin Cooper wrote: On 2/23/07, Martin van den Bemt [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
