Add support to GNOME Keyring for SVN auth

[edgardmessias]

trafficstars

• VSCode Version: all
• OS Version: linux
• Extension Version: all
• System Language: all
• SVN Version: all

Issue

Run a remote svn command (like svn up) without unlocking the GNOME Keyring

[edgardmessias]

Solution:

• On auth failed, parse all files in ~/.subversion/auth/svn.simple
• Find same server on svn:realmstring
• On each, if passtype is gnome-keyring, run: secret-tool lookup domain {svn:realmstring} user {username} to get password for use in --username={username} --password=****

[edgardmessias]

Solution2: This script unlocks the gnome keyring. Documentation

import gi
gi.require_version('GnomeKeyring', '1.0')
from gi.repository import GnomeKeyring

GnomeKeyring.unlock_sync(None, "password")

To check is locked

GnomeKeyring.get_info_sync().info.get_is_locked()

[daldr-ntml]

The Documentation link in comment of Feb 27 is broken. Did it have instructions on how to use the script?

[edgardmessias]

@DavidA2014 , look http://mindbending.org/en/bending-gnome-keyring-with-python-part-2 to start

[daldr-ntml]

@edgardmessias I think we need something more user-friendly.

[edgardmessias]

@DavidA2014, yes, my idea: create a python script to unlock when svn use a gnome keyring. The question is: How check the SVN use a Gnome Keyring

[Zastai]

I'm slightly confused. I thought the extension used the installed system svn client. The installed system svn client does gnome keyring just fine. So why would you need to go around the client and try to parse its config files to do what it already does? (And potentially less securely, because you might then be passing a password via command line where otherwise it wouldn't have left the process.)

[edgardmessias]

@Zastai, because the gnome keyring only work in subversion when command is interactive mode. Commands called by VSCode are non interactive mode.

Look the file: https://github.com/apache/subversion/blob/trunk/subversion/libsvn_auth_gnome_keyring/gnome_keyring.c

First comment:

/* Return TRUE if the default collection is available and FALSE
   otherwise.  In interactive mode the collection only has to exist to
   be available, it can be locked or unlocked.  The default collection
   will be created if necessary.
   In non-interactive mode the collection is only available if it
   already exists and is unlocked.  Such an available collection can
   be used without prompting.  Strictly this is racy: nothing ensures
   the collection remains unlocked.  A similar issue affects the
   KWallet and original GNOME Keyring providers.
   As a non-racy alternative one could override prompt_async in the
   _SecretServiceClass vtable, the get/set would still fail but there
   would be no prompt and no race.  This "works" but it is not clear
   to me whether it is legitimate since the SecretService is a
   singleton and the effect would be application-wide.
 */

[edgardmessias]

I have a idea, @Zastai @DavidA2014, can paste here the svn log with error?

[Zastai]

OK, I assumed you'd run in interactive mode and attach to stdin/stderr/stdout to deal with interactive prompts. Then the keyring unlock dialog would Just Work(tm).

Anyway, this is what I get when the keyring isn't unlocked yet:

Using svn "1.10.4" from "svn"
[workspace]$ svn info --xml svn-external-1
[workspace]$ svn info --xml svn-external-2
[workspace]$ svn info --xml svn-external-3
[workspace]$ svn info --xml svn-external-4
[workspace]$ svn info --xml
[workspace]$ svn stat --xml --no-ignore --ignore-externals --show-updates
[workspace]$ svn: E170013: Unable to connect to a repository at URL 'https://svn.domain.org/repos/path'
[workspace]$ svn: E215004: No more credentials or we tried too many times.
[workspace]$ Authentication failed[workspace]$ svn info --xml /path/to/current/file/in/editor

(including that lack of line feed after "Authentication failed")

After unlocking the keyring via svn up in a console window, that goes away. I do see there are a lot of svn info's launched for a bunch a files that result in

[some-file]$ svn info --xml
[some-file]$ svn: warning: W155010: The node '/path/to/some/unrelated/directory' was not found.
[some-file]$ svn: E200009: Could not display info for all targets because some targets don't exist[svn-external-3]$ svn stat --xml --no-ignore --ignore-externals --show-updates

(note the lack of linefeed after the error again). Would it not make sense to run a svn ls (for files already on the server) and svn status --xml (for local additions/removals/changes) first, to avoid those errors?

[daldr-ntml]

@Zastai I have created a separate issue for the svn info warnings: #621

[daldr-ntml]

BTW Does anyone have any guidance on how to configure gnome keyring for svn, particularly on a headless Centos system?

[edgardmessias]

@DavidA2014 @Zastai, can test with modified svn-scm-1.54.2.vsix.zip

My idea: when use Gnome Keyring, call a interactive terminal to unlock the Gnome Keyring

Note: The modified version every call terminal

[Zastai]

@DavidA2014 No idea for CentOS, but what I have done for debian (connection via Putty, with X11 forwarding, and a local Cygwin/X server) is:

• configure svn with password-stores = gnome-keyring
• in ~/.bash_login:
  • dbus-update-activation-environment --systemd DISPLAY XAUTHORITY

This is with current Debian (so Gnome 3 and systemd). I know that previously, I had to get pids from envvars and start the keyring manager myself (and then kill it manually at the end of the shell session), but the DBus integration now seems to handle it just fine.

Supposedly, you can set things up via pam as well, with some module that unlocks the keyring automatically as part of login (the way it happens when logging in graphically). I never got that to work (I suppose I could try again at some point; it may work now).

[Zastai]

Ah, found someone who still has the old setup - this is what I used to do, and what may still be needed on some distributions:

In ~/.bash_login:

# Handle some GNOME stuff for ssh+X environments
if test -z "$DBUS_SESSION_BUS_ADDRESS"; then
  # This avoids 'Couldn't connect to accessibility bus' startup warnings for gtk programs (e.g. emacs) under ssh+X.
  export NO_AT_BRIDGE=1
  # Start D-Bus (amongs other things, this enables the use of GNOME Keyring for svn authentication
  # Note: KILL_DBUS_ON_LOGOUT should NOT be exported
  eval $(/usr/bin/dbus-launch --sh-syntax)
  KILL_DBUS_ON_LOGOUT=Y
  # Then start the Gnome Keyring daemon
  (nohup /usr/bin/gnome-keyring-daemon --start --foreground --replace --daemonize --components=secrets >/dev/null 2>&1 &)
  # Starting up the settings daemon activates GTK theming etc.
  (nohup /usr/bin/gnome-settings-daemon >/dev/null 2>&1 &)
else
  echo "D-Bus Already Active"
fi

In ~/.bash_logout:

# End some things we may have started at login
if test -n "$KILL_DBUS_ON_LOGOUT"; then
  # Start by killing the DBUS session (if possible); that stops most other things
  if test -n "$DBUS_SESSION_BUS_PID"; then
    kill "$DBUS_SESSION_BUS_PID" > /dev/null 2>&1
  fi
  # These don't stop by themselves
  /usr/bin/pulseaudio -k > /dev/null 2>&1
fi

[Zastai]

@edgardmessias Yup, that worked. Started up VSCode, I saw the output/terminal window appear, then the Gnome Keyring unlock dialog showed up. After that, things seemed to work as before. Svn log is identical to the one above (same errors etc).

[daldr-ntml]

@Zastai Thanks for your instructions.

As a sanity check, would it be easier to use GPG (GnuPG)? Gnome keyring seems quite hard to configure.

[Zastai]

If you already use gpg-agent, probably. It is my understanding that that does’t persist passwords across sessions though. So if you use multiple repos, you’ll get asked for each of the passwords. With kwallet/gnome-keyring you store all your svn passwords behind a simple unlock (which when using a graphical login is even automatic).