From thomas.stroesslin at epfl.ch Thu Apr 1 18:30:34 2004 From: thomas.stroesslin at epfl.ch (Thomas Stroesslin) Date: Thu Apr 1 18:28:13 2004 Subject: dash-escape - a potential improvement? Message-ID: Hi, rfc 2440 section 7.1 defines what dash-escaping means for the OpenPGP Message Format. Many people don't understand why a line starting with "-" ends up like "- -". I propose a change which confuses less people and breaks nothing (except for violating rfc2440): preface: I always hear that a line beginning with "-" could interfere with the header parsing. This is not true. Only a line beginning with "-----" can break the header parsing. The natural way of escaping is to escape as rarely as possible, so a line such as "-- " which is no problem anyway should not be escaped. notation: "_rfc": rfc 2440 "_de": the dash escape method described in _rfc "_!de": unescaping _de "_p": a program which implements _rfc (digest, _de, verify, _!de) "_h": this proposal (here) "_4de": the dash escape method of _h "_!4de": unescaping_4de "_p4": a program which implements _h (digest, _4de, verify, _!4de) the potential improvement: ("^" means beginning of line) _4de: 1) escape "^----" with "^----+" 2) remove trailing spaces 3) escape "^- -" with "^+ -" (for backward compatibility only) digest: calculate the digest on the escaped text instead of the cleartext. verification: if verification fails, do _!de and retry. If this succeeds, the signature is good, else it is bad. backwards compatibility: a) verifying a _h message using _rfc: _p would _!de the message before verifying. In perl, this could be done by: "$line =~ s/^- (-.*)/$1/". No line would match in a _h message, so _p would actually verify the escaped _h message which is what _h calculates the digest for. -> This works! b) verifying an _rfc message using _h: _p4 would detect a verification failure because it calculates the digest on the escaped message. But it then retries after _!de and therefore calculates the digest over the original cleartext message. -> This also works! potential problems: a) _h violates _rfc twice: first, it calculates the digest over the escaped instead of the cleartext message. It also uses a different dash-escaping mechanism. If _rfc is an axiom to you (ie. it cannot be questioned), then this is a problem. For everybody else, this is not a real problem. b) _p might implement _!de in a dangerous way. It has to be checked that no _p does something like (perl): "$line =~ s/^-.(.*)/$1/" benefits: 1) Users would be less surprised to what happens to their cleartext because in almost all cases, nothing would be escaped. Today, almost all mails have at least one escaped line (the signature identifier "-- "). Today, _rfc unaware MUAs fail to detect the signature correctly. With _h, this problem is solved. 2) _h is backward compatible. Only bad MUAs which don't implement _!de safely would break. The patch to all those programs is to do something like "$line =~ s/^- (-.*)/$1/" (perl) to implement _!de. What is your opinion on that? Is this a good proposal? Did I miss an important point? cheers, tom From dshaw at jabberwocky.com Thu Apr 1 19:26:03 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Apr 1 19:23:28 2004 Subject: keyids in signatures getting corrupted, GPG and/or Debian problem? In-Reply-To: <20040331075803.GA13451@marvin.sbg.palfrader.org> References: <20040331012400.GL10980@pm1.ric-41.lft.widomaker.com> <20040331054451.GA3683@jabberwocky.com> <20040331075803.GA13451@marvin.sbg.palfrader.org> Message-ID: <20040401172603.GC32671@jabberwocky.com> On Wed, Mar 31, 2004 at 09:58:03AM +0200, Peter Palfrader wrote: > On Wed, 31 Mar 2004, David Shaw wrote: > > > Since you saw this frequently on Debian maintainer keys, I wonder if > > there is a problem there? I know the Debian folks have their own HKP > > keyserver that isn't pksd or sks, but I don't know anything about the > > engine behind it. Worth a look, but still only a guess of course. > > hkp://keyring.debian.org is powered by GnuPG 1.0.6. I don't think > anything else deals with the keys directly, tho if you want I maybe > could investigate. That's okay. GnuPG 1.0.6 handles subpackets properly. David From jharris at widomaker.com Thu Apr 1 21:32:14 2004 From: jharris at widomaker.com (Jason Harris) Date: Thu Apr 1 21:29:33 2004 Subject: keyids in signatures getting corrupted, GPG and/or Debian problem? In-Reply-To: <20040331054451.GA3683@jabberwocky.com> References: <20040331012400.GL10980@pm1.ric-41.lft.widomaker.com> <20040331054451.GA3683@jabberwocky.com> Message-ID: <20040401193213.GA82062@pm1.ric-01.lft.widomaker.com> On Wed, Mar 31, 2004 at 12:44:51AM -0500, David Shaw wrote: > On Tue, Mar 30, 2004 at 08:24:00PM -0500, Jason Harris wrote: > > the bogus subkey binding signature was hard to miss: 0x12F506C8. I meant to add: ^ not > Jason, how on earth did you find this? Really awesome discovery, and > an interesting problem. I have a suspicion on how it happens, though The patterns in the "bogus" signature looked weird (kjsl output): sub 2048g/AC0E538A 1998-04-28 Key fingerprint = F5AF 74B5 3257 FB0B 85DA AAD6 B3D3 34D5 AC0E 538A sig 0x18 12F506C8 2003-12-17 [keybind, hash: type 2, 2d 09] sig 0x18 12F506C8 2003-12-17 [keybind, hash: type 2, 2d 09] sig 0x18 12F506C8 1998-04-28 [keybind, hash: type 2, 3d 0a] sig 0x18 12F50910 2003-12-17 [invalid signer? corrupted signature?, hash: type 2, 2d 09] and _this_ looked even weirder (GPG 1.2.4 output): sub 2048g/AC0E538A 1998-04-28 Key fingerprint = F5AF 74B5 3257 FB0B 85DA AAD6 B3D3 34D5 AC0E 538A sig! 12F506C8 2003-12-17 Peter Sjoberg sig! 12F50910 2003-12-17 [User id not found] > All of that said, I'm not too worried about this. It's annoying, but > ultimately harmless. The corrupt sig will not validate (though the > sig itself is actually good, the bad issuer means the key that issued > it will never be found), so it will be ignored. Except where the issuer is irrelevant. -- Jason Harris | NIC: JH329, PGP: This _is_ PGP-signed, isn't it? jharris@widomaker.com _|_ web: http://keyserver.kjsl.com/~jharris/ Got photons? (TM), (C) 2004 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : /pipermail/attachments/20040401/9a745981/attachment.bin From dshaw at jabberwocky.com Thu Apr 1 22:34:26 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Apr 1 22:31:50 2004 Subject: keyids in signatures getting corrupted, GPG and/or Debian problem? In-Reply-To: <20040401193213.GA82062@pm1.ric-01.lft.widomaker.com> References: <20040331012400.GL10980@pm1.ric-41.lft.widomaker.com> <20040331054451.GA3683@jabberwocky.com> <20040401193213.GA82062@pm1.ric-01.lft.widomaker.com> Message-ID: <20040401203426.GC2326@jabberwocky.com> On Thu, Apr 01, 2004 at 02:32:14PM -0500, Jason Harris wrote: > > All of that said, I'm not too worried about this. It's annoying, but > > ultimately harmless. The corrupt sig will not validate (though the > > sig itself is actually good, the bad issuer means the key that issued > > it will never be found), so it will be ignored. > > Except where the issuer is irrelevant. I'm afraid I don't follow that comment. The issuer is always relevant, as it is used to find the key that issued the signature. David From jharris at widomaker.com Thu Apr 1 23:56:34 2004 From: jharris at widomaker.com (Jason Harris) Date: Thu Apr 1 23:53:54 2004 Subject: keyids in signatures getting corrupted, GPG and/or Debian problem? In-Reply-To: <20040401203426.GC2326@jabberwocky.com> References: <20040331012400.GL10980@pm1.ric-41.lft.widomaker.com> <20040331054451.GA3683@jabberwocky.com> <20040401193213.GA82062@pm1.ric-01.lft.widomaker.com> <20040401203426.GC2326@jabberwocky.com> Message-ID: <20040401215634.GA82820@wilma.widomaker.com> On Thu, Apr 01, 2004 at 03:34:26PM -0500, David Shaw wrote: > On Thu, Apr 01, 2004 at 02:32:14PM -0500, Jason Harris wrote: > > > All of that said, I'm not too worried about this. It's annoying, but > > > ultimately harmless. The corrupt sig will not validate (though the > > > sig itself is actually good, the bad issuer means the key that issued > > > it will never be found), so it will be ignored. > > > > Except where the issuer is irrelevant. > > I'm afraid I don't follow that comment. The issuer is always > relevant, as it is used to find the key that issued the signature. As the GPG output in my last message demonstrates, GPG disregards the issuer in subkey binding signatures. While the RFC specifies the issuer be included in subkey binding signatures, it also only allows for the parent pubkey to issue such signatures. Therefore, the issuer of subkey signatures is currently irrelevant, a priori. -- Jason Harris | NIC: JH329, PGP: This _is_ PGP-signed, isn't it? jharris@widomaker.com _|_ web: http://keyserver.kjsl.com/~jharris/ Got photons? (TM), (C) 2004 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : /pipermail/attachments/20040401/ae6a15be/attachment.bin From dshaw at jabberwocky.com Fri Apr 2 00:20:24 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Apr 2 00:18:16 2004 Subject: [Sks-devel] Re: keyids in signatures getting corrupted, GPG and/or Debian problem? In-Reply-To: <20040401215634.GA82820@wilma.widomaker.com> References: <20040331012400.GL10980@pm1.ric-41.lft.widomaker.com> <20040331054451.GA3683@jabberwocky.com> <20040401193213.GA82062@pm1.ric-01.lft.widomaker.com> <20040401203426.GC2326@jabberwocky.com> <20040401215634.GA82820@wilma.widomaker.com> Message-ID: <20040401222024.GD2326@jabberwocky.com> On Thu, Apr 01, 2004 at 04:56:34PM -0500, Jason Harris wrote: > On Thu, Apr 01, 2004 at 03:34:26PM -0500, David Shaw wrote: > > On Thu, Apr 01, 2004 at 02:32:14PM -0500, Jason Harris wrote: > > > > All of that said, I'm not too worried about this. It's annoying, but > > > > ultimately harmless. The corrupt sig will not validate (though the > > > > sig itself is actually good, the bad issuer means the key that issued > > > > it will never be found), so it will be ignored. > > > > > > Except where the issuer is irrelevant. > > > > I'm afraid I don't follow that comment. The issuer is always > > relevant, as it is used to find the key that issued the signature. > > As the GPG output in my last message demonstrates, GPG disregards > the issuer in subkey binding signatures. While the RFC specifies > the issuer be included in subkey binding signatures, it also only > allows for the parent pubkey to issue such signatures. Therefore, > the issuer of subkey signatures is currently irrelevant, a priori. There are optimizations done, and there is general good practice. Don't rely on this. You'll hurt yourself. David From Axel.Thimm at physik.fu-berlin.de Tue Apr 6 14:08:38 2004 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Tue Apr 6 14:05:54 2004 Subject: build problem with pinentry 0.7.0 (and qt 3.1?) Message-ID: <20040406120838.GJ15798@neu.nirvana> Hi, I have upgraded all gnupg components (gnupg, gnupg2, gpgme, libksba, libgpg-error, dropped newpg) at ATrpms and wanted to do the same with pinentry 0.7.0. Unfortunately I get lots of function prototype and shadow warnings against gtk-1.2, like In file included from /usr/include/gtk-1.2/gtk/gtk.h:80, from pinentry-gtk.c:24: /usr/include/gtk-1.2/gtk/gtkitemfactory.h:48: warning: function declaration isn't a prototype In file included from /usr/include/gtk-1.2/gtk/gtk.h:86, from pinentry-gtk.c:24: /usr/include/gtk-1.2/gtk/gtkmenu.h:118: warning: declaration of `index' shadows a global declaration :0: warning: shadowed declaration is here but also errors in the qt part like secqstring.cpp:68:38: private/qunicodetables_p.h: No such file or directory secqstring.cpp: In member function `bool SecQString::isRightToLeft() const': secqstring.cpp:904: error: `::direction' undeclared (first use here) I am building on Fedora Core 1 (and RH9 to 7.3). FC1 has QT 3.1 Thanks! -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20040406/064c1144/attachment.bin From jvender at owensboro.net Wed Apr 7 07:14:37 2004 From: jvender at owensboro.net (J Vender) Date: Wed Apr 7 07:12:45 2004 Subject: GPG random data gathering Message-ID: <200404070014370260.0017B17E@127.0.0.1> A Few questions about GnuPG on windows... When, and under what conditions (using a native windows compile of GnuPG built using MSYS/MingW32 in Windows98SE) does GnuPG gather random data for the entropy pool? Does this only happen when the dos console is open and GnuPG is running, or does it happen even if GnuPG isn't running? Under windows, when generating a key, is it necessary to move the mouse or type on the keyboard for the random device to gather entropy for the key generation, and does the mouse pointer need to be within the dos window for the movement to count for entropy gathering. Last questions: When building a native windows binary of GnuPG using MSYS/MingW32 on Windows98SE, is there any advantage to using the --enable-m-guard switch in the ./configure step, or is this unnecessary, and if so, why? Thanks. From jvender at owensboro.net Wed Apr 7 07:38:02 2004 From: jvender at owensboro.net (J Vender) Date: Wed Apr 7 07:35:58 2004 Subject: GPG random data gathering Message-ID: <200404070038020370.002D2322@127.0.0.1> Sorry about the long lines. I had the hard line breaks turned off in Calypso because they break long URLs, but I see that this message board doesn't re-wrap the messages, which I guess if I'd thought about it makes sense since some people use GnuPG to sign their messages here. I hope this post will turn out better, as I've turned on hard breaks at 76 characters. If this post doesn't look better, I guess I'll have to use a different email client to post with. Oh well...here goes nothing... From wk at gnupg.org Wed Apr 7 09:25:47 2004 From: wk at gnupg.org (Werner Koch) Date: Wed Apr 7 09:11:52 2004 Subject: GPG random data gathering In-Reply-To: <200404070014370260.0017B17E@127.0.0.1> (J. Vender's message of "Wed, 07 Apr 2004 00:14:37 -0500") References: <200404070014370260.0017B17E@127.0.0.1> Message-ID: <8765cc9rlw.fsf@vigenere.g10code.de> On Wed, 07 Apr 2004 00:14:37 -0500, J Vender said: > When, and under what conditions (using a native windows compile of GnuPG built using MSYS/MingW32 in Windows98SE) does GnuPG gather random data for the entropy pool? Does this only happen when the dos console is open and GnuPG is running, or does it happen even if GnuPG isn't running? I don't know about MSYS. If you build GnupG the suggested way as described in README.W32, GnupG wiol gather random while it is running from a couple of available sources, there is no direct access to the mouse but system data which changes while the move is moved will be used for example. > Last questions: When building a native windows binary of GnuPG using MSYS/MingW32 on Windows98SE, is there any advantage to using the --enable-m-guard switch in the ./configure step, or is this unnecessary, and if so, why? No, I am even nor sure whether it still builds using that configure option. I have not used it for ages. Werner From jvender at owensboro.net Wed Apr 7 09:45:01 2004 From: jvender at owensboro.net (J Vender) Date: Wed Apr 7 09:42:34 2004 Subject: GPG random data gathering In-Reply-To: <8765cc9rlw.fsf@vigenere.g10code.de> References: <200404070014370260.0017B17E@127.0.0.1> <8765cc9rlw.fsf@vigenere.g10code.de> Message-ID: <200404070245010360.00392CE8@127.0.0.1> >I don't know about MSYS. If you build GnupG the suggested way as >described in README.W32, GnupG wiol gather random while it is running >from a couple of available sources, there is no direct access to the >mouse but system data which changes while the move is moved will be >used for example. > O.K. >No, I am even nor sure whether it still builds using that configure >option. I have not used it for ages. > > Werner > O.K., no benefit in using it anymore. Does GnuPG lock the memory where the passphrase is stored, like PGP does? FYI, I've been using --enable-m-guard with every compile. It compiled with everything up to the latest version I've tried-GnuPG 1.3.5. I've never had any error messages relating to it, that I know of. GnuPG 1.2.5 built all the way through, no problems. I've had problems in the po directory when building 1.3.5, but the binaries work O.K. Not sure why the problem in the po directory with 1.3.5, but no problem there with 1.2.5. From wk at gnupg.org Wed Apr 7 12:58:38 2004 From: wk at gnupg.org (Werner Koch) Date: Wed Apr 7 12:42:00 2004 Subject: GPG random data gathering In-Reply-To: <200404070245010360.00392CE8@127.0.0.1> (J. Vender's message of "Wed, 07 Apr 2004 02:45:01 -0500") References: <200404070014370260.0017B17E@127.0.0.1> <8765cc9rlw.fsf@vigenere.g10code.de> <200404070245010360.00392CE8@127.0.0.1> Message-ID: <87ptak836p.fsf@vigenere.g10code.de> On Wed, 07 Apr 2004 02:45:01 -0500, J Vender said: > Does GnuPG lock the memory where the passphrase is stored, like PGP does? It does thi on systems wehere it is possible It is not possible under Windows without installing a special driver to support unswappable memory - there exists no such free driver. All Windows functions claiming to lock the memory don't do what you would expect them to do. Newer Windows versions (XP?) might have a new API to do this, I am not sure about this. > GnuPG 1.2.5 built all the way through, no problems. I've had problems in > the po directory when building 1.3.5, but the binaries work O.K. Not sure We have not worked on that in 1.3.x; this will be fixed when we are about to move 1.3 to 1.4. Werner From pgut001 at cs.auckland.ac.nz Wed Apr 7 13:22:09 2004 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Wed Apr 7 13:19:44 2004 Subject: GPG random data gathering In-Reply-To: <87ptak836p.fsf@vigenere.g10code.de> Message-ID: Werner Koch writes: >On Wed, 07 Apr 2004 02:45:01 -0500, J Vender said: >>Does GnuPG lock the memory where the passphrase is stored, like PGP does? > >It does thi on systems wehere it is possible It is not possible under Windows >without installing a special driver to support unswappable memory - there >exists no such free driver. All Windows functions claiming to lock the >memory don't do what you would expect them to do. Actually there's a lot of confusion about VirtualLock, with contradicting claims about what it really does. After I did my analysis of it (and unfortunately too late to make it into the book), an MS security person had a close look at it and was unable to get VirtualLock()'ed memory paged out no matter what he did. He also checked with someone who had worked on VirtualLock who said that it did indeed prevent the memory from being paged. The problem is that there have been instances in the past where an MS developer has believed that his code did X when in fact it did Y, since there have been reports from other sources that it does result in data being paged my best guess is that it did this under NT and perhaps early Win2K, but has been changed in newer Win2K and XP. It may also be that since VirtualLock() has per-page granularity, some of the people who reported data being swapped experienced this because they'd VirtualUnlock()'ed adjacent data on the same page. My code goes to some lengths to ensure that it never VirtualUnlock()'s anything on the same page, although if your keys happen to share a page with data that something else VirtualUnlock()'s then that guarantee is gone. To in turn get around *that*, you can use VirtualAlloc() in place of malloc(), specifying memory blocks in 4K increments. This kinda wastes memory (and means you have to do additional work to handle thread-safety), but it does mean you can completely control the memory you're getting. You can also get nonpageable memory using AWE (Address Windowing Extensions), but the interface to that is clunky to say the least. Peter. From wk at gnupg.org Wed Apr 7 14:36:11 2004 From: wk at gnupg.org (Werner Koch) Date: Wed Apr 7 14:21:55 2004 Subject: GPG random data gathering In-Reply-To: (Peter Gutmann's message of "Wed, 07 Apr 2004 23:22:09 +1200") References: Message-ID: <87brm47yo4.fsf@vigenere.g10code.de> On Wed, 07 Apr 2004 23:22:09 +1200, Peter Gutmann said: > close look at it and was unable to get VirtualLock()'ed memory paged out no > matter what he did. He also checked with someone who had worked on > VirtualLock who said that it did indeed prevent the memory from being paged. That is interesting. Given that this is a standard Win32 API function, it is an easy way to add this to gpg. There is 30 pages limit per process which is far more than gpg requires. > page. My code goes to some lengths to ensure that it never VirtualUnlock()'s > anything on the same page, although if your keys happen to share a page with > data that something else VirtualUnlock()'s then that guarantee is gone. To in For gpg it is easier because we set a block of memory aside right at startup and thus we don't need to unlock anything. > You can also get nonpageable memory using AWE (Address Windowing Extensions), > but the interface to that is clunky to say the least. That's what I had in mind when mentioning a possible new API. Thanks, Werner From checco at optonline.net Wed Apr 7 15:03:04 2004 From: checco at optonline.net (John Checco) Date: Wed Apr 7 15:00:14 2004 Subject: non-paged memory under windows References: Message-ID: <001401c41ca0$aa2764b0$6300000a@dual> just to re-iterate your point, I've worked on a project that needed non-paged memory to pass to a frame-grabber pci board... We found out the hard way that none of the retail functions ever guaranteed memory was not paged -- we ended up creating our own memory device driver, including creation of SGLs and IRPs and using ExAllocatePool... needless to say, true non-paged access is really difficult to implement under Windows. ----- Original Message ----- From: "Peter Gutmann" To: ; Sent: Wednesday, April 07, 2004 7:22 AM Subject: Re: GPG random data gathering > Werner Koch writes: > >On Wed, 07 Apr 2004 02:45:01 -0500, J Vender said: > >>Does GnuPG lock the memory where the passphrase is stored, like PGP does? > > > >It does thi on systems wehere it is possible It is not possible under Windows > >without installing a special driver to support unswappable memory - there > >exists no such free driver. All Windows functions claiming to lock the > >memory don't do what you would expect them to do. > > Actually there's a lot of confusion about VirtualLock, with contradicting > claims about what it really does. After I did my analysis of it (and > unfortunately too late to make it into the book), an MS security person had a > close look at it and was unable to get VirtualLock()'ed memory paged out no > matter what he did. He also checked with someone who had worked on > VirtualLock who said that it did indeed prevent the memory from being paged. > The problem is that there have been instances in the past where an MS > developer has believed that his code did X when in fact it did Y, since there > have been reports from other sources that it does result in data being paged > my best guess is that it did this under NT and perhaps early Win2K, but has > been changed in newer Win2K and XP. It may also be that since VirtualLock() > has per-page granularity, some of the people who reported data being swapped > experienced this because they'd VirtualUnlock()'ed adjacent data on the same > page. My code goes to some lengths to ensure that it never VirtualUnlock()'s > anything on the same page, although if your keys happen to share a page with > data that something else VirtualUnlock()'s then that guarantee is gone. To in > turn get around *that*, you can use VirtualAlloc() in place of malloc(), > specifying memory blocks in 4K increments. This kinda wastes memory (and > means you have to do additional work to handle thread-safety), but it does > mean you can completely control the memory you're getting. > > You can also get nonpageable memory using AWE (Address Windowing Extensions), > but the interface to that is clunky to say the least. > > Peter. > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From pgut001 at cs.auckland.ac.nz Wed Apr 7 15:33:22 2004 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Wed Apr 7 15:31:13 2004 Subject: non-paged memory under windows In-Reply-To: <001401c41ca0$aa2764b0$6300000a@dual> Message-ID: John Checco writes: >just to re-iterate your point, I've worked on a project that needed non-paged >memory to pass to a frame-grabber pci board... We found out the hard way that >none of the retail functions ever guaranteed memory was not paged -- we ended >up creating our own memory device driver, including creation of SGLs and IRPs >and using ExAllocatePool... needless to say, true non-paged access is really >difficult to implement under Windows. Hmm, just to confirm this, you're saying that neither VirtualLock() nor AWE guarantee that pages remain resident at all times? Do you have more info on the conditions under which (supposedly) locked pages can become non-resident? The two main sources that have said that VirtualLock() doesn't work have been working at the device-driver level, I wonder if this is something that isn't visible to apps but is visible to developers working at a lower level? (If you don't mind discussing the details with someone from MS, let me know, it'd be good to get this tracked down and fixed. The biggest hurdle so far has been replicating the problem to demonstrate that it really exists). Peter. From jvender at owensboro.net Thu Apr 8 01:13:04 2004 From: jvender at owensboro.net (J Vender) Date: Thu Apr 8 01:11:00 2004 Subject: An auto-key-retrieve question. Message-ID: <200404071813040490.000BCE11@127.0.0.1> Does GnuPG 1.2.4 or higher have an option which would enable one, when verifying a signature, to automatically retrieve the signing key from the keyserver, BUT would also enable me to view the key details and cancel the import after the retrieval if I wish? PGP allows one to examine the key details and signatures before actually importing the key into the keyring, which can be cancelled after retrieving the key, if so desired. From dshaw at jabberwocky.com Thu Apr 8 01:35:37 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Apr 8 01:33:04 2004 Subject: An auto-key-retrieve question. In-Reply-To: <200404071813040490.000BCE11@127.0.0.1> References: <200404071813040490.000BCE11@127.0.0.1> Message-ID: <20040407233537.GA14915@jabberwocky.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Apr 07, 2004 at 06:13:04PM -0500, J Vender wrote: > Does GnuPG 1.2.4 or higher have an option which would enable one, when > verifying a signature, to automatically retrieve the signing key from the > keyserver, BUT would also enable me to view the key details and cancel the > import after the retrieval if I wish? PGP allows one to examine the key > details and signatures before actually importing the key into the keyring, > which can be cancelled after retrieving the key, if so desired. Set "--interactive". David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6-cvs (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iHEEARECADEFAkB0kEkqGGh0dHA6Ly93d3cuamFiYmVyd29ja3kuY29tL2Rhdmlk L2tleXMuYXNjAAoJEOJmXIdJ4cvJt0AAn13jEtuzNZrstAtowNZyKgziJSRWAJ9e z/nXrRhTn6EfZI1ZHHwcckjZag== =z3++ -----END PGP SIGNATURE----- From jharris at widomaker.com Fri Apr 9 16:43:42 2004 From: jharris at widomaker.com (Jason Harris) Date: Fri Apr 9 16:41:15 2004 Subject: [pgp-keyserver-folk] keyids in signatures getting corrupted, GPG and/or Debian problem? In-Reply-To: <4076A1D7.1020900@neggie.net> References: <20040331012400.GL10980@pm1.ric-41.lft.widomaker.com> <4076A1D7.1020900@neggie.net> Message-ID: <20040409144342.GY10980@pm1.ric-41.lft.widomaker.com> On Fri, Apr 09, 2004 at 09:15:03AM -0400, John Belmonte wrote: > Jason Harris wrote: > >I've just noticed some signatures with their keyids changed to > >0x0910 in the last two bytes. Both keys I've noticed this on > >so far have been submitted directly to kjsl from different > >machines/users, and I believe both users use GPG. The "mangled" > My key (keyID 0x4C40410A) has the corruption you describe. From memory > and looking at the output of "gpg --list-keys -v", here is some relevant > history: > > * 2003-12-06 -- I added a new user ID to my key (john@neggie.net), > set the new ID as primary, and sent the key to pgp.mit.edu (to be > merged). At this time, the corrupt signature appeared on my former > primary ID (jvb@prairienet.org). I believe I was using gnupg 1.2.3. From my log (keyserver.kjsl.com): [Sun Dec 7 xx:xx:01 2003] mail_req: request received from PGP Key Server Administrator : incremental [Sun Dec 7 xx:xx:01 2003] kd_add: flags=100000 [Sun Dec 7 xx:xx:01 2003] display_new_sig: new sig 1 by 4C40410A added to 4C40410A John V. Belmonte [Sun Dec 7 xx:xx:01 2003] display_new_sig: new sig 2 by 4C40410A added to 4C40410A John V. Belmonte [Sun Dec 7 xx:xx:01 2003] display_new_sig: new sig 3 by 4C40410A added to 4C40410A John V. Belmonte [Sun Dec 7 xx:xx:01 2003] display_new_sig: new sig 4 by 4C40410A added to 4C40410A John V. Belmonte * 2004-02-18 -- I think I noticed that my previous setting of the > primary ID did not take affect (gpg was probably confused by two user > ID's being marked primary), so I set it again. Only the > jvb@prairienet.org ID got a new signature, which makes sense. I also > added another new user ID (jbelmonte@debian.org). No new corruption. I > was using gnupg 1.2.4. I got the new userid, but still not the packet in question (TZ=PST8PDT): [Tue Feb 17 23:19:00 2004] mail_req: request received from PGP Key Server Administrator : incremental [Tue Feb 17 23:19:00 2004] kd_add: flags=100000 [Tue Feb 17 23:19:00 2004] display_new_userid: new userid 1 on key 4C40410A: John V. Belmonte [Tue Feb 17 23:19:02 2004] kd_sync: completed successfully [Tue Feb 17 23:19:02 2004] kd_add: pub+0 dksigs+0 subu=0 sig+0 uid+1 uid=1 rev+0 It arrives over two months later than when you thought it was generated, and from a different keyserver than you submitted your Debian userid to, as well as several minutes after that submission was processed: [Tue Feb 17 23:31:00 2004] mail_req: request received from sks keyserver.bu.edu: incremental [Tue Feb 17 23:31:00 2004] kd_add: flags=100000 [Tue Feb 17 23:31:00 2004] display_new_sig: new sig 1 by 4C400910 added to 4C40410A John V. Belmonte I suspect the bug is (or was) in gnupg. If 1.2.3 exhibited the problem The bogus packet could have been generated at any time after the good signature from 2003-12-06 was made available (to anyone else), but it doesn't seem to have been submitted to a keyserver by you. Yaron, will you inquire about the log(s) for keyserver.bu.edu? It seems like someone submitted the bogus packet via HKP to bu.edu about 10 minutes after John sent his Debian userid to mit.edu. -- Jason Harris | NIC: JH329, PGP: This _is_ PGP-signed, isn't it? jharris@widomaker.com _|_ web: http://keyserver.kjsl.com/~jharris/ Got photons? (TM), (C) 2004 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : /pipermail/attachments/20040409/ef367adc/attachment.bin From john at neggie.net Fri Apr 9 18:02:42 2004 From: john at neggie.net (John Belmonte) Date: Tue Apr 13 08:34:07 2004 Subject: [pgp-keyserver-folk] keyids in signatures getting corrupted, GPG and/or Debian problem? In-Reply-To: <20040409144342.GY10980@pm1.ric-41.lft.widomaker.com> References: <20040331012400.GL10980@pm1.ric-41.lft.widomaker.com> <4076A1D7.1020900@neggie.net> <20040409144342.GY10980@pm1.ric-41.lft.widomaker.com> Message-ID: <4076C922.5030601@neggie.net> Jason Harris wrote: > The bogus packet could have been generated at any time after the good > signature from 2003-12-06 was made available (to anyone else), but it > doesn't seem to have been submitted to a keyserver by you. > > Yaron, will you inquire about the log(s) for keyserver.bu.edu? > It seems like someone submitted the bogus packet via HKP to bu.edu > about 10 minutes after John sent his Debian userid to mit.edu. In that case, I suspect something in the Debian infrastructure. I don't recall the timing, but it seems likely that after adding the debian ID to my key and uploading to mit.edu, the next thing I did was try to update my key on the Debian keyring. -John -- http:// if ile.org/ From massey at privacynetworks.com Thu Apr 15 19:37:32 2004 From: massey at privacynetworks.com (todd massey) Date: Thu Apr 15 19:54:18 2004 Subject: Just starting Message-ID: <407EC85C.7030608@privacynetworks.com> Folks, First which library should I use for creating keys, encrypting and decrypting messages. I want use an API to make these calls from my program and don't want to use gpg from the command line since I want to store my keys and manage my keys differently. Thanks, Todd From ndtt at ll.iac.es Thu Apr 15 22:07:00 2004 From: ndtt at ll.iac.es (Noel D. Torres Tan~a) Date: Thu Apr 15 22:04:58 2004 Subject: Just starting In-Reply-To: <407EC85C.7030608@privacynetworks.com> References: <407EC85C.7030608@privacynetworks.com> Message-ID: <407EEB64.6010807@ll.iac.es> todd massey wrote: > Folks, > > First which library should I use for creating keys, encrypting and > decrypting messages. I want use an API to make these calls from my > program and don't want to use gpg from the command line since I want to > store my keys and manage my keys differently. > > Thanks, > Todd > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > > Try gcrypt Envite From marcus.brinkmann at ruhr-uni-bochum.de Mon Apr 19 15:56:09 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Apr 19 15:52:05 2004 Subject: gpgme+gpgsm bug: fails when stdout redirected In-Reply-To: <20040128195132.GC1017@antares.localdomain> References: <20040127210100.GA1389@antares.localdomain> <20040127215833.GN16814@212.23.136.22> <20040128195132.GC1017@antares.localdomain> Message-ID: <87zn98vzpi.wl@ulysses.g10code.de> At Wed, 28 Jan 2004 20:51:32 +0100, Albrecht Dre? wrote: > I discovered this bug when testing the first steps of s/mime support for > the gnome mua balsa. When running balsa form a terminal, it works fine, > but when launching it from the gnome menu or panel, it fails, apparently > because they redirect stdout/stderr for diagnostic purposes. Needless to > say that this bug is a real blocker, and explaining a hundred times in the > mailing lists that people have to open a terminal and launch balsa > manually if they want to have s/mime support is a nightmare! Hi, this has been fixed in the meanwhile with the following two changes in GPGME 0.4.6: 2004-03-23 Marcus Brinkmann * engine-gpgsm.c (gpgsm_new): Protect _only_ tty related code with isatty(). Submitted by Bernhard Herzog. 2004-03-11 Marcus Brinkmann * engine-gpgsm.c (gpgsm_new): Protect all tty related code with isatty(). Thanks, Marcus From beuc at gnu.org Tue Apr 20 00:30:57 2004 From: beuc at gnu.org (Sylvain Beucler) Date: Tue Apr 20 00:27:56 2004 Subject: gpg-agent Message-ID: <20040419223057.GI17955@wolf.minfo.bug> Hello, At savannah.gnu.org, we are using a system were each file upload has to be GPG-signed so as to protect file integrity in the case of a new crack. However, several people are not happy with it because it is cumbersome. We need gpg-agent so they can upload lots of files at once, without using the --passphrase-fd unsecure 'trick'. gpg-agent is only available using CVS, and does not seem to compile. Can you tell me what is the status of this tool? -- Sylvain From marcus.brinkmann at ruhr-uni-bochum.de Tue Apr 20 01:14:16 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue Apr 20 01:10:24 2004 Subject: gpg-agent In-Reply-To: <20040419223057.GI17955@wolf.minfo.bug> References: <20040419223057.GI17955@wolf.minfo.bug> Message-ID: <87k70bwofr.wl@ulysses.g10code.de> At Tue, 20 Apr 2004 00:30:57 +0200, Sylvain Beucler wrote: > We need gpg-agent so they can upload lots of files at once, without > using the --passphrase-fd unsecure 'trick'. > > gpg-agent is only available using CVS, and does not seem to compile. > Can you tell me what is the status of this tool? Note that gpg from version 1.0.5 or so on supports the use of gpg-agent. The gpg-agent in gnupg 1.9.x compiles fine for us. If it doesn't for you, please report the error so we can look into it. Hopefully it will be packaged for Debian not before too long. Thanks, Marcus From moritz at g10code.com Fri Apr 16 17:26:07 2004 From: moritz at g10code.com (Moritz Schulte) Date: Tue Apr 20 06:33:28 2004 Subject: [Announce] Libgcrypt-1.2.0 released Message-ID: We are pleased to announce the availability of Libgcrypt 1.2.0, which is the first stable release of this general purpose crypto library based on GnuPG code. Note, that Libgcrypt is neither a replacement for GnuPG nor does it contain a library version of GnuPG. It is only of interest for developers of crypto applications with a need for crypto building blocks available under the GNU Lesser General Public License. Complete source packages: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.2.0.tar.gz (927k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.2.0.tar.gz.sig Patch against version 1.9.94: ftp://ftp.gnupg.org/gcrypt/alpha/libgcrypt/libgcrypt-1.1.94-1.2.0.diff.gz (246k) Mirrors are listed at http://www.gnupg.org/download/mirrors.html. MD5 sums are: 5c508072d8387ce17d1ab05075c2be40 libgcrypt-1.2.0.tar.gz a1657523beebf926ca7992cc6b9ea9b5 libgcrypt-1.1.94-1.2.0.diff.gz Except for one bug fix this release is basically equivalent to the last pre-release. Thanks to all who have worked on Libgcrypt (and thanks to those who have worked on other things as well). Happy hacking. -- Moritz Schulte g10 Code GmbH http://www.g10code.com -=- The GnuPG Experts -=- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From matt at domsch.com Mon Apr 19 06:57:30 2004 From: matt at domsch.com (Matt Domsch) Date: Tue Apr 20 06:33:36 2004 Subject: HTTP proxy authentication / libcurl? Message-ID: <20040419045729.GA13374@domsch.com> I find I need to have gnupg handle HTTP proxy authentication. I've seen several other posters looking for similar functionality. In trying to add HTTP proxy authentication to gnupg, I see that much of the work is already being done by another application, curl, and that its libcurl might be a reasonable mechanism to employ from within gnupg to handle keyserver communication. Thoughts? It would be a shame to have to re-implement the various proxy authentication mechanisms that curl provides (Basic, GSS, NTLM) in gnupg. At a glance, the portions of gnupg that would be affected are util/http.c:{http_open(),http_start_data(), http_wait_response(), http_open_document(), and http_close()}, - all of which look like they can be replaced by curl_easy_perform() with appropriate setup/cleanup for the library itself. Curl's license is the X11 license, thus GPL compatible, as of late 2002. Or, is there another preferred mechanism to have gnupg communicate with the keyservers over authenticating HTTP proxies? Thanks, Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20040418/acedc86e/attachment.bin From arnechaa at online.no Mon Apr 19 23:27:47 2004 From: arnechaa at online.no (=?iso-8859-15?Q?Arne_Christian_H=E5rseth?=) Date: Tue Apr 20 06:33:41 2004 Subject: International characters Message-ID: Hi! I am working on a Java front end to GPG and a small java library. I have some problems handling international characters. Using gpg.exe I can enter Norwegian characters (???) fine and I can read the Norwegian characters with my library by using a buffer with character set set to C865 like this: BufferedReader gpgres = new BufferedReader( new InputStreamReader(child.getInputStream(), "Cp865")); By the way why is not gpg using UTF-8 all over (not just for input)? When I try to make a new key from my library however, using UTF-8, when reading the characters back "???" apears like this: "???" (note that they are not escaped so it seems like the UTF-encoding is OK but offset). I am writing by using a buffer with character set set to UTF-8 for the buffer like this: BufferedWriter gpginput = new BufferedWriter( new OutputStreamWriter(child.getOutputStream(), "UTF8")); Why isn't this working? Java is using Unicode internally and I though that UTF characters were uniquely defines so I would think that this would be staight forward? How should I encode the character when writing to gpg.exe input? I don't subscribe to this list so please respond to arnechaa@online.no Arne From beuc at gnu.org Tue Apr 20 13:16:35 2004 From: beuc at gnu.org (Sylvain Beucler) Date: Tue Apr 20 13:55:52 2004 Subject: gpg-agent In-Reply-To: <87k70bwofr.wl@ulysses.g10code.de> (from marcus.brinkmann@ruhr-uni-bochum.de on Tue, Apr 20, 2004 at 01:14:16 +0200) References: <20040419223057.GI17955@wolf.minfo.bug> <87k70bwofr.wl@ulysses.g10code.de> Message-ID: <20040420111635.GE24078@wolf.minfo.bug> On 2004.04.20 01:14, Marcus Brinkmann wrote: > At Tue, 20 Apr 2004 00:30:57 +0200, > Sylvain Beucler wrote: > > We need gpg-agent so they can upload lots of files at once, without > > using the --passphrase-fd unsecure 'trick'. > > gpg-agent is only available using CVS, and does not seem to > > compile. > > Can you tell me what is the status of this tool? > > Note that gpg from version 1.0.5 or so on supports the use of > gpg-agent. > > The gpg-agent in gnupg 1.9.x compiles fine for us. If it doesn't for > you, please report the error so we can look into it. > > Hopefully it will be packaged for Debian not before too long. Actually I was not aware of v1.9.x, and tried the HEAD branch, ie v1.3.5. Version 1.9.7 compiles fine here as well. However, I have been searching for an equivalent to ssh-add, with no luck. Is such a tool present in GnuPG? Thanks, -- Sylvain From marcus.brinkmann at ruhr-uni-bochum.de Tue Apr 20 14:30:41 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue Apr 20 14:26:39 2004 Subject: gpg-agent In-Reply-To: <20040420111635.GE24078@wolf.minfo.bug> References: <20040419223057.GI17955@wolf.minfo.bug> <87k70bwofr.wl@ulysses.g10code.de> <20040420111635.GE24078@wolf.minfo.bug> Message-ID: <87isfux24u.wl@ulysses.g10code.de> At Tue, 20 Apr 2004 13:16:35 +0200, Sylvain Beucler wrote: > However, I have been searching for an equivalent to ssh-add, with no > luck. Is such a tool present in GnuPG? That's what gpg-agent is. To make it use caching, you have to configure it (default-cache-ttl SECONDS into ~/.gnupg/gpg-agent.conf). You also need to have pinentry installed (and configure the path to the pinentry you are using with "pinentry-program /usr/bin/pinentry-gtk" or similar in gpg-agent.conf). Finally, you need to use the option --use-agent with gpg (you can use gpg 1.2.x). Thanks, Marcus From wk at gnupg.org Tue Apr 20 15:02:56 2004 From: wk at gnupg.org (Werner Koch) Date: Tue Apr 20 14:46:16 2004 Subject: gpg-agent In-Reply-To: <20040420111635.GE24078@wolf.minfo.bug> (Sylvain Beucler's message of "Tue, 20 Apr 2004 13:16:35 +0200") References: <20040419223057.GI17955@wolf.minfo.bug> <87k70bwofr.wl@ulysses.g10code.de> <20040420111635.GE24078@wolf.minfo.bug> Message-ID: <87y8oq7qf3.fsf@vigenere.g10code.de> On Tue, 20 Apr 2004 13:16:35 +0200, Sylvain Beucler said: > However, I have been searching for an equivalent to ssh-add, with no > luck. Is such a tool present in GnuPG? There is no need for it. When using gpg with the gpg-agent, the ganet does not do what it eventually should: Keeping all secret key stuff under the sole control of the agent. Instead gpg uses the agent simply as a way to access the pinentry and to cache passphrases. gpgsm (the S/MIME cousing of gpg) uses gpg-agent the real way. We have several ways adding secret keys to the gpg-agent: If gpgsm creates a certification request, it requests gpg-agent to create a secret key and store it away, gpg-agent then returns the public part and takes requests for signing and decryption. If you have a pkcs#12 file with a secret key, gpgsm allows to import it (simply use "gpgsm --import") by forwarding the secret key to the agent. If you use a smartcard, the secret key is stored there and the agent will only store way a stub secret key with a reference to the smartcard. Finally you may add a secret key to the agents secret key store by copying the file to there. Salam-Shalom, Werner From albrecht.dress at arcor.de Tue Apr 20 21:07:06 2004 From: albrecht.dress at arcor.de (Albrecht =?iso-8859-1?Q?Dre=DF?=) Date: Tue Apr 20 21:17:54 2004 Subject: gpg-agent In-Reply-To: <87y8oq7qf3.fsf@vigenere.g10code.de> (from wk@gnupg.org on Die, Apr 20, 2004 at 15:02:56 +0200) References: <20040419223057.GI17955@wolf.minfo.bug> <87k70bwofr.wl@ulysses.g10code.de> <20040420111635.GE24078@wolf.minfo.bug> <87y8oq7qf3.fsf@vigenere.g10code.de> Message-ID: <20040420190706.GA1217@antares.localdomain> Am 20.04.04 15:02 schrieb(en) Werner Koch: > When using gpg with the gpg-agent, the ganet does not do what it > eventually should: Keeping all secret key stuff under the sole > control of the agent. Instead gpg uses the agent simply as a way to > access the pinentry and to cache passphrases. ...which is a *really* nice feature, e.g. if you want to decrypt a bunch of files! However, the output when using gpg is really sparse: for me, pinentry-gtk just says "Passphrase" and nothing more (in contrast to gpgsm, where I get some information abut what is needed and why). Isn't it possible to make output with gpg somewhat more meaningful == user- friendly? Cheers, Albrecht. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Albrecht Dre? - Johanna-Kirchner-Stra?e 13 - D-53123 Bonn (Germany) Phone (+49) 228 6199571 - mailto:albrecht.dress@arcor.de _________________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20040420/1934c1e1/attachment-0001.bin From wk at gnupg.org Wed Apr 21 08:52:42 2004 From: wk at gnupg.org (Werner Koch) Date: Wed Apr 21 08:36:11 2004 Subject: gpg-agent In-Reply-To: <20040420190706.GA1217@antares.localdomain> (Albrecht =?iso-8859-1?q?Dre=DF's?= message of "Tue, 20 Apr 2004 21:07:06 +0200") References: <20040419223057.GI17955@wolf.minfo.bug> <87k70bwofr.wl@ulysses.g10code.de> <20040420111635.GE24078@wolf.minfo.bug> <87y8oq7qf3.fsf@vigenere.g10code.de> <20040420190706.GA1217@antares.localdomain> Message-ID: <87k7097rgl.fsf@vigenere.g10code.de> On Tue, 20 Apr 2004 21:07:06 +0200, Albrecht Dre? said: > gpgsm, where I get some information abut what is needed and why). Isn't it > possible to make output with gpg somewhat more meaningful == user- > friendly? Are you using an old version of gpg-agent or gpg? For me (gpg 1.2.4, gpg-agent 1.9.7) shows: You need a passphrase to unlock the secret key for user: "Werner Koch " 1024-bit DSA key, ID 010A57ED, created 2004-03-21 (main key ID 5B0358A2) which happens to be identical to the message gpg prints on the console. Werner From albrecht.dress at arcor.de Mon Apr 26 21:53:03 2004 From: albrecht.dress at arcor.de (Albrecht =?iso-8859-1?Q?Dre=DF?=) Date: Mon Apr 26 22:00:55 2004 Subject: gpg-agent In-Reply-To: <87k7097rgl.fsf@vigenere.g10code.de> (from wk@gnupg.org on Mit, Apr 21, 2004 at 08:52:42 +0200) References: <20040419223057.GI17955@wolf.minfo.bug> <87k70bwofr.wl@ulysses.g10code.de> <20040420111635.GE24078@wolf.minfo.bug> <87y8oq7qf3.fsf@vigenere.g10code.de> <20040420190706.GA1217@antares.localdomain> <87k7097rgl.fsf@vigenere.g10code.de> Message-ID: <20040426195303.GC26604@antares.localdomain> Am 21.04.04 08:52 schrieb(en) Werner Koch: > Are you using an old version of gpg-agent or gpg? For me (gpg 1.2.4, > gpg-agent 1.9.7) shows: > > You need a passphrase to unlock the secret key for user: > "Werner Koch " > 1024-bit DSA key, ID 010A57ED, created 2004-03-21 (main key ID > 5B0358A2) Hmm, I have [albrecht@antares albrecht]$ gpg-agent --version gpg-agent[3028]: Secure memory is not locked into core gpg-agent (GnuPG) 1.9.6 and [albrecht@antares albrecht]$ gpg --version gpg (GnuPG) 1.2.4 I can see, though, that the gtk-pinentry window gets higher (as if the space over the entry somehow grows to two invisible lines) when gpg-agent "asks again" as I mistyped the first passphrase. May it be a problem that my User ID contains (a UTF-8 encoded? Not sure...) Umlaut? Thanks, Albrecht. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Albrecht Dre? - Johanna-Kirchner-Stra?e 13 - D-53123 Bonn (Germany) Phone (+49) 228 6199571 - mailto:albrecht.dress@arcor.de _________________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20040426/93fed589/attachment.bin From beuc at gnu.org Mon Apr 26 22:10:06 2004 From: beuc at gnu.org (Sylvain Beucler) Date: Mon Apr 26 22:19:10 2004 Subject: gpg-agent In-Reply-To: <20040426195303.GC26604@antares.localdomain> (from albrecht.dress@arcor.de on Mon, Apr 26, 2004 at 21:53:03 +0200) References: <20040419223057.GI17955@wolf.minfo.bug> <87k70bwofr.wl@ulysses.g10code.de> <20040420111635.GE24078@wolf.minfo.bug> <87y8oq7qf3.fsf@vigenere.g10code.de> <20040420190706.GA1217@antares.localdomain> <87k7097rgl.fsf@vigenere.g10code.de> <20040426195303.GC26604@antares.localdomain> Message-ID: <20040426201006.GN6240@wolf.minfo.bug> On 2004.04.26 21:53, Albrecht Dre? wrote: > Am 21.04.04 08:52 schrieb(en) Werner Koch: >> Are you using an old version of gpg-agent or gpg? For me (gpg >> 1.2.4, >> gpg-agent 1.9.7) shows: >> >> You need a passphrase to unlock the secret key for user: >> "Werner Koch " >> 1024-bit DSA key, ID 010A57ED, created 2004-03-21 (main key ID >> 5B0358A2) > > Hmm, I have > > [albrecht@antares albrecht]$ gpg-agent --version > gpg-agent[3028]: Secure memory is not locked into core > gpg-agent (GnuPG) 1.9.6 > > and > > [albrecht@antares albrecht]$ gpg --version > gpg (GnuPG) 1.2.4 > > I can see, though, that the gtk-pinentry window gets higher (as if > the space over the entry somehow grows to two invisible lines) when > gpg-agent "asks again" as I mistyped the first passphrase. May it be > a problem that my User ID contains (a UTF-8 encoded? Not sure...) > Umlaut? 1.3.6-cvs/1.9.7/gtk-pinentry is also 'mute'. I do not have any accent / non-US-ASCII character in my user id. Maybe Werner is using the kde pinentry? (I didn't try it) -- Sylvain From wk at gnupg.org Tue Apr 27 10:59:38 2004 From: wk at gnupg.org (Werner Koch) Date: Tue Apr 27 10:41:14 2004 Subject: gpg-agent In-Reply-To: <20040426201006.GN6240@wolf.minfo.bug> (Sylvain Beucler's message of "Mon, 26 Apr 2004 22:10:06 +0200") References: <20040419223057.GI17955@wolf.minfo.bug> <87k70bwofr.wl@ulysses.g10code.de> <20040420111635.GE24078@wolf.minfo.bug> <87y8oq7qf3.fsf@vigenere.g10code.de> <20040420190706.GA1217@antares.localdomain> <87k7097rgl.fsf@vigenere.g10code.de> <20040426195303.GC26604@antares.localdomain> <20040426201006.GN6240@wolf.minfo.bug> Message-ID: <87isflx0cl.fsf@vigenere.g10code.de> On Mon, 26 Apr 2004 22:10:06 +0200, Sylvain Beucler said: > Maybe Werner is using the kde pinentry? (I didn't try it) Definitely not. However I am of course using the CVS version and only realized last week that there was no release since December. Thus I released 0.7.1 last week - did you already tried it? Werner From wk at gnupg.org Tue Apr 27 12:09:07 2004 From: wk at gnupg.org (Werner Koch) Date: Tue Apr 27 11:50:50 2004 Subject: gpg-agent In-Reply-To: <20040427091246.GA10904@wolf.minfo.bug> (Sylvain Beucler's message of "Tue, 27 Apr 2004 11:12:46 +0200") References: <20040419223057.GI17955@wolf.minfo.bug> <87k70bwofr.wl@ulysses.g10code.de> <20040420111635.GE24078@wolf.minfo.bug> <87y8oq7qf3.fsf@vigenere.g10code.de> <20040420190706.GA1217@antares.localdomain> <87k7097rgl.fsf@vigenere.g10code.de> <20040426195303.GC26604@antares.localdomain> <20040426201006.GN6240@wolf.minfo.bug> <87isflx0cl.fsf@vigenere.g10code.de> <20040427091246.GA10904@wolf.minfo.bug> Message-ID: <87vfjlvikc.fsf@vigenere.g10code.de> On Tue, 27 Apr 2004 11:12:46 +0200, Sylvain Beucler said: > pinentry-gtk does not display any text but 'passphrase'. Hmmm. I can only tell that I am happily using it for a very long time and it always displays the description of the key. > Incidentally, pinentry-curses does not cache my passphrase. Is it > normal? The pinentry does not cache the passpharse; this is the job of the gpg-agent. You may want to check your ~/.gpg-agent.conf for these options: `--default-cache-ttl N' Set the time a cache entry is valid to N seconds. The default are 600 seconds. `--pinentry-program FILENAME' Use program FILENAME as the PIN entry. The default is installation dependend and can be shown with the `--version' command. Shalom-Salam, Werner From beuc at beuc.net Tue Apr 27 11:12:46 2004 From: beuc at beuc.net (Sylvain Beucler) Date: Tue Apr 27 13:06:07 2004 Subject: gpg-agent In-Reply-To: <87isflx0cl.fsf@vigenere.g10code.de> (from wk@gnupg.org on Tue, Apr 27, 2004 at 10:59:38 +0200) References: <20040419223057.GI17955@wolf.minfo.bug> <87k70bwofr.wl@ulysses.g10code.de> <20040420111635.GE24078@wolf.minfo.bug> <87y8oq7qf3.fsf@vigenere.g10code.de> <20040420190706.GA1217@antares.localdomain> <87k7097rgl.fsf@vigenere.g10code.de> <20040426195303.GC26604@antares.localdomain> <20040426201006.GN6240@wolf.minfo.bug> <87isflx0cl.fsf@vigenere.g10code.de> Message-ID: <20040427091246.GA10904@wolf.minfo.bug> On 2004.04.27 10:59, Werner Koch wrote: > On Mon, 26 Apr 2004 22:10:06 +0200, Sylvain Beucler said: > > > Maybe Werner is using the kde pinentry? (I didn't try it) > > Definitely not. However I am of course using the CVS version and > only realized last week that there was no release since December. > Thus I released 0.7.1 last week - did you already tried it? I am using 0.7.1-cvs, ie 0.7.1 minus the release announcement in the ChangeLog :) pinentry-gtk does not display any text but 'passphrase'. Incidentally, pinentry-curses does not cache my passphrase. Is it normal? -- Sylvain From beuc at gnu.org Tue Apr 27 13:19:26 2004 From: beuc at gnu.org (Sylvain Beucler) Date: Tue Apr 27 13:29:07 2004 Subject: gpg-agent In-Reply-To: <87vfjlvikc.fsf@vigenere.g10code.de> (from wk@gnupg.org on Tue, Apr 27, 2004 at 12:09:07 +0200) References: <87k70bwofr.wl@ulysses.g10code.de> <20040420111635.GE24078@wolf.minfo.bug> <87y8oq7qf3.fsf@vigenere.g10code.de> <20040420190706.GA1217@antares.localdomain> <87k7097rgl.fsf@vigenere.g10code.de> <20040426195303.GC26604@antares.localdomain> <20040426201006.GN6240@wolf.minfo.bug> <87isflx0cl.fsf@vigenere.g10code.de> <20040427091246.GA10904@wolf.minfo.bug> <87vfjlvikc.fsf@vigenere.g10code.de> Message-ID: <20040427111926.GA11411@wolf.minfo.bug> On 2004.04.27 12:09, Werner Koch wrote: > On Tue, 27 Apr 2004 11:12:46 +0200, Sylvain Beucler said: > > > Incidentally, pinentry-curses does not cache my passphrase. Is it > > normal? > > The pinentry does not cache the passpharse; this is the job of the > gpg-agent. You may want to check your ~/.gpg-agent.conf for these > options: Sorry, I meant that using pinentry-curses as the gpg-agent pinentry program does not cache the passphrase, while using pinentry-gtk does. With pinentry-curses, the second time gpg needs my passphrase, I get: gpg-agent[11424]: command get_passphrase failed: Operation cancelled gpg-agent[11424]: DBG: map_to_assuan_status called with no error source I tried without and with 'default-cache-ttl 600' in my .gpg-agent.conf. pinentry-gtk, on the contrary, ask me the passphrase the first time, and remember it then. -- Sylvain From wk at gnupg.org Tue Apr 27 14:23:57 2004 From: wk at gnupg.org (Werner Koch) Date: Tue Apr 27 14:05:50 2004 Subject: gpg-agent In-Reply-To: <20040427111926.GA11411@wolf.minfo.bug> (Sylvain Beucler's message of "Tue, 27 Apr 2004 13:19:26 +0200") References: <87k70bwofr.wl@ulysses.g10code.de> <20040420111635.GE24078@wolf.minfo.bug> <87y8oq7qf3.fsf@vigenere.g10code.de> <20040420190706.GA1217@antares.localdomain> <87k7097rgl.fsf@vigenere.g10code.de> <20040426195303.GC26604@antares.localdomain> <20040426201006.GN6240@wolf.minfo.bug> <87isflx0cl.fsf@vigenere.g10code.de> <20040427091246.GA10904@wolf.minfo.bug> <87vfjlvikc.fsf@vigenere.g10code.de> <20040427111926.GA11411@wolf.minfo.bug> Message-ID: <87d65ttxr6.fsf@vigenere.g10code.de> On Tue, 27 Apr 2004 13:19:26 +0200, Sylvain Beucler said: > Sorry, I meant that using pinentry-curses as the gpg-agent pinentry > program does not cache the passphrase, while using pinentry-gtk does. The gpg-agent caches the passphrase and calls the pinentry only if it does not know the passphrase. > With pinentry-curses, the second time gpg needs my passphrase, I get: > gpg-agent[11424]: command get_passphrase failed: Operation cancelled > gpg-agent[11424]: DBG: map_to_assuan_status called with no error source That might be a bug in the curses version. Marcus, can you please check what's going wrong? > I tried without and with 'default-cache-ttl 600' in my .gpg-agent.conf. 600 secinds is the default anyway. > pinentry-gtk, on the contrary, ask me the passphrase the first time, > and remember it then. Tsss. Werner From albrecht.dress at arcor.de Tue Apr 27 20:50:52 2004 From: albrecht.dress at arcor.de (Albrecht =?iso-8859-1?Q?Dre=DF?=) Date: Tue Apr 27 20:53:00 2004 Subject: gpg-agent In-Reply-To: <87isflx0cl.fsf@vigenere.g10code.de> (from wk@gnupg.org on Die, Apr 27, 2004 at 10:59:38 +0200) References: <20040419223057.GI17955@wolf.minfo.bug> <87k70bwofr.wl@ulysses.g10code.de> <20040420111635.GE24078@wolf.minfo.bug> <87y8oq7qf3.fsf@vigenere.g10code.de> <20040420190706.GA1217@antares.localdomain> <87k7097rgl.fsf@vigenere.g10code.de> <20040426195303.GC26604@antares.localdomain> <20040426201006.GN6240@wolf.minfo.bug> <87isflx0cl.fsf@vigenere.g10code.de> Message-ID: <20040427185052.GA1169@antares.localdomain> Am 27.04.04 10:59 schrieb(en) Werner Koch: > Definitely not. However I am of course using the CVS version and only > realized last week that there was no release since December. Thus I > released 0.7.1 last week - did you already tried it? Installed 0.7.1, still the same problem... And there *is* a problem with national characters. Running pinentry-gtk directly from the command line, and then saying setdesc us-ascii text getpin displays "us-ascii text", whereas setdesc Test with ??????? getpin displays an empty line (i.e. not even "Test with "). An other strange thing is that it emits pinentry-gtk: no LC_CTYPE known - assuming UTF-8 twice after giving getpin, even if I run it (in bash) using LC_ALL=de_DE pinentry-gtk. My environment *is* set up properly, btw, locale says that everything is "de_DE". And, finally, when run by gpg-agent, the window doesn't come up with the preferred (programmed) theme, but with the default one - running it from the command line pops up the window in the correct theme. Any ideas? Thanks, Albrecht. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Albrecht Dre? - Johanna-Kirchner-Stra?e 13 - D-53123 Bonn (Germany) Phone (+49) 228 6199571 - mailto:albrecht.dress@arcor.de _________________________________________________________________________ From marcus.brinkmann at ruhr-uni-bochum.de Tue Apr 27 22:11:15 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue Apr 27 22:07:39 2004 Subject: gpg-agent In-Reply-To: <20040427185052.GA1169@antares.localdomain> References: <20040419223057.GI17955@wolf.minfo.bug> <87k70bwofr.wl@ulysses.g10code.de> <20040420111635.GE24078@wolf.minfo.bug> <87y8oq7qf3.fsf@vigenere.g10code.de> <20040420190706.GA1217@antares.localdomain> <87k7097rgl.fsf@vigenere.g10code.de> <20040426195303.GC26604@antares.localdomain> <20040426201006.GN6240@wolf.minfo.bug> <87isflx0cl.fsf@vigenere.g10code.de> <20040427185052.GA1169@antares.localdomain> Message-ID: <87oepddvvg.wl@ulysses.g10code.de> At Tue, 27 Apr 2004 20:50:52 +0200, Albrecht Dre? wrote: > > Am 27.04.04 10:59 schrieb(en) Werner Koch: > > Definitely not. However I am of course using the CVS version and only > > realized last week that there was no release since December. Thus I > > released 0.7.1 last week - did you already tried it? > > Installed 0.7.1, still the same problem... And there *is* a problem with > national characters. Running pinentry-gtk directly from the command line, > and then saying > > setdesc us-ascii text > getpin > > displays "us-ascii text", whereas > > setdesc Test with ??????? > getpin > > displays an empty line (i.e. not even "Test with "). That's certainly suboptimal, but note that the string must be provided in UTF-8. > An other strange > thing is that it emits > > pinentry-gtk: no LC_CTYPE known - assuming UTF-8 > > twice after giving getpin, even if I run it (in bash) using LC_ALL=de_DE > pinentry-gtk. My environment *is* set up properly, btw, locale says that > everything is "de_DE". This is only relevant if pinentry is used in curses mode, and relates to the character set used on the terminal that pinentry should display the dialog box on. It has nothing to do in particular with your environment, because it must be provided by the invoker (via OPTIONS --lc-type=... etc). > And, finally, when run by gpg-agent, the window doesn't come up with the > preferred (programmed) theme, but with the default one - running it from > the command line pops up the window in the correct theme. Dunno. How do Gtk apps know the theme to use? Thanks, Marcus From albrecht.dress at arcor.de Wed Apr 28 08:57:12 2004 From: albrecht.dress at arcor.de (=?ISO-8859-15?Q?Albrecht_Dre=DF?=) Date: Wed Apr 28 08:54:17 2004 Subject: Aw: Re: gpg-agent Message-ID: <25097116.1083135432419.JavaMail.ngmail@webmail07.arcor-online.net> > That's certainly suboptimal, but note that the string must be provided > in UTF-8. O.K., if it's a requirement - no problem! But I suspect gpg (or gpg-agent) feeding a *non utf8 string* into pinentry-gtk, which would then b a bug on that side. This would at least explain why I can't see any output, as my UID contains a "?" char. Is there a possibility to debug the stuff fed into pinentry by gpg-agent? > This is only relevant if pinentry is used in curses mode, and relates > to the character set used on the terminal that pinentry should display > the dialog box on. It has nothing to do in particular with your > environment, because it must be provided by the invoker (via OPTIONS > --lc-type=... etc). I see - thanks for the explanation! > Dunno. How do Gtk apps know the theme to use? I think it's coming from reading $HOME/.gtk or $HOME/.gtkrc during gtk_init(). I'll try to check that, but it's been a long time since I hacked with gtk1... Thanks, Albrecht. > > Thanks, > Marcus > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From marcus.brinkmann at ruhr-uni-bochum.de Thu Apr 29 22:17:13 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Apr 29 22:13:14 2004 Subject: gpg-agent In-Reply-To: <87d65ttxr6.fsf@vigenere.g10code.de> References: <87k70bwofr.wl@ulysses.g10code.de> <20040420111635.GE24078@wolf.minfo.bug> <87y8oq7qf3.fsf@vigenere.g10code.de> <20040420190706.GA1217@antares.localdomain> <87k7097rgl.fsf@vigenere.g10code.de> <20040426195303.GC26604@antares.localdomain> <20040426201006.GN6240@wolf.minfo.bug> <87isflx0cl.fsf@vigenere.g10code.de> <20040427091246.GA10904@wolf.minfo.bug> <87vfjlvikc.fsf@vigenere.g10code.de> <20040427111926.GA11411@wolf.minfo.bug> <87d65ttxr6.fsf@vigenere.g10code.de> Message-ID: <87u0z2czee.wl@ulysses.g10code.de> At Tue, 27 Apr 2004 14:23:57 +0200, Werner Koch wrote: > > On Tue, 27 Apr 2004 13:19:26 +0200, Sylvain Beucler said: > > > With pinentry-curses, the second time gpg needs my passphrase, I get: > > gpg-agent[11424]: command get_passphrase failed: Operation cancelled > > gpg-agent[11424]: DBG: map_to_assuan_status called with no error source > > That might be a bug in the curses version. > > Marcus, can you please check what's going wrong? The cancel error is likely a failure of pinentry_utf8_to_local, for which we currently don't set pinentry->locale_err. Why a conversion error occurs I don't know. Maybe gpg-agent does not send the strings in UTF-8? > > pinentry-gtk, on the contrary, ask me the passphrase the first time, > > and remember it then. pinentry-gtk does not seem to fail on all conversion errors (but ignore some). Thanks, Marcus From crack77 at libero.it Thu Apr 29 19:48:09 2004 From: crack77 at libero.it (*) Date: Fri Apr 30 06:00:56 2004 Subject: gpg2, gpgsm & pkcs15 compliant file system on smart card Message-ID: On my LINUX box (Debian 3.0r1 "woody" i386) i have: towitoko chipdrive micro USB GPK 16000 blank (not gemsafe) gnupg-1.9.7 libgcrypt-1.1.94 opensc 0.8.1 (snapshot 20040424 on /usr/local) openct 0.5 (deb package) pcscd 1.2.0 Now, all is working (openct and openct and pcsc too, obiousvly): 1)reader, card initializing ,reading, writing X.509 certificate with pkcs15-init (p12 format) 2)gnupg (gpg2 by gpa interface and by prompt with key generation, signing ecc.) - libgcrypt-1.1.94 tests are all passed 3)pkcs15 file system creation on smart card with pkcs15-init 4) mozilla with same certificate (OpenCA fully working but not real authority) and pkcs11 plugin by opensc (token access and use) 5) pam module with opensc (login). When i use: gpg2 --card-status or gpg2 --card-edit or scdaemon --server --debug-sc 3 --allow admin .. < learn --force .. log file result is as reported below. My opinion is gpg2 or gpgsm (scdaemon and gpg-agent correctly work when invoked) don't find openpgp card structure or application files but the README file in gnupg-1.9.7 says "GPGSM, the CMS (S/MIME) part of GnuPG, supports two kinds of smartcards. The most flexible way is to use PKCS#15 compliant cards ......" Have you some opinion ? Thank you for attention Daniele Vetrugno ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- scdaemon log file ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- scdaemon[1864.0x8064738] DBG: -> OK GNU Privacy Guard's Smartcard server ready scdaemon[1864.0x8064738] DBG: <- learn sc.c:120:sc_detect_card_presence: called sc.c:125:sc_detect_card_presence: returning with: 1 card.c:346:sc_connect_card: called card.c:431:sc_connect_card: returning with: 0 2004-04-29 18:57:30 scdaemon[1864] connected to card in opensc reader 0 using driver `EMV compatible cards' 2004-04-29 18:57:30 scdaemon[1864] reader slot 0: active protocol: 2004-04-29 18:57:30 scdaemon[1864] reader 0: ATR=3B A7 00 40 18 80 65 A2 09 01 03 52 2004-04-29 18:57:30 scdaemon[1864] DBG: send apdu: c=00 i=A4 p0=00 p1=0C lc=2 le=-1 2004-04-29 18:57:30 scdaemon[1864] DBG: APDU_data: 00 A4 00 0C 02 3F 00 card.c:229:sc_transmit_apdu: called card.c:468:sc_lock: called card.c:196:sc_transceive: Sending 7 bytes (resp. 260 bytes): 00 A4 00 0C 02 3F 00 .....?. card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=90 SW2=00) card.c:488:sc_unlock: called card.c:493:sc_unlock: Calling card logout function card.c:691:sc_select_file: called; type=2, path=3f00 card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 7 bytes (resp. 2 bytes): 00 A4 00 00 02 3F 00 .....?. card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=61 SW2=12) iso7816.c:440:iso7816_select_file: returning with: 0 card.c:713:sc_select_file: returning with: 0 2004-04-29 18:57:30 scdaemon[1864] DBG: response: sw=9000 datalen=0 2004-04-29 18:57:30 scdaemon[1864] DBG: dump: 2004-04-29 18:57:30 scdaemon[1864] DBG: send apdu: c=00 i=A4 p0=02 p1=0C lc=2 le=-1 2004-04-29 18:57:30 scdaemon[1864] DBG: APDU_data: 00 A4 02 0C 02 2F 02 card.c:229:sc_transmit_apdu: called card.c:468:sc_lock: called card.c:196:sc_transceive: Sending 7 bytes (resp. 260 bytes): 00 A4 02 0C 02 2F 02 ...../. card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=6A SW2=82) card.c:488:sc_unlock: called card.c:493:sc_unlock: Calling card logout function card.c:691:sc_select_file: called; type=2, path=3f00 card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 7 bytes (resp. 2 bytes): 00 A4 00 00 02 3F 00 .....?. card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=61 SW2=12) iso7816.c:440:iso7816_select_file: returning with: 0 card.c:713:sc_select_file: returning with: 0 2004-04-29 18:57:30 scdaemon[1864] DBG: response: sw=6A82 datalen=0 2004-04-29 18:57:30 scdaemon[1864] DBG: send apdu: c=00 i=A4 p0=04 p1=00 lc=6 le=-1 2004-04-29 18:57:30 scdaemon[1864] DBG: APDU_data: 00 A4 04 00 06 D2 76 00 01 24 01 card.c:229:sc_transmit_apdu: called card.c:468:sc_lock: called card.c:196:sc_transceive: Sending 11 bytes (resp. 260 bytes): 00 A4 04 00 06 D2 76 00 01 24 01 ......v..$. card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=6A SW2=82) card.c:488:sc_unlock: called card.c:493:sc_unlock: Calling card logout function card.c:691:sc_select_file: called; type=2, path=3f00 card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 7 bytes (resp. 2 bytes): 00 A4 00 00 02 3F 00 .....?. card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=61 SW2=12) iso7816.c:440:iso7816_select_file: returning with: 0 card.c:713:sc_select_file: returning with: 0 2004-04-29 18:57:30 scdaemon[1864] DBG: response: sw=6A82 datalen=0 2004-04-29 18:57:30 scdaemon[1864] DBG: send apdu: c=00 i=A4 p0=04 p1=0C lc=7 le=-1 2004-04-29 18:57:30 scdaemon[1864] DBG: APDU_data: 00 A4 04 0C 07 D2 76 00 00 03 01 02 card.c:229:sc_transmit_apdu: called card.c:468:sc_lock: called card.c:196:sc_transceive: Sending 12 bytes (resp. 260 bytes): 00 A4 04 0C 07 D2 76 00 00 03 01 02 ......v..... card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=6A SW2=82) card.c:488:sc_unlock: called card.c:493:sc_unlock: Calling card logout function card.c:691:sc_select_file: called; type=2, path=3f00 card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 7 bytes (resp. 2 bytes): 00 A4 00 00 02 3F 00 .....?. card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=61 SW2=12) iso7816.c:440:iso7816_select_file: returning with: 0 card.c:713:sc_select_file: returning with: 0 2004-04-29 18:57:31 scdaemon[1864] DBG: response: sw=6A82 datalen=0 2004-04-29 18:57:31 scdaemon[1864] DBG: send apdu: c=00 i=A4 p0=04 p1=0C lc=6 le=-1 2004-04-29 18:57:31 scdaemon[1864] DBG: APDU_data: 00 A4 04 0C 06 D2 76 00 00 66 01 card.c:229:sc_transmit_apdu: called card.c:468:sc_lock: called card.c:196:sc_transceive: Sending 11 bytes (resp. 260 bytes): 00 A4 04 0C 06 D2 76 00 00 66 01 ......v..f. card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=6A SW2=82) card.c:488:sc_unlock: called card.c:493:sc_unlock: Calling card logout function card.c:691:sc_select_file: called; type=2, path=3f00 card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 7 bytes (resp. 2 bytes): 00 A4 00 00 02 3F 00 .....?. card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=61 SW2=12) iso7816.c:440:iso7816_select_file: returning with: 0 card.c:713:sc_select_file: returning with: 0 2004-04-29 18:57:31 scdaemon[1864] DBG: response: sw=6A82 datalen=0 2004-04-29 18:57:31 scdaemon[1864] no supported card application found: No such file or directory sc.c:120:sc_detect_card_presence: called sc.c:125:sc_detect_card_presence: returning with: 1 card.c:346:sc_connect_card: called card.c:401:sc_connect_card: trying driver: EMV compatible cards card-emv.c:98:emv_match_card: ATR parse: TB1 = 0x00 TD1 = 0x40 TC2 = 0x18 card-emv.c:101:emv_match_card: historic bytes: 80 65 A2 09 01 03 52 .e....R card.c:401:sc_connect_card: trying driver: Siemens CardOS card.c:401:sc_connect_card: trying driver: Schlumberger Multiflex/Cryptoflex card.c:401:sc_connect_card: trying driver: Schlumberger Cyberflex card.c:401:sc_connect_card: trying driver: Gemplus GPK driver card.c:407:sc_connect_card: matched: Gemplus GPK driver card.c:468:sc_lock: called card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 5 bytes (resp. 15 bytes): 80 C0 02 A4 0D ..... card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=6B SW2=00) card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 5 bytes (resp. 15 bytes): 80 C0 02 A4 0D ..... card.c:249:sc_transmit_apdu: Received 13 bytes (SW1=90 SW2=00) A2 09 01 01 52 00 FF 00 10 00 FF 86 86 ....R........ card.c:488:sc_unlock: called card.c:493:sc_unlock: Calling card logout function card.c:691:sc_select_file: called; type=2, path=3f00 card-gpk.c:652:gpk_select_file: called card-gpk.c:613:gpk_select_id: gpk_select_id(0x3F00, kind=0) card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 7 bytes (resp. 2 bytes): 00 A4 00 00 02 3F 00 .....?. card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=61 SW2=12) card.c:713:sc_select_file: returning with: 0 card.c:431:sc_connect_card: returning with: 0 2004-04-29 18:57:32 scdaemon[1864] connected to card in reader 0 using driver `Gemplus GPK driver' card.c:468:sc_lock: called pkcs15.c:437:sc_pkcs15_bind: called pkcs15-syn.c:52:sc_pkcs15_bind_synthetic: called card.c:691:sc_select_file: called; type=2, path=3f002f00 card-gpk.c:652:gpk_select_file: called card-gpk.c:613:gpk_select_id: gpk_select_id(0x2F00, kind=2) card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 8 bytes (resp. 258 bytes): 00 A4 02 00 02 2F 00 00 ...../.. card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=61 SW2=12) card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 5 bytes (resp. 20 bytes): 00 C0 00 00 12 ..... card.c:249:sc_transmit_apdu: Received 18 bytes (SW1=90 SW2=00) 85 10 01 02 2F 00 01 00 00 80 00 00 00 00 00 00 ..../........... 00 6F .o iso7816.c:591:iso7816_get_response: returning with: 18 card.c:713:sc_select_file: returning with: 0 card.c:563:sc_read_binary: called; 128 bytes at index 0 card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 5 bytes (resp. 130 bytes): 00 B0 00 00 80 ..... card.c:249:sc_transmit_apdu: Received 128 bytes (SW1=90 SW2=00) 61 20 4F 0C A0 00 00 00 63 50 4B 43 53 2D 31 35 a O.....cPKCS-15 50 0A 62 65 74 65 6C 67 65 75 73 65 51 04 3F 00 P.betelgeuseQ.?. 50 15 00 00 00 00 00 00 00 00 00 00 00 00 00 00 P............... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ iso7816.c:126:iso7816_read_binary: returning with: 128 card.c:594:sc_read_binary: returning with: 128 asn1.c:1035:asn1_decode: called, left=128, depth 0 asn1.c:1060:asn1_decode: Looking for 'dirRecord', tag 0x11000001 asn1.c:859:asn1_decode_entry: decoding 'dirRecord' asn1.c:1035:asn1_decode: called, left=32, depth 1 asn1.c:1060:asn1_decode: Looking for 'aid', tag 0x1000000f asn1.c:859:asn1_decode_entry: decoding 'aid' asn1.c:1060:asn1_decode: Looking for 'label', tag 0x10000010, OPTIONAL asn1.c:859:asn1_decode_entry: decoding 'label' asn1.c:1060:asn1_decode: Looking for 'path', tag 0x10000011, OPTIONAL asn1.c:859:asn1_decode_entry: decoding 'path' asn1.c:1060:asn1_decode: Looking for 'ddo', tag 0x11000013, OPTIONAL asn1.c:1076:asn1_decode: not present asn1.c:1111:asn1_decode: returning with: 0 asn1.c:1111:asn1_decode: returning with: 0 asn1.c:1035:asn1_decode: called, left=94, depth 0 card.c:691:sc_select_file: called; type=2, path=3f005015 card-gpk.c:652:gpk_select_file: called card-gpk.c:613:gpk_select_id: gpk_select_id(0x5015, kind=2) card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 7 bytes (resp. 2 bytes): 00 A4 02 00 02 50 15 .....P. card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=6A SW2=82) iso7816.c:98:iso7816_check_sw: File not found card-gpk.c:584:gpk_select: Card returned error: File not found card-gpk.c:613:gpk_select_id: gpk_select_id(0x3F00, kind=0) card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 7 bytes (resp. 2 bytes): 00 A4 00 00 02 3F 00 .....?. card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=61 SW2=12) card-gpk.c:613:gpk_select_id: gpk_select_id(0x5015, kind=1) card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 7 bytes (resp. 2 bytes): 00 A4 01 00 02 50 15 .....P. card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=61 SW2=20) card.c:713:sc_select_file: returning with: 0 card.c:691:sc_select_file: called; type=2, path=3f0050155031 card-gpk.c:652:gpk_select_file: called card-gpk.c:613:gpk_select_id: gpk_select_id(0x5031, kind=2) card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 8 bytes (resp. 258 bytes): 00 A4 02 00 02 50 31 00 .....P1. card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=61 SW2=12) card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 5 bytes (resp. 20 bytes): 00 C0 00 00 12 ..... card.c:249:sc_transmit_apdu: Received 18 bytes (SW1=90 SW2=00) 85 10 42 03 50 31 01 00 01 00 00 00 00 00 00 00 ..B.P1.......... 00 6D .m iso7816.c:591:iso7816_get_response: returning with: 18 card.c:713:sc_select_file: returning with: 0 card.c:563:sc_read_binary: called; 256 bytes at index 0 card.c:563:sc_read_binary: called; 248 bytes at index 0 card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 5 bytes (resp. 250 bytes): 00 B0 00 00 F8 ..... card.c:249:sc_transmit_apdu: Received 248 bytes (SW1=90 SW2=00) A8 0A 30 08 04 06 3F 00 50 15 44 01 A0 0A 30 08 ..0...?.P.D...0. 04 06 3F 00 50 15 44 02 A4 0A 30 08 04 06 3F 00 ..?.P.D...0...?. 50 15 44 04 00 00 00 00 00 00 00 00 00 00 00 00 P.D............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 ........ iso7816.c:126:iso7816_read_binary: returning with: 248 card.c:594:sc_read_binary: returning with: 248 card.c:563:sc_read_binary: called; 8 bytes at index 248 card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 5 bytes (resp. 10 bytes): 00 B0 00 3E 08 ...>. card.c:249:sc_transmit_apdu: Received 8 bytes (SW1=90 SW2=00) 00 00 00 00 00 00 00 00 ........ iso7816.c:126:iso7816_read_binary: returning with: 8 card.c:594:sc_read_binary: returning with: 8 card.c:591:sc_read_binary: returning with: 256 asn1.c:1035:asn1_decode: called, left=256, depth 0, choice asn1.c:1060:asn1_decode: Looking for 'privateKeys', tag 0x21000000, CHOICE asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'publicKeys', tag 0x21000001, CHOICE asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'trustedPublicKeys', tag 0x21000002, CHOICE asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'certificates', tag 0x21000004, CHOICE asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'trustedCertificates', tag 0x21000005, CHOICE asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'usefulCertificates', tag 0x21000006, CHOICE asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'dataObjects', tag 0x21000007, CHOICE asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'authObjects', tag 0x21000008, CHOICE asn1.c:859:asn1_decode_entry: decoding 'authObjects' asn1.c:1035:asn1_decode: called, left=10, depth 1 asn1.c:1060:asn1_decode: Looking for 'path', tag 0x1000010 asn1.c:859:asn1_decode_entry: decoding 'path' asn1.c:1035:asn1_decode: called, left=8, depth 2 asn1.c:1060:asn1_decode: Looking for 'path', tag 0x4 asn1.c:859:asn1_decode_entry: decoding 'path' asn1.c:1060:asn1_decode: Looking for 'index', tag 0x2, OPTIONAL asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'length', tag 0x20000000, OPTIONAL asn1.c:1076:asn1_decode: not present asn1.c:1111:asn1_decode: returning with: 0 asn1.c:1111:asn1_decode: returning with: 0 asn1.c:1110:asn1_decode: returning with: 7 asn1.c:1035:asn1_decode: called, left=244, depth 0, choice asn1.c:1060:asn1_decode: Looking for 'privateKeys', tag 0x21000000, CHOICE asn1.c:859:asn1_decode_entry: decoding 'privateKeys' asn1.c:1035:asn1_decode: called, left=10, depth 1 asn1.c:1060:asn1_decode: Looking for 'path', tag 0x1000010 asn1.c:859:asn1_decode_entry: decoding 'path' asn1.c:1035:asn1_decode: called, left=8, depth 2 asn1.c:1060:asn1_decode: Looking for 'path', tag 0x4 asn1.c:859:asn1_decode_entry: decoding 'path' asn1.c:1060:asn1_decode: Looking for 'index', tag 0x2, OPTIONAL asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'length', tag 0x20000000, OPTIONAL asn1.c:1076:asn1_decode: not present asn1.c:1111:asn1_decode: returning with: 0 asn1.c:1111:asn1_decode: returning with: 0 asn1.c:1110:asn1_decode: returning with: 0 asn1.c:1035:asn1_decode: called, left=232, depth 0, choice asn1.c:1060:asn1_decode: Looking for 'privateKeys', tag 0x21000000, CHOICE asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'publicKeys', tag 0x21000001, CHOICE asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'trustedPublicKeys', tag 0x21000002, CHOICE asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'certificates', tag 0x21000004, CHOICE asn1.c:859:asn1_decode_entry: decoding 'certificates' asn1.c:1035:asn1_decode: called, left=10, depth 1 asn1.c:1060:asn1_decode: Looking for 'path', tag 0x1000010 asn1.c:859:asn1_decode_entry: decoding 'path' asn1.c:1035:asn1_decode: called, left=8, depth 2 asn1.c:1060:asn1_decode: Looking for 'path', tag 0x4 asn1.c:859:asn1_decode_entry: decoding 'path' asn1.c:1060:asn1_decode: Looking for 'index', tag 0x2, OPTIONAL asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'length', tag 0x20000000, OPTIONAL asn1.c:1076:asn1_decode: not present asn1.c:1111:asn1_decode: returning with: 0 asn1.c:1111:asn1_decode: returning with: 0 asn1.c:1110:asn1_decode: returning with: 3 asn1.c:1035:asn1_decode: called, left=220, depth 0, choice pkcs15.c:545:sc_pkcs15_bind: The following DFs were found: pkcs15.c:550:sc_pkcs15_bind: DF type 8, path 3f0050154401, index 0, count -1 pkcs15.c:550:sc_pkcs15_bind: DF type 0, path 3f0050154402, index 0, count -1 pkcs15.c:550:sc_pkcs15_bind: DF type 4, path 3f0050154404, index 0, count -1 card.c:691:sc_select_file: called; type=2, path=3f0050155032 card-gpk.c:652:gpk_select_file: called card-gpk.c:613:gpk_select_id: gpk_select_id(0x5032, kind=2) card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 8 bytes (resp. 258 bytes): 00 A4 02 00 02 50 32 00 .....P2. card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=61 SW2=12) card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 5 bytes (resp. 20 bytes): 00 C0 00 00 12 ..... card.c:249:sc_transmit_apdu: Received 18 bytes (SW1=90 SW2=00) 85 10 42 04 50 32 01 00 00 29 00 00 00 00 00 00 ..B.P2...)...... 00 6C .l iso7816.c:591:iso7816_get_response: returning with: 18 card.c:713:sc_select_file: returning with: 0 card.c:563:sc_read_binary: called; 41 bytes at index 0 card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 5 bytes (resp. 43 bytes): 00 B0 00 00 29 ....) card.c:249:sc_transmit_apdu: Received 41 bytes (SW1=90 SW2=00) 30 27 02 01 00 04 02 00 00 0C 0E 4F 70 65 6E 53 0'.........OpenS 43 20 50 72 6F 6A 65 63 74 80 0A 62 65 74 65 6C C Project..betel 67 65 75 73 65 03 02 04 10 geuse.... iso7816.c:126:iso7816_read_binary: returning with: 41 card.c:594:sc_read_binary: returning with: 41 asn1.c:1035:asn1_decode: called, left=41, depth 0 asn1.c:1060:asn1_decode: Looking for 'TokenInfo', tag 0x1000010 asn1.c:859:asn1_decode_entry: decoding 'TokenInfo' asn1.c:1035:asn1_decode: called, left=39, depth 1 asn1.c:1060:asn1_decode: Looking for 'version', tag 0x2 asn1.c:859:asn1_decode_entry: decoding 'version' asn1.c:1060:asn1_decode: Looking for 'serialNumber', tag 0x4 asn1.c:859:asn1_decode_entry: decoding 'serialNumber' asn1.c:1060:asn1_decode: Looking for 'manufacturerID', tag 0xc, OPTIONAL asn1.c:859:asn1_decode_entry: decoding 'manufacturerID' asn1.c:1060:asn1_decode: Looking for 'label', tag 0x20000000, OPTIONAL asn1.c:859:asn1_decode_entry: decoding 'label' asn1.c:1060:asn1_decode: Looking for 'tokenflags', tag 0x3 asn1.c:859:asn1_decode_entry: decoding 'tokenflags' asn1.c:1060:asn1_decode: Looking for 'seInfo', tag 0x1000010, OPTIONAL asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'recordInfo', tag 0x21000001, OPTIONAL asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'supportedAlgorithms', tag 0x21000002, OPTIONAL asn1.c:1076:asn1_decode: not present asn1.c:1111:asn1_decode: returning with: 0 asn1.c:1111:asn1_decode: returning with: 0 card.c:691:sc_select_file: called; type=2, path=3f002f02 card-gpk.c:652:gpk_select_file: called card-gpk.c:613:gpk_select_id: gpk_select_id(0x2F02, kind=2) card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 8 bytes (resp. 258 bytes): 00 A4 02 00 02 2F 02 00 ...../.. card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=6A SW2=82) iso7816.c:98:iso7816_check_sw: File not found card-gpk.c:584:gpk_select: Card returned error: File not found card-gpk.c:613:gpk_select_id: gpk_select_id(0x3F00, kind=0) card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 7 bytes (resp. 2 bytes): 00 A4 00 00 02 3F 00 .....?. card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=61 SW2=12) card-gpk.c:613:gpk_select_id: gpk_select_id(0x2F02, kind=1) card.c:229:sc_transmit_apdu: called card.c:196:sc_transceive: Sending 8 bytes (resp. 258 bytes): 00 A4 01 00 02 2F 02 00 ...../.. card.c:249:sc_transmit_apdu: Received 0 bytes (SW1=6A SW2=82) iso7816.c:98:iso7816_check_sw: File not found card-gpk.c:584:gpk_select: Card returned error: File not found card.c:713:sc_select_file: returning with: File not found 2004-04-29 18:57:33 scdaemon[1864] sc_select_file failed: File not found scdaemon[1864.0x8064738] DBG: -> ERR 100663404 Card error scdaemon[1864.0x8064738] DBG: <- scdaemon[1864.0x8064738] DBG: <- scdaemon[1885.0x8064738] DBG: -> OK GNU Privacy Guard's Smartcard server ready scdaemon[1885.0x8064738] DBG: <- learn sc.c:120:sc_detect_card_presence: called sc.c:125:sc_detect_card_presence: returning with: 1 card.c:346:sc_connect_card: called card.c:431:sc_connect_card: returning with: 0 2004-04-29 19:14:46 scdaemon[1885] connected to card in opensc reader 0 using driver `EMV compatible cards' 2004-04-29 19:14:46 scdaemon[1885] reader slot 0: active protocol: 2004-04-29 19:14:46 scdaemon[1885] reader 0: ATR=3B A7 00 40 18 80 65 A2 09 01 03 52 2004-04-29 19:14:46 scdaemon[1885] DBG: send apdu: c=00 i=A4 p0=00 p1=0C lc=2 le=-1 2004-04-29 19:14:46 scdaemon[1885] DBG: APDU_data: 00 A4 00 0C 02 3F 00 card.c:468:sc_lock: called card.c:488:sc_unlock: called card.c:493:sc_unlock: Calling card logout function card.c:691:sc_select_file: called; type=2, path=3f00 iso7816.c:440:iso7816_select_file: returning with: 0 card.c:713:sc_select_file: returning with: 0 2004-04-29 19:14:46 scdaemon[1885] DBG: response: sw=9000 datalen=0 2004-04-29 19:14:46 scdaemon[1885] DBG: dump: 2004-04-29 19:14:46 scdaemon[1885] DBG: send apdu: c=00 i=A4 p0=02 p1=0C lc=2 le=-1 2004-04-29 19:14:46 scdaemon[1885] DBG: APDU_data: 00 A4 02 0C 02 2F 02 card.c:468:sc_lock: called card.c:488:sc_unlock: called card.c:493:sc_unlock: Calling card logout function card.c:691:sc_select_file: called; type=2, path=3f00 iso7816.c:440:iso7816_select_file: returning with: 0 card.c:713:sc_select_file: returning with: 0 2004-04-29 19:14:47 scdaemon[1885] DBG: response: sw=6A82 datalen=0 2004-04-29 19:14:47 scdaemon[1885] DBG: send apdu: c=00 i=A4 p0=04 p1=00 lc=6 le=-1 2004-04-29 19:14:47 scdaemon[1885] DBG: APDU_data: 00 A4 04 00 06 D2 76 00 01 24 01 card.c:468:sc_lock: called card.c:488:sc_unlock: called card.c:493:sc_unlock: Calling card logout function card.c:691:sc_select_file: called; type=2, path=3f00 iso7816.c:440:iso7816_select_file: returning with: 0 card.c:713:sc_select_file: returning with: 0 2004-04-29 19:14:47 scdaemon[1885] DBG: response: sw=6A82 datalen=0 2004-04-29 19:14:47 scdaemon[1885] DBG: send apdu: c=00 i=A4 p0=04 p1=0C lc=7 le=-1 2004-04-29 19:14:47 scdaemon[1885] DBG: APDU_data: 00 A4 04 0C 07 D2 76 00 00 03 01 02 card.c:468:sc_lock: called card.c:488:sc_unlock: called card.c:493:sc_unlock: Calling card logout function card.c:691:sc_select_file: called; type=2, path=3f00 iso7816.c:440:iso7816_select_file: returning with: 0 card.c:713:sc_select_file: returning with: 0 2004-04-29 19:14:47 scdaemon[1885] DBG: response: sw=6A82 datalen=0 2004-04-29 19:14:47 scdaemon[1885] DBG: send apdu: c=00 i=A4 p0=04 p1=0C lc=6 le=-1 2004-04-29 19:14:47 scdaemon[1885] DBG: APDU_data: 00 A4 04 0C 06 D2 76 00 00 66 01 card.c:468:sc_lock: called card.c:488:sc_unlock: called card.c:493:sc_unlock: Calling card logout function card.c:691:sc_select_file: called; type=2, path=3f00 iso7816.c:440:iso7816_select_file: returning with: 0 card.c:713:sc_select_file: returning with: 0 2004-04-29 19:14:47 scdaemon[1885] DBG: response: sw=6A82 datalen=0 2004-04-29 19:14:47 scdaemon[1885] no supported card application found: No such file or directory sc.c:120:sc_detect_card_presence: called sc.c:125:sc_detect_card_presence: returning with: 1 card.c:346:sc_connect_card: called card.c:401:sc_connect_card: trying driver: EMV compatible cards card.c:401:sc_connect_card: trying driver: Siemens CardOS card.c:401:sc_connect_card: trying driver: Schlumberger Multiflex/Cryptoflex card.c:401:sc_connect_card: trying driver: Schlumberger Cyberflex card.c:401:sc_connect_card: trying driver: Gemplus GPK driver card.c:407:sc_connect_card: matched: Gemplus GPK driver card.c:468:sc_lock: called card.c:488:sc_unlock: called card.c:493:sc_unlock: Calling card logout function card.c:691:sc_select_file: called; type=2, path=3f00 card-gpk.c:652:gpk_select_file: called card-gpk.c:613:gpk_select_id: gpk_select_id(0x3F00, kind=0) card.c:713:sc_select_file: returning with: 0 card.c:431:sc_connect_card: returning with: 0 2004-04-29 19:14:48 scdaemon[1885] connected to card in reader 0 using driver `Gemplus GPK driver' card.c:468:sc_lock: called pkcs15.c:437:sc_pkcs15_bind: called pkcs15-syn.c:52:sc_pkcs15_bind_synthetic: called card.c:691:sc_select_file: called; type=2, path=3f002f00 card-gpk.c:652:gpk_select_file: called card-gpk.c:613:gpk_select_id: gpk_select_id(0x2F00, kind=2) iso7816.c:591:iso7816_get_response: returning with: 18 card.c:713:sc_select_file: returning with: 0 card.c:563:sc_read_binary: called; 128 bytes at index 0 iso7816.c:126:iso7816_read_binary: returning with: 128 card.c:594:sc_read_binary: returning with: 128 asn1.c:1035:asn1_decode: called, left=128, depth 0 asn1.c:1060:asn1_decode: Looking for 'dirRecord', tag 0x11000001 asn1.c:859:asn1_decode_entry: decoding 'dirRecord' asn1.c:1035:asn1_decode: called, left=32, depth 1 asn1.c:1060:asn1_decode: Looking for 'aid', tag 0x1000000f asn1.c:859:asn1_decode_entry: decoding 'aid' asn1.c:1060:asn1_decode: Looking for 'label', tag 0x10000010, OPTIONAL asn1.c:859:asn1_decode_entry: decoding 'label' asn1.c:1060:asn1_decode: Looking for 'path', tag 0x10000011, OPTIONAL asn1.c:859:asn1_decode_entry: decoding 'path' asn1.c:1060:asn1_decode: Looking for 'ddo', tag 0x11000013, OPTIONAL asn1.c:1076:asn1_decode: not present asn1.c:1111:asn1_decode: returning with: 0 asn1.c:1111:asn1_decode: returning with: 0 asn1.c:1035:asn1_decode: called, left=94, depth 0 card.c:691:sc_select_file: called; type=2, path=3f005015 card-gpk.c:652:gpk_select_file: called card-gpk.c:613:gpk_select_id: gpk_select_id(0x5015, kind=2) iso7816.c:98:iso7816_check_sw: File not found card-gpk.c:584:gpk_select: Card returned error: File not found card-gpk.c:613:gpk_select_id: gpk_select_id(0x3F00, kind=0) card-gpk.c:613:gpk_select_id: gpk_select_id(0x5015, kind=1) card.c:713:sc_select_file: returning with: 0 card.c:691:sc_select_file: called; type=2, path=3f0050155031 card-gpk.c:652:gpk_select_file: called card-gpk.c:613:gpk_select_id: gpk_select_id(0x5031, kind=2) iso7816.c:591:iso7816_get_response: returning with: 18 card.c:713:sc_select_file: returning with: 0 card.c:563:sc_read_binary: called; 256 bytes at index 0 card.c:563:sc_read_binary: called; 248 bytes at index 0 iso7816.c:126:iso7816_read_binary: returning with: 248 card.c:594:sc_read_binary: returning with: 248 card.c:563:sc_read_binary: called; 8 bytes at index 248 iso7816.c:126:iso7816_read_binary: returning with: 8 card.c:594:sc_read_binary: returning with: 8 card.c:591:sc_read_binary: returning with: 256 asn1.c:1035:asn1_decode: called, left=256, depth 0, choice asn1.c:1060:asn1_decode: Looking for 'privateKeys', tag 0x21000000, CHOICE asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'publicKeys', tag 0x21000001, CHOICE asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'trustedPublicKeys', tag 0x21000002, CHOICE asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'certificates', tag 0x21000004, CHOICE asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'trustedCertificates', tag 0x21000005, CHOICE asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'usefulCertificates', tag 0x21000006, CHOICE asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'dataObjects', tag 0x21000007, CHOICE asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'authObjects', tag 0x21000008, CHOICE asn1.c:859:asn1_decode_entry: decoding 'authObjects' asn1.c:1035:asn1_decode: called, left=10, depth 1 asn1.c:1060:asn1_decode: Looking for 'path', tag 0x1000010 asn1.c:859:asn1_decode_entry: decoding 'path' asn1.c:1035:asn1_decode: called, left=8, depth 2 asn1.c:1060:asn1_decode: Looking for 'path', tag 0x4 asn1.c:859:asn1_decode_entry: decoding 'path' asn1.c:1060:asn1_decode: Looking for 'index', tag 0x2, OPTIONAL asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'length', tag 0x20000000, OPTIONAL asn1.c:1076:asn1_decode: not present asn1.c:1111:asn1_decode: returning with: 0 asn1.c:1111:asn1_decode: returning with: 0 asn1.c:1110:asn1_decode: returning with: 7 asn1.c:1035:asn1_decode: called, left=244, depth 0, choice asn1.c:1060:asn1_decode: Looking for 'privateKeys', tag 0x21000000, CHOICE asn1.c:859:asn1_decode_entry: decoding 'privateKeys' asn1.c:1035:asn1_decode: called, left=10, depth 1 asn1.c:1060:asn1_decode: Looking for 'path', tag 0x1000010 asn1.c:859:asn1_decode_entry: decoding 'path' asn1.c:1035:asn1_decode: called, left=8, depth 2 asn1.c:1060:asn1_decode: Looking for 'path', tag 0x4 asn1.c:859:asn1_decode_entry: decoding 'path' asn1.c:1060:asn1_decode: Looking for 'index', tag 0x2, OPTIONAL asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'length', tag 0x20000000, OPTIONAL asn1.c:1076:asn1_decode: not present asn1.c:1111:asn1_decode: returning with: 0 asn1.c:1111:asn1_decode: returning with: 0 asn1.c:1110:asn1_decode: returning with: 0 asn1.c:1035:asn1_decode: called, left=232, depth 0, choice asn1.c:1060:asn1_decode: Looking for 'privateKeys', tag 0x21000000, CHOICE asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'publicKeys', tag 0x21000001, CHOICE asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'trustedPublicKeys', tag 0x21000002, CHOICE asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'certificates', tag 0x21000004, CHOICE asn1.c:859:asn1_decode_entry: decoding 'certificates' asn1.c:1035:asn1_decode: called, left=10, depth 1 asn1.c:1060:asn1_decode: Looking for 'path', tag 0x1000010 asn1.c:859:asn1_decode_entry: decoding 'path' asn1.c:1035:asn1_decode: called, left=8, depth 2 asn1.c:1060:asn1_decode: Looking for 'path', tag 0x4 asn1.c:859:asn1_decode_entry: decoding 'path' asn1.c:1060:asn1_decode: Looking for 'index', tag 0x2, OPTIONAL asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'length', tag 0x20000000, OPTIONAL asn1.c:1076:asn1_decode: not present asn1.c:1111:asn1_decode: returning with: 0 asn1.c:1111:asn1_decode: returning with: 0 asn1.c:1110:asn1_decode: returning with: 3 asn1.c:1035:asn1_decode: called, left=220, depth 0, choice pkcs15.c:545:sc_pkcs15_bind: The following DFs were found: pkcs15.c:550:sc_pkcs15_bind: DF type 8, path 3f0050154401, index 0, count -1 pkcs15.c:550:sc_pkcs15_bind: DF type 0, path 3f0050154402, index 0, count -1 pkcs15.c:550:sc_pkcs15_bind: DF type 4, path 3f0050154404, index 0, count -1 card.c:691:sc_select_file: called; type=2, path=3f0050155032 card-gpk.c:652:gpk_select_file: called card-gpk.c:613:gpk_select_id: gpk_select_id(0x5032, kind=2) iso7816.c:591:iso7816_get_response: returning with: 18 card.c:713:sc_select_file: returning with: 0 card.c:563:sc_read_binary: called; 41 bytes at index 0 iso7816.c:126:iso7816_read_binary: returning with: 41 card.c:594:sc_read_binary: returning with: 41 asn1.c:1035:asn1_decode: called, left=41, depth 0 asn1.c:1060:asn1_decode: Looking for 'TokenInfo', tag 0x1000010 asn1.c:859:asn1_decode_entry: decoding 'TokenInfo' asn1.c:1035:asn1_decode: called, left=39, depth 1 asn1.c:1060:asn1_decode: Looking for 'version', tag 0x2 asn1.c:859:asn1_decode_entry: decoding 'version' asn1.c:1060:asn1_decode: Looking for 'serialNumber', tag 0x4 asn1.c:859:asn1_decode_entry: decoding 'serialNumber' asn1.c:1060:asn1_decode: Looking for 'manufacturerID', tag 0xc, OPTIONAL asn1.c:859:asn1_decode_entry: decoding 'manufacturerID' asn1.c:1060:asn1_decode: Looking for 'label', tag 0x20000000, OPTIONAL asn1.c:859:asn1_decode_entry: decoding 'label' asn1.c:1060:asn1_decode: Looking for 'tokenflags', tag 0x3 asn1.c:859:asn1_decode_entry: decoding 'tokenflags' asn1.c:1060:asn1_decode: Looking for 'seInfo', tag 0x1000010, OPTIONAL asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'recordInfo', tag 0x21000001, OPTIONAL asn1.c:1076:asn1_decode: not present asn1.c:1060:asn1_decode: Looking for 'supportedAlgorithms', tag 0x21000002, OPTIONAL asn1.c:1076:asn1_decode: not present asn1.c:1111:asn1_decode: returning with: 0 asn1.c:1111:asn1_decode: returning with: 0 card.c:691:sc_select_file: called; type=2, path=3f002f02 card-gpk.c:652:gpk_select_file: called card-gpk.c:613:gpk_select_id: gpk_select_id(0x2F02, kind=2) iso7816.c:98:iso7816_check_sw: File not found card-gpk.c:584:gpk_select: Card returned error: File not found card-gpk.c:613:gpk_select_id: gpk_select_id(0x3F00, kind=0) card-gpk.c:613:gpk_select_id: gpk_select_id(0x2F02, kind=1) iso7816.c:98:iso7816_check_sw: File not found card-gpk.c:584:gpk_select: Card returned error: File not found card.c:713:sc_select_file: returning with: File not found 2004-04-29 19:14:49 scdaemon[1885] sc_select_file failed: File not found scdaemon[1885.0x8064738] DBG: -> ERR 100663404 Card error From wk at gnupg.org Fri Apr 30 07:04:33 2004 From: wk at gnupg.org (Werner Koch) Date: Fri Apr 30 06:45:41 2004 Subject: gpg2, gpgsm & pkcs15 compliant file system on smart card In-Reply-To: (crack77@libero.it's message of "Thu, 29 Apr 2004 19:48:09 +0200") References: Message-ID: <87fzamawf2.fsf@vigenere.g10code.de> On Thu, 29 Apr 2004 19:48:09 +0200, * said: > gpg2 --card-status or > gpg2 --card-edit or gpg does not work with pkcs#15. gpg does only support the OpenPGP card and for that OpenSC is only used as a driver for APDU I/O. I have not tested using OpenSC as a driver very much, so if you run into problems, please use the native PC/SC support (put "disable-opensc" into ~/.gnupg/scdaemon.conf). There might be problems using OpenSC with the latest 1.9.8 release too (pthread vs. Pth usage). > "GPGSM, the CMS (S/MIME) part of GnuPG, supports two kinds of smartcards. > The most flexible way is to use PKCS#15 compliant cards ......" This is gpgsm (CMS) but you tried to use gpg (OpenPGP). Shalom-Salam, Werner From Holger.Sesterhenn at smgwtest.aachen.utimaco.de Fri Apr 30 16:12:00 2004 From: Holger.Sesterhenn at smgwtest.aachen.utimaco.de (Holger Sesterhenn) Date: Fri Apr 30 16:09:44 2004 Subject: Small bug in doc/DETAILS Message-ID: <40925EB0.3060905@smgwtest.aachen.utimaco.de> Hi, just a comment to 'IMPORT_RES' in doc/DETAILS. According to the latest version from cvs ( 1.59.2.10:1.2.5rc1, 1.79:HEAD) IMPORT_RES has 13 values. This is not true for at least 1.2.3 .. 1.2.5rc1, 1.3.5 .. HEAD. There is another value 'skipped_new_keys' in import.c:import_print_stats() (cvs 1.68.2.19:1.2.5rc1, 1.111:HEAD) just before . -- Best Regards, Holger Sesterhenn --- Internet http://www.utimaco.com From wk at gnupg.org Fri Apr 30 18:51:10 2004 From: wk at gnupg.org (Werner Koch) Date: Fri Apr 30 18:35:38 2004 Subject: Small bug in doc/DETAILS In-Reply-To: <40925EB0.3060905@smgwtest.aachen.utimaco.de> (Holger Sesterhenn's message of "Fri, 30 Apr 2004 16:12:00 +0200") References: <40925EB0.3060905@smgwtest.aachen.utimaco.de> Message-ID: <87hdv19zpd.fsf@vigenere.g10code.de> On Fri, 30 Apr 2004 16:12:00 +0200, Holger Sesterhenn said: > This is not true for at least 1.2.3 .. 1.2.5rc1, 1.3.5 .. HEAD. There is > another value 'skipped_new_keys' in import.c:import_print_stats() > (cvs 1.68.2.19:1.2.5rc1, 1.111:HEAD) just before . Funny. I also noticed this a couple of hours ago when adding stats for gpgsm's pkcs#12 import. Thanks, Werner