[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: Greg Stein <gstein_at_lyra.org>
Date: 2002-02-20 21:59:02 CET

On Tue, Feb 19, 2002 at 10:51:52PM -0800, Blair Zajac wrote:
> Ben Collins-Sussman wrote:
> > Blair Zajac <blair@orcaware.com> writes:
> > > 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?

A user's home directory somewhere. Storing it into the working copy is
insufficient. If they check out a brand new working copy, then they want to
reuse their previous information.

I would suggest that we begin to consider implementing ~/.subversion/ (note
that we don't want it to be ~/.svn because of conflicts; .svnrc is normally
a file, not a dir; so I suggested the full spelling).

Inside that directory, we can create a subdir named 'server-certs' and place
the certs into files in there. I'm not sure what canonical name to use for
the files. Does a cert have an internal name? Would that be an appropriate
name? (I haven't thought this one through yet)

The client cert would also go in ~/.subversion/, maybe as client.crt or
something. However, I can imagine a case where a client has multiple certs,
used for a bunch of different projects. So client-certs/ might be needed.

Note: there is still a good amount of infrastructure that needs to be
written in SVN to support client and server certs.

> > In the same place we save the username and password: in .svn/auth/, no?

Nope. Potentially, a user would have to verify that cert for N different
auth directories (depending upon the pattern of checkout/update).

> This looks like the right way to go, but a fair amount of work. How about
> the patch be applied as is and we can add the cert checking code later.

The original *intent* of the patch was "get this working, fix later." So
yes, of course, it should be applied. Some knee-jerk to blindly accepting
certs set off this thread, when the intent was "we obviously don't have a
solution yet, but let's get Neon upgraded, at least."


Greg Stein, http://www.lyra.org/
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.