Bug 376318

This is a regression in 5.9.1. There is a patch posted to bug 376228.

*** This bug has been marked as a duplicate of bug 376228 ***

We could not verify if the issue from bug 376228 is indeed a duplicate.

If your issue is not fixed with Plasma 5.9.3, please add a comment, ideally with the debug output of the ksshaskpass program.

Hi, seems to work so far with 5.9.3, otherwise I shall re-open. 

Kind regards, 

Christian

Hm, no, not fixed, 

unfortunately ksshaskpass gives zero usable debug output (is there a switch I don't know?), it just re-asks for the passphrase even though the keys have a valid entry in kwalletmanager. 

Removing all of them and re-adding them didn't help either. 

Fuchs

I can confirm that for me 5.9.2 doesn't save anything at all. Reverting to 5.9.0 fixes the problem. ksshaskpass itself doesn't output anything useful. Neither does the wallet subsystem, even if I turn on "285 kdeui (wallet)" and "kwalletd" in kdebugdialog.

ksshaskpass uses the new Qt logging. To get the debug output, please add ksshaskpass.*=true to your QT_LOGGING_RULES as described at http://doc.qt.io/qt-5/qloggingcategory.html

Either put it into your qtlogging.ini file or set the QT_LOGGING_RULES environment variable.

It should then display the failing prompt it needs to recognize.

Your distribution might also have configured Qt to redirect any logging to the syslog daemon instead of to the Konsole. In that case, please ask in a forum of your distribution how to search for ksshaskpass messages in the system wide log files.

I've tried the following with 5.9.2:

[0 mbunkus@chai-latte ~/tmp/askpass] export QT_LOGGING_RULES='ksshaskpass.*=true'
[0 mbunkus@chai-latte ~/tmp/askpass] ksshaskpass wuff                            
ksshaskpass: Unable to extract keyFile from phrase "wuff"
Pass a valid window to KWallet::Wallet::openWallet().
miau%                                                                                                                                                                                                                                        [0 mbunkus@chai-latte ~/tmp/askpass]

At the same time I had "journalctl -f" open as root. No message was written to the journal either. A regular syslog daemon is not running; I'm solely using systemd's journal for that.

Still completely useless.

(In reply to Moritz Bunkus from comment #8)

> Still completely useless.

And still completeley broken and useless in 5.9.3, I think I'll ask gentoo to mask it as it is apparently broken.

And no, it doesn't give any useful error messages. 

Pretty sure it is due to the "fix" with spaces in the entries, but I don't see why it would break.

I've just bisected the problem. The first bad commit is 9dbabcb38862c1590503169be3ae7806e6673dba.

More information. Running the compiled ksshaskpass from the command line shows the following debug information:

> ksshaskpass: Unable to extract keyFile from phrase "wuff"

"wuff" is the sole argument I've executed ksshaskpass with, as in:

> ./ksshaskpass wuff

My wallet does contain a password entry named "wuff", and ksshaskpass prior to commit 9dbabcb38862c1590503169be3ae7806e6673dba simply outputs that password.

This seems to me to be a case of wrong expectation of what the prompt contains… As soon as I call ksshaskpass with something that 9dbabcb38862c1590503169be3ae7806e6673dba expects it works, e.g.

> ./ksshaskpass "Enter passphrase for wuff: "

This works as expected.

Sorry for spamming, but I think I should explain my use case here. I'm using ksshaskpass not just with ssh-add via SSH_ASKPASS, but also for other purposes, including:

* letting mutt retrieve the password to my IMAP server login,
* retrieving a password for the OpenConnect VPN client from the wallet,
* automatically mounting encrypted file systems with encfs and its support for external password programs

In each case I simply execute ksshaskpass with a custom prompt, e.g. "ksshaskpass 'IMAP password'". I've modified my scripts and configurations to adhere to ksshaskpass' new expectations; e.g. "ksshaskpass 'Enter passphrase for IMAP password: '", and that works for me. However, I'd rather this wouldn't be necessary, and that ksshaskpass would simply fall back to using the whole prompt as the storage key if the prompt wasn't recognized as one from ssh-add instead of refusing to work. Otherwise all use cases apart from ssh-add will run into this problem because they're not aware that the prompt must follow pattern (including the trailing colon and space — the RegExes are that strict!).

(In reply to Moritz Bunkus from comment #12)
>  [...] 
> 
> In each case I simply execute ksshaskpass with a custom prompt, e.g.
> "ksshaskpass 'IMAP password'". I've modified my scripts and configurations
> to adhere to ksshaskpass' new expectations; e.g. "ksshaskpass 'Enter
> passphrase for IMAP password: '", and that works for me. However, I'd rather
> this wouldn't be necessary,

Also this sounds like something that is going horribly wrong as soon as localization comes into play, which might explain why it is broken here. 

Can that commit please either be fixed properly or reverted? 

Thank you very much for your work in bisecting this :)

I do not know if we have a maintainer for ksshaskpass, it looks like someone else (i.e. not the developer) imported the code.

Reading the commit log of 9dbabcb38862c1590503169be3ae7806e6673dba I understand it was intended for ssh, not for custom uses. The name suggests the same.

I get that, believe me. However, ksshaskpass is a very convenient tool for storing & retrieving passwords securely without having to write a whole script around dbus calls. Excellent for one-liner use such as the use cases I've listed before.

One solution I can see is to simply introduce another command line parameter that specifies the key to store/retrieve. If that option is given all the prompt parsing would be skipped.

If I wrote such a patch, would there be a non-trivial chance it'd get looked at and (assuming it's fine) applied? Or is there not being a maintainer basically a guarantee such a patch would not get looked at?

Well, we had developers looking at the patches that broke your use case, so I guess the chances are high that someone understands your position and accepts a patch to restore that.

In any case, if you add it to https://phabricator.kde.org/differential/diff/create/ please also add the Differential link here.

I'd say the main problem here is that it does not only break for special use cases, but for some people (e.g. me) for the very standard usecase of ssh. 

So it's completely unusable for me right now.

Christian, can you still reproduce it?

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!

I  request reopening this bug. I am affected - not in the SSH use case, but in general use case where I want the prompt to not be in one of a couple of fixed forms in English, but I still need to be able to specify the keyfile.

Also, whoever coded those fixed English phrase patterns should be put on keter duty. THOU SHALT NOT PARSE NATURAL LANGUAGE. The bug is not about the parsing code failing, it is about the parsing code existing. Do the right thing, throw away the parsing and introduce the option to explicitly specify the keyfile.