No info received.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Nov 5 2018
Oct 16 2018
I finally got around to look at your examples. Sorry for the delay. I can reproduce the issue and understand the problem.
Sep 21 2018
updated example sent.
Sep 11 2018
@dkg does --no-keyring solves the problem for you?
We assume that this has meanwhile been fixed.
Sep 7 2018
I think this might be a ticket in itself. If I send a PGP signed email to someone who then responds to me, there should ideally not be issues with it - although I think it would be important to separate which parts are signed and which are not.
header of mail forwarded. looks like it says utf-8. either way, it does work with the right key.
Received. Thanks, so this is PGP Inline. Encoding handling in PGP Inline is always "Guessing" as it is no where defined which encoding is used for the message.
interesting. email sent.
Mmh no, I can't reproduce this and my initial hunch was wrong. We do in fact handle encoding in that case.
Sep 4 2018
Closing.
Aug 29 2018
@elonsatoshi: Were you able to check this with 2.2.9 which has a fix for the resolver?
Aug 24 2018
No response so closing as invalid.
May 17 2018
In another report, it turned out to be, that with a 64 bit outlook and GnuPG not installed in the standard location it came to this error. ( T3988 )
We've analyzed another report of this and the problem turned out to be that with a 64 bit outlook and GnuPG not installed in the standard location it came to this error. ( T3988 )
May 15 2018
Hi and thanks. Yes, I consistently reproduce. Here's the log file.
May 14 2018
Thanks for your report!
Apr 27 2018
Now there it gets complicated. According to the card software author in 3.3 and even 2.2 there is a fix. BUT there was a small amount of cards already created in 3.3 without the fix. Nobody ever told my how to diferentiate them.
There is no Version 3.3.1 you can by - it is only 3.3. So you can buy one and hope you have a good one.
At least this is my understanding.
Apr 26 2018
Does v3.3.1 fix this? (The release notes for it seem to imply that's not the case.)
Apr 19 2018
Let's use the new issue as the problem is described completely there and it makes it more clear.
Apr 18 2018
I already created a new issue for this in the new version of gpg4win (v3.1.0) with GpgOL v2.1.0. This is the issue: T3917.
Apr 13 2018
Apparently, your /lib/x86_64-linux-gnu/libgpg-error.so.0 is not the one you installed (I mean, libgpg-error version 1.27).
You need to install your new version of libgpg-error so that it is usable.
Please check your ldconfig or LD_LIBRARY_PATH, etc.
Apr 11 2018
Mar 22 2018
I'm closing this as I've got confirmation that one crash was fixed by disabling async encryption again. And a class of general "Crash when encrypting" bugs that were related to the communication between Kleopatra and GpgOL no longer exists as Kleopatra is no longer used when encrypting from GpgOL in gpg4win 3.1.0.
Mar 13 2018
Hallo Werner,
Mar 12 2018
New cards will come with a fix. I am not sure whether a production run has yet been done, though.
From one user I have received a debug log of the current beta where it apparently crashes in the dtor of the mail object after send.
Mar 10 2018
Hello again,
Mar 8 2018
At some point we really need to look at better error handling so that such an error would be more visible in the UI.
Mar 1 2018
Hi Andre
C:\Users\XavierFRUTON>gpg --gen-key
gpg (GnuPG) 2.2.4; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
I close this bug as wontfix. If you can provide the requested changes for libtool please re-open this bug.
Feb 28 2018
Is it possible that your %APPDATA% directory is redirected? Maybe you are running into T3818 I also got "General Error" when trying to generate a key because of that bug.
Feb 27 2018
@Ainahir thanks for the info. However, your problem might be different because you are on Windows and not on Linux.
Please use for dirmngr --debug=ipc,dns instead of --debug-level=guru
same behavior on gpg 2.2.1
Feb 26 2018
It's a bug in the OpenPGP card implementation.
I put an entry in Wiki: https://wiki.gnupg.org/SmartCard#Known_Bug.28s.29_of_OpenPGPcard
Feb 22 2018
No more info received - assuming this has been fixed after 1.2.20
Jan 24 2018
I close this bug - if you can provide the log files please feel free to reopen.
Jan 15 2018
For the 3.0.3 I tested more with Microsoft Exchange Online, an Exchange 2012 Server and could not reproduce such problems. So I'm lowering the priority to normal as I don't think many users are affected.
Jan 12 2018
Oh dear what an evening and morning. I reversed the facts I reported. Sure 2.1 is borken - that is the whole point. ( I realized that only after install 2.2.4 and generating fresh keys). To avoid confusion I will delete my last comments.
@werner It's just simple; With --personal-cipher-preferences 3DES (3DES only), make a encrypted message. Then, try to decrypt the message with OpenPGPcard (version 2.1 and later).
Jan 10 2018
I find your question confusing. I'm the reporter of this bug. All the efforts and tries of gniibe and myself are documented above.
Or do you refrer to something else ?
Can you exactly explain how you tested this?
I also have the 2.1 Card which has this bug
Version ..........: 2.1
Manufacturer .....: ZeitControl
Jan 9 2018
As this is still waiting for info for two years and I can't reproduce with current GpgOL -> Resolved.
FWIW, I ran the same test with three card versions:
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.
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.
Jan 5 2018
Here is an extract of the log file which shows the assumed cause
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
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.)
Dec 31 2017
The conformance problem may (only) happen between PGP 2.6 and OpenPGPcard, because PGP 2.6 uses old format not compatible to PKCS#1, but OpenPGPcard requires PKCS#1.
Dec 30 2017
Ok - thats good news.
Thank you very much for your analysis.
Dec 29 2017
OK, I got the picture, now.
Well, my speculation of SERIALNO undefined may be wrong.
Thanks, I received the log file.
Dec 28 2017
Thank you for your efforts. Logfiles is in the mail
Thanks a lot for your testing. Here are my keys:
Dec 27 2017
All right - that was quicker.
I deinstalled pcscd (apt remove pcscd)
I changed .gnupg/scdaemon.conf as you proposed.
I tried again to decrypt the message (in the meantime I have a file) which works decrypting withoutl SmartCard when I use it on a pc with the key.
Still failed. Can I send you the Logfile encrypted ? If so - what is you eMail / key.
As said - it took me a while. Sorry for the delay.
I could dig out the Key in some archives. So I was able to test the decryption of the message on a computer without smartcard.
It worked.
Dec 15 2017
Dec 14 2017
You start Windows Explorer (the file manager thingy)
I feel dumb for asking this, but I'm a Mac guy, and my client is on Windows 10. How do I exactly "move away the data directory"?
Dec 13 2017
Looking an example code of http://g10code.com/docs/openpgp-card-v21-free-source.zip (Note that this is just an example code), 6A88 can be occurred for PSO:DECIPHER when:
Dec 12 2017
Please reopen or comment if that problem still happens if you move away the gnupg home directory.
Dec 11 2017
Thanks a lot. Please note that there is a bit of possibility the messages which cause failure are one of attack vectors. (While most likely case is they are generated by broken implementation.)
Im mean GnuPG fails for messages from a particular sender, while it works for messages from other senders.
Do you mean, GnuPG fails for a particular message, while it works for other messages?
Or do you mean, GnuPG fails for messages from a particular sender, while it works for messages from other senders?
Dec 10 2017
The new reader arrived. Works find for every message - except obviously this one sender.
See reader https://pcsclite.alioth.debian.org/ccid/supported.html#0x04E60x5116 ti should support large APDU. Same error messages
I think we are on the wrong error track here. It is not the reader. I now tested 4.
Dec 8 2017
Thank you for your cooperation.
Dec 7 2017
I still have trouble beliving it is the reader. Since I tried now 3.
As well I have a 4096 bit key and everybody has been encrypting this with my key. Therefore it does not make sense to me.
I tried to reproduce this with current GpgOL and it just worked. Even if I connected Enigmail to Exchange (Outlook.com).
For Gemalto USB Shell Token V2, libccid has known issue: https://ludovicrousseau.blogspot.jp/2017/03/gemalto-idbridge-k30-k50-ct30-and-zero.html
I don't know about ACR 38U.
Dec 6 2017
Here two other Reader example - same message - same problem:
Reader: Gemalto USB Shell Token V2 (00483E73) 00 00
Reader: ACS ACR 38U-CCID 00 00
For Gemalto Shell Tokens: http://support.gemalto.com/index.php?id=tokens
There are three variants. Please describe detail.
Nov 1 2017
OK, closed.
Oct 26 2017
Oct 24 2017
Oct 20 2017
No info received, similar to another fixed bug, and for 2.0 which will soon reach EOL.
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.
Given that we received no info after nearly two years, shouldn't we simply assume that this bug as been fixed?
Sep 21 2017
No info received and thus assuming that the caching was disabled.
Sep 1 2017
Ok, I implemented this for Inline messages. The resulting armored literal data packet is encrypted as PGP/MIME message. I'm not sure this is what we want.
Aug 14 2017
Ok. Lets put this problem back until we have a possibility to encrypt through filters so that can maybe enable this just for some kind of reenecrypt workflow.
Aug 11 2017
To make this work again, I think gpg-agent needs to cache the public key or support batch-operations (which would require some restructuring in gpg to request such a batch-operation).
Aug 10 2017
Aug 8 2017
I'm closing this. Feel free to reopen the bug with more information.
Aug 3 2017
The platform is illumos, a fork of OpenSolaris.
I think you should take this up with the support of your in-house web service, and if the developers of it find a bug, they can report it here.
This looks suspiciously like T1547: gnupg >= 2.0.21 won't build on OSX 10.8.5 with XCode5.