Reading pages of the following links:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_gettime.html
https://docs.oracle.com/cd/E36784_01/html/E36873/unistd.h-3head.html
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Oct 5 2021
Thank you for your investigation.
Oct 4 2021
Hi gniibe!
Hi gniibe!
Currently, I am using --lock-never config to avoid generating lock file as a workaround.
How about:
- Only when hash-handle is used for multiple purposes, a user needs to compose SEXP
- when hash-handle is used for a single purpose, a user doesn't need to compose SEXP, but static one.
In the original SuSE's patch, _gcry_pk_sign_md function gets data template as SEXP as an argument, and the implementation does decomposing SEXP to get hash-algo. (A user of the function needs to compose SEXP with hash-algo.)
For 2.3, when you use PC/SC, please use the disable-ccid option in your .gnupg/scdaemon.conf.
Oct 3 2021
Hey, are there any other logs that I can grab? Is there a way to override the defaults, which will allow me to use the right key to sign?
okidok - understand and thank you.
Quite possibe and thanks for the report. However, this is a dev state of the things and thus not expected to work. I'll keep this open as a reminder for me, but in general I would prefer to get a report at the gnupg-devel ML.
Sorry, a hostname with slash is simply not allowed by IETF standards. Given that the hostname is part of temporary file names, you will run into an error. Yes, we could remap the slash in the mktemp function but there are lot of other plzces where the hostname is used and certain properties are expected.
Oct 2 2021
After testing about a dozen different term types and doing some library tracing, it appears to be that any terminfo type for which has_colors() is false (so the start_color code is never called) works correctly.
Hi gniibe!
Just tracking my own additional investigation still about past Werner statement "percent escaping is correct and required" when this bug was closed for 1st time.
Also found interesting past references into rG055f8854d3f4 and rGe064c75b08a5 but only this last seems indeed much more specifically directly involved since it really contains related part of code (common/stringhelp.c) directly involved with this bug report for 'percent escaping' ':' (colon) character with '%3a' string even if sometimes, when possibly un-needlingly done, may even provide users unexpected on-screen displayed results like those I documented in this bug.
Problem now is that to really fully understand why on-screen displayed strings by 'gpgconf --list-dirs' correctly show a ':' (colon) correctly expected character near an unexpected (by end users) '%3a' (percent escaped) string that should just have corresponded with another simple (& user correctly expected) ':' colon character I can only really see to 2 options:
A) reopening this bug once again :-S ;
B) simply opening a new separate one asking for some additional explanations and maybe even to consider some future slight code changes to (at least for Windows OSes) ensure 'gpgconf --list-dirs' directory displayed paths results are more UI consistent with 'gpgconf --list-dirs homedir' or 'gpgconf --list-dirs sysconfdir' displayed ones where displayed C:\... paths always correctly display ':' (colon) instead of '%3a'.
So far this last seems me best viable option also because in same rGe064c75b08a5 I also saw another piece of code (tools/gpgconf-comp.c) with some similar code lines, that apparently (it seems me) if directly referenced (at least only for Windows OSes only, so maybe when a system variable %OS%==Windows_NT exists) instead of current one (common/stringhelp.c) also providing '%3a' 'percent escaping' results, might then have probably also easily avoided '%3a' user unexpected on-screen displayed results only depending by 'percent escaping'.
Just adding this note for any future reference needs only (or even message localization reference, since involved text characters strings are also expected to be among Italian language localized messages even if involved strings are not specifically being localized).
Oct 1 2021
Well this seems to be a gcc 4.2 bug. But well, forward declarations should go into a separate file so that tehre is only one place which would require changes. In this case it does not matter.
All of my testing has been done while connecting via ssh to my OpenIndiana workstation. I'm using PuTTY 0.76 as my terminal/SSH client.
It appears to you identified the problem really quickly again. If I select the entire screen and paste it, the dialog text is there:
@mooney Just in case when it's color related problem, could you try to cut&paste the text of the screen when pinentry should display a dialog box?
I found some links:
XTerm FAQ:
https://invisible-island.net/xterm/xterm.faq.html
Why not just use TERM set to "xterm"?
https://invisible-island.net/ncurses/ncurses.faq.html#xterm_generic
What $TERM should I use?
https://tools.ietf.org/doc/xterm/xterm.faq.html#xterm_terminfo
Opened https://dev.gnupg.org/T5631 for the pinentry-curses issue.
do you want me to open a separate bug report for the pinentry issue and reference this bug report?
You did all the work to locate the bug, gniibe! Nice job identifying it so quickly.
Thank you for locating the bug for (1).
Sep 30 2021
Hello again Werner,
You're definitely on the correct track: setting 's2k-count 29176832' in my gpg-agent.conf fixed the gpg-agent hang. Now the decrypt I was trying earlier works. Also, 'gpg-agent' is no longer accumulating CPU time, and I can kill it off with gpgconf.
s2k-count matters when you import the key.
When I run the gpg-connect-agent, it starts the agent and then hangs without responding with the time:
My current keypair is old, but it's stored on my workstation's disk and appears to have been correctly imported into the private-keys-v1.d/ store. I do still have my 'secring.gpg' too, in case I ever need it for an older GPG.
It seems that there are some problems: https://bugs.python.org/issue35455
After the passphrase has been entered and gpg hangs, gpg-agent starts to accumulate CPU time at a rapid rate, as displayed by 'ps -ef'.
gpg-agent doesn't disappear from the process list after entering the passphrase; in fact it can't be killed with anything but 'kill -9'. 'gpgconf --kill gpg-agent' cannot kill it, the gpg-conf command just hangs when trying to.
Yes, xterm as a terminal type is correctly supported on OpenIndiana. I have been using it for many years, for both command-line and curses-based programs. It works well.
With the options that Werner recommended for debugging in my ~/.gnupg/gpg-agent.conf:
I think that the first problem is related to T5577: Null ptr dereference in gpg-agent (gnupg 2.3.2).
If gpg-agent has gone (after entering passphrase, it must be SEGV.
Let us try to solve problems, one by one.
Hi gniibe!
BTW, when pinentry interaction doesn't work well, use of --pinentry-mode loopback option for gpg may help you.
It seems for me that there are multiple problems.
For pinentry-curses, please have a look at: T4771: pinentry-tty/pinentry-curses interact a user as background process
It only works well in some situations; It doesn't work when the screen is occupied by foreground program like Emacs and Midnight Commander.
Thank you for reporting.
Fixed in master.
Sep 29 2021
Hi, was there any update on this? I found the following bug [0] in libgcrypt, which we solved [1] with using poll ages ago.
Requires a new option or command.
Looks like this should be handled in the Enigmail tracker, if being handled at all.
Hi @Lambd0x, with Thunderbird having migrated to a different main OpenPGP implementation and Enigmail not supporting old thunderbirds version anymore (in two days https://www.enigmail.net/index.php/en/home/news/71-2021-08-31-end-of-support-for-thunderbird) and new GnuPG versions over the last three years. Do you still have problems?
In my understanding, it should be possible to wait for the gpg command pipe from a different process and then terminate the connection on a timeout, kllling the process eventually. So the Enigmail side could implement something. These days I'm not sure what Enigmail uses for OpenPGP support. Thunderbird has moved on to a different implementation and Enigmail stops supporting Thunderbird 68 in two days https://www.enigmail.net/index.php/en/home/news/71-2021-08-31-end-of-support-for-thunderbird
Enigmail's support for Thunderbird 68 ends in two days:
https://www.enigmail.net/index.php/en/home/news/71-2021-08-31-end-of-support-for-thunderbird
@rupor-github no problem! :)
@werner I think @Rombobeorn suggests something like
Sorry, I can't read all your comments about this. The percent escaping is correct and required. If you want to use the output in a script you can get it without percent escaping by using for example
Hello again Werner,
Thanks for the guidance, Werner!
Use of version 5 format for Ed448/X448 was pushed by rG86cb04a23d2b: gpg: Ed448 and X448 are only for v5 (for subkey)..
OK, effect avoided. Only dued to a big sequence of '-' characters that this bug reporting system interpreted as special control code characters for making font bigger.