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
Stephane QUIN/BPSS/FR/EUROPE/GROUP est absent(e).
Je serai absent(e) du 23/02/2007 au 27/02/2007. I will be out of the office starting 23/02/2007 and will not return until 27/02/2007. I will answer your message when I will be back. For ACET or Eurocomfort issues, please contact PARIS BP2S GLM SUPPORT. For any other urgent query, please contact Martin Smith (x24606). This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[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]
