I'm not sure why a special case should be needed -- failure to create
the .kbx should not be a failure for a decryption operation in general.

Ah well, no rules without exception.

I don't recall, but I suppose I did. It may not have been a manual invocation, but possibly a batch job from mutt or something.

In T3442#104402, @JochenSaalfeld wrote:

1. Mails encrypted with S/MIME are stored with "No Data" in the sent EMail folder, but arrive properly at the recipients (you will recieve a readable copy, if you add yourself to the list of recipients). This Issue breaks the GpgOL Plugin after some time which is leading to the described Problem.

This indeed is a mixup of the protocol detection and likely a regression from a fix for exchange support. (On Exchange emails from exchange to exchange look the same as sent mails as both don't go through the MIME conversion)

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

This error looks like an element might be referenced that is not available in Outlook 2010. In that case the problem should be reproducible for users that have Developer Options -> Show Add-In Errors enabled.

Fwiw I don't want to patch KDE Librarys to work with older Qt Versions and don't want to patch Qt to support older Windows Versions. I think greying out is a good solution.

Duplicated problem. Solution for the installer is described in: T3434

In T3434#103995, @werner wrote:

Indeed the notes for QT 5.9 do not anymore show Vista as supported. Stupid decision if you ask me.

In light of this I would suggest to tweak the installer to grey out QT applications for all platforms older than Windows 7. We also need to make pinentry-gtk the default in this case. Of course there should also be notes in the docs about these restrictions. And that should be done immediately.

Both my coworker and I have the same issue. We just started using gpg for git commit signing. Works the first time. Then sometime later, no window pops up and will hang git indefinitely because it's waiting on the agent. Kill the agent and gpg process let git error out. try again, gpg-agent window prompting for password shows up and works.

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.

No, I was not accurate. EXAMPLE.COM works, while example.com doesn't work.

I confirmed this is same bug in T2923: trust signature domain restrictions don't work, I am closing this one as duplicate.

Henry Spencer wrote three implementations (old, BSD, and Tcl): https://garyhouston.github.io/regex/
Indeed, for the one in old library and BSD library, \ + CHAR means that single CHAR.
For one in Tcl library, \s, \S, \w, \W is supported (just like GNU), and \d, \D (digit) is also supported.

ECDH on Curve25519 is fully supported in libgcrypt. You can see GnuPG supports ECDH on Curve25519.
Lower layer routines (point addition and point duplication) are not implemented, though.
That's because ECDH only requires point multiplication and it is better to implement point multiplication by Montgomery Ladder for Curve25519.

Fixed both for master and 1.8 branch.

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

Is there a more detailed logging that i can switch on? Perhaps i can help you to get diagnostic files. Nearly every day i notice this bug. In the log (with "verbose" in gpg-agent.conf) are the same entries i already posted.

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.