/*here in where I am ... we can always go down to Turing primitives and maths*/

/* what? */

This might be a reason that we got multiple reports for Kleopatra since 3.0 was released that it hangs on keylisting: https://bugs.kde.org/show_bug.cgi?id=381910

Everything works correctly but the warning message is probably too cryptic. It means that the signature could not be checked because the public key that created this signature is not found. It needs to downloaded, imported and verified. (See: https://www.gpg4win.org/package-integrity.html )
We improved the warning message with gpg4win-3.0

This means that the MAPI to MIME conversion did not happen.

Jochen could you please test this on one of our test VM's again and resolve this then?

I've added a note about this in the wiki: https://wiki.gnupg.org/TroubleShooting#Passphrase_on_the_command_line

A new binary for GpgOL can be found under: http://files.gpg4win.org/Beta/gpgol/2.0.2-beta8/ or for http://files.gpg4win.org/Beta/gpgol/2.0.2-beta8_x64/

Nagi: The third suggestion (adding "--pinentry-mode loopback" to your command) should work in that case.

This is intentional with the rationale being that users either want ascii armor for some reason for all their usecases or they don't want it.
And most users won't even know what ASCII Armor means (Adding "Armor" sounds like additional protection). So we moved this setting into configuration and renamed it.

Indeed bug in Kleo, it was always 0 in kleo. (likely created during Qt5 port) fixed with: https://commits.kde.org/kleopatra/0d53416cfbe6d8fa087887c428cdfffb13514a7d

@aheinecke Regarding closing: I'd say that we should have a test on this one and then close it for only the refocussed "send-folder problem".
Can you provide an updated gpgol.dll drop in replacement?
Some of the users in the forum may be willing to test as well.

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

I think this is resolved here. As we now have the check in the installer to warn on Vista and disable Kleo / pinentry-qt

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.

No problems, if you get struggled I am here up to go extra mile for an ideal. Regards "convenience" ... well I quite agree with Richard Stallman on the specific topic the trade off between " freedom Vs convenience" https://www.youtube.com/watch?v=CP8CNp-vksc (jump to video @1minutes, 15 seconds) ;-)

So, to protect against this attack, the client needs to do both of the following:

Here are two examples:

@werner suggests using an ephemeral home directory. this is an important point.

@justus asked for examples.

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.

Hi, Werner what are the machinery requirements required for running the VM ? I can try to squeeze my academic schedule to do it but I probably would like to change twitter login for something more 'GNU' such as https://mastodon.sdf.org/about

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.

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.