[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 6864 - branches/neon-0.24/subversion/libsvn_ra_dav

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-08-26 20:36:47 CEST

David Waite <mass@akuma.org> writes:

> Just to make the question more explicit - the CA and client
> certificate options are limited by Neon 0.24. I can get PEM support
> in for client certificates by using openssl directly, but IMO it isn't
> worth it. The ssl-authorities-file limitation may be overcome by
> trusting the default CAs (I need to look more into what this really
> does); it may also be possible to support the existing semantics using
> openssl directly.
>
> I'm in favor of reducing options, so always trusting default CAs (if
> possible, and if these can be specified at the machine and user level)
> and only support PKCS#12 formatted client certificates seems like a
> good idea for me. $DEITY knows that there are other options which
> would be useful (such as trusting server certs by thumbprint, a la
> SSH) which will complicate things right back up.

David and I had a chat about this stuff, and here's our conclusions
(and David's list of action-items):

  * svn will -not- be making direct calls to openssl. way too complex.

  * the 'ssl-authorities-file' variable used to point to a file
    containing a list of trusted CAs. But neon doesn't work that way
    anymore; it wants a single CA per file. So David is going to make
    our config variable take a semicolon-separated *list* of
    file-paths. That prevents us from losing functionality when we
    switch to neon-0.24.

  * there's really only one kind of client certificate, but at least
    two different disk formats for them. Neon has dropped support for
    the .pem disk format, so subversion must as well. Not a big deal,
    really. Openssl has tools to convert a .pem file to the one
    format we support (pkcs#12). This means we get to *lose* two
    config variables -- "ssl-client-cert-type", and
    "ssl-client-key-file". And we get to lose an extra cert-type enum
    in svn_auth.h. Yay, smaller code.

Once David makes these changes to the neon-0.24 branch, we can merge
them to trunk and be done with this issue. We should then be fully
neon-0.24 compatible, with no loss of features.

(In a *separate*, future issue, we plan to add new SSL
features... like the ability to cache specific server certs, or the
ability to trust whatever "default trustable CAs" that users may have
installed into their copy of openssl. But that's another topic.)

 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 26 20:42:00 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.