Revisiting this I don't think there is anything to do. The ChnageLog-2011 files already carry a note explaining there purpose and that the more recent logs are either in the git or in a file ChangeLog.

Merged into master. Lets test it for a few days before I backport it.

FWIW, I added a gpgtar.1

You could use the --directory option. However< I agree that your suggested changes is less surprising then the current behaviour. Thus I would consider this a bug fix. Can you please apply to 2.2?

That does not look like a GnuPG or GPGME bug but more like an incompatibility in python-gnupg. Please report this to the maintainers of python-gnupg. I would have suggested to use the GPGME Python bindings but unfortunately we don't have a Windows version on them yet.

I prefer plain git patches. Thanks.

That should be emitted only in verbose mode. I have verbose almost always enabled so I didn't caught it. Thanks.

That is the same as a key generated from a passphrase. We have already have a task T169 for this. Thus I merge them.

What is your use case for these configure option?

Hmm. I am fine changing this for master. But for 2.2 I am nut sure. Asking on gnupg-devel?

@aa: Please do us a favor and comment only relevant stuff. The bug tracker is not chitchat. Thanks.

Please use just "po:" instead of "po/NN:" as tag for future commits

Ah well, no rules without exception.

We already have a donated machine with everything setup. This is not going to change. Twitter logon is just a convenience for many folks because there are just so many twitter accounts. And after all this is a public tracker.

On Fri, 10 Nov 2017 13:17, noreply@dev.gnupg.org said:

@aa: From the mail address associated with @t62q7_aa I assume that this is an alias of your. If that is really the case please delete this alias and do not create another one. That would not be acceptable use.

It might be easier to include a regexp implementation in GnUPG proper. This way we have a well defined behaviour and it will work also on Windows. The gpg-check-pattern tool might slightly change its behaviour, though.

Right, we can't do anything in Libgcrypt except for adding a way to return the open fds. This is the usual problem with libraries and the required closing of fds before an exec. Anyway the FIPS mode is questionable because it has not been adjusted for many years and does not take account newer requirements.

Please take discussions to the mailing list. A bug tracker is not a good place for it because only a few will see that.

The thing is that I don't see this bug with verbose logging enabled. So we need to do more code starring or instrument the code

gpg-connect-agent is used by gpgconf to make things easier. Adding socket playing games is the opposite of simplifying things.

The default for the timeout are 100 seconds. I will chnage that to 15 seconds which is the same what we use for keyservers.

This dialog actually belongs to Kleopatra. I added the respective tag.

However you can tell gpg-agent to let gpg ask for the passphrase. Add

Passphrase handling changed a lot with gpg 2.1.

Can you try to kill the gpg-agent process from the task manager before you create the second keypair? If that helps the problem might be the same as T3378. Are you creating a standard key (ie. rsa2048) or something else?

We won't have a solution for 2.2.2 but I added --2k-count as a workaround
(rG78a6d0ce88ae) and the GETINFO subcommands s2k_count_cal and s2k_time.

Also failed to replicate on Windows-7 using a dedicated laptop.

I have still problems to reliable replicate this bug. I tried on Windows-7 on real hardware without success.

Done. Will go into 2.2.2.

Please explain what you mean by "recreate the keypairs". What do you mean by "server" - are you using gpg4win on a headless Windows installation?

Put

log-file /foo/bar/dirmngr.log
debug network,dns,ipc
verbose

into ~/.gnupg/dirmngr.conf and restart dirmngr "gpgconf --kill all". Then run your gpg command avain (a single -v is sufficient). Does the log reveal something?

Thanks. that was a good hint. I merged your report into T3378.

I tested for several days with logging enabled but was not able to replicate it again. Then I tried again w/o logging and couldn't replicate it either.

Shall we mark that for backport to some 2.2 version?