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

Re: --non-interactive and keyrings

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Fri, 03 Feb 2012 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.

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

uberSVN: Apache Subversion Made Easy
Received on 2012-02-03 11:39:37 CET

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