Philip Martin wrote on Fri, Feb 03, 2012 at 12:59:47 +0000:
> Daniel Shahaf <danielsh_at_elego.de> writes:
>
> > *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.
>
> There are so many switches that interact it's hard to know what
> constitutes correct behaviour.
>
> Suppose I have a password stored on disk. If kwallet is enabled
> Subversion will use the disk password, I won't get prompted and the
> password will remain stored on disk. If gnome-keyring is enabled I get
> the prompt to unlock the keyring but the password itself gets read from
> the disk and doesn't get stored in the keyring. So despite the user
> interaction with the keyring the password remains stored on disk, that's
> a bit odd.
>
> Worse, if I add --non-iteractive to command then kwallet will still use
> the password cached on disk without prompting. However gnome-keyring
> will error out because it is unable to prompt for the keyring. The
> error message is "Could not authenticate to server" with neon and "GNOME
> Keyring is locked" with serf and svnserve. That's despite the fact that
> the passowrd is on disk. I suppose we could argue that this is a
> configuration error on the part of the user.
Well, we could, had gnome-keyring not been enabled by default.
(For example, on Debian I'd run into the 'Password for (null) keyring'
issue when using the system's svn, despite never having enabled the
keyring or otherwise interacted with it; so I resorted to using my
self-built svn. I suppose that proactively disabling the keyring daemon
from starting would have worked too.)
>
> --
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com
Received on 2012-02-03 14:10:01 CET