A Yubikey has for example the name "Yubikey [...] OTP+CCID 0". The Kleopatra drop down box however does not display (or at least use) the "+" from that string and puts "Yubikey [...] OTP CCID 0" into scdaemon.conf. Thus the Yubikey is not found.
Description
Description
Details
Details
- Version
- vsd 3.1.20.3
Revisions and Commits
Revisions and Commits
| rLIBKLEO Libkleo | |||
| rLIBKLEO19e4f2f506a4 Add a test for the hexdecode helpers | |||
| rLIBKLEOc894f0c65918 Fix erroneous unescaping of reader names | |||
| rLIBKLEO671f2bbf2059 Export the hexdecode/hexencode helpers | |||
| rKLEOPATRA Kleopatra | |||
| rKLEOPATRAc7be8cf847fc Use the hexdecode/hexencode helpers provided by libkleo | |||
Event Timeline
Comment Actions
This looks like a missing escaping issue in the sender (scdaemon?) or an unwanted unescaping issue in the receiver of the string (which uses Kleo::hexdecode()).
Comment Actions
Yes, kleo always maps '+' -> ' '
if (*it == '%') {
[...]
} else if (*it == '+') {
result += ' ';it is a bit unforunate that our interfaces use percent escape with and without plus escaping. There is of course a good reason for this, but it is annoying. What shall we do? Escaping in scd seems to be the better thing, I guess.
Comment Actions
Hmm, I looked at the gpg-side a bit. assuan_send_data that's used for returning GETINFO reader_list only does escaping "as required by the Assuan protocol", i.e. percent escaping of certain characters but no plus escaping.
I can live with the rule that data returned using the Assuan protocol is always percent escaped, but not plus escaped. I will add the unescaping to the low-level function that sends a command returning data, so that callers don't have to care about unescaping.
Comment Actions
Doh! gpgme already performs the unescaping of data retrieved via the Assuan protocol for us in llass_status_handler. Doing it again in Kleo::SCDaemon::getReaders was simply wrong.