Add support to GNOME Keyring for SVN auth

[edgardmessias]

• 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