Fixed for 2.0. But take care: The code now also uses the fixed-list-mode which
is the default in --list-keys for ages:
pub:-:1024:17:4713D527ECE16009:1118095577:::-:
fpr:::::::::8BFD3F436366D9820E9EAB2F4713D527ECE16009:
uid:::::::::George Hacker <georgeh@axian.com>:
uid:::::::::George Hacker <ghacker@axian.com>:
uid:::::::::George Hacker (GLS) <ghacker@redhat.com>:
uat:::::::::1 2493:
sub:-:1024:16:0D94CF6C0C8C2F1B:1118095578::::
I worked with the guys and fixed versions have been released in time. The paper
and website actuallay tell this.
It is not the keygrip but the authority key identifier based lookup
which fails. Quite obvious if they do that stupid re-issuing. The
problem with dirmngr is only a side-effect of gpg not using the proper
certificate form the chain. Though, the question is which is the
proper certificate? They are both correct. I solved that my looking
for all matching certificates and using the latest one. That should
match reality better. Below is a log using a certificate store with
both DFN certificates. I have not done any Dirmngr tests, though.
The old certificate:
ID: 0xFFFFFFFFA3EFE945 S/N: 00C7 Issuer: /CN=Deutsche Telekom Root CA 2/OU=T-TeleSec Trust
Center/O=Deutsche Telekom AG/C=DE
Subject: /CN=DFN-Verein PCA Global - G01/OU=DFN-PKI/O=DFN-Verein/C=DE validity: 2006-12-19 10:29:00 through 2019-06-30 23:59:00 key type: 2048 bit RSA key usage: certSign crlSign
chain length: 2
fingerprint: F0:28:8F:DA:C6:3A:F7:9A:31:9A:E9:72:F3:95:09:0E:A3:EF:E9:45
The re-issued one:
ID: 0x55715DB8 S/N: 0089901115583E879B Issuer: /CN=Deutsche Telekom Root CA 2/OU=T-TeleSec Trust
Center/O=Deutsche Telekom AG/C=DE
Subject: /CN=DFN-Verein PCA Global - G01/OU=DFN-PKI/O=DFN-Verein/C=DE validity: 2014-02-11 13:11:45 through 2019-07-09 23:59:00 key type: 2048 bit RSA key usage: certSign crlSign
chain length: 2
fingerprint: 2E:EF:D9:C0:99:A2:BB:1C:2B:AC:52:97:BD:FF:D8:C8:55:71:5D:B8
Use gpgsm --dump-cert to see the other info. By deleting one or the
other certificate and importing them in a different order, it is
possible to verify that the latest certificate is use.
$ echo hallo | ~/b/gnupg/sm/gpgsm -ea --disable-crl-checks --debug 1 -r Schnarre
gpgsm: used in a production environment or with production keys!
gpgsm: enabled debug flags: x509
gpgsm: DBG: BEGIN Certificate 'target':
gpgsm: DBG: serial: 13F7C661A329F4
gpgsm: DBG: notBefore: 2012-06-13 08:01:21
gpgsm: DBG: notAfter: 2015-06-13 08:01:21
gpgsm: DBG: issuer:
1.2.840.113549.1.9.1=#706B692D63614062756E6465737461672E6465,CN=Deutscher
Bundestag CA - G01,OU=Deutscher Bundestag,O=Deutscher Bundestag,C=DE
gpgsm: DBG: subject:
1.2.840.113549.1.9.1=#736162696E652E6C657574686575737365722D7363686E617272656E6265726765724062756E6465737461672E6465,CN=Sabine
Leutheusser-Schnarrenberger,OU=MdB,O=Deutscher Bundestag,C=DE
gpgsm: DBG: hash algo: 1.2.840.113549.1.1.5
gpgsm: DBG: SHA1 Fingerprint:
73:99:B8:58:93:E5:F8:E0:D7:7C:BE:7F:D8:4C:14:86:78:A1:E8:03
gpgsm: DBG: END Certificate
gpgsm: failed to open '/home/wk/.gnupg/policies.txt': No such file or directory
gpgsm: note: non-critical certificate policy not allowed
gpgsm: DBG: looking for parent certificate
gpgsm: DBG: found via authid and keyid
gpgsm: DBG: got issuer's certificate:
gpgsm: DBG: BEGIN Certificate 'issuer':
gpgsm: DBG: serial: 0D688CAF
gpgsm: DBG: notBefore: 2008-12-17 14:39:27
gpgsm: DBG: notAfter: 2019-06-30 00:00:00
gpgsm: DBG: issuer: CN=DFN-Verein PCA Global - G01,OU=DFN-PKI,O=DFN-Verein,C=DE
gpgsm: DBG: subject:
1.2.840.113549.1.9.1=#706B692D63614062756E6465737461672E6465,CN=Deutscher
Bundestag CA - G01,OU=Deutscher Bundestag,O=Deutscher Bundestag,C=DE
gpgsm: DBG: hash algo: 1.2.840.113549.1.1.5
gpgsm: DBG: SHA1 Fingerprint:
0A:0D:87:72:EE:E7:B9:47:AE:A7:FC:58:C5:47:90:7F:75:F9:50:62
gpgsm: DBG: END Certificate
gpgsm: DBG: gcry_pk_verify: Success
gpgsm: certificate is good
gpgsm: DBG: looking for parent certificate
gpgsm: DBG: found via authid and keyid
gpgsm: DBG: got issuer's certificate:
gpgsm: DBG: BEGIN Certificate 'issuer':
gpgsm: DBG: serial: 0089901115583E879B
gpgsm: DBG: notBefore: 2014-02-11 13:11:45
gpgsm: DBG: notAfter: 2019-07-09 23:59:00
gpgsm: DBG: issuer: CN=Deutsche Telekom Root CA 2,OU=T-TeleSec Trust
Center,O=Deutsche Telekom AG,C=DE
gpgsm: DBG: subject: CN=DFN-Verein PCA Global - G01,OU=DFN-PKI,O=DFN-Verein,C=DE
gpgsm: DBG: hash algo: 1.2.840.113549.1.1.11
gpgsm: DBG: SHA1 Fingerprint:
2E:EF:D9:C0:99:A2:BB:1C:2B:AC:52:97:BD:FF:D8:C8:55:71:5D:B8
gpgsm: DBG: END Certificate
gpgsm: DBG: gcry_pk_verify: Success
gpgsm: intermediate certificate is good
gpgsm: DBG: looking for parent certificate
gpgsm: DBG: found via authid and keyid
gpgsm: DBG: got issuer's certificate:
gpgsm: DBG: BEGIN Certificate 'issuer':
gpgsm: DBG: serial: 26
gpgsm: DBG: notBefore: 1999-07-09 12:11:00
gpgsm: DBG: notAfter: 2019-07-09 23:59:00
gpgsm: DBG: issuer: CN=Deutsche Telekom Root CA 2,OU=T-TeleSec Trust
Center,O=Deutsche Telekom AG,C=DE
gpgsm: DBG: subject: CN=Deutsche Telekom Root CA 2,OU=T-TeleSec Trust
Center,O=Deutsche Telekom AG,C=DE
gpgsm: DBG: hash algo: 1.2.840.113549.1.1.5
gpgsm: DBG: SHA1 Fingerprint:
85:A4:08:C0:9C:19:3E:5D:51:58:7D:CD:D6:13:30:FD:8C:DE:37:BF
gpgsm: DBG: END Certificate
gpgsm: DBG: gcry_pk_verify: Success
gpgsm: root certificate is good
gpgsm: CRLs not checked due to --disable-crl-checks option
gpgsm: validation model used: shell
gpgsm: encrypted data created
Run ./autogen.sh first to build these files. There should also be a README.GIT.
BTW, GIT versions are for developers and we expect some experience with software
development. These are not releases of a software and even may not work or harm
your system.
Please explain why you need new options in gpg.
Adding the right rebased-to-master patch
Deeper analysis showed that not the keygrip but the DN is misinterpreted as
unique identifyer for a certificate when used in the SENDCERT inquire by
dirmngr. So I correct the title again.
The distinguished name distinguishes human beings or network end points but
neither certificates nor key pairs. For valid reasons, there can be multiple
certificates with the same DN and these certificates may contain the same or
different public keys. The GnuPG suite has to learn to handle this situation.
Using gpgsm with the options --disable-dirmngr --disable-crl-checks made our
webmailer work again, but places all users at inacceptable higher risk. So I
keep the priority setting "critical".
Should be fixed with the current stable GnuPG and GPGME versions.
This has meanwhile been fixed. It actually was a GnuPG Problem.
Meanwhile there are a couple of other fixes in GPA.
It might be useful to do a release soon.
Won't happen. Please read the FAQ. IF you need to discuss this, please do that
at gnupg-users@
Fixed in master (i.e. 2.1)
Due to the "in mind" part it took me a while to realize
that your patch is already available ...
Looks good to me and seems to work as expected (on FreeBSD with
gpa 0.9.4, I didn't try with git master). Thanks a lot.
I suspect that (outside the GNU project) ".asc" is more common than
".sig" and would thus sort and check the extensions in alphabetical
order, but obviously it doesn't really matter and I have no data to
support my theory anyway.
OpenPGP stores the expiration time as seconds after key creation. Now we
commonly have 2 keys (primary key and encryption subkey) and it is useful
toset the creation time to the same. Unfortunately the used time stamp is taken
right before the expiration time prompt is show and thus the actual value
depends on how long it takes to enter the string.
I can change that for 2.1.
I have a somewhat different patch in mind. It cleans up the code and adds an
additional test for the signed_file in addition to ".asc".
As it turns out the patch also prevents false negatives when
using the "verify" button on the signature file instead of
the signed file.
A couple of screenshots:
http://www.fabiankeil.de/bilder/screenshots/patched-gpa/
That was some kind of spam. The attachment was a made up page with an innocent
text linking to some other side.
This has already been fixed in the repo:
commit e78abe490ff6806f8083b23075ae036e5894513a
Author: Werner Koch <wk@gnupg.org>
Date: Mon Jan 6 16:16:24 2014 +0100
Update libtool and autogen.sh. -- This is the version from current libgpg-error which already has the changes done here plus these: bf0d67db * Update libtool to support Android. dd05f379 * Fix libtool 2.4.2 to correctly detect .def files. 6971fe55 * Update to libtool 2.4.2.
That is standard Unix behaviour and not a bug. Set your umask properly.
GnuPG does the same.
Do you want to turn this into a feature request?
Fixed with commit 2bb2618 for master. Will go into 1.5.0.
Thanks.
Please don't ask us to read log files and guess what you are asking about.
Send a detailed bug report. However, ed25519 support in GnuPG is under
development and not released and thus a bug report does not make any sense. IF
you have questions or suggestions, please writen to gnupg-devel@
When decrypting files in the file manager window, GPA 0.9.0 creates the plaintext
files with the user's default permissions. On most Linux distributions, this means
the plaintext file is world readable (i.e. umask 0022 -> permissions 0755).
It is a wiki. please fix yourself. Nio bee for BTS entry. Thanks.
No. It should not. Everything else wuld be surprising for a Unix tool.