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

Re: "Locked" messages useless

From: Daniel Rall <dlr_at_collab.net>
Date: 2005-11-01 23:59:52 CET

On Tue, 01 Nov 2005, Julian Foad wrote:

> Greg Hudson wrote:
> >On Sun, 2005-10-16 at 16:43 +0100, Philip Martin wrote:
> >
> >>>svn: Path '/trunk/sprints/Sprints.mdb' is already locked by user 'iar'
> >>>in filesystem 'C:/Daten/svnroot/myrepo/db'
> >
> >>When using http:// the repository location will get stripped from the
> >>error message as a security measure. Perhaps svnserve should be doing
> >>the same?
> >
> >I'd say that this error message should not be using the filesystem
> >location in the first place.
> I think I agree. Callers, at least up to the level of svn_repos_fs_lock(),
> know what filesystem they are accessing, so if they want to add this
> information to any error that is returned, they can.
> So, I vote for removing the path to the repository filesystem from all of
> the error messages in subversion/libsvn_fs_{base,fs}/err.c
> Opinions?

The route that has been taken in other places is not to remove
information from the error's message, but to filter out info from or
replace messages which contain possibly sensitive info at the
appropriate layer (see mod_dav_svn for an example). I prefer this
approach on the principle that error messages should always be
self-sufficient, and contain as much context as they have available to
them when the error is encountered. The fact that a caller may (or
may not) have this context available is something I prefer not to have
to consider. Instead, we have today's situation, which while isn't
always convenient, is not unreasonable, either.

> (While we're on the subject, shouldn't those two "err.c" files be unified,
> given that only about 2 of the 25 functions differ at all between them?)

Yes, I think there's some consolidation that can take place. I too
noticed quite a bit of similarity between the two FS backends while
originally looking into this issue.

Daniel Rall
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 1 23:58:44 2005

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