Philip Martin wrote on Fri, Feb 03, 2012 at 10:38:49 +0000:
> Daniel Shahaf <danielsh_at_elego.de> writes:
>
> > Philip Martin wrote on Fri, Feb 03, 2012 at 10:02:06 +0000:
> >> Julian Foad <julianfoad_at_btopenworld.com> writes:
> >>
> >> > * Brings kwallet to the same behaviour as Gnome keyring.
> >>
> >> I've realised there is another difference in the current behaviour. The
> >> way auth works is that Subversion records whether a particular provider
> >> was used to store a particular password. The KDE provider will only
> >> prompt to open the wallet when the auth data indicates that KDE was used
> >> to store a particular password. The GNOME provider prompts to unlock the
> >> keyring whenever any password is requested, before checking the auth
> >> data to see if this particular password was stored in the keyring.
> >>
> >> I don't see any advantage to the GNOME behaviour, it looks more like a
> >> bug than a feature.
> >
> > That behaviour is defensible. "Why should any random app I run know
> > what passwords my keyring stores?"
> >
> > Compare how Subversion does not disclose the names of directories one
> > doesn't have read access to.
>
> Subversion does send the top-level names of trees that are excluded.
>
Mike patched mod_dav_svn recently not to do that. See for example
https://svn.apache.org/repos/infra/
(which has an 'infrastructure' child that isn't disclosed)
> Even without that I'm not sure I understand. The user can also try
> arbitrary names and get "access denied"; that would be similar to the
> user trying arbitrary URLs to see whether it caused the keyring to be
> unlocked.
Or to someone trying many usernames and seeing which of them cause the
server to prompt for a password, instead of an immediate "No such
username" error. (The equivalent here would be to issue a password
prompt even for nonexistent usernames tried.)
*shrug*. All I'm saying is that it's done, and it's defensible.
I don't want to get into an argument about which behaviour is more
correct or more secure.
>
> --
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com
Received on 2012-02-03 11:53:10 CET