Werner: Yes please.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 20 2016
Apr 19 2016
I have some stashed work to fix this but it is not ready - let me know if you
want to work on it.
*See also T2070
See also issue20170
Apr 15 2016
I understand the reason for re-encrypting -- i'm quite happy that the agent is
sensible about improving the security of the key when it adopts it.
my concern is that users don't know what to expect, and that different workflows
result in different sets of keys stored in the agent.
So i'd recommend that when importing without --batch, if the password fails for
any reason, gpg should fall back to the fast migration "kludge" rather than just
skipping that keyblock. That way the imported secret key material will still be
available and can be cleaned up/hardened on first successful use.
Mar 23 2016
Thank you for your report and the log, but it doesn't have useful information so
that I can debug.
The information of card reader is required, if the problem happens for specific
card reader only. Please include full log which includes card reader information.
Mar 22 2016
There seems to be a problem with your reader. We would need to closer analyze
the log (which I copy below):
DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0
DBG: ccid-driver: PC_to_RDR_IccPowerOn:
DBG: ccid-driver: dwLength ..........: 0
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 145
DBG: ccid-driver: bPowerSelect ......: 0x01 (5.0 V)
DBG: ccid-driver: [0008] 00 00
DBG: ccid-driver: RDR_to_PC_DataBlock:
DBG: ccid-driver: dwLength ..........: 21
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 145
DBG: ccid-driver: bStatus ...........: 0
DBG: ccid-driver: [0010] 3B DA 18 FF 81 B1
DBG: ccid-driver: [0016] FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C
DBG: ccid-driver: PC_to_RDR_XfrBlock:
DBG: ccid-driver: dwLength ..........: 4
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 146
DBG: ccid-driver: bBWI ..............: 0x00
DBG: ccid-driver: wLevelParameter ...: 0x0000
DBG: ccid-driver: [0010] FF 11 18 F6
DBG: ccid-driver: RDR_to_PC_DataBlock:
DBG: ccid-driver: dwLength ..........: 4
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 146
DBG: ccid-driver: bStatus ...........: 0
DBG: ccid-driver: [0010] FF 11 18 F6
DBG: ccid-driver: PC_to_RDR_SetParameters:
DBG: ccid-driver: dwLength ..........: 7
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 147
DBG: ccid-driver: bProtocolNum ......: 0x01
DBG: ccid-driver: [0008] 00 00 18 10 FF 75 00 FE
DBG: ccid-driver: [0016] 10
DBG: ccid-driver: RDR_to_PC_Parameters:
DBG: ccid-driver: dwLength ..........: 7
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 147
DBG: ccid-driver: bStatus ...........: 0
DBG: ccid-driver: protocol ..........: T=1
DBG: ccid-driver: bmFindexDindex ....: 18
DBG: ccid-driver: bmTCCKST1 .........: 10
DBG: ccid-driver: bGuardTimeT1 ......: FF
DBG: ccid-driver: bmWaitingIntegersT1: 75
DBG: ccid-driver: bClockStop ........: 00
DBG: ccid-driver: bIFSC .............: 254
DBG: ccid-driver: bNadValue .........: 16
DBG: ccid-driver: PC_to_RDR_XfrBlock:
DBG: ccid-driver: dwLength ..........: 5
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 148
DBG: ccid-driver: bBWI ..............: 0x00
DBG: ccid-driver: wLevelParameter ...: 0x0000
DBG: ccid-driver: [0010] 10 C1 01 FE 2E
DBG: ccid-driver: RDR_to_PC_DataBlock:
DBG: ccid-driver: dwLength ..........: 4
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 148
DBG: ccid-driver: bStatus ...........: 0
DBG: ccid-driver: [0010] 00 82 00 82
DBG: ccid-driver: invalid response for S-block (Change-IFSD)
apdu_send_simple(0) failed: unknown host status error
DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0
Mar 21 2016
Without pcscd running, I get a "Not supported" error. The scd.log is attached.
Using pcscd, it works, except for that special case.
debug 2048
debug 1024
is what I need.
Thanks. We need to know some more detailed information. Please
put
debug 2018
debug 1024
log-file /somewhere/scd.log
into scdaemon.conf, kill scdaemon and try again. It seems you have not yet been
asked for a PIN so the log won't reveal the PIN. Anyway, you may want to send
the log to me by PM (wk@gnupg.org - key 1e42b367).
Mar 19 2016
Fails with 2.0.29 too, compiled from source. With enabled debug-all verbose in
scdaemon.conf, the log ends with:
2016-03-19 10:12:09 scdaemon[1988] DBG: response: sw=6A88 datalen=0
2016-03-19 10:12:09 scdaemon[1988] operation decipher result: Missing item in object
2016-03-19 10:12:09 scdaemon[1988] app_decipher failed: Missing item in object
scdaemon[1988]: chan_7 -> ERR 100663364 Missing item in object <SCD>
scdaemon[1988]: chan_7 <- RESTART
scdaemon[1988]: chan_7 -> OK
Mar 17 2016
We should create a test case for trust signatures before we start to fix it.
The current version is 2.0.29 - please try again using this version.
Mar 12 2016
Mar 1 2016
Marking as resolved since this is available in 2.1 and we are not going to
backport this to 1.4 or 2.0. Thanks.
Feb 15 2016
I guess you are reporting for GnuPG 2.0 or 1.4.
We already implemented your suggestion in 2.1.
Feb 11 2016
Feb 2 2016
Why is this a reasonable assumption? This proposal changes the way that GnuPG
has been working for years and will inevitably break someone's setup. It would
be much better for the receiver to use a non-critical notation to indicate the
desired behavior.
Apr 10 2015
Please give me the output of lsusb -v -d 058f:9540
and debug log of scdaemon.
Do you mean --card-status works bug --decrypt fails?
Apr 9 2015
Aug 6 2014
There are no known attacks on SHA-1. MD5 is disabled anyway in recent versions.
But please continue at gnupg-users - if you like.
Thank you for the prompt response.
I am familiar with the standard. The only violation of a MUST I'm aware of is that
recipient and personal digest preferences are ignored for hashes with known attacks;
perhaps some of these changes cause GnuPG to behave badly in other cases?
This has been discussed at gnupg-users at lengths. You need to read the OpenPGP
standard to understand some of the defaults. For the others you may start yet
another disucssion thread at gnupg-users.
re 4) The iteration count used depends on the machine.
Aug 5 2014
Feb 17 2014
Feb 14 2014
Sorry for the delay, the passphrase is 512 characters long (now I should change
it after publishing that here ;-)) and just ascii characters.
Jan 23 2014
With GnuPG 1.x, Enigmail takes care of presenting the passphrase dialog.
With GnuPG 2.x GnuPG does it of its own. For that it spawns a small tool
called pinentry which asks for the passphrase. We actually have several
versions of that pinentry. The one you are using is based on Qt (a toolkit) and
has a limit of 256 bytes for the passphrase. The limit may actually be lower if
you are using non-ascii characters, but I can't see how that value is not
sufficient.
How long is your passphrase and does it contain many non-ascii characters (e.g.
Umlauts)?
Jan 22 2014
Hello, Thank you for your reply.
I used the gpg4win-2.2.1.exe binary which I downloaded from gpg4win.org
The popup I mentioned is the screen that asks me for my password when I try to
open an encrypted mail in my mailbox via thunderbird/enigmail. See the
screenshot. In the newer gpg version this popup is replaced by a prompt screen
that says pinentry and will allow only for shorter passwords.
I understand that my password is exceptional long, as I still was (and maybe
still am) a beginner on the encrypted mail part. But backwards compatibility
seems pretty important in the case of encrypted mails and passwords to decrypt them.
Jan 8 2014
What do you mean by "openpgp popup"?
Which installation options did you used whethn installing gpg4win? Depending on
the version you get a different pinentry version - we have a qt based one, a GTK
based base, and a very simple native windows pinentry.
Dec 27 2013
Nov 8 2012
Fix for 1.4.13 (commit 64e7c23).
Aug 26 2011
Aug 13 2011
Mar 12 2011
Oct 21 2010
Hello Werner,
Hallo Werner!
Oct 20 2010
For the given use case you should ask the former employee to revoke the uid.
And in case you can't contact him, the signers may revoke their signatures
(--edit-key, "revsig").
Oct 15 2010
May 25 2010
Dec 21 2009
We can't do anything about it.
Cards with manufacturer id 5 and serial numbers up to 346 (0x15a) are affected.
Newer cards work fine.
Dec 17 2009
Done in trunk (2.1), rev 5233
Sep 3 2009
This is now a known problem. The likely reason is bug in the card's code. The
workaround is to forget about card based 3072 bit encryption keys.
Sep 1 2009
Does the fact that I can encrypt, sign, and authenticate correctly with 3072 bit
keys affect your hypothesis?
According to http://pcsclite.alioth.debian.org/shouldwork.html#0x0B970x7762
this reader should work but it has not been tested.
Aug 26 2009
Is there any more information I can provide? Can you reproduce it?
Aug 18 2009
This is the built-in reader in my Dell Latitude D430, by the way.
This is the relevant lsusb output:
What card reader are you using?
Aug 17 2009
Dec 15 2008
Dec 10 2008
Closing this report. If further support is required, please reopen.
Dec 8 2008
Dec 5 2008
Oct 23 2008
Note: It also works for gpgme_op_decrypt_verify, but the error code
GPG_ERR_NO_DATA needs to be ignored in this case. This is because we didn't get
a DECRYPTION_OKAY status message, and this is semantically the same as for a
signed but not decrypted file. We can consider making this case better in a
major upgrade when we change the ABI anyway, but not now.