Can't get rid of seahorse

Help
1

Hello all,

I’ve recently found that when trying to push/pull to git, seahorse is being used to capture my username/password, rather than whatever more helpful tool was appearing before. I’ve not consciously changed any settings to have this happen, and I can’t seem to make it stop. To make matters worse, it uses https rather than ssh, which git has just now disallowed. On this last point, I’m sure this is configurable, but I’d rather not learn how to configure a program that I never invited in in the first place. I have the following in my configuration.nix:

  services.xserver.displayManager.gdm.enable = true;
  services.xserver.desktopManager.gnome3.enable = false;
  programs.seahorse.enable = false;  
  services.gnome3.gnome-keyring.enable = false;

  # Askpass
  programs.ssh.askPassword = "${pkgs.x11_ssh_askpass}/libexec/x11-ssh-askpass";

which you would think might make things quite unambiguous that seahorse hasn’t been invited to the party.

However, when I do echo $SSH_ASKPASS, I get /nix/store/s0syfivjsnrkwk0xl750k3s4smif8sa9-seahorse-40.0/libexec/seahorse/ssh-askpass. I can’t see where this is even being set - I’ve tried to grep for it in my config but get nothing.

Probably the mature response at this point is to just get used to using seahorse, but I’m feeling a little aggrieved about having it show up uninvited and first I’d like to try to just get rid of it. Can anyone offer any suggestions?

Thanks in advance!

2

To correct myself, the decision to use https vs ssh is set in the individual repo’s .git/config file and isn’t really seahorse’s fault (some things aren’t). Switching the repo config to use ssh basically fixes everything I’m complaining about here. Seahorse continues its unwelcome existence on my system but I can live with that.

3

The snippet you have shown is obviously system configuration, do you use some other way to manage your user environment?

4

what was the name of this tool?

5

I use home-manager. I can’t see anything in the configuration for that which would cause this, though.

6

I’m not sure. But it looks like this:
image

7

Can you do a grep over your HM configuration? Looking for seahorse and askpass, ignoring case (-i).

8

Sure - they both return no results at all, though.

9

can you run

 xprop _NET_WM_PID | sed 's/_NET_WM_PID(CARDINAL) = //'

and click on the window? :slight_smile:

10

I just tried this (without having any idea what it does) - no window appears, though. It didn’t complete but it also didn’t seem to do anything - I Ctrl+C’ed it after a few seconds.

11

Sorry, seems like I shut it down too early - it did eventually finish with

48355
direnv: error LoadConfig() Getwd failed: getwd: no such file or directory
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory```
12

sorry, i wasn’t exactly clear… this will sum it up.

:slight_smile:

sorry, even a robot from the future can things wrong from time to time.

13

I’m a bit confused by the direnv output here…

Do you have a top-level .envrc or did you run the command from within a direnv environment?

14

Right, gotcha, thanks. That’s a useful command! The program in question - the one that’s not seahorse - seems to be called pinentry.

15

That was just me not understanding how to use the xprop command - please see my other comment just now.

2 Likes
16

What does running nixos-option programs.ssh.askPassword output? It should tell not only its current value, but also where it was defined. In this case I would expect it to say:

...
Defined by:
[ "/etc/nixos/configuration.nix" ]
1 Like
17

Thanks for the response. It is defined in configuration.nix, and interestingly, its value is .../libexec/x11-ssh-askpass. However, the SSH_ASKPASS environment variable is still pointing to seahorse.

18

I struggled with this for far too long. I was trying to push to a self-hosted gitea repo.

My issue was in my repo’s .git/config. Under the [remote “origin”] section, the url was incorrectly set to use http, and was using my gitea login instead of the default user “git”. Setting it to the following got rid of the annoying “suppress prompts” thing:

url = ssh://git@[hostname]:2222/[user_name]/[repo_name].git

I think at some point I’d modified some settings via the repo’s gitea dashboard, and that got everything all hosed up.

Posting this just in case some other poor soul struggles with this annoyance as much as I have for the past week.