Agreed
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mar 2 2023
I think the patch is okay.
Mar 1 2023
Feb 28 2023
Since I have closed T6377 which had high priority I am assigning this issue the same prio. Which I also think is appropriate.
Feb 27 2023
The code has meanwhile been reworked and the mentioned test server is not anymore available
Thanks for the report; the regression happened due to fixing T6135.
Feb 26 2023
Please use
gpgtar -C /home/matt/data ....
instead of using an absolute name. This makes things much easier to implement in a secure way: You don't want to have absolute file names in the tarball and mapping them to relative names is not easy or even impossible in case of, say "/home/foo/x.data /home/bar/x.data". Keep in mind that gpgtar does also not handle symlinks and other special files.
Feb 24 2023
I should probably add that Kleopatra calls this command when reading a smart card to create the key stubs if necessary. Kleopatra does this since gpg4win-3.1.24 (according to the tags) and the KDE Gear 22.04 release (see T5782: Kleopatra: Smartcard unusable secret key until used via command line).
Your report lacks any useful information starting with the version of gpg you are using. Did this ever work? What did you change? Did you probably upgrade the system and have previously been using gpg1, but are now using gpg2?
Thanks
Feb 23 2023
Feb 21 2023
The application probably doesn't support this curve, the changelog only mentions Curve25519 and NIST P-256. Also Kleopatra lists only these two curves when generating a key from the card. Upon further inspection, the 0xFA DO listing the supported algorithms only has RSA 2048, RSA 4096, nistp256, ed255519 and cv25519
This is a Nitrokey 3A with the firmware 1.2.2-alpha.20221130. I'll check with the vendor.
Sure that you specific card/implementation of Nitrokey supports this curve? The card application uses a vendor from the test card range - this it is likely that it is some Javacard implementaion or it is an old gnuk firmware on the nitrokey basic.
Changing the key attributes didn't help unfortunately:
There must be some regression in the code which changes the key attributes. Please try
"gpg --card-edit" admin, key-attr
and switch to nistp384.
I also tried to import the key with the gpg-card writekey command and I got the same error.
Same error message but probably a different cause, in this case the card was factory reset before importing.
Looks similar to T6378. Can you provide the output of
Feb 17 2023
well, this user made a backup and it went wrong anyway ;-) See T6377
Feb 16 2023
Thanks. please give a few days.
created ~/.gnupg/gpg-agent.conf containing:
debug ipc,cache debug-pinentry log-file socket://
Okay, I see. The commands above are a real reproducer and not standalone examples. Then yes, you should get a pinentry only for the first gpg -d (as long as the keys are still in the cache). I am lacking macOS/homebrew stuff to replicate this. What you can do is to put
Feb 15 2023
I may be reading your comment wrong, but the problem here is not multiple pinentry prompts, or multiple gpg-agents present.
Although gpg-agent launching is protected by a file system lock, there is indeed a small race related to the pinentry. The invocation of the pinentries is serialized but if a second pinentry is requested while the first pinentry has not yet returned and put the passphrase into the cache, the second pinentry will be called anyway. Fixing this not easy and should rarely be a problem. The mitigation is to do a dummy decryption to seed the cache or use a custom pinentry.
Hier is a log file from GpgOL (+Code verfolgung)
Feb 14 2023
Here is the output of gpg --full-timestrings --check-sigs:
pub rsa3072 2019-05-09 12:08:21 [C] [expired: 2022-05-05 12:08:21] ABC96B3B4BAFB57DC45D81B56A48221A903A158B sig! 6A48221A903A158B 2019-05-09 12:08:21 [self-signature] uid [ expired] Linda Mary Patricia Deborah Barbara Susan Maria Nancy <linda@example.org> sig!3 6A48221A903A158B 2019-05-09 12:08:21 [self-signature] sub rsa3072 2019-05-09 12:08:21 [E] [expired: 2022-05-05 12:08:21] sig! 6A48221A903A158B 2019-05-09 12:08:21 [self-signature] sub rsa3072 2019-05-09 12:08:21 [S] [expired: 2022-05-05 12:08:21] sig! 6A48221A903A158B 2019-05-09 12:08:21 [self-signature]
With the current development version I get
$ gpg --version gpg (GnuPG) 2.4.1-beta21 libgcrypt 1.11.0
Feb 13 2023
This is the file I am repeatedly importing in the sessions from my report. It is one of the keys that seem impossible to unexpire for me.
There is no privacy issue: this belongs to a published test suite and is not used by any human.
Feb 9 2023
Good catch. The translation of the option descriptions is done as part of the option parser (libgpg-error/src/argparse.c) and thus we need to have gettext support over there. Also for some other error messages.
Feb 8 2023
Seems to work if NLS support is enabled. Updating in https://github.com/Homebrew/homebrew-core/pull/122706. Once merged, users will need to brew reinstall libgpg-error (Homebrew has decided to avoid forcing updates to all users outside of critical fixes).
Probably due to libgpg-error being built without NLS support on macOS as formula currently doesn't have gettext dependency. On Linux, libintl is provided by glibc so doesn't need any extra dependencies.
Gpg4win 4.1.0 comes a slighly newer gpgol which should be tried before we continue. Set to low prioprity because this seems not to be easily reproducible.
I have no idea about Homebrew - can you figure out the maintainer and point him to here?
With 2.4.1 you will get a runtime error
sendmail tool '%s' is not correctly installed\n
Feb 7 2023
This is the Homebrew build. Maybe something not included in the recipe?
No idea what happens. I can't replicate that on a Linux box using GNU gettext and neither in Windows using gnupg's own gettext implementation. It seems that strings without any line feed don't get translated.
Thanks. Looks pretty standard. I will have a closer look.
Feb 6 2023
gpgconf -L:
sysconfdir:/usr/local/etc/gnupg bindir:/usr/local/Cellar/gnupg/2.4.0/bin libexecdir:/usr/local/Cellar/gnupg/2.4.0/libexec libdir:/usr/local/Cellar/gnupg/2.4.0/lib/gnupg datadir:/usr/local/Cellar/gnupg/2.4.0/share/gnupg localedir:/usr/local/Cellar/gnupg/2.4.0/share/locale socketdir:/Users/emirsari/.gnupg dirmngr-socket:/Users/emirsari/.gnupg/S.dirmngr keyboxd-socket:/Users/emirsari/.gnupg/S.keyboxd agent-ssh-socket:/Users/emirsari/.gnupg/S.gpg-agent.ssh agent-extra-socket:/Users/emirsari/.gnupg/S.gpg-agent.extra agent-browser-socket:/Users/emirsari/.gnupg/S.gpg-agent.browser agent-socket:/Users/emirsari/.gnupg/S.gpg-agent homedir:/Users/emirsari/.gnupg
Can you please provide the output of
Jan 31 2023
Thanks. I fixed the documentation. Will go into 1.19
Jan 24 2023
The interaction goes back to "Your decision?" after you didn't answer "y/N" to the question of "Do you really...?".
What you are asked is: 1, 2, 3, 4, 5 or m.
Jan 23 2023
Jan 19 2023
Jan 18 2023
Commited with revision 1642622.
I am closing this now, as we now should have complete kleopatra translation and can just move one of them to testing.
Jan 17 2023
I am pretty sure that this was related to issues we found when analyzing another crash / hang with Kleopatra. In T5478 we are currently reworking how we handle archives completely. This will fix this issue, too.
Jan 16 2023
Thanks a lot.
Jan 13 2023
Commited this state with revision 1642162
Not yet fully finished, but it's better for me to put it now:
Jan 10 2023
I leave this open as ticket for the rest ?
Jan 9 2023
I'm that user - only thing I can think of really is that I used the tool "O&O ShutUp10++" to restrict Win10 Settings. During the troubleshooting I reverted to the standard settings, but it made not difference.
kwatchgnupg translation commited as revision 1641797 I leave this open as ticket for the rest ?
Thanks commited this to https://websvn.kde.org/trunk/l10n-support/ja/summit/messages/libkleo/ this should then be automatically arrive in the po/jp subfolder of libkleo. But I keep it as testing to check if this actually was done.
Jan 8 2023
Can you therefore please clarify the purpose of the Libgcrypt LTS branch? My impression was that pairing the Libgcrypt LTS with GnuPG LTS was appropriate, based on both GnuPG and Libgcrypt LTS appearing on your downloads page at approximately the same time (from memory). Specifically, is there any issue using latest Libgcrypt 1.10.x with GnuPG LTS? Thank you.
Will not be fixed because the only change is intentionally the export target for a regression test suite. The other fix is for the old FIPS RNG which is not used at all.