Justin Erenkrantz wrote:
--On Friday, January 24, 2003 16:58:01 -0700 David Waite
I assume all of these should be in the servers file. Other than names
above, there are a couple of issues I'm seeking feedback on:
I think the CA options you have listed would be system wide rather
than per server. But, that's me.
I assume that they will be put into the servers 'default' section, which
makes them pretty much ra_dav-wide, but allows you to selectively
override options, especially when it comes to ignoring certificate problems.
- should ssl-authorities-file have a default if not specified? If so,
what should this be across platforms?
Yes, I think so. ~/.subversion/certs/ sounds like a reasonable
starting point (I believe OpenSSL supports pointing at a directory and
adding all of the .pem's to its internal list).
Perhaps you could do some registry entries on Win32, but I've seen
Brane starting to mumble that Win32 should have a ~/.subversion/ dir
anyway. I'd defer to whatever the Win32 crowd says...
I think I will just defer having a default for the time being, then.
- should ignore-ssl-host-mismatch allow you to specify an alternate
hostname to match against the server certificate CN?
I don't think so. An 'alternate-ssl-host-name' per-server option
might be sufficient rather than wrapping it in the
- should there be prompting on the above errors?
My hunch is no, but it should print out a warning at the very least.
Perhaps the host mismatch should at least produce a prompt the first
time (thinking of how OpenSSH does this when there is a mismatch).
The rest of them aren't as 'fatal.' (It's out-of-date or the CA is
unknown isn't the end of the world and probably is worth a warning if
From a security standpoint, they should all be 'fatal' and require
manual overriding. My install of OpenSSH client will give a failure on
host mismatch and tell the user to edit the known_hosts file with the
new cert, or to delete it at their own risk.
Eventually it might be nice to have the OpenSSH client behavior of
pulling in unknown certificates, but this may be difficult due to the
heirarchial nature of SSL certificates.
I would also probably suggest that you do this on a branch rather than
doing it in a cave. But, that's me. =) Earlier feedback would be
better, I think. -- justin
I would need access to a branch to do that, but other than that its fine
:-) I will hopefully have the server certificate validation portion
workable soon, and can post a patch to the list for evaluation. For the
client certificate authentication work, I am sorta blocked on svn_auth,
and wouldn't want to create a branch while that is still rapidly evolving.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Oct 14 02:16:26 2006