The patch rG054d14887ef8: scd: Add workaround for ECC attribute on Yubikey. fixes a particular problem of Yubikey implementation where it returns bogus octet for its data object of C1, C2, and C3.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 9 2022
May 6 2022
With the patch and after starting a new gpg-agent, gpg --card-status now works immediately.
But when I re-plug the yubikey, gpg reports gpg: OpenPGP card not available: Card error until either gpg-agent is restarted, or pcscd is restarted.
pcsc-lite in debug mode reports no errors, but one log is obviously much shorter as gpg fails early (I've attached both, same pcscd and gpg-agent instance).
I pushed a workaround.
For my environment, it is not PC/SC-specific. It also occurs when CCID driver is used.
For bcdDevice 5.24, I can replicate the symptom, but only once. After second invocation of gpg --card-status, it works well.
May 5 2022
I've applied the patch and can confirm that the segfault is fixed, but gpg still has severe problems communicating with the Yubikey over pcsc-lite.
Ours are even newer (5.4.3). Did you the Yubico tools to switch to curve443?
In any case, is it possible that you apply my fix and test again?
Your Yubikey's firmware version is 5.2.7 - let me see what versions we have in stock to test my fix.
May 4 2022
I've taken the liberty to regenerate the valgrind report including libc and gnupg debugsyms. Maybe it'll help.
I am not sure about the crash but the unknown curve is
1.3.6.1.4.1.11591.15.1.2 which seems to be a GNU OID for curve448
It segfaults on SERIALNO. Here's what valgrind outputs:
What I would do in this case is to stop the gnupg daemon amd anything whiuch might start them and run scdaemon under valgrind.
May 2 2022
Apr 28 2022
Apr 25 2022
Works together with the changes for T5939: Kleopatra: Better error for wrong password in symmetric decryption. Tested with symmetric encrypted file and with symmetric+pk encrypted file.
Apr 22 2022
Apr 14 2022
Seems we can close this bug.
Printing a note as we do in --edit-key is a good idea.
Apr 9 2022
The reason for this is probably that we expect that several UIDs are added and running a check-trustdb for eachleads to some extra waiting time.
Apr 8 2022
Apr 5 2022
(Werner just told me that I was mistaken and he needs to take a look. There was a mixup because of the 2018 CVE number.)
Sorry, that was a misunderstanding. My fault.
Apr 4 2022
In fact, decent 2.2 versions (>=2.2.21) have the ability to decrypt AEAD packets - this has been implemented exactly for the case that some things get wrong at the user site. But we can't change old versions - we are not the Sirius Computer Corporation. I close this ticket because we can can't do anything if you are not able/willing to update to the latest version of the respective branch. Sorry.
Apr 2 2022
@werner
The setpref S9 S8 S7 S2 H10 H9 H8 H11 H2 Z2 Z3 Z1 worked!
Apr 1 2022
S9, etc. are short-hand IDs, for the cipher algorithms, digest algorithms, etc. Use showpref instead of pref to get the preference list in human-readable form (AES256, SHA512, etc.) instead of in expert form (cryptic IDs).
Hi @werner
I had missed your earlier post quoted below on using setperf.
Create the keys with gpg 2.2. I'm not aware of such documentation apart from the manual page of GnuPG. And, as I tried to explain, this situation isn't really different from any other software. If you create a document with the newest version of LibreOffice then you cannot expect it to look exactly the same with an older version of LibreOffice. It's your responsibility not to use new features of the new LibreOffice if you still need to use an older version on another machine.
@ikloecker Thanks for the clarification (appreciated).
Backward compatibility means that newer versions work with data created with older versions of a program. What you are asking for is forward compatibility, i.e. you want older versions of a program to work with data created with newer versions of a program. In the extreme that would mean that gpg must not use modern encryption algorithms because old versions of gpg cannot deal with them. It should be obvious that this doesn't make any sense.
@ikloecker thanks for your reply.
Mar 31 2022
Not in the way it is used by gpg. See T5880
Mar 30 2022
Not in the way it is used by gpg. See T5880
Mar 28 2022
Good idea. Thanks. Goes onto 2.3 and 2.2
In T5886#156407, @TonyBarganski wrote:
- As things stand right now, someone with a Public key created on gpg version 2.3 on a macOS cannot privately communicate with someone using a Linux server, news group or Linux Desktop.
Use a gpg 2.3 version:
Mar 25 2022
Hi Werner
.
Firstly, let me say how much I appreciate the work you and others do at OpenPG.org! Really.
- No we can't because current GnuPG 2.2 versions are able to decrypt such AEAD data.
- So, firstly, can we get an error message that states something to that effect AND can also be displayed by Mutt?
Packet 20 is the new AEAD packet which GnuPG 2.3 can generate and does generate if all recipients have new keys generated with such a versions. However, the version of gpg you use now does not support AEAD and thus fails.
Mar 21 2022
Using an armor header would allow for this. But well, this blows up the data and frankly, I fear that it can lead to unexpected side effects. Better to use a respective file name or MIME header.
Adding
GPG_TTY=$(tty) export GPG_TTY
makes this working so thank you for the pointer.
Mar 18 2022
Is your GPG_TTY set so that pinentry can find the right tty?
the -v does not show more useful info on the gpg side:
# gpg2 --quick-gen-key admin About to create a key for: "admin"
Please run with option -v to see what's wrong with pinentry.
Mar 17 2022
Mar 16 2022
Mar 15 2022
Mar 12 2022
Mar 7 2022
I went through my test files and found that --enarmor on zero length input file did no longer work. I made separate patch to fix that issue, which then also needs another approach for handling compress issue noticed earlier:
Ack from me for new 0005 and 0006.
Mar 6 2022
Mar 3 2022
Mar 2 2022
Mar 1 2022
Great. No problem for me.
Feb 27 2022
Feb 25 2022
I used "1<<30" by example of existing code in g10/free-packet.c, which is another place where iobuf_read is reading to NULL.
Patches look good for me.
Please go ahead.
Feb 24 2022
Feb 23 2022
Feb 21 2022
Feel free to ask me by PM if you run into problems (wk at gnupg.org). Two of my colleagues are Vim users and thus have an interest in a well working plugin :-). Thanks.
Feb 17 2022
I have tested it. When I try it with public keyserver it has of course problematic results when vandalized keys like werners are hit but its great that even if I abort at that point I nicely see the results of the other imports.
Feb 16 2022
Feb 11 2022
Feb 10 2022
Feb 9 2022
Optional automatic retrieval after import of new OpenPGP keys is now also possible.
Feb 7 2022
Yes, it would be convenient to use the same $GNUPGHOME in Git Bash (using /usr/bin/gpg) as in PowerShell / Cmd (using gpg.exe in %PATH%)
Feb 4 2022
Manual retrieval of missing certification keys is now possible from the Certifications dialog.
Jan 31 2022
As this hinders the trusted-introducer setup in Keyserver centric deployments we should treat this with high priority.