No, the error is harmless. I guess it shouldn't be printed (except when debugging).

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.

I should have explained the context.
No, there is no discussion about this in the WG.

The new bugs have been fixed in 2.3.3; see T5565.

@bernhard Sorry for the delayed answer, was on sabbatical.

Is that really required? Should we wait what the conlusion of the WG will be?

I'm reading RFC5297, which says:

SIV can be used as a drop-in replacement for any specification that uses [RFC3394] or [RFC3217], including the aforementioned use. It is a more general purpose solution as it allows for associated data to be specified.

Note that I'm referring to file based keys, not card based.

I tested this on 2.3, and it doesn't seem to be fixed. When adding an existing ECDSA subkey I don't get the option to choose whether to make it a signing or encrypting subkey. Instead it only allows me to choose an encrypting subkey.

OpenPGP requires the P < U property and gpg does also. In some parts of the GnuPG we re-calculate the CRT parameters but not in these code paths. Right, a better error message would be appropriate. I'll turn this into a feature request.

In that case maybe GetUserDefaultUILanguage. Thank you for considering.

Thanks for the info.

Major problem here (before the change) was that clock_gettime returned an error with no valid value of the time, which confuses gpg-agent's calibration of time. This occurred on (not newest) Solaris kernel, as it offers clock_gettime function in the library and CLOCK_THREAD_CPUTIME_ID constant in the header.

I mentioned the two POSIX getconf settings you referenced in those links, and the developer that implemented CLOCK_THREAD_CPUTIME_ID and a couple other CLOCK_THREAD types had this to say:

FreeBSD has _POSIX_THREAD_CPUTIME > 0.
GNU/Linux has _POSIX_THREAD_CPUTIME == 0, because older kernel doesn't support the system call.

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

Hi gniibe!

For 2.3, when you use PC/SC, please use the disable-ccid option in your .gnupg/scdaemon.conf.

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.

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).

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.

Requires a new option or command.

@rupor-github no problem! :)

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)..

@bernhard thank you for explaining, did not mean to offend anybody. Before creating win-gpg-agent I tried to read as much as I could on a history and obviously had to study source a bit. Be it as it may - I decided to have separate wrapper, rather then contributing directly to gpg code base. There is noticable number of use cases on Windows which presently not addressed, some I believe are sitting it the queue already.

@rupor-github thanks for your explanations and the contribution to the GnuPG and crypto Free Software code base!

Since Windows user naively could expect multiple methods of accessing certificates from different programs (or sometimes from the same program but different supported environments, like Git4Win and git in WSL) to work together transparently, win-gpg-agent covers translation of one accidentally supported method (32 bit putty shared memory) to multiple unsupported ones (named pipe, cygwin, etc). It also takes care of managing gpg-agent.exe lifetime tying it to user login session for convenience. It uses command line parameters to only to overwrite staff critical to its functionality and does not prevent user from having configuration file(s). Optionally it provides pinentry which is integrated with Windows native Crypto Vault and UX rather than using wonderful QT or GTK. As specified in documentation when developers of gpg and WIndows will get their act together and figure out what they want and how they want it - most of functionality would not be needed. I would like to point out that simply claiming superiority and not supporting cygwin (Git4Win) or working Assuan ssh socket or putty shared memory in 64 bits Windows build does not help with user experience a single bit.

Just to be sure. please provide the output of

Bug in creating such a blob is fixed in rG08a3a4db27dc: kbx: A 20 byte fingerprint is right filled in version 2 blob..

Lots of detailed documentation but frankly, after a brief read I have not yet figured out what it really does. We won't support Cygwin stuff - this is all obsolete and awe also removed starting gpg-agent as a service for good reasons. Instead of starting gpg-agent with lot of command line args it would be better to put this into a per user or system wide config file.

There is a user report that got things to work with https://github.com/rupor-github/win-gpg-agent
on https://wald.intevation.org/forum/forum.php?thread_id=2359&forum_id=21&group_id=11

Here is James' writeup on the use https://gnupg.org/blog/20210315-using-tpm-with-gnupg-2.3.html . For more details please consult the mailing lists and the commit messages.

I think that scenario with TPM emulation would be more generic.
What needs to be done to have TPM emulation? Can you point on some doc about that?

Ich you do not have a working TPM or emulation but the tpm libraries installed run configure with the option

--disable-tpm2d

We ran the coverity again with the new 2.3.1 release and there are couple of new stuff that I probably missed in the initial review.

Interesting idea.

Fixed in 2.3 and 2.2

(I closed this by accident)

You could use --disable-keyboxd which should fix this. However, there will eventually be no more way to build w/o Sqlite and thus I would suggest not to allow disabling of sqlite.

I filed a bug report to GCC, with modified test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102151

Aihhh, my fault. seems that a new version it not too far away.

Fixed for (1): Now it writes correct record with valid checksum and flag.

Will only be fixed for 2.3 and that has already been released.