For what is worth I think sanitize_regexp was programmed while reading 4880 because the RFC allows backslash + any character (section 8: Regular Expressions):

It might be not a regression. The possibilities are: (1) it was tested by using non-GNU operating system. (2) Tests didn't cover characters (b, B, w, W, s, and S).

For the reference sanitize_regexp was introduced in this commit from 2007 to "Protect against malloc bombs.": and I see no changes to it (except typo correction) in git blame in trustdb.c.

I confirmed that clock is better on FreeBSD, too. And FreeBSD has clock_gettime with CLOCK_THREAD_CPUTIME_ID.
I tested FreeBSD 11.1 running QEMU.

# My update of D450: clock_gettime if CLOCK_THREAD_CPUTIME_ID is available. has gone somewhere. So, I update it again.

Passphrase handling changed a lot with gpg 2.1.

I'll try that when it happens again. Thanks

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?

The OS runs Windows 2008 R2 , on a Oracle's Virtualbox, so I wouldn't consider this being a headless Windows installation, why? When you first create your keypairs it goes pretty fast usually under 5 mins. But if you recreate or try an create a new keypair it never completes, takes 20+ minutes or longer. But if you shut down the OS, or restart the OS, and try it again then it completes in under 5 mins.

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.

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

That's your building problem, not the problem of gnupg.

I cannot explain why it works now

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.

By the way: This is when I try to use a key stored on my hard disk. I have never had any issue like this with those keys in previous versions, but I have always had similar problems with keys stored on my smartcard.

gpg is required by several parts of GnuPG. Tracking dependencies for it for the esoteric case of not building it does not make any sense. Thus the option will be removed from from master.

Did you run gpg before your copying $HOME data and after your installation of Stretch?
That gpg invocation create the file ~/.gnupg/.gpg-v21-migrated, which marks "the migration finished".

What do you think about a special case for the homedir "/dev/null" ? We use this device as a specila value at other places too. I have often seen "/nonexistent" in /etc/passwd but there is no standard for this. However, /dev/null is well defined.

Actually before the fingerprint, which is a general argument and not an argument to -k. Thus

OK, closed.

GnuPG is picky about the order of options. Please put "--list-options show-photos" before -k.

I am experiencing this error too and did not see any way to get to the Pinentry window. Only after killing the hung outlook process did the Pinentry window pop up.

When receiving an S/MIME mail that is encrypted, the successful log looks like:

clock returns CPU time on POSIX, wall clock time on Windows. For threads, I don't know.

Comparing the gpgol.log files in the case of OpenPGP decryption (successful) and S/MIME decryption in send folder (failing).

Here is the link to the wald report by John Mrkva:
https://wald.intevation.org/forum/forum.php?thread_id=1785&forum_id=21&group_id=11

Thanks for testing and proposing new patch.

Same here: I can confirm the bug. I can move an email, if i unselect it before an then use its context menu to move it.
This behaviour is already mentioned in the readme:
c:\Program Files (x86)\Gpg4win\share\gpg4win\README.en.txt

Oh sorry i mixed my explanation. I create a normal encrypted file with gpg --encrypt and this file can be decrypted successfully with "gpg -d".
But if I give that encrypted file to gpgme i get the described error, instead of GpgME::Error(0 (Success))).

OK, the problem with D450 lies in the way the value obtained from clock_gettime(2) is used.

agreed, generically changing this check to log_info doesn't make sense. However, in *this circumstance*, gpg actually has no error.

Hi,
I have tried this on Windows 10 (1511,1703,1709&RS4TP)
Gpg4win Version 3.0.0
Regards

Hi,
I was using Windows 7 Professional.
The last version that worked was gpg4win 2.3.4 (I didn't try any beta or rc), and encryption/decryption works fine for single files.

It turns out I cannot reproduce the bug with a 4.13.2 kernel. Whatever happened to times in slightly older kernels when VIRT_CPU_ACCOUNTING_GEN was enabled seems to have been fixed in newer kernels.

"gpg -d" decrypts data why do you think you can decrypt or verify it again?

Why I shouldn't do that? Sorry, but I can't see a reason to pin the installation directory to a predefined value ("well known location").
Then, why can I still change the installation directory for gpg4win?

You can't and you shall not.

Hi, thanks for the report.

I have also experience the same bug and reported it on:
https://bugs.kde.org/show_bug.cgi?id=385390

$ gpg --homedir /notexistent -dv <1.msg --override-session-key 7:D6E1027D58A0CB047C41EA881A137197 --status-fd 2 
gpg: keyblock resource '/notexistent/pubring.kbx': No such file or directory
[GNUPG:] ERROR add_keyblock_resource 33587281
gpg: public key is 7F3B7ED4319BCCA8
[GNUPG:] ENC_TO 7F3B7ED4319BCCA8 18 0
[GNUPG:] ERROR keydb_search 33554445
gpg: encrypted with ECDH key, ID 7F3B7ED4319BCCA8

Indeed, this makes gpg return 2. The reason is that the first error message uses log_error which sets a flag to have gpg return 2. Now, changing this to log_info may produce problems for applications which expect that gpg errors out for a bad homedir.

can you try it with --homedir /does/not/exist

I got it working.. turns out I had to force a migration by doing an rm ~/.gnupg/.gpg-v21-migrated.

Thanks!

The Linux specific solution in /D450 looks like a good solution but it needs some testing.

But how can I influence the target directory for GnuPG during an automatic installation? We are not using the default directories.

Right, this differs. GnuPG is now installed at a well known location. Actually the Gpg4win installer includes the standard GnuPG installer and it is possible to update just GnuPG without a need to update the entire gpg4win.
This avoid multiple installs of GnuPG with all its problems.

Hello all together,

I close this for now. If you run into problems with 2.2.2 again, please re-open this bug.

Thanks for the list

Using an npth function is not good because we want to come up with a reasonable iteration count. Allowing npth to switch threads would not be good. The Linux specific solution in /D450 looks like a good solution but it needs some testing.

Yesterday I could reproduce that emails in the "send" folder cannot be decrypted anymore.

How about D450: clock_gettime if CLOCK_THREAD_CPUTIME_ID is available.?

Here is the list:

• libgcrypt
• libassuan
• ntbtls
• gpgme : autogen.sh is ready
• npth

Applied to 2.2 branch.

I fixed for master.
It will be into 2.2.

This week I'm trying to make progress with this issue.

Confirmed, this is the exact same problem!

Thanks!

Just tried this but can't replicate it:

$ ../g10/gpg -dv <1.msg --override-session-key 7:D6E1027D58A0CB047C41EA881A137197 --status-fd 2 
gpg: public key is 7F3B7ED4319BCCA8
[GNUPG:] ENC_TO 7F3B7ED4319BCCA8 18 0
gpg: encrypted with ECDH key, ID 7F3B7ED4319BCCA8
[GNUPG:] BEGIN_DECRYPTION
gpg: AES encrypted data
[GNUPG:] DECRYPTION_INFO 2 7
gpg: original file name=''
[GNUPG:] PLAINTEXT 62 1508859245 
[GNUPG:] PLAINTEXT_LENGTH 68
"Well hello there Charlie Brown, you blockhead."
                -- Lucy Van Pelt
[GNUPG:] DECRYPTION_OKAY
[GNUPG:] GOODMDC
[GNUPG:] END_DECRYPTION
$ echo $?
0
$ gpg -k 7F3B7ED4319BCCA8
gpg: error reading key: No public key

Unfortunately --batch option doesn't help, it only suppresses user input.

$ gpg2 --pinentry-mode loopback --batch --delete-secret-keys F4433F96910C9AC1FEF65A7299A5538C769B6150
gpg: deleting secret key failed: No pinentry
gpg: deleting secret subkey failed: No pinentry
gpg: F4433F96910C9AC1FEF65A7299A5538C769B6150: delete key failed: No pinentry

GPG pinentry works well on my Gnome desktop (wellformated form appear) but I have a problem when I need remove secret key (enter passphrase) on remote machine via SSH.
It can be handled with --export why not with --delete-secret-keys?
Is there some fix already? Or roadmap this will be fixed? Or some workaround how can I remove secret key remotely via SSH?