Status of issue2489 branch and the gnome-keyring feature

Hi, just wanted to give an update on this branch and what we have
learned so far in managing and providing builds from it to a customer.
 This email will also pave the way for some patches that will be
forthcoming to the Gnome keyring support.

First off, using merge tracking to manage this has worked really well.
 Basically, the branch tracks the 1.5.x branch for its baseline. All
customizations are coming from revisions that are being selectively
merged from trunk. When 1.5.2 came out, it was as simple as synching
with the branch to keep it up to date with the main releases. I think
we knew this was a scenario that was ideally suited for the design of
merge tracking, but it is still good to see it work properly.

Maintaining a custom branch and providing builds to a customer has
been very beneficial to this feature. There are all sorts of problems
with this general feature that this process has revealed. I suspect
these problems would have all made it to 1.6.0 final release had we
not gone through this process, as it gave us a chance to see how users
really wanted to use this feature in the wild. So here are some of
the things we have found:

1. The feature initially required fairly up to date dependencies. I
know Senthil and Arfrever have been playing ping pong with some fixes
in this area, but I believe we have the feature now working fine with
out of the box RHEL 4 level dependencies. That is a pretty good
baseline to hit.

2. The feature as it currently exists, only really works for a local
desktop running Gnome in X. Our customer wants it to also work in an
SSH terminal to a remote *nix workstation. We pretty much have this
working now. There will be one or more patches coming to help, but
here is what you have to do:

In the remote terminal session:

$ eval `gnome-keyring-daemon`
$ export GNOME_KEYRING_SOCKET
$ export GNOME_KEYRING_PID

There is a third export related to DBUS if gnome-keyring is >= 0.7.9.11

These commands essentially startup the gnome-keyring in your remote
SSH terminal. Currently there is a problem when you go to use it in
that there is no UI to prompt you to unlock the keyring if it is
locked. So we have a patch coming for SVN where the CLI can prompt
you to unlock a locked keyring. It will be helpful if we can get some
review and suggestions on the best way to properly implement this in
SVN. Alexander Thomas will be providing a patch for this.

There is a remaining issue and that is that you must actually have a
keyring created, which may not be the case. For now, CollabNet plans
to create some command line tools to do this and we will package those
tools with our RPM's. In theory, SVN could create a keyring for you
if the daemon is running and you do not already have a keyring. This
seems more controversial to live inside SVN, so for now we are going
to use an external tool. In a GUI, you do get prompted to create a
keyring, but it is the GNOME GUI that does all of this. For whatever
reason, they do not provide anything that works in a console. So we
are planning to create a set of command line tools to create a
keyring, change its passphrase, lock a keyring, and possibly one to
set the default keyring.

With these changes, SVN users get safe storage for all of their
passwords and SSL certificate passphrases, even when running with just
a plain console.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org