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.

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

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:

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.

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.

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

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

Thanks you very much for your quick reply. I added your code to my invocations for decryption and signing and all is well now. You probably saved me many hours of searching with your kind reply!

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

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.

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?

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

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.

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:

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

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

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.

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.

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,

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

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

I tried to melt it down to a specific beta release with which it isn't possible anymore to decrypt send emails.

Since this is a bug that is related to two different parts of the gpg4win package, this bug now only cares about the GpgOL Issue, that GpgOL crashes and cant decrypt messages from the sent folder that are encrypted with S/MIME. All File Based Issues are belonging to Kleopatra are documentet in the KDE Phabricator (https://phabricator.kde.org/T7310).

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.

2. Files that are Signed and Encrypted to a S/MIME Certificate is broken. When you select a file and encrypt and sign it to a recipient, only a detached signature will be created and the Encrpyted file is missing. (Very similar to Issue 1, but file based).

https://phabricator.kde.org/D8368

Please look in the status bar of your desktop. You should see a (blinking) tab for the Pinentry. Unfortunately it is not always possible to get the Pinentry into the foreground and Windows will instead show it in the status bar.

Same here on current stable (3.0.0):

2.0 will reach EOL soon and we have received no response. Thus closing. If the problem persists with 2.2 (e.g. from gpg4win 3.0) please re-open this bug.

GnuPG does not mess with suffixes but Kleopatra has some rules of it own which might be common to KDE. I thus flag your report as a feature request.

This is exactly what I was looking for --> Settings > Configure Kleopatra > Crypto operations > Create signed or encrypted files as text files
Thanks!

I would suggest to close this report even that I have the same problem with the g10 Code cert on Vista - but it used to work when I bought that cert.

Hello Jochen,

There is just another person experiencing the same problem with an Exchange based account on Win10pro x64, Outlook 2016 x86.

I don't have access to this description. I used official, newest releases. I searched for this issue on the web, on the gpg4win page but did not find a solution. Is there any accessible information?

In T3457#104401, @werner wrote:

gpg --print-mds  FILES
gpg --print-md ALGO FILES

With that in place, I think there is no need to add them to the PATH.

So far we could recreate the following issues:

DLL hell. There are no command line tools and thus tehre is no need to put them into PATH. Well, except for the shasums - if that is really required, put them into a different directory but that needs to synced with Kleopatras use.

In what kind of problem should we run by adding it to the path?

The gpg4win 3.0 installer does not have the option to install documentation, therefore the docs are missing on purpose. This is done to lower the footprint of the installer, but they are of coursestill available via the homepage.

Why should that be useful? It will only run us into lot of problems.

Additional report in https://wald.intevation.org/forum/message.php?msg_id=5308

There are more Logfiles:

Then this is a duplicate of T3442 as well! Thank you for you Logfiles and your report!

I have both types of certificates stored in kleopatra; S/MIME from StartCOM and OpenPGP created by Kleopatra.

What I mean is that the installer does not install the documentation (I even de-compressed the installer "gpg4win-3.0.0.exe" with 7-zip: PDF doc archives are present in this version but links to the PDF files are not installed) nor the menu in the "Start Menu" (see below the Menu correctly installed by "gpg4win-2.3.4.exe" but not available at install time and by the way not installed in the Menu drop list (OS: WIN7 64-bit, US).

Duplicate of T3441.

What menus did you miss? Do you mean the right-click menus or kleopatra/gpa in the start menu?

You could try to use NO-MIME (or PGP/INLINE) instead of the OpenPGP/MIME standard. You can change the way of packaging your encrypted content in the GpgOL Addin Options.

In T3448#104201, @werner wrote:

What is this Chocolatey?