From benjamin at py-soft.co.uk Sun May 2 13:30:00 2010 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Sun, 2 May 2010 12:30:00 +0100 Subject: Some build is broken with libassuan-2.0.0 In-Reply-To: <87mxwufvyb.fsf@vigenere.g10code.de> References: <20100309103958.547af9f2@mandrivalinux.hu> <20100309125010.16a0c175@mandrivalinux.hu> <87wrxlmypy.fsf@vigenere.g10code.de> <20100309155622.5f594dd7@mandrivalinux.hu> <87hbopmdr8.fsf@vigenere.g10code.de> <8739ynh81l.fsf@vigenere.g10code.de> <-8004492588036948116@unknownmsgid> <87mxwufvyb.fsf@vigenere.g10code.de> Message-ID: On 23 April 2010 08:51, Werner Koch wrote: >> Seems similar to the issue I reported with MacOS X - >> https://bugs.g10code.com/gnupg/issue1205 > Did you tried the current SVN version of libassuan? Tested with: libassuan svn 373. Libgpg-error v1.8-svn239 (Dependency). Libassuan fails with the following, which I have not had chance to investigate yet: gcc-4.0 -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wpointer-arith -c ce-server.c In file included from ce-server.c:51: common.h: In function ?do_strconcat?: common.h:265: warning: implicit declaration of function ?stpcpy? common.h:265: warning: incompatible implicit declaration of built-in function ?stpcpy? In file included from ce-server.c:51: common.h: In function ?do_strconcat?: common.h:265: warning: implicit declaration of function ?stpcpy? common.h:265: warning: incompatible implicit declaration of built-in function ?stpcpy? ce-server.c: In function ?server?: ce-server.c:1291: error: ?fd_set? undeclared (first use in this function) ce-server.c:1291: error: (Each undeclared identifier is reported only once ce-server.c:1291: error: for each function it appears in.) ce-server.c:1291: error: syntax error before ?rfds? ce-server.c:1295: warning: implicit declaration of function ?FD_ZERO? ce-server.c:1295: error: ?rfds? undeclared (first use in this function) ce-server.c:1296: warning: implicit declaration of function ?FD_SET? ce-server.c:1309: warning: implicit declaration of function ?select? ce-server.c:1311: warning: implicit declaration of function ?FD_ISSET? ce-server.c: In function ?server?: ce-server.c:1291: error: ?fd_set? undeclared (first use in this function) ce-server.c:1291: error: (Each undeclared identifier is reported only once ce-server.c:1291: error: for each function it appears in.) ce-server.c:1291: error: syntax error before ?rfds? ce-server.c:1295: warning: implicit declaration of function ?FD_ZERO? ce-server.c:1295: error: ?rfds? undeclared (first use in this function) ce-server.c:1296: warning: implicit declaration of function ?FD_SET? ce-server.c:1309: warning: implicit declaration of function ?select? ce-server.c:1311: warning: implicit declaration of function ?FD_ISSET? lipo: can't figure out the architecture type of: /var/folders/1V/1VnkOifVHtupY-d0-4-OcU+++TI/-Tmp-//ccGR617m.out make[3]: *** [ce-server.o] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 I'll update the bug report too. Take care, Ben From dkg at fifthhorseman.net Mon May 3 23:20:02 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 03 May 2010 17:20:02 -0400 Subject: WoT Proposal: implicit transitive self-certification Message-ID: <4BDF3E02.8030406@fifthhorseman.net> People undergoing key transitions or who hold multiple keys present some unusual challenges for calculating key+userid validity through the WoT. For example, a common case during key transtion is: 0) You believe that user U holds key old key X, 1) You find another key Y with user U's identity associated. 2) The key+userid binding is certified by X this scenario seems to correspond to a key transition or some other circumstance where a user holds multiple keys. Unless the user has explicitly stated "Do Not Trust" ownertrust for key X, reasonable automated pathfinding tools could treat Y,U as having full calculated validity as well, since people presumably know their own identity. My proposal is: If (a) key+userID binding has full calculated validity, and (b) X has any ownertrust setting (including unassigned) other than "Do Not Trust", and (c) key Y has a binding over the same User ID U certified by X Then treat as having full calculated validity. I'm currently calling this proposal "implicit transitive self-certification", though i welcome suggestions for a catchier name. Does this sound like something that GnuPG would consider adopting in its WoT pathfinding algorithms? Are there problems with this proposal that i am not seeing? Any cases where it could be dangerous or insecure? --dkg PS: Note that this proposal does *not* modify ownertrust in any way; it only modifies the calculated validity of matching User IDs. Note also the equivalence to introducing a new subkey -- a new subkey would be effectively treated as bound to the user ID in question already; this proposal simply allows people to transition to a new primary key (which is useful, for example, for people with old/weak primary keys) PPS i note also that there would need to be some recursive limit in practice. Conservatively, i'd propose no recursion be allowed. That is, if I find , certified by Y, I should not treat Z,U as having full calculated validity. This might complicate implementation. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Tue May 4 00:59:18 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 03 May 2010 18:59:18 -0400 Subject: WoT Proposal: double-counting suppression Message-ID: <4BDF5546.3070400@fifthhorseman.net> This is another proposal for tuning WoT pathfinding algorithms in the face of the possibility that people hold multiple keys. In particular, it is concerned with assignments of marginal ownertrust and multiple keyholders. My concern is with the case where User U holds two keys: X and Y. I know U, and have verified that she holds both of these keys. I also believe that U's certifications are useful, but i am not willing to rely on them for certificate validation unless they are corroborated by two other similar keyholders. This corresponds to "marginal" ownertrust. Let's assume there is another key, Z, with an associated user ID V. If U has certified with both X and Y, those should not count as independent corroborations. My proposal is: ------------- If (a) is certified by two keys X and Y, and (b) the user has assigned marginal ownertrust to both X and Y, and (c) there exists any User ID U such that i believe and both have full calculated validity, Then The certifications by X and Y over are treated as a single certification for the purposes of corroboration. That is, if three marginally-trusted certifications are required to reach full calculated validity for , then two more certifications by other keys with "marginal ownertrust" are needed, not one. ------------- The name i'm currently using for this proposal is "double-counting suppression", though i'm happy to entertain suggestions for a catchier name. What do folks think? Is this something that GnuPG might want to adopt? Are there dangers or problems with the proposal? Are there other ways to accomplish the same goal? --dkg PS I'm not sure how this interacts with variant certifications -- for example, if one certification contains a subpacket that other ones do not; perhaps this is not relevant. PPS thinking about this more radically, it seems possible that users might really prefer to assign the equivalent of "ownertrust" to User IDs, and not to keys, since we actually rely on named real-world entities to make good certifications. Interestingly, the only reference to anything like "ownertrust" in the OpenPGP spec is trust signatures, which are actually assigned to a key+UserID combo, so the choice of how to represent this information is implementation-specific. There are still issues around the root(s) of trust in such an arrangement (e.g. "ultimate" might still need to be assigned key-wise), though. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From matteo.sasso at gmail.com Thu May 6 00:09:05 2010 From: matteo.sasso at gmail.com (Matteo Sasso) Date: Thu, 6 May 2010 00:09:05 +0200 Subject: s2k-count limits Message-ID: Hi everyone, In a thread a while back (Nov. 30, 2009) David Shaw pointed out that current default for s2k-count might be a little low for today's CPU speeds: a brute force attack is more and more feasable against users who need passphrases they can remember. However there is something else that's troubling me right now: in that thread a quick benchmark by Werner Koch showed that about 5 million iterations is a good challenge for today's hardware, as it kept his PC busy for 90ms. That number is just 13 times lower that the maximum number of iterations allowed by gpg. This is important because: - As you probably know LUKS uses a similar scheme and a time of 1 second is used for calibration. People who prefer a more conservative number of iterations (equivalent to 1s) are already hitting the maximum on gpg. - Moore's law is still going strong. 90ms today means 1ms in 10 years. This is not enough against a determined attacker (a rough estimate gives 7 days to brute force a 40-bit entropy passphrase with 1000 entry-level CPUs in 2020). - Iteration count is really important to protect a passphrase (and data) in a symmetric encryption scenario. Think encrypted, remote backups where the user doesn't want to generate a truly random key for fear of losing it. The user doesn't mind even a huge initialization delay (backups take long anyway) if that means more protection. I hope I made my point clear. Thank you for your attention and for your comments. From beebe at math.utah.edu Thu May 6 02:54:40 2010 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Wed, 5 May 2010 18:54:40 -0600 (MDT) Subject: [gnupg-devel] the value of gnupg Message-ID: Some of you may be interested in this recent story in ComputerWorld: Symantec buys encryption specialist PGP for $300M http://www.computerworld.com/s/article/9176121/Symantec_buys_encryption_specialist_PGP_for_300M I had viewed PGP as mostly defunct, but clearly, Symantec saw otherwise. Even though gnupg is developed under the GPL, there may well be a business opportunity here for someone (I'm thinking of Red Hat and Novell SuSE support models for free software). It could even be that partnering with Red Hat or Novell could provide a revenue stream for gnupg development that could support one or more developers full time. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From wk at gnupg.org Thu May 6 10:03:04 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 May 2010 10:03:04 +0200 Subject: s2k-count limits In-Reply-To: (Matteo Sasso's message of "Thu, 6 May 2010 00:09:05 +0200") References: Message-ID: <87vdb1tq2v.fsf@vigenere.g10code.de> On Thu, 6 May 2010 00:09, matteo.sasso at gmail.com said: > thread a quick benchmark by Werner Koch showed that about 5 million > iterations is a good challenge for today's hardware, as it kept his PC FWIW, "iterations" as used here is an approximation and not the real number of loops to run. The OpenPGP scheme depends on the lengths of the passphrase and the selected hash algorithm. > - Iteration count is really important to protect a passphrase (and > data) in a symmetric encryption scenario. Think encrypted, remote I don't agree. The main goal of the salted+iterated protection mechanism is to thwart dictionary+brute-force attacks on week passphrases. It is a failstop mechanism and proper security design should never ever rely on this mechanism. For symmetric only encryption you need to use a strong key which may be derived from a proper passphrases. The accepted standard is a 128 bit key which you should derive in a way that it reflects 128 bit of entropy (most security policies view 80 to 90 bits as sufficient). It is not possible to remember such a long key without noting it down. For such valuable data you can't rely on one or two human brains to remember such a key. The conclusion is that you need to use a key management system - external to gpg - if you want to use symmetric encryption. For public key encryption the passphrase is only used to protect the secret part of the key. It has never been claimed that this will give you protection in the same range as the actual public key encryption - it merely gives you some time to prepare for the key compromise. For highly secure stuff you would use a physical secure machine to hold the secret key; which in the simplest case maybe a smartcard. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From matteo.sasso at gmail.com Thu May 6 14:43:37 2010 From: matteo.sasso at gmail.com (Matteo Sasso) Date: Thu, 6 May 2010 14:43:37 +0200 Subject: s2k-count limits In-Reply-To: <87vdb1tq2v.fsf@vigenere.g10code.de> References: <87vdb1tq2v.fsf@vigenere.g10code.de> Message-ID: > I don't agree. ?The main goal of the salted+iterated protection > mechanism is to thwart dictionary+brute-force attacks on week > passphrases. ?It is a failstop mechanism and proper security design > should never ever rely on this mechanism. Thank you for your clarification. So the s2k mechanism wasn't designed to compensate for a medium-strength passphrase in symmetric encryption. If gpg implemented something like TKS1 (used by LUKS), do you think it would make my use case feasible without compromising security? After all, gpg is one of the few tools to provide file encryption; maybe it wasn't designed for this purpose, but now the net is full of tutorials that show how to encrypt a file using gpg. This shows my use case isn't uncommon. From wk at gnupg.org Thu May 6 16:48:34 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 May 2010 16:48:34 +0200 Subject: s2k-count limits In-Reply-To: (Matteo Sasso's message of "Thu, 6 May 2010 14:43:37 +0200") References: <87vdb1tq2v.fsf@vigenere.g10code.de> Message-ID: <87wrvhrsql.fsf@vigenere.g10code.de> On Thu, 6 May 2010 14:43, matteo.sasso at gmail.com said: > medium-strength passphrase in symmetric encryption. If gpg implemented > something like TKS1 (used by LUKS), do you think it would make my use > case feasible without compromising security? I don't know TKS1. There are two established algorithms to transform a string into a passphrase: PBKDF1 (and 2) and OpenPGP's S2K. There is no way to replace a key with insufficient entropy by any other mechanism. Sure you can do some tradeoff between the time to decrypt with a known key and to brute-force a key. After all this is impractial because public key encryption gives you a more powerful way to do the same in a secure way. > maybe it wasn't designed for this purpose, but now the net is full of > tutorials that show how to encrypt a file using gpg. This shows my use You should use public key encryption for best security. Getting symmetric encryption right is not easy and in almost all use cases more insecure because you expose the secret key at two places. In particular for backup purposes public key encryption is what you want. The case for disk encryption is different but I seen no reason why you should use a symmetric only solution. A hybrid solution is not worse and gives you the opportunity to store the secret key on a smartcard. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Fri May 7 08:34:08 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 07 May 2010 02:34:08 -0400 Subject: bug in gnupg handling of revoker signatures Message-ID: <4BE3B460.7010504@fifthhorseman.net> Hi GnuPG folks-- I think gnupg does not handle self-signatures that indicate revocation keys [0] properly. Consider key C108E83A, which i've made to demonstrate this bug. At the bottom of this message are two copies of the same key. The first copy has an indication that my key (D21739E9) is allowed to revoke certifications by it. The second copy has a deliberately broken (that is, not cryptographically-valid) revocation certification, indicating that a key with fingerprint 0x000...001 is allowed to revoke it. I created this bogus version by just swapping out the fingerprint bytes in the signature made over the primary key. If the local keyring has the bogus version installed, then importing the good key will fail to update gpg's revoker information. That is, save the two versions of the key below as bogus.key and good.key compare the output of: gpg --delete-key C108E83A gpg --import bogus.key gpg --import good.key gpg --list-keys --with-colons C108E83A with: gpg --delete-key C108E83A gpg --import good.key gpg --import bogus.key gpg --list-keys --with-colons C108E83A The final versions should be identical, but (at least for me, with gpg versions 1.4.10 and 2.0.14 on debian testing) the former shows no rvk: line, while the latter shows an rvk: line. Compare also the output of "gpg --export C108E83A | gpg --list-packets" with these two states. It appears to be "first revocation certification received wins", even if one of them is cryptographically unsound. This is a potential security problem, because it suggests that a malicious user could block the distribution of revocation indicators. A user who relies on published revocation certifications may not have them treated properly if a malefactor produces a modified or simply corrupt revocation certification that somehow overrides the first. It appears that fetching the good key material from the keyservers does not fix the problem either. If i can provide more information, please let me know. Thanks for gpg, --dkg Here is the good version of the key: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.10 (GNU/Linux) mI0ES+OoSQEEAJUZ/+fC6DXN2X7Wxl4Huud/+i2qP1hcq+Qnbr7hVCKEnn0edYl+ 6xfsKmAMBjl+qTZxPSDSx4r3ciMiIbnvXFtlBAQmji86kqoR6fm9s8BN7LTq7+2/ c2FHVF67D7zES7WgHc4i7CfiZnwXgkLvi5b1jBt+MTAOrFhdobxoy6/XABEBAAGI twQfAQIAIQUCS+OsRRcMgAEO5b6XkoLYC591QPHM0u2U0hc56QIHAAAKCRA0t9EL wQjoOrRXBACBqhigTcj8pJY14AkjV+ZzUbm55kJRDPdU7NQ1PSvczm7HZaL3b8Lr Psa5c5+caVLjsGWkQycQl7lUIGU84KoUfwACQKVVLkqJz8LkL54lLcwkG70+1NH5 xoSNcHHVbYtqDLNeCOq5jEIoXuz44wiWVEfF+/B115PvgwZ63pjH1rRGVGVzdCBL ZXkgRGVtb25zdHJhdGluZyBSZXZva2VyIFRyb3VibGUgKERPIE5PVCBVU0UpIDx0 ZXN0QGV4YW1wbGUubmV0Poi+BBMBAgAoBQJL46hJAhsDBQkACTqABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAAKCRA0t9ELwQjoOgLpA/9/si2QYmietY9a6VlAmMri mhZeqo6zyn8zrO9RGU7+8jmeb5nVnXw1YmZcw2fiJgI9+tTMkTfomyR6k0EDvcEu 2Mg3USkVnJfrrkPjSL9EajW6VpOUNxlox3ZT1oyEo3OOnVF1gC1reWYfy7Ns9zIB 1leLXbMr86zYdCoXp0Xu4g== =xsEd -----END PGP PUBLIC KEY BLOCK----- And here is the modified/bogus version of the key: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.10 (GNU/Linux) mI0ES+OoSQEEAJUZ/+fC6DXN2X7Wxl4Huud/+i2qP1hcq+Qnbr7hVCKEnn0edYl+ 6xfsKmAMBjl+qTZxPSDSx4r3ciMiIbnvXFtlBAQmji86kqoR6fm9s8BN7LTq7+2/ c2FHVF67D7zES7WgHc4i7CfiZnwXgkLvi5b1jBt+MTAOrFhdobxoy6/XABEBAAGI twQfAQIAIQUCS+OsRRcMgAEAAAAAAAAAAAAAAAAAAAAAAAAAAQIHAAAKCRA0t9EL wQjoOrRXBACBqhigTcj8pJY14AkjV+ZzUbm55kJRDPdU7NQ1PSvczm7HZaL3b8Lr Psa5c5+caVLjsGWkQycQl7lUIGU84KoUfwACQKVVLkqJz8LkL54lLcwkG70+1NH5 xoSNcHHVbYtqDLNeCOq5jEIoXuz44wiWVEfF+/B115PvgwZ63pjH1rRGVGVzdCBL ZXkgRGVtb25zdHJhdGluZyBSZXZva2VyIFRyb3VibGUgKERPIE5PVCBVU0UpIDx0 ZXN0QGV4YW1wbGUubmV0Poi+BBMBAgAoBQJL46hJAhsDBQkACTqABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAAKCRA0t9ELwQjoOgLpA/9/si2QYmietY9a6VlAmMri mhZeqo6zyn8zrO9RGU7+8jmeb5nVnXw1YmZcw2fiJgI9+tTMkTfomyR6k0EDvcEu 2Mg3USkVnJfrrkPjSL9EajW6VpOUNxlox3ZT1oyEo3OOnVF1gC1reWYfy7Ns9zIB 1leLXbMr86zYdCoXp0Xu4g== =YV5g -----END PGP PUBLIC KEY BLOCK----- [0] http://tools.ietf.org/html/rfc4880#section-5.2.3.15 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri May 7 10:43:37 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 May 2010 10:43:37 +0200 Subject: bug in gnupg handling of revoker signatures In-Reply-To: <4BE3B460.7010504@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 07 May 2010 02:34:08 -0400") References: <4BE3B460.7010504@fifthhorseman.net> Message-ID: <87k4rgrtja.fsf@vigenere.g10code.de> On Fri, 7 May 2010 08:34, dkg at fifthhorseman.net said: > I think gnupg does not handle self-signatures that indicate revocation > keys [0] properly. I can replicate this and working on a solution. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri May 7 13:43:02 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 May 2010 13:43:02 +0200 Subject: bug in gnupg handling of revoker signatures In-Reply-To: <87k4rgrtja.fsf@vigenere.g10code.de> (Werner Koch's message of "Fri, 07 May 2010 10:43:37 +0200") References: <4BE3B460.7010504@fifthhorseman.net> <87k4rgrtja.fsf@vigenere.g10code.de> Message-ID: <87fx24rl89.fsf@vigenere.g10code.de> Hi! We did not checked the direct key signature during import. The problem is that during the import we try to detect duplicate signatures by comparing the signature but not the signed material. With the bogus signature already in the keyring, importing a good signature will sort the latter out as a duplicate. The implemented solution is to check the direct signature on import. To detect problems from the past we also check the existing key for bad direct key signatures during import and delete them. Fixed in 1.4, 2.0 and trunk. Added a test case to trunk. Because gpg --desig-revoke includes a copy of the key in question, the import of this revocation certificate would delete any bogus direct key signatures and insert a correct one. Daniel, thanks for the very good report, it was really helpful. 2.0.16 will be released pretty soon. For 1.4.11 we need to see what else should go in. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Sun May 9 16:13:13 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 09 May 2010 10:13:13 -0400 Subject: 403 forbidden to gnupg-commits web archive Message-ID: <4BE6C2F9.6070803@fifthhorseman.net> http://lists.gnupg.org/mailman/listinfo/gnupg-commits suggests that the archives for the gnupg-commits mailing list should be at: http://lists.gnupg.org/pipermail/ However, that link returns a 403 Forbidden HTTP response. So it seems like something is broken there. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From daniel.leidert.spam at gmx.net Sun May 9 20:46:26 2010 From: daniel.leidert.spam at gmx.net (Daniel Leidert) Date: Sun, 09 May 2010 20:46:26 +0200 Subject: 403 forbidden to gnupg-commits web archive In-Reply-To: <4BE6C2F9.6070803@fifthhorseman.net> References: <4BE6C2F9.6070803@fifthhorseman.net> Message-ID: <1273430786.7676.3.camel@haktar.wgdd.de> Am Sonntag, den 09.05.2010, 10:13 -0400 schrieb Daniel Kahn Gillmor: > http://lists.gnupg.org/mailman/listinfo/gnupg-commits suggests that the > archives for the gnupg-commits mailing list should be at: > > http://lists.gnupg.org/pipermail/ > > However, that link returns a 403 Forbidden HTTP response. So it seems > like something is broken there. There is also an open bug-report about this: https://bugs.g10code.com/gnupg/issue1048 Regards, Daniel From nicholas.cole at gmail.com Tue May 11 17:22:54 2010 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Tue, 11 May 2010 16:22:54 +0100 Subject: gpg card status crash Message-ID: Dear List, On gpg 1.4.10, the following command works fine: gpg --card-status The following command causes gpg to crash: Macintosh-2:~ nicholas$ gpg --status-fd 1 --card-status gpg(34195) malloc: *** mmap(size=6594112295125651456) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug There is no crash on gpg 2.0.9 Best wishes, Nicholas From dshaw at jabberwocky.com Tue May 11 20:27:57 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 11 May 2010 14:27:57 -0400 Subject: gpg card status crash In-Reply-To: References: Message-ID: <9D84512C-D1EB-4D7B-96B6-CE5B7125F766@jabberwocky.com> On May 11, 2010, at 11:22 AM, Nicholas Cole wrote: > Dear List, > > On gpg 1.4.10, the following command works fine: > > gpg --card-status > > The following command causes gpg to crash: > > Macintosh-2:~ nicholas$ gpg --status-fd 1 --card-status > gpg(34195) malloc: *** mmap(size=6594112295125651456) failed (error code=12) > *** error: can't allocate region > *** set a breakpoint in malloc_error_break to debug Need more information to even guess. What OS is this? (Your prompt is "Macintosh" - is this an OSX box? If so, what version of OSX?) What card reader do you use? What version of the card is this? David From nicholas.cole at gmail.com Tue May 11 23:12:53 2010 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Tue, 11 May 2010 22:12:53 +0100 Subject: gpg card status crash In-Reply-To: <9D84512C-D1EB-4D7B-96B6-CE5B7125F766@jabberwocky.com> References: <9D84512C-D1EB-4D7B-96B6-CE5B7125F766@jabberwocky.com> Message-ID: >> On gpg 1.4.10, the following command works fine: >> >> gpg --card-status >> >> The following command causes gpg to crash: >> >> Macintosh-2:~ nicholas$ gpg ?--status-fd 1 --card-status >> gpg(34195) malloc: *** mmap(size=6594112295125651456) failed (error code=12) >> *** error: can't allocate region >> *** set a breakpoint in malloc_error_break to debug > > Need more information to even guess. ?What OS is this? ?(Your prompt is "Macintosh" - is this an OSX box? ?If so, what version of OSX?) > What card reader do you use? ?What version of the card is this? Dear David, Sorry for the poor report. I'm running OS X 10.6.3, with version 2 of the card and with the GREMALTO USB Shell Token version 2. Best wishes, N. From dshaw at jabberwocky.com Wed May 12 00:15:48 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 11 May 2010 18:15:48 -0400 Subject: gpg card status crash In-Reply-To: References: <9D84512C-D1EB-4D7B-96B6-CE5B7125F766@jabberwocky.com> Message-ID: On May 11, 2010, at 5:12 PM, Nicholas Cole wrote: >>> On gpg 1.4.10, the following command works fine: >>> >>> gpg --card-status >>> >>> The following command causes gpg to crash: >>> >>> Macintosh-2:~ nicholas$ gpg --status-fd 1 --card-status >>> gpg(34195) malloc: *** mmap(size=6594112295125651456) failed (error code=12) >>> *** error: can't allocate region >>> *** set a breakpoint in malloc_error_break to debug >> >> Need more information to even guess. What OS is this? (Your prompt is "Macintosh" - is this an OSX box? If so, what version of OSX?) >> What card reader do you use? What version of the card is this? > > Dear David, > > Sorry for the poor report. I'm running OS X 10.6.3, with version 2 of > the card and with the GREMALTO USB Shell Token version 2. Hmm. I tried to duplicate this (same OSX, same card, but different card reader), but without any luck. Can you try and get a backtrace? To do that, run "gdb /the/path/to/gpg" then enter "break malloc_error_break", and finally "run --status-fd 1 --card-status". When you get a prompt, enter "bt full". Send the output of the bt full. David From nicholas.cole at gmail.com Wed May 12 01:39:31 2010 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Wed, 12 May 2010 00:39:31 +0100 Subject: gpg card status crash In-Reply-To: References: <9D84512C-D1EB-4D7B-96B6-CE5B7125F766@jabberwocky.com> Message-ID: On Tue, May 11, 2010 at 11:15 PM, David Shaw wrote: > On May 11, 2010, at 5:12 PM, Nicholas Cole wrote: > >>>> On gpg 1.4.10, the following command works fine: >>>> >>>> gpg --card-status >>>> >>>> The following command causes gpg to crash: >>>> >>>> Macintosh-2:~ nicholas$ gpg ?--status-fd 1 --card-status >>>> gpg(34195) malloc: *** mmap(size=6594112295125651456) failed (error code=12) >>>> *** error: can't allocate region >>>> *** set a breakpoint in malloc_error_break to debug >>> >>> Need more information to even guess. ?What OS is this? ?(Your prompt is "Macintosh" - is this an OSX box? ?If so, what version of OSX?) >>> What card reader do you use? ?What version of the card is this? >> >> Dear David, >> >> Sorry for the poor report. ?I'm running OS X 10.6.3, with version 2 of >> the card and with the GREMALTO USB Shell Token version 2. > > Hmm. ?I tried to duplicate this (same OSX, same card, but different card reader), but without any luck. ?Can you try and get a backtrace? ?To do that, run "gdb /the/path/to/gpg" then enter "break malloc_error_break", and finally "run --status-fd 1 --card-status". ?When you get a prompt, enter "bt full". ?Send the output of the bt full. > Dear David, I have posted the full report from that at the end of this email. I'm having a (possibly related?) problem with that reader, which is that it frequently refuses to read the card at all. At first I thought the card was not seated properly, but I've concluded that it is. Sometimes the reader works flawlessly, and sometimes gpg reports that the card is not present. The error only occurs if the reader has been removed and then reattached. I have not been able to work out conditions under which it works and fails. Do you have any suggestions for how to go about tracking down the problem? Best wishes, Nicholas gdb `which gpg` GNU gdb 6.3.50-20050815 (Apple version gdb-1461.2) (Fri Mar 5 04:43:10 UTC 2010) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ...... warning: Could not find object file "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_archivers_bzip2/work/bzip2-1.0.5/blocksort.o" - no debug information available for "blocksort.c". warning: Could not find object file "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_archivers_bzip2/work/bzip2-1.0.5/huffman.o" - no debug information available for "huffman.c". warning: Could not find object file "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_archivers_bzip2/work/bzip2-1.0.5/crctable.o" - no debug information available for "crctable.c". warning: Could not find object file "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_archivers_bzip2/work/bzip2-1.0.5/randtable.o" - no debug information available for "randtable.c". warning: Could not find object file "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_archivers_bzip2/work/bzip2-1.0.5/compress.o" - no debug information available for "compress.c". warning: Could not find object file "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_archivers_bzip2/work/bzip2-1.0.5/decompress.o" - no debug information available for "decompress.c". warning: Could not find object file "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_archivers_bzip2/work/bzip2-1.0.5/bzlib.o" - no debug information available for "bzlib.c". .. done (gdb) break malloc_error_break Breakpoint 1 at 0x4189374bb859cd (gdb) run --status-fd 1 --card-status Starting program: /opt/local/bin/gpg --status-fd 1 --card-status Reading symbols for shared libraries .+++++++...... done Reading symbols for shared libraries . done gpg(472) malloc: *** mmap(size=6594112295125651456) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Breakpoint 1, 0x00007fff8399a9cd in malloc_error_break () (gdb) bt full #0 0x00007fff8399a9cd in malloc_error_break () No symbol table info available. #1 0x00007fff8399bb24 in szone_error () No symbol table info available. #2 0x00007fff838c1256 in allocate_pages () No symbol table info available. #3 0x00007fff838d1235 in large_malloc () No symbol table info available. #4 0x00007fff838c2fa8 in szone_malloc_should_clear () No symbol table info available. #5 0x00007fff838c236a in malloc_zone_malloc () No symbol table info available. #6 0x00007fff838c0668 in malloc () No symbol table info available. #7 0x000000010009e967 in xmalloc () No symbol table info available. #8 0x000000010003ff26 in apdu_open_reader () No symbol table info available. #9 0x0000000100030808 in open_card () No symbol table info available. #10 0x0000000100031975 in agent_learn () No symbol table info available. #11 0x00000001000344a6 in card_status () No symbol table info available. #12 0x0000000100007dfa in main () No symbol table info available. (gdb) From dshaw at jabberwocky.com Wed May 12 18:02:10 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 12 May 2010 12:02:10 -0400 Subject: gpg card status crash In-Reply-To: References: <9D84512C-D1EB-4D7B-96B6-CE5B7125F766@jabberwocky.com> Message-ID: On May 11, 2010, at 7:39 PM, Nicholas Cole wrote: > On Tue, May 11, 2010 at 11:15 PM, David Shaw wrote: >> On May 11, 2010, at 5:12 PM, Nicholas Cole wrote: >> >>>>> On gpg 1.4.10, the following command works fine: >>>>> >>>>> gpg --card-status >>>>> >>>>> The following command causes gpg to crash: >>>>> >>>>> Macintosh-2:~ nicholas$ gpg --status-fd 1 --card-status >>>>> gpg(34195) malloc: *** mmap(size=6594112295125651456) failed (error code=12) >>>>> *** error: can't allocate region >>>>> *** set a breakpoint in malloc_error_break to debug >>>> >>>> Need more information to even guess. What OS is this? (Your prompt is "Macintosh" - is this an OSX box? If so, what version of OSX?) >>>> What card reader do you use? What version of the card is this? >>> >>> Dear David, >>> >>> Sorry for the poor report. I'm running OS X 10.6.3, with version 2 of >>> the card and with the GREMALTO USB Shell Token version 2. >> >> Hmm. I tried to duplicate this (same OSX, same card, but different card reader), but without any luck. Can you try and get a backtrace? To do that, run "gdb /the/path/to/gpg" then enter "break malloc_error_break", and finally "run --status-fd 1 --card-status". When you get a prompt, enter "bt full". Send the output of the bt full. >> > > Dear David, > > I have posted the full report from that at the end of this email. Alas, no symbols. Did you compile this yourself or get the binary from somewhere else? If you got the binary from somewhere else, do you think you could try and compile it yourself to get the backtrace? Clearly something is getting confused and making a really massive (6594112295125651456 bytes!) memory request, but it's not clear why without the backtrace. Also, are you really sure you are running gpg 1.4.10 (what does "gpg --version" say)? David From nicholas.cole at gmail.com Wed May 12 19:17:16 2010 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Wed, 12 May 2010 18:17:16 +0100 Subject: gpg card status crash In-Reply-To: References: <9D84512C-D1EB-4D7B-96B6-CE5B7125F766@jabberwocky.com> Message-ID: On Wed, May 12, 2010 at 5:02 PM, David Shaw wrote: > On May 11, 2010, at 7:39 PM, Nicholas Cole wrote: > >> On Tue, May 11, 2010 at 11:15 PM, David Shaw wrote: >>> On May 11, 2010, at 5:12 PM, Nicholas Cole wrote: >>> >>>>>> On gpg 1.4.10, the following command works fine: >>>>>> >>>>>> gpg --card-status >>>>>> >>>>>> The following command causes gpg to crash: >>>>>> >>>>>> Macintosh-2:~ nicholas$ gpg ?--status-fd 1 --card-status >>>>>> gpg(34195) malloc: *** mmap(size=6594112295125651456) failed (error code=12) >>>>>> *** error: can't allocate region >>>>>> *** set a breakpoint in malloc_error_break to debug >>>>> >>>>> Need more information to even guess. ?What OS is this? ?(Your prompt is "Macintosh" - is this an OSX box? ?If so, what version of OSX?) >>>>> What card reader do you use? ?What version of the card is this? >>>> >>>> Dear David, >>>> >>>> Sorry for the poor report. ?I'm running OS X 10.6.3, with version 2 of >>>> the card and with the GREMALTO USB Shell Token version 2. >>> >>> Hmm. ?I tried to duplicate this (same OSX, same card, but different card reader), but without any luck. ?Can you try and get a backtrace? ?To do that, run "gdb /the/path/to/gpg" then enter "break malloc_error_break", and finally "run --status-fd 1 --card-status". ?When you get a prompt, enter "bt full". ?Send the output of the bt full. >>> >> >> Dear David, >> >> I have posted the full report from that at the end of this email. > > Alas, no symbols. ?Did you compile this yourself or get the binary from somewhere else? ?If you got the binary from somewhere else, do you think you could try and compile it yourself to get the backtrace? Dear David, Yes, it is version 1.4.10: nicholas$ gpg --version gpg (GnuPG) 1.4.10 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 I thought I had compiled it myself, but probably on a slightly older version of OS X. Could that be the problem? (gpg2 I tend to get the macports or fink projects because of the dependencies, but I've always appreciated the ability to just download and compile the version 1 series without hassle.). I'll try recompiling tonight or tomorrow. Best wishes, Nicholas From dshaw at jabberwocky.com Wed May 12 19:28:00 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 12 May 2010 13:28:00 -0400 Subject: gpg card status crash In-Reply-To: References: <9D84512C-D1EB-4D7B-96B6-CE5B7125F766@jabberwocky.com> Message-ID: <09D9AB5B-FB22-442B-93D4-210D93B86B1D@jabberwocky.com> On May 12, 2010, at 1:17 PM, Nicholas Cole wrote: > I'll try recompiling tonight or tomorrow. Ah, I know what is going on. After you recompile, you should be okay - just get the backtrace before you delete the build tree. Thanks! David From nicholas.cole at gmail.com Tue May 25 17:17:27 2010 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Tue, 25 May 2010 16:17:27 +0100 Subject: Card Size Selection Message-ID: Dear Warner and David, I've noticed something strange while experimenting with an OpenPGP card version 2 using gpg 1.4.10. I've put the transcripts of two --card-edit on-card generations below. If I select size '3072' for the key size, three keys of 3072bits are created. If I select key size '2048', the size of key 2 is changed to 1024 automatically (with the message 'gpg: size of key 2 changed to 1024 bits'). If I use the user interface, and not --command-fd and --status-fd, then everything works as expected (ie. I can create 3 2048 keys). What is going on? Is it a bug? Best wishes, Nicholas #### TRANSCRIPTS FOLLOW ############ Macintosh-2:~ nicholas$ gpg --command-fd 0 --with-colons --status-fd 1 --card-edit gpg: detected reader `Gemplus GemPC Twin 00 00' [GNUPG:] CARDCTRL 3 D2760001240102000005000004C40000 AID:D2760001240102000005000004C40000:openpgp-card: version:0200: vendor:0005:ZeitControl: serial:000004C4: name::: lang:de: sex:u: url:: login:: forcepin:1::: keyattr:1:1:2048: keyattr:2:1:1024: keyattr:3:1:2048: maxpinlen:32:32:32: pinretry:3:0:3: sigcount:5::: private_do:1:: private_do:2:: cafpr:::: fpr:6D483F1319B89F81D7B1F45D0E52F6FDA858F0BF:B1B1694833AE02DD6FEB66A2BE4797AB15F9741E:174C4604138F40F60F87E6947BAEEA320843A299: fprtime:1274798826:1274798826:1274798826: [GNUPG:] GET_LINE cardedit.prompt genkey [GNUPG:] GOT_IT Invalid command (try "help") [GNUPG:] GET_LINE cardedit.prompt create [GNUPG:] GOT_IT Invalid command (try "help") [GNUPG:] GET_LINE cardedit.prompt admin [GNUPG:] GOT_IT Admin commands are allowed [GNUPG:] GET_LINE cardedit.prompt [GNUPG:] GET_LINE cardedit.prompt generate [GNUPG:] GOT_IT [GNUPG:] GET_LINE cardedit.genkeys.backup_enc no [GNUPG:] GOT_IT gpg: NOTE: keys are already stored on the card! [GNUPG:] GET_BOOL cardedit.genkeys.replace_keys yes [GNUPG:] GOT_IT Please note that the factory settings of the PINs are PIN = `123456' Admin PIN = `12345678' You should change them using the command --change-pin gpg: 3 Admin PIN attempts remaining before card is permanently locked [GNUPG:] NEED_PASSPHRASE_PIN OPENPGP 3 D2760001240102000005000004C40000 Please enter the Admin PIN [GNUPG:] GET_HIDDEN passphrase.adminpin.ask 12345678 [GNUPG:] GOT_IT [GNUPG:] NEED_PASSPHRASE_PIN OPENPGP 1 D2760001240102000005000004C40000 Please enter the PIN [GNUPG:] GET_HIDDEN passphrase.pin.ask 123456 [GNUPG:] GOT_IT [GNUPG:] GET_LINE cardedit.genkeys.size 3072 [GNUPG:] GOT_IT The card will now be re-configured to generate a key of 3072 bits NOTE: There is no guarantee that the card supports the requested size. If the key generation does not succeed, please check the documentation of your card to see what sizes are allowed. gpg: size of key 1 changed to 3072 bits [GNUPG:] GET_LINE cardedit.genkeys.size 3072 [GNUPG:] GOT_IT The card will now be re-configured to generate a key of 3072 bits gpg: 3 Admin PIN attempts remaining before card is permanently locked [GNUPG:] NEED_PASSPHRASE_PIN OPENPGP 3 Please enter the Admin PIN [GNUPG:] GET_HIDDEN passphrase.adminpin.ask 12345678 [GNUPG:] GOT_IT gpg: size of key 2 changed to 3072 bits [GNUPG:] GET_LINE cardedit.genkeys.size 3072 [GNUPG:] GOT_IT The card will now be re-configured to generate a key of 3072 bits gpg: 3 Admin PIN attempts remaining before card is permanently locked [GNUPG:] NEED_PASSPHRASE_PIN OPENPGP 3 Please enter the Admin PIN [GNUPG:] GET_HIDDEN passphrase.adminpin.ask 12345678 [GNUPG:] GOT_IT gpg: size of key 3 changed to 3072 bits Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years [GNUPG:] GET_LINE keygen.valid 1 [GNUPG:] GOT_IT Key expires at Wed 26 May 15:53:29 2010 BST You need a user ID to identify your key; the software constructs the user ID from the Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) " [GNUPG:] GET_LINE keygen.name Test Key Card [GNUPG:] GOT_IT [GNUPG:] GET_LINE keygen.email [GNUPG:] GOT_IT [GNUPG:] GET_LINE keygen.comment [GNUPG:] GOT_IT You selected this USER-ID: "Test Key Card" gpg: generating new key gpg: 3 Admin PIN attempts remaining before card is permanently locked [GNUPG:] NEED_PASSPHRASE_PIN OPENPGP 3 Please enter the Admin PIN [GNUPG:] GET_HIDDEN passphrase.adminpin.ask 12345678 [GNUPG:] GOT_IT gpg: please wait while key is being generated ... gpg: key generation completed (51 seconds) gpg: signatures created so far: 0 [GNUPG:] NEED_PASSPHRASE_PIN OPENPGP 1 D2760001240102000005000004C40000/E664B97130A3E2D466F4166CCAFD187A73D06E95 Please enter the PIN [sigs done: 0] [GNUPG:] GET_HIDDEN passphrase.pin.ask 123456 [GNUPG:] GOT_IT gpg: generating new key gpg: please wait while key is being generated ... gpg: key generation completed (72 seconds) gpg: signatures created so far: 1 gpg: signatures created so far: 2 gpg: generating new key gpg: please wait while key is being generated ... gpg: key generation completed (57 seconds) gpg: signatures created so far: 3 gpg: signatures created so far: 4 gpg: key 73D06E95 marked as ultimately trusted public and secret key created and signed. pub:i:3072:1:CAFD187A73D06E95:2010-05-25:2010-05-26::u:Test Key Card::s: fpr:::::::::E664B97130A3E2D466F4166CCAFD187A73D06E95: sub:i:3072:1:E5BF8C59B71B2F52:2010-05-25:2010-05-26:::::: sub:i:3072:1:60DD34DD7DC5C462:2010-05-25:2010-05-26:::::: [GNUPG:] KEY_CREATED B E664B97130A3E2D466F4166CCAFD187A73D06E95 [GNUPG:] GET_LINE cardedit.prompt generate [GNUPG:] GOT_IT [GNUPG:] GET_LINE cardedit.genkeys.backup_enc /tmp/backup-file [GNUPG:] GOT_IT gpg: NOTE: keys are already stored on the card! [GNUPG:] GET_BOOL cardedit.genkeys.replace_keys y [GNUPG:] GOT_IT Please note that the factory settings of the PINs are PIN = `123456' Admin PIN = `12345678' You should change them using the command --change-pin [GNUPG:] NEED_PASSPHRASE_PIN OPENPGP 1 D2760001240102000005000004C40000 Please enter the PIN [GNUPG:] GET_HIDDEN passphrase.pin.ask 123456 [GNUPG:] GOT_IT [GNUPG:] GET_LINE cardedit.genkeys.size 2048 [GNUPG:] GOT_IT The card will now be re-configured to generate a key of 2048 bits gpg: size of key 1 changed to 2048 bits [GNUPG:] GET_LINE cardedit.genkeys.size 2048 [GNUPG:] GOT_IT The card will now be re-configured to generate a key of 2048 bits gpg: 3 Admin PIN attempts remaining before card is permanently locked [GNUPG:] NEED_PASSPHRASE_PIN OPENPGP 3 Please enter the Admin PIN [GNUPG:] GET_HIDDEN passphrase.adminpin.ask 12345678 [GNUPG:] GOT_IT gpg: size of key 2 changed to 2048 bits [GNUPG:] GET_LINE cardedit.genkeys.size 2048 [GNUPG:] GOT_IT The card will now be re-configured to generate a key of 2048 bits gpg: 3 Admin PIN attempts remaining before card is permanently locked [GNUPG:] NEED_PASSPHRASE_PIN OPENPGP 3 Please enter the Admin PIN [GNUPG:] GET_HIDDEN passphrase.adminpin.ask 12345678 [GNUPG:] GOT_IT gpg: size of key 3 changed to 2048 bits Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years [GNUPG:] GET_LINE keygen.valid 1 [GNUPG:] GOT_IT Key expires at Wed 26 May 15:59:44 2010 BST You need a user ID to identify your key; the software constructs the user ID from the Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) " [GNUPG:] GET_LINE keygen.name Test Key Card 2 [GNUPG:] GOT_IT [GNUPG:] GET_LINE keygen.email [GNUPG:] GOT_IT [GNUPG:] GET_LINE keygen.comment [GNUPG:] GOT_IT You selected this USER-ID: "Test Key Card 2" gpg: generating new key gpg: 3 Admin PIN attempts remaining before card is permanently locked [GNUPG:] NEED_PASSPHRASE_PIN OPENPGP 3 Please enter the Admin PIN [GNUPG:] GET_HIDDEN passphrase.adminpin.ask 12345678 [GNUPG:] GOT_IT gpg: please wait while key is being generated ... gpg: key generation completed (33 seconds) gpg: signatures created so far: 0 [GNUPG:] NEED_PASSPHRASE_PIN OPENPGP 1 D2760001240102000005000004C40000/18DCAE60403CEFCEE2519108C9A3D625C4FB8184 Please enter the PIN [sigs done: 0] [GNUPG:] GET_HIDDEN passphrase.pin.ask 123456 [GNUPG:] GOT_IT gpg: generating new key gpg: please wait while key is being generated ... gpg: key generation completed (29 seconds) gpg: signatures created so far: 1 gpg: signatures created so far: 2 You need a Passphrase to protect your secret key. [GNUPG:] NEED_PASSPHRASE_SYM 3 3 2 [GNUPG:] GET_HIDDEN passphrase.enter 123456 [GNUPG:] GOT_IT [GNUPG:] PROGRESS primegen + 0 0 [GNUPG:] PROGRESS primegen + 0 0 [GNUPG:] PROGRESS primegen + 0 0 [GNUPG:] PROGRESS primegen + 0 0 [GNUPG:] PROGRESS primegen + 0 0 [GNUPG:] PROGRESS primegen X 100 100 [GNUPG:] PROGRESS primegen . 0 0 [GNUPG:] PROGRESS primegen + 0 0 [GNUPG:] PROGRESS primegen + 0 0 [GNUPG:] PROGRESS primegen + 0 0 [GNUPG:] PROGRESS primegen + 0 0 [GNUPG:] PROGRESS primegen + 0 0 [GNUPG:] PROGRESS primegen X 100 100 gpg: writing new key gpg: size of key 2 changed to 1024 bits gpg: 3 Admin PIN attempts remaining before card is permanently locked [GNUPG:] NEED_PASSPHRASE_PIN OPENPGP 3 Please enter the Admin PIN [GNUPG:] GET_HIDDEN passphrase.adminpin.ask 12345678 [GNUPG:] GOT_IT gpg: NOTE: backup of card key saved to `/Users/nicholas/.gnupg/sk_2CF23CCB5C4C0D99.gpg' [GNUPG:] BACKUP_KEY_CREATED 8929C407CAE1B2BCC9707DAF2CF23CCB5C4C0D99 /Users/nicholas/.gnupg/sk_2CF23CCB5C4C0D99.gpg gpg: signatures created so far: 3 [GNUPG:] NEED_PASSPHRASE_PIN OPENPGP 1 D2760001240102000005000004C40000/18DCAE60403CEFCEE2519108C9A3D625C4FB8184 Please enter the PIN [sigs done: 3] [GNUPG:] GET_HIDDEN passphrase.pin.ask 123456 [GNUPG:] GOT_IT gpg: signatures created so far: 4 public and secret key created and signed. pub:i:2048:1:C9A3D625C4FB8184:2010-05-25:2010-05-26::u:Test Key Card 2::s: fpr:::::::::18DCAE60403CEFCEE2519108C9A3D625C4FB8184: sub:i:2048:1:0854C8CA683554ED:2010-05-25:2010-05-26:::::: sub:i:1024:1:2CF23CCB5C4C0D99:2010-05-25:2010-05-26:::::: [GNUPG:] KEY_CREATED B 18DCAE60403CEFCEE2519108C9A3D625C4FB8184 [GNUPG:] GET_LINE cardedit.prompt From wk at gnupg.org Tue May 25 19:23:58 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 25 May 2010 19:23:58 +0200 Subject: Card Size Selection In-Reply-To: (Nicholas Cole's message of "Tue, 25 May 2010 16:17:27 +0100") References: Message-ID: <874ohvlwsx.fsf@vigenere.g10code.de> On Tue, 25 May 2010 17:17, nicholas.cole at gmail.com said: > If I select key size '2048', the size of key 2 is changed to 1024 > automatically (with the message 'gpg: size of key 2 changed to 1024 > bits'). Yeah, that is a bug. 1.4.10 uses this code to create the backup key: rc = generate_raw_key (algo, 1024, timestamp, &sk_unprotected, &sk_protected); Here the v1 card is still hardwired. In 2.0.x we use this code /* Get the size of the key directly from the card. */ { struct agent_card_info_s info; memset (&info, 0, sizeof info); if (!agent_scd_getattr ("KEY-ATTR", &info) && info.key_attr[1].algo) nbits = info.key_attr[1].nbits; else nbits = 1024; /* All pre-v2.0 cards. */ agent_release_card_info (&info); } /* Create a key of this size in memory. */ rc = generate_raw_key (algo, nbits, timestamp, &sk_unprotected, &sk_protected); This needs to be fixed (bug#1230). Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dpd at opsol.com.au Tue May 25 15:35:03 2010 From: dpd at opsol.com.au (Denis Dowling) Date: Tue, 25 May 2010 23:35:03 +1000 Subject: Key capabilities missing in private key list Message-ID: <4BFBD207.6030604@opsol.com.au> Hi, I am building an application that interfaces with gnupg using the gpgme library. I need to get a list of all keys in the key chain that are capable of signing some data. When I obtain the private key list is reports all keys as having no capabilities. I traced this down to some strange behavior in the way gnupg lists private keys. If I list a specific key I get the output below: $ gpg --with-colons -K test at example.com sec::1024:17:41485ADBDCE7CB7A:2010-04-06::::Test User (Only for testing) ::scESC: ssb::2048:16:4CB00EF002555296:2010-04-06::::::e: Note that this key has sign (s), certify (c) and encrypt (e) capabilities shown in field #12. If I list all private keys in the key ring I get the following: $ gpg --with-colons -K sec::1024:17:41485ADBDCE7CB7A:2010-04-06::::Test User (Only for testing) ::: ssb::2048:16:4CB00EF002555296:2010-04-06::::::: sec::1024:17:1EE58341D4F149E4:2010-04-22::::d (d) ::: ssb::2048:16:0C5177BEB27853AA:2010-04-22::::::: sec::1024:17:A7A564AF31CA7661:2010-04-22::::Denis Dowling (test key) ::: ssb::2048:16:FC75B03C084005B5:2010-04-22::::::: Note that none of these keys have any capabilities shown in field #12. Is this a bug or am I missing something subtle with the key listing commands? I have repeated the same behavior in gnupg versions 1.4.5 from RedHat EL5 and the latest 1.4.10 from gnupg.org. Regards, Denis From wk at gnupg.org Tue May 25 20:06:21 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 25 May 2010 20:06:21 +0200 Subject: Key capabilities missing in private key list In-Reply-To: <4BFBD207.6030604@opsol.com.au> (Denis Dowling's message of "Tue, 25 May 2010 23:35:03 +1000") References: <4BFBD207.6030604@opsol.com.au> Message-ID: <87r5kzkg9u.fsf@vigenere.g10code.de> On Tue, 25 May 2010 15:35, dpd at opsol.com.au said: > I am building an application that interfaces with gnupg using the gpgme > library. I need to get a list of all keys in the key chain that are > capable of signing some data. When I obtain the private key list is > reports all keys as having no capabilities. I traced this down to some That is due to the way gpg works. It is unlikely that we will change it in the stable branches because the development version has been changed to drop the duplication of a lot of code in regard to working with the secring and the pubring. This will automagically fix your issue. The workaround is to list the corresponding public key. I know that this is not very elegant but most key managers do it this way. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Tue May 25 21:36:42 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 25 May 2010 15:36:42 -0400 Subject: Key capabilities missing in private key list In-Reply-To: <4BFBD207.6030604@opsol.com.au> References: <4BFBD207.6030604@opsol.com.au> Message-ID: <4BFC26CA.6060409@fifthhorseman.net> On 05/25/2010 09:35 AM, Denis Dowling wrote: > When I obtain the private key list is > reports all keys as having no capabilities. I traced this down to some > strange behavior in the way gnupg lists private keys. If I list a > specific key I get the output below: [...] > Note that none of these keys have any capabilities shown in field #12. > > Is this a bug or am I missing something subtle with the key listing > commands? This is a known bug: https://bugs.g10code.com/gnupg/issue945 --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From nicholas.cole at gmail.com Wed May 26 12:57:03 2010 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Wed, 26 May 2010 11:57:03 +0100 Subject: Card Size Selection In-Reply-To: <874ohvlwsx.fsf@vigenere.g10code.de> References: <874ohvlwsx.fsf@vigenere.g10code.de> Message-ID: It's a minor bug, but should the prompt "cardedit.genkeys.backup_enc" actually be a "GET_BOOL" rather than a "GET_LINE"? Best wishes, N.