Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#47288 - [ksshaskpass] 5.4.3-1 conflicts with x11-ssh-askpass (seahorse)

Attached to Project: Arch Linux
Opened by Moabit (Moabit) - Monday, 07 December 2015, 00:15 GMT
Last edited by Antonio Rojas (arojas) - Tuesday, 22 December 2015, 22:30 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Gaetan Bisson (vesath)
Jan Alexander Steffens (heftig)
Antonio Rojas (arojas)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No


I have plasma-meta 5.4-2 installed, which depends on ksshaskpass 5.4.3-1. I'm using gnome-keyring to store passwords for mutt and associated command-line utilities. AFAIK the only way to manage the keyring is via seahorse [1].

Seahorse conflicts with ksshaskpass. Hence, I would have to uninstall plasma-meta in order to install seahorse and manage Gnome Keyring.

Seahorse (3.18.0-1) and ksshaskpass both provide x11-ssh-askpass. However, ksshaskpass also conflicts with x11-ssh-askpass. I can see no file conflicts. Is it okay to just remove this conflict?

This task depends upon

Closed by  Antonio Rojas (arojas)
Tuesday, 22 December 2015, 22:30 GMT
Reason for closing:  Fixed
Additional comments about closing:  Dropped SSH_ASKPASS from ksshaskpass, seahorse, x11-ssh-askpass, openssh-askpass
Comment by Antonio Rojas (arojas) - Monday, 07 December 2015, 01:32 GMT
The conflict is not because they install the same files, it's because they both set the SSH_ASKPASS env variable. Whether this is something that packages should do in Arch instead of letting users deal with it themselves is questionable, though. But it's something that should be solved for all ssh-askpass packages, not only this one.
Comment by Moabit (Moabit) - Monday, 07 December 2015, 01:44 GMT
Thanks Antonio. It's good to know that I can install both in the meantime, if I remove the seahorse script ( I had a few ideas for the longer term:
* Notify users that they should manually set SSH_ASKPASS (as you say).
* Bundle a small script, similar to `archlinux-java`, that sets SSH_ASKPASS.
* Set it according to the current DE (but this is perhaps too prescriptive).

Also, I forgot to add the link, but I originally asked in the forums. Apparently I'm not the only one that would like to install both.
Comment by Moabit (Moabit) - Monday, 07 December 2015, 03:02 GMT
FWIW in this case, ksshaskpass's script ( runs before seahorse's script ( The former sets SSH_ASKPASS, while the latter only sets SSH_ASKPASS if it's not already set. Hence, in this case, my SSH_ASKPASS was left assigned by ksshaskpass.

I built and installed ksshaskpass without the conflicts, and installed seahorse in parallel. This appears to be working perfectly so far.
Comment by Antonio Rojas (arojas) - Monday, 07 December 2015, 10:23 GMT
Adding maintainers of other ssh-askpass packages for opinions. IMO we should not set SSH_ASKPASS in packages and remove all conflicts (this is Arch after all). If others don't agree, another option would be to split the ssh-askpass part out of seahorse, so it's possible to install it together with other ssh-askpass packages
Comment by Jakob Gruber (schuay) - Monday, 07 December 2015, 12:25 GMT
What about keeping the conflicts but

1) having each askpass package provide 'ssh-askpass', and
2) depending on that instead of specific packages?
Comment by Antonio Rojas (arojas) - Monday, 07 December 2015, 19:30 GMT
@schuay this is the current situation, with packages providing 'x11-ssh-askpass'. The main issue here is that seahorse can't be installed alongside any other ssh-askpass package.
Comment by Gaetan Bisson (vesath) - Monday, 07 December 2015, 20:42 GMT
Antonio: Letting users set SSH_ASKPASS themselves and steering clear from that in our packages sounds good to me.
Comment by Jakob Gruber (schuay) - Monday, 07 December 2015, 20:57 GMT
arojas: Not exatly, since plasma-meta depends on ksshaskpass instead of x11-ssh-askpass.

If that dependency would be changed, then ASKPASS could still be set by the package.
There would be no problem as long as users do not want to install more than one askpass package at once.

Anyway, not setting SSH_ASKPASS is also fine by me.
Comment by Moabit (Moabit) - Wednesday, 09 December 2015, 02:49 GMT
@schuay The reason for opening this task in the first place was that I *did* want to install more than one askpass package. I'd like to use ksshaskpass for most of the time, but also seahorse in particular situations (for mutt, etc.).

Hence for me, any solution that kept the conflicts might improve the situation, but not fix my particular problem.
Comment by Jakob Gruber (schuay) - Wednesday, 09 December 2015, 09:42 GMT
Moabit: Thanks for clearing that up.

In any case, I still think that the standard case should not need manual setting of env variables. But as I said, I'll go with the majority here.
Comment by Antonio Rojas (arojas) - Thursday, 17 December 2015, 14:25 GMT
heftig, JCG: I guess this is up to you then. Do you want to split the askpass part from seahorse or should we stop setting SSH_ASKPASS in all packages?
Comment by Jan Alexander Steffens (heftig) - Thursday, 17 December 2015, 14:27 GMT
I'd prefer getting rid of SSH_ASKPASS.