[sailfish-secrets] Properly detect the key ID in case of a subkey. #189
Conversation
|
|
||
| // Ugly hack here due to GnuPG being stuck in 2.0.4 | ||
| // and not having SETKEYINFO command yet. Description may contain "ID xxxxx". | ||
| { | ||
| const QString &str(self->prompt.message()); | ||
| int id = str.lastIndexOf("ID "); | ||
| int id = str.lastIndexOf(", ID "); |
There was a problem hiding this comment.
What's the content like here actually? Wondering should the comment about "ID ..." be adjusted too to include the comma part.
There was a problem hiding this comment.
That's a good remark. I've updated the comment with an example of description that can be parsed to extract the key ID.
There was a problem hiding this comment.
Suppose the change here fixes what is says, but for another thing if the content is like above, why is this using lastIndexOf() instead of indexOf()? Quick google on such strings shows instances with email address in the end which theoretically at least might involve the id?
If fixes an issue this could be fine already.
There was a problem hiding this comment.
The problem I got was exactly this one: with the localisation of the description by GnuPG, I ended up parsing something like clé secrète pour l'utilisateur: « Damien Caliste <email> » clé de 2048 bits RSA, ID A099539B, créée le 2018-04-13 (ID clé principale 41123AA4). Which gives, with the code in master branch, an ID like "clé prin". And I saw this string in the UI, wondering what happened.
Indeed, my first intention in using lastIndexOf() was to avoid a possible match of "ID " in the first line containing the name and the email. But then, I didn't though about subkeys... Thus the change to parse the comma with it.
I agree this is very fragile and ugly. GnuPG in a later version is providing the key ID by itself and we don't need to parse a changing string. But this later version is GPLv3, you know.
In case of a subkey, the hack code to detect the key ID in the pinentry has to be modified since the description contains both the main key and the sub key.
In the pinentry, when asking for a passphrase, the system is asking to access the GnuPG secrets to read the passphrase from cache if any. When this confirmation is dismissed by the user the pinentry should not ask again to access the secret to cache the passphrase.
|
I've added the first line of the description in the comment, so it may justify the use of |
Also don't bother the user with a second demand to access the cache passphrase if the first attempt was dismissed.
@pvuorela , if you have time to give a look. Thank you.