For information, I can’t reproduce here, either with GnuPG 2.2.17 / Pinentry 1.1.0 or with a fresh build from the tip of the master branches. Both pinentry-tty and pinentry-curses prompt for the password as expected, independently of whether the file to decrypt is specified as an argument or sent through standard input.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Aug 28 2019
Aug 27 2019
i'm actually running make -j3 check, since make -j3 distcheck has the problems described in T4688.
So i've been able to (intermittently) reproduce the failures that i think @werner was alluding to here, but not under any circumstances where i can get them to happen reliably to understand what's going on.
I've sent a mail to a protonmail dev asking if protonmail supports PGP/MIME.
Aug 26 2019
Please read my answer again. Posting to gnupg-users does not require a subscription.
Please do not force me subscribe to yet another mailing list to see the answer.
So do you have any plans to make new release? :)
Aug 25 2019
I'll start working on PowerPC GHASH implementation in September after SHA2 is done.
I'll start working on new PowerPC SHA2 implementations for libgcrypt in coming weeks.
Patches for PowerPC AES acceleration sent to mailing-list, based partly on initial work by Shawn Landden (@slandden): https://lists.gnupg.org/pipermail/gcrypt-devel/2019-August/004788.html
Aug 24 2019
It has now been more than a month since:
Aug 23 2019
And also this is excellent point.
oops: That was an accidential priority change
The mentioned "strange hangs" would only be solvedwhen using master - in 2.2 we already had proper locking.
Implemented master and 2.2. Note that the comment in the master commit about possible reason for stucked keylisting in gpgsm is only related to master.
I implemented it nearly as suggested. However, the default AKL is used, which is "local,wkd" (local is not used with that command though).
Fixed for 2.2.18. To allow seeing these warnings this change will only have an effect if a listing of all keys is requested.
Done for 2.2.18
This was already fixed with version 2.2.5.
Will be in 2.2.18
I changed the suggestion to read:
The agent is an important part of gnupg and it does not make sense to single out cases when it might not be needed. I can't see any harm from having an agent running. In fact, one of th netxt versions will add yet another daemon which will then be needed in all cases.