I'm pretty sure that the first 3 messages are always decrypted with the first key because the passphrase of the first key is still cached. I don't think you can tell gpg to only use a specific key for decryption. The only way to make sure that gpg does not try to use the first key for decryption is to remove the private key of the first key. Alternatively, clear the cache after using the first key, but gpg might still ask the user for the passphrase of the first key.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Oct 18 2021
Oct 17 2021
Urgs, I already implemented this:
On macOS _NSGetExecutablePath could be used, but iiuc this requires linking against dyld. For other OSes we would also need more code. I doubt that this makes a lot of sense these days; but we should come up with a solution, even if that means we need an envvar to specify the location of that open gpgconf.ctl file.
Oct 16 2021
That looks like a support question. Please ask on a mailing list for help. Sorry, we can't do individual support here.
Oct 15 2021
For completeness here's a screenshot that shows the situation on a TERM=sun-console text console with the latest code :
After thinking a little more about this issue, I am of the opinion that the best option here is to provide a compile time configure option :
It would be convenient if the -c option could be easily set in the gpg-agent.conf or in some configuration file for pinentry. The workaround that I use now to create a script that I can then use as pinentry-program is extra work because it requires an additional script.
The typo is fixed now and after pulling the latest sources from the repo and configure --disable-ncurses :
It seems for me that the patches to random/ was written in old days.
- Now, we have getentropy in libc
- This is most reliable one
- better than urandom, because it may block when kernel is not yet seeded
- better than random, because it never blocks once kernel is seeded
- So, the real path in rndlinux.c is actually, call to getentropy
- No access to /dev/random or /dev/urandom any more, in fact
- Although old code remains, non-touched
- like use of syscall when getentropy function is not available
Add doc in gcrypt.texi.
Thank you. Applied.
Thanks for testing. I pushed a fix for my typo: rPb713f31c5b04: curses: Fix the previous commit.
I don't know if it's same in your case, but to fix my case, I pushed a change rG48359c723206: dns: Make reading resolv.conf more robust.
I managed to create a case. Put a line:
BTW, in your screen shot (log is preferred here), it shows 1c00, that must be actually written as AAAA (0x1c). In the bug T3803, we saw byte sequence like that, additional 00 was added then resulted malformed DNS packet.
Oct 14 2021
Even better. Thanks,
In T5617#150908, @gniibe wrote:OK, let us start discussion by applying the patch first.
I have wondered if introducing another state in FSM would be needed, because:
The information is shown on the primary tab of the About dialog. Displaying the information in the Libraries tab requires bleeding edge KDE frameworks because the possibility to show custom information on this tab has been added very recently.
My previous patch is not perfect as the screenshot in attach shows. The clear() is not really sufficient as it only redraws the portion below the frame in the new background color (black instead of white).
In the patch in attach I do a clear screen in the non-ncurses case.
Hello Tim and Yukata Iibe (gniibe),
A way to get the output of "gpgconf --show-versions" might also be useful. Actually this command could be used to get the versions.
dots are not allowed in hostnames.
OK, I'll gdb in there to see what happens. My domain is a classic pgp.domain.com
OK, let us start discussion by applying the patch first.
Applied the RSA part.
Ah, other possible case is .. in hostname.
It's hard to investigate your problem, with no information of host for the query.
I mean, there is no case to replicate (for us).
Oct 13 2021
No, the error is harmless. I guess it shouldn't be printed (except when debugging).
Wouldn't it be safer to use gpgv for verifying the signature than to add a code path to gpg to circumvent the hard de-vs compliance check?
We now require a way to get the actual image of a process. For macOS the BSD method is used and we obviously need to find another way for macOS.
@rupor-github no problem for the delay. Thanks for explaining!
Fixed in 2.3.3.
Fixed in GnuPG 2.3.3.
Fixed in GnuPG 2.3.3.
Thank you for locating the bug!
I should have explained the context.
No, there is no discussion about this in the WG.
Oct 12 2021
Hi gniibe!
Thank you again.