incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Incubator Wiki] Update of "CommonsSSLProposal" by JuliusDavies
Date Sat, 10 Mar 2007 06:31:58 GMT
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


Mime
View raw message