Dear Wiki user, You have subscribed to a wiki page or wiki category on "Incubator Wiki" for change notification. The following page has been changed by JuliusDavies: http://wiki.apache.org/incubator/CommonsSSLProposal The comment on the change is: looking more like a proposal now ------------------------------------------------------------------------------ developer can now create a single isolated SSL``Socket``Factory very easily (SSL``lient extends SSL``Socket``Factory). - SSLClient client = new SSLCLient(); + SSLClient client = new SSLCLient();M [Notice how we're borrowing from Http``Client's own usage pattern: Http``Client client = new Http``Client();] @@ -132, +132 @@ {{{ #!java + SSLClient client = new SSLCLient(); + char[] pwd = "secret".toCharArray(); client.setCheckHostname( false ); @@ -143, +145 @@ client.setKeyMaterial( new KeyMaterial( "/path/to/key.pem", "/path/to/certs.pem", pwd ) ); }}} + = Current Status = + + == Meritocracy == + + So far it's just been Julius committing whenever he likes. + This has been convenient to try and get the library into a useable state. + The library has good coherency partly because only one person has been + working on it so far. But on the other hand, SSL is touchy stuff, and + it needs eyes looking at it. We will never be able to declare that + "yes, this library doesn't compromise your security" without more committers + on board. + + There is a lot of Java-SSL expertise spread around Apache: Tomcat, Commons-Net, + HttpComponents, Synapse, Directory (recently looking into STARTTLS!) + are just five examples that immediately spring to mind, and of course there + are many, many more. Hopefully the SSL experts on some of these projects will take an + interest in Commons-SSL. + + == Community == + + The community is very new, but they are enthusiastic. A "not-yet-commons-ssl" + mailing list was started on January 5th off of juliusdavies.ca, and already within + 2 months, out of 10 subscribers so far, three are quite active and helpful. + + There is a good relationship with the BouncyCastle project. + + There is a strong relationship with the HttpComponents team. Julius tries + to float design ideas by httpcomponents-dev. The recent 0.3.7 release of + not-yet-commons-ssl was done primarily to provide support for the new httpcomponents + NIO-SSL module. + + It's probably a coincidence, but "SSL and Java" related queries on the OpenSSL-User mailing list + have completely disappeared since the library was announced on that list. SSL related questions + seem to have diminished on the HttpClient-User list as well. + + We're currently averaging 150 - 200 downloads a month (from 150 - 200 unique IP addresses). + + + == Core Developers == + + Definitely a weak spot with Commons-SSL right now. There's only Julius, + with input on the mailing lists coming mostly from Roland and Oleg, + and recently also from Mike Ressler and Steve Davidson. + + + == Alignment with existing Apache subprojects == + + Here's where Commons-SSL is very strong. It's actually allowing all + these server-socket-creating Java applications so point to the Apache + httpd TLS FAQ! + + http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#selfcert + + We're actually bridging an old split, between OpenSSL + and Sun's Java, perhaps like the Pope's visit to Turkey? + + In terms of code use: we're using code from directory.apache.org, + we've also using code from commons-codec. In terms of helping other + projects: Commons-SSL has lots of hooks in place for HttpComponents and + anyone who uses SSLSocketFactory or SSLServerSocketFactory can drop + Commons-SSL into their project quite seamlessly. + + I think Commons-SSL would be good for many open-source projects. Here + are a few ideas: + + http://jtds.sourceforge.net/ + http://telnetd.sourceforge.net/ + http://directory.apache.org/ (to help when being an ldaps:// server) + http://tomcat.apache.org/ (so support APR-SSL config when APR isn't around) + + That's just the server side. It's very handy on the client side, too. + Already three open source projects (that I know of) are using + Commons-SSL: + + http://xfire.codehaus.org/HTTP+Transport + http://www.soapui.org/ + http://www.bedework.org/ + + The library recently appeared in Shibboleth's source tree, but I can't find any use of it! + + http://svn.middleware.georgetown.edu/view/trunk/lib/?root=java-xmltooling + + = Known Risks = + + == Orphaned products == + + The main developer has been supporting users on the httpclient-user mailing list for 2 years. + He's been supporting the Commons-SSL library for 9 months so far, issuing regular releases + along the way. Commons-SSL is not going to be orphaned any time soon, whether incubation + happens or not! + + == Inexperience with Open Source == + + Commons-SSL has been an Open Source project already for 9 months, with mailing-lists + for 2 months. The code was derived from HttpClient code in its "contrib" repository. + The main developer so far has been active on open source mailing lists for 3 years. + + Inexperience with Apache will definitely cause many fumbles on the incubator and + commons-dev mailing lists. This will probably frustrate more experienced committers. + We'll try our best, and remain tenacious. + + == Homogeneous Developers == + + Homogeneity is not really the problem. The problem is lack of developers. But + this is common for small "jakarta-commons" sub-projects. Nonetheless, jakarta-commons + is quite a vibrant part of Apache. + + == Relationships with Other Apache Products == + + The relationship with HttpComponents is strong, and a relationship with Synapse + is just starting. The library seems to be very popular in the web-services world + (SoapUI, XFire), and indeed, webservices is exactly where Credit Union Central of British Columbia + (the original developer) uses the code inside their shop. + + We hope to eventually be the one library everyone in the Java world uses when + doing SSL as a server or client, blocking or non-blocking. + + The library was written particularly with Tomcat in mind. There is currently + no relationship with Tomcat, and more than anything this goal is like a guiding + mirage rather than something that actually matters. The Tomcat goal has helped give the + library a nice shape. The symmetry with SSLServer and SSLClient is pleasing. + + == A Excessive Fascination with the Apache Brand == + + A few people on the current not-yet-commons-ssl mailing list have asked when + this code will become Apache code. The Apache brand is going to help people + feel safer about bringing this SSL security-sensitive code into their shop - + there's no question about that. + + Perhaps there is some excessive fascination with the Apache Brand in this case, + although I like to think the fascination was more with Apache-Jakarta-Commons than + just "Apache". HttpClient is such an excellent library! This SSL code seemed like + a good way to partially return the favour, and Jakarta-Commons seemed like such a + good fit for these 100 java classes. The HttpComponents team was also very + encouraging when Commons-SSL was first announced, and that was exciting. + + By the way, sorry for the original "common-ssl" name. That was an unfortunate + and foolish mistake. + + = Documentation = + + http://juliusdavies.ca/commons-ssl/ + + = Initial Source = + + http://juliusdavies.ca/commons-ssl/download.html + + = Source and Intellectual Property Submission Plan = + + All CLA's and CCLA's submitted and accepted. + + = External Dependencies = + + Compile-time dependencies on HttpClient and Log4J. + + No run-time depedencies. + + Confession: + I did copy & paste Base64 from commons-codec, and ASN.1 parsing from directory.apache.org. + But "java -jar common-ssl.jar" wouldn't work without this, and the library is still under 200 KB. + I hope to move these out once JSR-277 and Java-7 are ubiquitous (probably in 5 - 7 years). + + = Cryptography = + + Yes! + + + + + + + + + + + + + + + + + --------------------------------------------------------------------- To unsubscribe, e-mail: cvs-unsubscribe@incubator.apache.org For additional commands, e-mail: cvs-help@incubator.apache.org