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

Re: [PATCH] Upgrade svn to use neon 0.19.2 & fix #625

From: Blair Zajac <blair_at_orcaware.com>
Date: 2002-02-20 01:18:36 CET

Alex Holst wrote:
>
> Quoting William Uther (will=subversion@cs.cmu.edu):
> > On 19/2/02 6:42 PM, "Blair Zajac" <blair@orcaware.com> wrote:
> >
> > > This patch replaces the previous one to neon 0.19.1.
> >
> > Hi,
> > In the following callback function, should the user be warned? I'm just
> > wondering if there should be a message: "The server seems to have an invalid
> > SSL certificate. Connecting Anyway.\n".
>
> Suggest that this produces a similar warning to OpenSSH's "changed hostkey"
> detection, and that it be made a user option which by default prevents
> the user from connecting to an SSL repository with an invalid cert.
>
> /* The host key has changed. */
> fp = key_fingerprint(host_key, SSH_FP_MD5, SSH_FP_HEX);
> error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
> error("@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @");
> error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
> error("IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!");
> [..]

I just tested neon against a self-signed cert and it called the svn callback.
I'm guessing a lot of people would use self-signed certs for their own development
use. So having something that would work with this situation and not complain
all the time would be useful.

If we get a bad cert, then we can ask if the user wants to abort for the
connection, accept the certificate for this one time, or accept it forever.
If the cert if accepted forever, then we can save it and use it compare
against the server cert next time we connect to it. If they differ then, then
we also print a large warning.

Where would the server cert would be saved though?

Blair

-- 
Blair Zajac <blair@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:09 2006

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.