extension throws exception when doing "hg pull" over ssh

Issue #21 wontfix
Anonymous created an issue

When I use mercurial extension on my machine and do "hg pull" from a password protected repository, things are great.

However, if I "ssh" into the machine and do an "hg pull" I get the exception in the attachment. I use gnome-shell (Fedora 17) and gnome-keyring, so perhaps the keyring isn't accessible from an ssh session, but at least the extension should fall back to the normal password prompt.

Comments (4)

  1. Marcin Kasperski repo owner

    Let me first confirm what you are doing:

    a) you have some desktop machine, let's call it workmachine

    b) you have mercurial_keyring enabled on it (and it works properly when you are sitting on the machine)

    c) you sit on some other machine, open text session - via ssh in this case, but I believe the problem would look similar if you telnet-ed or used any other text session):

    ssh workmachine

    and within this session try to hg pull or hg push to password protected repository:

    cd some/where
    hg pull passwdprotectedremote

    That means, that while you execute this hg pull/push, gnome keyring is not available (as Gnome is likely not running, or even if running, not connected to current session).

    In normal case keyring (the library below mercurial_keyring) should pick some other keyring backend in such a case (likely the simple encrypted text backend). Did you configure your keyring to always use Gnome (via ~/.keyringrc maybe)?

    PS I'd like not to fall back within mercurial keyring (extension) code as «finding some usable keyring backend» is the competence of keyring (the library), mercurial keyring is just a trivial glue binding one with another. So it would be better to patch it on keyring library level.

  2. Brian Anderson

    (I'm the original reporter FYI, just created an account)

    Yes you have the scenario correct. I do not have a .keyringrc file and no alternate keyring as far as I know of.

    I can understand your desire to get it fixed in the library, but from a mercurial user point of view, if the keyring library has a problem then a reasonable fall back would be to announce the problem and then offer to complete authorization using the standard mercurial prompt; sort of like when ssh can't find a valid key in ~/.ssh and then falls back to password authentication as the final attemp.

  3. Marcin Kasperski repo owner

    I disagree with opinion above. mercurial_keyring can't blindly eat errors as knowledge about them is frequently necessary to reconfigure the system or fix some code here or there.

    Keyring library could probably use better ways of picking default backend considering the circumstances, but that is out of „my area”. After all note, that it is keyring library what is reasonably comples piece of code expected to properly guess/prioritize backends, handle their configurations etc, mercurial_keyring is just a glue connecting keyring to mercurial.

  4. Log in to comment