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.

Jochen can you please confirm that this works reliable for you too?

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.

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

if you're do not have an infinite time, at CERN we're about experimenting stuff at plank scale ...

do you have infinite time, just asking ...

This is not an issue of GnuPG. Sorry.

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.

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

OK, i've pushed 0471ff9d3bf8d6b9a359f3c426d70d0935066907 and 149041b0b917f4298239fe18b5ebd5ead71584a6 to branch T3490-proposal1. It cuts GnuPG's own simple test suite down from about 3 minutes to 1.5 minutes for me. I haven't tested the speedup for the full test suite yet.

To clarify, i'll push them to a separate branch for you to decide whether to merge.

I'll push some patches for proposal 1.

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.

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.

the UP arrow can be trick ... it reminds me the whole thing about Apollo Missions ... the navigation system;

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.

Well, I gues it's complex enough to warrant strategic discussion, which can be done in this ticket :)

I built gnupg 2.2.1 with the patch from D450, but that didn't help.
I even got an additional error:

In the autocrypt spec, this is called a "setup code", not a "backup code" :)

So maybe there is also a display problem, as I saw 0:00 in Kleo. I have to recheck.

Yes, it will be in 2.2.3. It's too late for 2.2.2.

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

So is 380bce13d94f the correct fix? If so, I will update the OpenBSD port including this as a local patch.

I believe this is due to the bug of gpg-agent. So, I put this report as a sub task under T3276: the calibrate_get_time() function depends on a system that has a non-tickless kernel.