Breaking the flawless decryption of existing old data is unfortunately a highly controversy topic. Recall the no-more-v3 packet support or the required MDC. It was technically okay and 99.99% of the users didn't even notice it. But some were very vocational.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
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%)
% export GPG_TTY=$(tty)
In T5813#154552, @Valodim wrote:Might be an issue with matching ciphersuites? There was a problem with this before when GnuPG didn't support AES-GCM yet (https://dev.gnupg.org/T4597). That was added in 2020, maybe it's not rolled out far enough yet?
Either way, I hadn't considered this for the WKD relay. I'll look into enabling AES-CBC there, at least for backwards compatibility.
The change of pinentry-tty rP7f7fd8bcfd74: tty: Fix error return paths and its resource leaks. fixes SEGV, but the problem of your case is that access to the device file (/dev/pts/2 in the case of your log with pinentry-tty) failed.
GnuPG 2.1 is seriously out of date and long out of support. It's probably full of bugs that have been fixed in the last 5 years since its release. Please do yourself a big favor and update to a supported version of GnuPG 2.2.
As the above commit only references pinentry-tty.c, what's the problem with pinentry-curses? Shall I provide the same log with pinentry-curses?
Yes, this was the correct tty at the time of the generation of this log.
Thank you for your debugging.
Feb 6 2022
I am not sure what all the other ode changes are about. There is no explanation.
I am not sure what all the other ode changes are about. There is no explanation.
disk full. Fixed. Thanks.
Feb 5 2022
Feb 4 2022
Manual retrieval of missing certification keys is now possible from the Certifications dialog.
I killed gpg-agent after the config change / before running gpg again. That should be enough to pick-up the config change, correct? In the mean time the system in question was rebooted. Here the full log /with key related stuff redacted).
Strange. pinentry-tty has no place to report ENOENT. I wonder if you notified gpg-agent when you change the config (like gpgconf --reload gpg-agent).
Feb 3 2022
gpg4win_spkgs is used for building the stuff for gpg4win, i.e. for Windows. Are you sure you need/want ntbtls for the Windows build?
This and some other issues with draft encryption are now fixed in master and need a release of GpgOL.
We now autoselect the key.
Why not simply cast to uintmax_t ? That makes the string easier to read.
Might be an issue with matching ciphersuites? There was a problem with this before when GnuPG didn't support AES-GCM yet (https://dev.gnupg.org/T4597). That was added in 2020, maybe it's not rolled out far enough yet?
GPG_TTY in my tests from which I generated the logs above is set to /dev/pts/1 (which is what "tty" returns, what exists in the FS, and what is writable to the user which performs the test).
The string 'Pinentry' is a module name, which is defined in libgpg-error.
It means, the error source is pinentry.