This is strange, something in your setup must be different from other users. Any Idea what might be special for you? In your log it looks like only the send event for the encrypted mail is passed.
Where do you send your mails to, to another user on the same exchange server?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jan 9 2018
my <output> was the following...
FWIW, I ran the same test with three card versions:
I can confirm that PGP/MIME works ok for me.
What is the output of
gpg-connect-agent --dirmngr 'getinfo dnsinfo' /bye
and what is the content of your /etc/nsswitch.conf and /etc/resolv.conf ? Is there anything special in your /etc/hosts? Are you using any kind of non mainstream DNS resolver on your system or network?
I forwarded the bug report to the OpenPGP card author.
I think that 2.0 card is OK, 2.1, 2.2, and 3.3 card have this bug.
I disabled all my add-ins and tested it again. Still the same. Mails are sent unencrypted.
Tried also to send a plain text message
I attached the actual log file
Add-Ins are disabled...
Tried also with full disabled virus protection
and disabled hardware acceleration...
Jan 8 2018
$ gpg --debug-level guru --search-keys CEB167EFB5722BD6 $ cat dirmngr.log 2018-01-08 20:06:37 dirmngr[1085.0] permanently loaded certificates: 141 2018-01-08 20:06:37 dirmngr[1085.0] runtime cached certificates: 0 2018-01-08 20:06:37 dirmngr[1085.0] trusted certificates: 141 (140,0,0,1) 2018-01-08 20:06:37 dirmngr[1085.6] handler for fd 6 started 2018-01-08 20:06:37 dirmngr[1085.6] DBG: chan_6 -> # Home: /home/walz/.gnupg 2018-01-08 20:06:37 dirmngr[1085.6] DBG: chan_6 -> # Config: /home/walz/.gnupg/dirmngr.conf 2018-01-08 20:06:37 dirmngr[1085.6] DBG: chan_6 -> OK Dirmngr 2.2.4 at your service 2018-01-08 20:06:37 dirmngr[1085.6] connection from process 1084 (1000:100) 2018-01-08 20:06:37 dirmngr[1085.6] DBG: chan_6 <- GETINFO version 2018-01-08 20:06:37 dirmngr[1085.6] DBG: chan_6 -> D 2.2.4 2018-01-08 20:06:37 dirmngr[1085.6] DBG: chan_6 -> OK 2018-01-08 20:06:37 dirmngr[1085.6] DBG: chan_6 <- KS_SEARCH -- CEB167EFB5722BD6 2018-01-08 20:06:37 dirmngr[1085.6] DBG: dns: libdns initialized 2018-01-08 20:06:37 dirmngr[1085.6] DBG: dns: getsrv(_pgpkey-https._tcp.hkps.pool.sks-keyservers.net) -> 0 records 2018-01-08 20:06:37 dirmngr[1085.6] DBG: dns: resolve_dns_name(hkps.pool.sks-keyservers.net): No name 2018-01-08 20:06:37 dirmngr[1085.6] resolving 'hkps.pool.sks-keyservers.net' failed: No name 2018-01-08 20:06:37 dirmngr[1085.6] number of system provided CAs: 156 2018-01-08 20:06:37 dirmngr[1085.6] DBG: dns: resolve_dns_name(hkps.pool.sks-keyservers.net): No name 2018-01-08 20:06:37 dirmngr[1085.6] resolving 'hkps.pool.sks-keyservers.net' failed: No name 2018-01-08 20:06:37 dirmngr[1085.6] can't connect to 'hkps.pool.sks-keyservers.net': host not found 2018-01-08 20:06:37 dirmngr[1085.6] error connecting to 'https://hkps.pool.sks-keyservers.net:443': No name 2018-01-08 20:06:37 dirmngr[1085.6] command 'KS_SEARCH' failed: No name 2018-01-08 20:06:37 dirmngr[1085.6] DBG: chan_6 -> ERR 167772380 No name <Dirmngr> 2018-01-08 20:06:37 dirmngr[1085.6] DBG: chan_6 <- BYE 2018-01-08 20:06:37 dirmngr[1085.6] DBG: chan_6 -> OK closing connection 2018-01-08 20:06:37 dirmngr[1085.6] handler for fd 6 terminated
That is likely "host not found" or "domain not found". Maybe a problem with your resolver. Please add
I believe that this was fixed in T3658 which reported more clearly what was attempted to verify and what failed.
Indeed, thanks for the note. I added the variable only later on for the check of protocol unknown and overlooked to update the setProtocol call.
I've updated the code accordingly.
I can reproduce the issue but only for PGP/Inline, encrypted only mails. PGP/MIME works finde. This allows for an easy workaround (sending PGP MIME) so Prio down to Normal.
All e-mails I tried to open with 2.0.6-beta7 gpgol.dll were readable and showed the correct content in my environment, now. Great!
@aheinecke thanks for the fix. But I have a suggestion for the code(I only looked at the diff):
While trying to reproduce another bug I've set up an account with Exchange Online. With that account I had similar behavior with empty mails shown. The behavior also matched to the logging of the last mail in your log.
In the folder %APPDATA%\gnupg create a file named gpg.conf (or edit it if it exists) and put the line "ignore-mdc-error" in there. This should globally set this option and gpgol will also respect this.
Fixed for 2.2.5. Thanks for the report.
You might want to look at: https://wiki.gnupg.org/TroubleShooting#Passphrase_on_the_command_line
Can you please run debugview ( https://technet.microsoft.com/en-us/sysinternals/debugview.aspx ) and attach or paste any lines here that start with "org.kde.pim" when you try to encrypt the folder?
Thank you for your report. I can reproduce this problem. Kleopatra correctly looks for the signature file but then fails to set the protocol. This results in an internal error.
Prio High as this makes GpgOL unusable in such a setup.
I give this high priority as sending unencrypted is pretty much a worst case scenario. :-o
In T3714#109045, @Lloyd wrote:I appreciate the dangers. Whilst I try and persuade the sender to deal with the issue at their end, is there anyway to include this option in GpgOL on a temporary basis?
Jan 7 2018
I have attached a small patch to show this two additional key flags with "--list-keys":
Hi, Werner.
My OS has everything compiled from sources obtained from devs as they release them. Funtoo Linux is a derivative of Gentoo Linux.
Hence, the default behavior of the software is not altered except when removed some of its features, but I've installed gnupg without alteration.
Jan 6 2018
So the assumption is it is an Error of the GnuPG card.
I tried today with an Yubikey 4 and it works. This confirms the theorie.
However - my preference is on the Smartcards. So how would we proceed now. Who can check for the error and correct it / flash a new version on a card.
I would offer to verify if it is fixed.
This looks more like an Enigmail bug. In particular the manual start of gpg-agent as described in the workaround is useless because gpg-agent is always started as needed. I don't know your OS and thus I do not know whether gpg-agent is used in --supervised mode, as in Debian, or in the default way. What does
The first thing you should do is to write a proper bug reporting, including your OS, any special configiration you use (e.g. using a dedicated DNS sever) and the exact commands you give and outputs you see. Always use option -v with gpg. dirmngr can create a log file:
Despite that the use of a passphrase is entirely useless if a command like that is used, you need to add
--pinentry-mode=loopback
to the invocation. ( I assume you are using gnupg 2.1 or 2.2)
Andre, I assign this to you. If you don't think that a better warning in Kleopatra is needed, please close the report.
Jan 5 2018
OK. Thank you for that.
Thanks for asking. We may need to put this into the FAQ, so here is my answer:
Forgive me if I'm completely off the mark here. In no way do I claim to fully understand gpg etc.
Here is an extract of the log file which shows the assumed cause
The last line shows that gpg decided that to return a failure because the message does not use the MDC scheme. Since the introduction of modern algorithms with a _blocklength_ of 128 bit (e.g. AES) gpg always uses the MDC encryption system even if it is not announced by the respective key flags. The reason for theses algorithms are newer than the MDC system and thus we can expect that all applications supporting AES will also support MDC.
Ignore my previous comment - seems that if I'm off our corporate network, I have the issue. Back on the network, Kleopatra is ok, and the gpg command completes. (I suspect that there is a firewall rule required, as the firewall is only enabled off network.)
OK. I managed to reproduce same behavior. I think that it is a bug of OpenPGP card implementation.
Here is the log:
In the log above, I did for RSA-2048. I also did for RSA-4096. The result was same: it was failed with 6A88
I guess that the implementation somehow confuses with the sequence of 00 02 which appears with 3DES.
Jan 4 2018
Tried that, and it complained that the gpg-agent was not running. Now Kleopatra fails to , constantly trying to load certificate cache. Self test fails on UiServer Connectivity. Was fine up to that point.
I guess that the MDC indicated a broken encryption or no MDC was used at all. Can you pleae run the decryption of the file on the commandline? Assuming that thar the file is msg.eml you do:
I sent the gpg: DBG: DEK frame via encrypted eMail to you. Hope this helps.
FWIW, the old format was only used up to PGP 2.3 . PGP 2.6 used the new format. This is actually more indication that the message has not been generated by an old PGP version.
Could you please give me the debug output line for DEK frame: by encrypted mail to me? So far, I can't find any likely scenario where an error occurs with smartcard. (Use of PGP2.6 is unlikely.)
Jan 3 2018
Agreed, Signing subkeys can be useful for checking historical signatures. And even encryption subkeys *can* be useful after their expiration, e.g. when doing historical auditing.
Jan 2 2018
By the given version number, do you mean: with gpg4win 3.0.1 it worked with 3.0.2 id does not work anymore?
Please explain en detail what you are trying to do and what the error is. Thanks.