> -----Original Message-----
> From: Mark Phippard [mailto:mphippard_at_collab.net]
> Sent: Wednesday, December 17, 2008 2:30 PM
> To: Arfrever Frehtes Taifersar Arahesis
> Cc: alexander_at_collab.net; dev_at_subversion.tigris.org
> Subject: Re: [PATCH] unlock gnome-keyring
> 2008/12/15 Mark Phippard <markphip_at_gmail.com>:
> > On Sun, Dec 14, 2008 at 7:32 PM, Arfrever Frehtes Taifersar Arahesis
> > <Arfrever.FTA_at_gmail.com> wrote:
> >> 2008-12-12 06:33 Alexander Thomas <alexander_at_collab.net> napisał(a):
> >>> Here is a patch which try to address a Subversion issues with gnome
> >>> keyring support. Present implementation of gnome-keyring fails to
> >>> a locked keyring and if there is no X present.
> >>> This patch, try to unlock the keyring by prompting the user for
> >>> password only if the default keyring is locked.
> >> Could you write steps to reproduce "a locked keyring"?
> > 1) Turn on computer
> > No more steps. A keyring is locked until you unlock it. Since
> > gnome-keyring only provides a GUI for this operation if you are
> > working via an SSH terminal to a Linux system (without X) then there
> > is no way to use an unlock your keyring without this patch.
> > Without this patch the feature was useless except for users that are
> > running Linux on their local graphical workstation. Even those users
> > were not able to use the feature if they also use SSH to work on
> > remote systems.
> > With this patch, you just need to do this when you login to your SSH
> > $ export `gnome-keyring-daemon`
> > This starts the keyring and exports the environment variables used by
> > the feature. SVN then has the code to detect your keyring is locked
> > and prompts you to unlock it so that it can retrieve your passwords
> > etc.
> Does anyone have any feedback for Alex on this? Should I just ask
> Senthil to commit it as is?
> We need this functionality in SVN 1.6. The gnome-keyring feature is
> only useful in one very specific situation without it. With this
> patch, the gnome-keyring feature works very well and can be used to
> store passwords securely even when there is no X environment
> I'd rather not have to maintain a special 1.6 branch to hold this code.
I replied on the final commit as I didn't review this mail before it was committed.
The patch adds a console prompt to a library, which we should never do. We designed our entire authentication library to use prompt handlers and we should/must use such handlers here as well.
Our library should /never/ directly communicate to the user without allowing a library user to at least override this behavior. But in almost every case the library user (=subversion client application/integration) should just provide a prompt implementation.
I see this as a 1.6 blocking issue, for the reasons mentioned above.
Received on 2008-12-31 10:51:07 CET