From wk at gnupg.org Fri Oct 2 13:39:14 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Oct 2009 13:39:14 +0200 Subject: [svn] GnuPG - r5171 - trunk/g10 In-Reply-To: (svn author wk's message of "Fri, 02 Oct 2009 14:31:15 +0200") References: Message-ID: <878wfu3tzx.fsf@vigenere.g10code.de> On Fri, 2 Oct 2009 14:31, cvs at cvs.gnupg.org said: > New Revision: 5171 > > Modified: > trunk/g10/ChangeLog > trunk/g10/encr-data.c > trunk/g10/parse-packet.c > Log: > Fixed EOF detection for encrypted packets. > The code won't get confused anymore by extra packages following the > encrypted one. A quick check in the BTS didn't showed a related report but I have in mind that this problem has been reported in the past. Thus we might want to backport it to 2.0 and possible to 1.4. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From mailinglisten at hauke-laging.de Mon Oct 5 04:08:59 2009 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 5 Oct 2009 04:08:59 +0200 Subject: email hashes in PGP keys as protection against spam Message-ID: <200910050409.00014.mailinglisten@hauke-laging.de> Hello, I would like to propose a small change to gpg (which I cannot do myself as I am not a programmer) which should solve the spammers harvest key servers problem. The description is on my web site: http://www.hauke-laging.de/ideen/gpg-hash/index.en.html Google told me that several people are aware of the problem but that it's importance is assessed differently. One mentioned the idea I had, too, but thought it was not possible with openpgp. So I hope that my suggestion is new (I haven't found anything about that in the mailing list archive). I hope that somebody with the necessary capabilities finds this interesting and easy enough to give it a try. :-) Of course, I am interested in comments in order to improve the concept if necessary. Hauke From dkg at fifthhorseman.net Mon Oct 5 06:28:31 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 05 Oct 2009 00:28:31 -0400 Subject: email hashes in PGP keys as protection against spam In-Reply-To: <200910050409.00014.mailinglisten@hauke-laging.de> References: <200910050409.00014.mailinglisten@hauke-laging.de> Message-ID: <4AC975EF.8050808@fifthhorseman.net> Hi Hauke-- Interesting proposal (about digesting User IDs), but i suspect that the ietf's openpgp working group is a better place to discuss this kind of change than the tool-specific gpg-devel list. For that reason, i'm sending my reply there, and i've set Reply-To there as well. i hope that's OK with you. On 10/04/2009 10:08 PM, Hauke Laging wrote: > The description is on my web site: > http://www.hauke-laging.de/ideen/gpg-hash/index.en.html [...] > Of course, I am interested in comments in order to improve the concept if > necessary. (full message here: http://lists.gnupg.org/pipermail/gnupg-devel/2009-October/025378.html ) some questions your proposal raises for me: 0) you only talk about digesting the e-mail part of the address. what about the human-specific name? Would this need to be digested also? Why or Why not? 1) your proposal lacks a concrete example case; What would the User ID for 'Jane Doe ' look like under this policy? The devil is often in the details, and an explicit example would help sort out the details. 2) Would the act of keysigning need to change under your proposal? If so, what would keysigners need to do differently than they currently do? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Mon Oct 5 19:47:35 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 05 Oct 2009 13:47:35 -0400 Subject: email hashes in PGP keys as protection against spam In-Reply-To: <4AC975EF.8050808@fifthhorseman.net> References: <200910050409.00014.mailinglisten@hauke-laging.de> <4AC975EF.8050808@fifthhorseman.net> Message-ID: <4ACA3137.6070502@sixdemonbag.org> I have removed the IETF list from the follow-up. I don't think this proposal is ripe for consideration by the specification community. >> The description is on my web site: >> http://www.hauke-laging.de/ideen/gpg-hash/index.en.html Proposals like this come up a lot. I have yet to see one which I think really understands the problem. Spam depends on: 1. High volume. If the spammer can't spam millions upon millions of emails, the spammer loses. 2. Permissive SMTP. The SMTP protocol has nothing in it to constrain spammers. 3. Financial instruments. Spammers have to get paid somehow. 4. Email lists. The spammer has to have some way to target people. 5. Permissive law enforcement. Spammers thrive on the lax enforcement of anti-fraud and anti-spam laws. 6. User interaction. The user has to see the spam. What we can handle via technical means are #s 1, 2 and 6 (graylisting, SMTP security, and Bayesian spam filtering). Those three work pretty well. Graylisting alone reduced my spam by 99%; between that and a good Bayesian filter, I can go for a week or more without seeing one. Targeting #s 3 and 5 requires significant government intervention. We can't do that by ourselves; we have to get law enforcement to participate, too. In today's climate, that's just not happening. Targeting #4 is a lost cause. Taking away one resource is pointless, given how many resources the spammers have. Even if you remove all of them, the spammers can still use statistical models of email addresses to get messages out without impairment. From mailinglisten at hauke-laging.de Mon Oct 5 20:27:01 2009 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 5 Oct 2009 20:27:01 +0200 Subject: email hashes in PGP keys as protection against spam In-Reply-To: <4ACA3137.6070502@sixdemonbag.org> References: <200910050409.00014.mailinglisten@hauke-laging.de> <4AC975EF.8050808@fifthhorseman.net> <4ACA3137.6070502@sixdemonbag.org> Message-ID: <200910052027.01509.mailinglisten@hauke-laging.de> Am Montag 05 Oktober 2009 schrieb Robert J. Hansen: > Proposals like this come up a lot. I have yet to see one which I think > really understands the problem. It seems we have to make clear what the problem is we are talking about. I think for you the problem is "fighting spam in general". That is a noble aim but has nothing to do with my proposal. My aim is to let people publish their keys without being afraid that *this* action leads to (more) spam. Have you considered that some people are not willing to use spam filters for certain addresses? My aim is not to get rid of spammers by blocking their main source of new email addresses. Obviously that would not be key servers. It is not the task of gpg development to solve the spam problem. But IMHO it is one of its task to avoid unnecessary spam problems which arise directly from the use of the software. A second reason to do this is privacy. There is no reason to allow easy queries the email addresses somebody or an organization uses. Hauke From rjh at sixdemonbag.org Mon Oct 5 21:14:42 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 05 Oct 2009 15:14:42 -0400 Subject: email hashes in PGP keys as protection against spam In-Reply-To: <200910052027.01509.mailinglisten@hauke-laging.de> References: <200910050409.00014.mailinglisten@hauke-laging.de> <4AC975EF.8050808@fifthhorseman.net> <4ACA3137.6070502@sixdemonbag.org> <200910052027.01509.mailinglisten@hauke-laging.de> Message-ID: <4ACA45A2.6020702@sixdemonbag.org> Hauke Laging wrote: > My aim is to let people publish their keys without being afraid that *this* > action leads to (more) spam. Have you considered that some people are not > willing to use spam filters for certain addresses? Sure, but this just goes to show you that people are awful at estimating risks. Take flying as an example: driving to the airport is the most dangerous part of the trip, but people are more afraid of the plane crashing than them getting into a fatal car accident. Likewise, anyone who keeps their keys off the keyservers because they're afraid of getting spam is fantastically missing the point. If this is really your aim, then I think this proposal needs to get shot down. The protocol can either address real concerns or else it can make people feel better about things without actually doing anything at all. The former is engineering; the latter is snake-oil. > A second reason to do this is privacy. There is no reason to allow easy > queries the email addresses somebody or an organization uses. So run a private keyserver. Bang, problem solved. From John at Mozilla-Enigmail.org Mon Oct 5 22:31:07 2009 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Mon, 05 Oct 2009 15:31:07 -0500 Subject: email hashes in PGP keys as protection against spam In-Reply-To: <4ACA45A2.6020702@sixdemonbag.org> References: <200910050409.00014.mailinglisten@hauke-laging.de> <4AC975EF.8050808@fifthhorseman.net> <4ACA3137.6070502@sixdemonbag.org> <200910052027.01509.mailinglisten@hauke-laging.de> <4ACA45A2.6020702@sixdemonbag.org> Message-ID: <4ACA578B.2060802@Mozilla-Enigmail.org> Robert J. Hansen wrote: > Hauke Laging wrote: >> My aim is to let people publish their keys without being afraid that *this* >> action leads to (more) spam. Have you considered that some people are not >> willing to use spam filters for certain addresses? > > Sure, but this just goes to show you that people are awful at estimating > risks. Take flying as an example: driving to the airport is the most > dangerous part of the trip, but people are more afraid of the plane > crashing than them getting into a fatal car accident. Likewise, anyone > who keeps their keys off the keyservers because they're afraid of > getting spam is fantastically missing the point. They are also not so good at estimating the incidence of "Keyserver SPAM". Yes, it happens. But when I tried to measure it, it was of a level statistically indistinguishable from random noise. > If this is really your aim, then I think this proposal needs to get shot > down. The protocol can either address real concerns or else it can make > people feel better about things without actually doing anything at all. > The former is engineering; the latter is snake-oil. I see this proposal breaking a lot of applications to "solve" a minute level of SPAM. It's a security blanket that really doesn't address the problem, only a perceived cause. >> A second reason to do this is privacy. There is no reason to allow easy >> queries the email addresses somebody or an organization uses. > > So run a private keyserver. Bang, problem solved. LDAP servers make a great keyserver for this sort of application -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 679 bytes Desc: OpenPGP digital signature URL: From mailinglisten at hauke-laging.de Mon Oct 5 23:02:39 2009 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 5 Oct 2009 23:02:39 +0200 Subject: email hashes in PGP keys as protection against spam In-Reply-To: <4ACA45A2.6020702@sixdemonbag.org> References: <200910050409.00014.mailinglisten@hauke-laging.de> <200910052027.01509.mailinglisten@hauke-laging.de> <4ACA45A2.6020702@sixdemonbag.org> Message-ID: <200910052302.40020.mailinglisten@hauke-laging.de> Am Montag 05 Oktober 2009 schrieb Robert J. Hansen: > Sure, but this just goes to show you that people are awful at estimating > risks. Maybe. But I would not call it science that you imply that harvesting from key servers will result in about the same amount of spam as pure address guessing by the spammers would. > Likewise, anyone > who keeps their keys off the keyservers because they're afraid of > getting spam is fantastically missing the point. Your point maybe. It seems a bit strange to me that you believe to be capable of calculating everyone's personal spam risk. > If this is really your aim, then I think this proposal needs to get shot > down. Because you want to decide for others what risks they have to take and which not. You may make fun of afraid flight passengers but nonetheless such assessments should be up to the user. > The protocol can either address real concerns or else it can make > people feel better about things without actually doing anything at all. > The former is engineering; the latter is snake-oil. There is a clear technical effect and an unclear estimation how completely different problems might create the problem which shall be guarded against this way. Snake-oil refers to fooling somebody. I don't do that. I do not claim that an email address is spam safe just because the key server problem is solved. > > A second reason to do this is privacy. There is no reason to allow > > easy queries the email addresses somebody or an organization uses. > > So run a private keyserver. Bang, problem solved. You are funny. You are promoting to avoid key servers thus not being reachable any more for most users as the superior solution to hiding the critical data in hash values? "people are awful at estimating"? Sometimes. Hauke From mailinglisten at hauke-laging.de Mon Oct 5 23:16:54 2009 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 5 Oct 2009 23:16:54 +0200 Subject: email hashes in PGP keys as protection against spam In-Reply-To: <4ACA578B.2060802@Mozilla-Enigmail.org> References: <200910050409.00014.mailinglisten@hauke-laging.de> <4ACA45A2.6020702@sixdemonbag.org> <4ACA578B.2060802@Mozilla-Enigmail.org> Message-ID: <200910052316.54688.mailinglisten@hauke-laging.de> Am Montag 05 Oktober 2009 schrieb John Clizbe: > They are also not so good at estimating the incidence of "Keyserver > SPAM". Yes, it happens. But when I tried to measure it, it was of a > level statistically indistinguishable from random noise. And some are not good at reading. My description states twice that this is not a problem today but could easily become one in the future if (what I think we all hope) more and more people use PGP. It will take several years until we reach this point. So we have enough time to make the technical preparations. > I see this proposal breaking a lot of applications Some examples (for breaking applications which get their keys from key servers)? Even if this is the situation today probably no problem would arise as there is enough time to introduce such a feature quite slowly. > It's a security blanket that really doesn't address the > problem, only a perceived cause. It addresses the obvious future problem, not the irrelevant problem of today. How shall I understand "security blanket"? Anyway: If enough people "percieve" such a problem, do you think your "it will never be a problem because it is none today" theory is a good enough argument against that? > LDAP servers make a great keyserver for this sort of application Not being reachable is not the application I was talking about. Hauke From rjh at sixdemonbag.org Mon Oct 5 23:33:38 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 05 Oct 2009 17:33:38 -0400 Subject: email hashes in PGP keys as protection against spam In-Reply-To: <200910052302.40020.mailinglisten@hauke-laging.de> References: <200910050409.00014.mailinglisten@hauke-laging.de> <200910052027.01509.mailinglisten@hauke-laging.de> <4ACA45A2.6020702@sixdemonbag.org> <200910052302.40020.mailinglisten@hauke-laging.de> Message-ID: <4ACA6632.3000405@sixdemonbag.org> Hauke Laging wrote: > Maybe. But I would not call it science that you imply that harvesting > from key servers will result in about the same amount of spam as pure > address guessing by the spammers would. Estimating how many email addresses are released to spammers via the keyservers is a black art. It has been attempted, though. See, e.g., John Clizbe's result. For your proposal to work, you can never have an email address exposed. Ever. Anywhere. The instant you screw up and your email address gets out, the game is over. Soon a spammer will discover it. Within days all the spammers will have it, since spammers share email lists with each other. In the end, you haven't done anything to stop spam. All you've done is bought yourself a little time, and paid a very high price for it -- you've made it very difficult for people who want to talk to you to get in touch with you. > Your point maybe. It seems a bit strange to me that you believe to be > capable of calculating everyone's personal spam risk. Objective reality is the same for everybody. The objective reality of the situation is that as soon as your email address gets exposed anywhere, spammers will get it. Closing off just one avenue of address collection is absurd; it's like facing a horde of army ants and thinking that just by stomping on one you're going to do something about the swarm. > Because you want to decide for others what risks they have to take > and which not. You may make fun of afraid flight passengers but > nonetheless such assessments should be up to the user. It already _is_ up to the user. Nobody forces you to put an email address on your key. You can leave it off if you want. If you're really that concerned about keyserver spam, then feel free. Be my guest. The protocol accommodates you. But I think it's a very bad idea to start changing the protocol just to appease the phantom fears of a small number of users. Once you do that, then everyone who has a phantom fear will demand the protocol be changed to support them. > Snake-oil refers to fooling somebody. I don't do that. You may be fooling yourself. I have cc'd GnuPG-Users on this one. There doesn't appear to be anything in this thread that's related to ongoing GnuPG development, so continuing it on -devel seems inappropriate. Let's move it over there. From petersonmaxx at googlemail.com Mon Oct 5 23:49:40 2009 From: petersonmaxx at googlemail.com (Max) Date: Mon, 5 Oct 2009 23:49:40 +0200 Subject: email hashes in PGP keys as protection against spam In-Reply-To: <200910050409.00014.mailinglisten@hauke-laging.de> References: <200910050409.00014.mailinglisten@hauke-laging.de> Message-ID: you can use http://retroshare.sf.net as it is a web of trust, you can add friends without a key server, but only, if friends of friends know them. but if you do not add them, you cannot get mail or spam. RetroShare Email is spam-free. Max On Mon, Oct 5, 2009 at 4:08 AM, Hauke Laging wrote: > Hello, > > I would like to propose a small change to gpg (which I cannot do myself as > I am not a programmer) which should solve the spammers harvest key servers > problem. > > The description is on my web site: > http://www.hauke-laging.de/ideen/gpg-hash/index.en.html > > Google told me that several people are aware of the problem but that it's > importance is assessed differently. One mentioned the idea I had, too, but > thought it was not possible with openpgp. So I hope that my suggestion is > new (I haven't found anything about that in the mailing list archive). > > I hope that somebody with the necessary capabilities finds this interesting > and easy enough to give it a try. :-) > > Of course, I am interested in comments in order to improve the concept if > necessary. > > > Hauke > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmoore3rd at bellsouth.net Tue Oct 6 00:45:33 2009 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Mon, 05 Oct 2009 18:45:33 -0400 Subject: email hashes in PGP keys as protection against spam In-Reply-To: <200910052316.54688.mailinglisten@hauke-laging.de> References: <200910050409.00014.mailinglisten@hauke-laging.de> <4ACA45A2.6020702@sixdemonbag.org> <4ACA578B.2060802@Mozilla-Enigmail.org> <200910052316.54688.mailinglisten@hauke-laging.de> Message-ID: <4ACA770D.50905@bellsouth.net> Hauke Laging wrote: >> LDAP servers make a great keyserver for this sort of application > > Not being reachable is not the application I was talking about. The PGP Global Directory is both an LDAP Keyserver _and_ Reachable. :-\ JOHN ;) Timestamp: Monday 05 Oct 2009, 18:45 --400 (Eastern Daylight Time) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 653 bytes Desc: OpenPGP digital signature URL: From mat69 at gmx.net Sat Oct 10 15:19:14 2009 From: mat69 at gmx.net (Matthias Fuchs) Date: Sat, 10 Oct 2009 15:19:14 +0200 Subject: GPGME -- Context Message-ID: <200910101519.14760.mat69@gmx.net> Hi, I hope this is the correct place to describe my problem. I have GPGME 1.2.0, GnuPG 1.4.10 and GnuPG 2.0.13 installed on my 64 bit Arch- Linux system. Now creating gpgme_ctx_t does not work for me anymore (it did work on another 64 bit distribution with older versions though) gpgme_ctx_t ctx = 0; gpgme_error_t errCtx = gpgme_new (&ctx); std::cout << errCtx << std::endl; //always prints 536871088 Can anybody help me on this issue? Cheers! matthias From daniel at danm.de Sat Oct 10 20:36:24 2009 From: daniel at danm.de (Daniel Mueller) Date: Sat, 10 Oct 2009 20:36:24 +0200 Subject: GPGME -- Context In-Reply-To: <200910101519.14760.mat69@gmx.net> References: <200910101519.14760.mat69@gmx.net> Message-ID: <20091010203624.56100f18@torax.danm.home> Hi Matthias, On Sat, 10 Oct 2009 15:19:14 +0200 Matthias Fuchs wrote: > I have GPGME 1.2.0 [..] > [..] > gpgme_ctx_t ctx = 0; > gpgme_error_t errCtx = gpgme_new (&ctx); > std::cout << errCtx << std::endl; //always prints 536871088 Did you call gpgme_check_version(const char *REQUIRED_VERSION) before creating the context? Please see gpgme's developer info page section 2.6 "Library Version Check" for more information. bye, Daniel -- Daniel Mueller http://www.danm.de Berlin, Germany OpenPGP: F9F982C1 From mat69 at gmx.net Sun Oct 11 14:45:26 2009 From: mat69 at gmx.net (Matthias Fuchs) Date: Sun, 11 Oct 2009 14:45:26 +0200 Subject: GPGME -- Context In-Reply-To: <20091010203624.56100f18@torax.danm.home> References: <200910101519.14760.mat69@gmx.net> <20091010203624.56100f18@torax.danm.home> Message-ID: <200910111445.26285.mat69@gmx.net> On Saturday 10 October 2009 20:36:24 Daniel Mueller wrote: > Hi Matthias, > > On Sat, 10 Oct 2009 15:19:14 +0200 Matthias Fuchs wrote: > > I have GPGME 1.2.0 [..] > > [..] > > gpgme_ctx_t ctx = 0; > > gpgme_error_t errCtx = gpgme_new (&ctx); > > std::cout << errCtx << std::endl; //always prints 536871088 > > Did you call gpgme_check_version(const char *REQUIRED_VERSION) before > creating the context? Please see gpgme's developer info page section 2.6 > "Library Version Check" for more information. > > bye, > Daniel > Oh, thx! Should have rtfm, sorry for that stupid question. Cheers! matthias From beebe at math.utah.edu Mon Oct 12 23:15:26 2009 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Mon, 12 Oct 2009 15:15:26 -0600 (MDT) Subject: gnupg-2.0.13: unwanted gcc-ism in source code, and a needed library Message-ID: I've made some further progress in getting gnupg-2.0.13 installed on various local Unix platforms, and today, hit an apparent gcc-ism in the source code: % cd tests % sed -n 202p asschk.c #define die(format, args...) (die) ("%s: " format, __func__ , ##args) %% Compiling this single file with gcc, and using the native compiler on all other files, was sufficient to get this release on build on Sun Solaris (SPARC, AMD64, and IA-32). A check of the text of the 1999 ISO C Standard shows this specification of the use of variable numbers of arguments in macro definitions: 6.10.3 Macro replacement ... 4 If the identifier-list in the macro definition does not end with an ellipsis, the number of arguments (including those arguments consisting of no preprocessing tokens) in an invocation of a function-like macro shall equal the number of parameters in the macro definition. Otherwise, there shall be more arguments in the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ invocation than there are parameters in the macro definition ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (excluding the ...). There shall exist a ) preprocessing token that terminates the invocation. The gnupg code seems to violate that highlighted requirement, since it has subsequent statement like die ("out of core"); die ("received line too large"); after the macro definition. Also, the Standard's syntax description does not appear to permit a comma to be omitted before the ellipsis. The Sun c99 compiler on this test file % cat foo-die.c extern void die (const char *format, ...); #define die(format, args, ...) (die) ("%s: " format, __func__ , ##args) void foo() { die("test 1"); /* line 8 */ die("test 1", "test 2"); /* line 9 */ die("test 1", "test 2", "test 3"); /* line 10 */ } produces these errors: % c99 -c foo-die.c "foo-die.c", line 8: warning: argument mismatch "foo-die.c", line 8: syntax error before or at: ) "foo-die.c", line 9: warning: argument mismatch c99: acomp failed for foo-die.c Notice that lines 8 and 9 elicit a diagnostic, but line 10, which has the required minimum number of arguments, does not. Inasmuch as this is the ONLY file in this gnupg release that uses this C99 feature, I suggest that it would be better to remove it, in the interests of gnupg being compilable by a wider range of compilers. Also, linking of this release on Solaris fails with nanosleep() unresolved. Restarting the build with make LIBS=-lrt resolves that problem. The -lrt (real-time) library is needed on several systems for features like high-precision timers, so configure scripts should be written to find whether -lrt is needed on a given build host. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From wk at gnupg.org Tue Oct 13 10:00:53 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 13 Oct 2009 10:00:53 +0200 Subject: gnupg-2.0.13: unwanted gcc-ism in source code, and a needed library In-Reply-To: (Nelson H. F. Beebe's message of "Mon, 12 Oct 2009 15:15:26 -0600 (MDT)") References: Message-ID: <87fx9nwwne.fsf@vigenere.g10code.de> On Mon, 12 Oct 2009 23:15, beebe at math.utah.edu said: > The gnupg code seems to violate that highlighted requirement, since it > has subsequent statement like > > die ("out of core"); > die ("received line too large"); > > after the macro definition. Also, the Standard's syntax description > does not appear to permit a comma to be omitted before the ellipsis. Thanks for pointing this out. > Inasmuch as this is the ONLY file in this gnupg release that uses this > C99 feature, I suggest that it would be better to remove it, in the > interests of gnupg being compilable by a wider range of compilers. Right, our policy is to use C-90 thus vararg macros should not be used. I replaced that by die_0, die_1 etc, macros. > Also, linking of this release on Solaris fails with nanosleep() > unresolved. Restarting the build with > > make LIBS=-lrt I'll take care of that later. I also need to read through the reports you sent me a couple of weeks ago. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Wed Oct 14 15:18:01 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 Oct 2009 15:18:01 +0200 Subject: [patch] G13 and EncFS Message-ID: <87pr8qunau.fsf@vigenere.g10code.de> Hi! As some of you might have noticed, I am currently working on a new GnuPG tool to manage a crypto container with OpenPGP or X.509 keys. This tool is called g13 and will be part of GnuPG 2.1. It is in the trunk of GnuPG's SVN repository. Take care: The code is far from being usable. The first crypto container we are going to support is EncFS: http://www.arg0.net/encfs . However we need some minor changes and thus I attach a patch verified with Debian's current version of EncFS (1.5.2). I don't now how long it will take until we get it into Debian proper. For the time being this patch should be used. The patch adds a new option --annotate to the encfs tool so that scripts can reliable detect prompts. It is most useful along with --stdinpass. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: encfs-1.5.2_annotate.diff.gz Type: application/octet-stream Size: 3443 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From tux.tsndcb at free.fr Thu Oct 15 11:51:06 2009 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Thu, 15 Oct 2009 11:51:06 +0200 (CEST) Subject: Covadis vega-alpha reader don't support by ccid-driver GnuPG and don't support readers PINPAD used In-Reply-To: <1478492783.10061241255599820740.JavaMail.root@zimbra7-e1.priv.proxad.net> Message-ID: <142681655.10062801255600266946.JavaMail.root@zimbra7-e1.priv.proxad.net> Hi, I wanted to used the reader's pinpad of my reader (covadis vega-alpha), so I need to use your internal ccid-driver. Modification has been done on ccid-driver.c, but it dosen(t works pin code is always ask on my desktop and not on the reader and I think your ccid-driver don't support this reader : Modification in scd/drivers.c : .... /* We need to know the vendor to do some hacks. */ enum { VENDOR_CHERRY = 0x046a, VENDOR_SCM = 0x04e6, VENDOR_OMNIKEY= 0x076b, VENDOR_GEMPC = 0x08e6, VENDOR_KAAN = 0x0d46, VENDOR_COVADIS= 0x0982 }; .... /* We have only tested a few readers so better don't risk anything and do not allow the use with other readers. */ switch (handle->id_vendor) { case VENDOR_SCM: /* Tested with SPR 532. */ case VENDOR_KAAN: /* Tested with KAAN Advanced (1.02). */ break; case VENDOR_COVADIS: /* COVADIS Vega-Alpha */ if ( handle->id_product == 0x0008 ) { break; } case VENDOR_CHERRY: /* The CHERRY XX44 keyboard echos an asterisk for each entered character on the keyboard channel. We use a special variant of PC_to_RDR_Secure which directs these characters to the smart card's bulk-in channel. We also need to append a zero Lc byte to the APDU. It seems that it will be replaced with the actual length instead of being appended before the APDU is send to the card. */ cherry_mode = 1; break; default: return CCID_DRIVER_ERR_NOT_SUPPORTED; } .... /* The following is a little endian word. */ msg[15] = pinlen_max; /* wPINMaxExtraDigit-Maximum. */ msg[16] = pinlen_min; /* wPINMaxExtraDigit-Minimum. */ msg[17] = 0x02; /* bEntryValidationCondition: Validation key pressed */ if (pinlen_min && pinlen_max && pinlen_min == pinlen_max) msg[17] |= 0x01; /* Max size reached. */ if ( (handle->id_vendor == VENDOR_COVADIS) && (handle->id_product == 0x0008) ) { msg[18] = 0x01; /* bNumberMessage: 0x01. */ } else { msg[18] = 0xff; /* bNumberMessage: Default. */ } ..... I used : debian squeeze GnuPG 2.0.13 with this scdaemon.conf : debug 10 debug 2048 debug 3070 debug-ccid-driver I've this in scdaemon.log : 2009-10-15 11:10:38 scdaemon[6548] handler for fd -1 terminated 2009-10-15 11:10:38 scdaemon[6548] scdaemon (GnuPG) 2.0.13 stopped 2009-10-15 11:11:35 scdaemon[7412] listening on socket `/tmp/gpg-2vLAid/S.scdaemon' 2009-10-15 11:11:35 scdaemon[7412] handler for fd -1 started 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: using CCID reader 0 (ID=0982:0008:X:0) 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: idVendor: 0982 idProduct: 0008 bcdDevice: 0100 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: ChipCard Interface Descriptor: 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: bLength 54 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: bDescriptorType 33 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: bcdCCID 1.00 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: nMaxSlotIndex 0 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: bVoltageSupport 7 ? 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: dwProtocols 3 T=0 T=1 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: dwDefaultClock 4000 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: dwMaxiumumClock 4000 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: bNumClockSupported 0 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: dwDataRate 10752 bps 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: dwMaxDataRate 500000 bps 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: bNumDataRatesSupp. 0 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: dwMaxIFSD 254 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: dwSyncProtocols 00000000 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: dwMechanical 00000000 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: dwFeatures 00010230 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: Auto clock change 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: Auto baud rate change 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: NAD value other than 0x00 accepted 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: TPDU level exchange 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: dwMaxCCIDMsgLen 271 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: bClassGetResponse 00 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: bClassEnvelope 00 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: wlcdLayout none 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: bPINSupport 3 verification modification 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: bMaxCCIDBusySlots 1 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: this drivers requires that the reader supports T=1, TPDU or APDU level exchange and auto configuration - this is not available 2009-10-15 11:11:35 scdaemon[7412] DBG: ccid-driver: device not supported 2009-10-15 11:11:35 scdaemon[7412] reader slot 0: not connected 2009-10-15 11:11:35 scdaemon[7412] slot 0: ATR=3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C scdaemon[7412.0] DBG: -> OK GNU Privacy Guard's Smartcard server ready scdaemon[7412.0] DBG: <- GETINFO socket_name scdaemon[7412.0] DBG: -> D /tmp/gpg-2vLAid/S.scdaemon scdaemon[7412.0] DBG: -> OK scdaemon[7412.0] DBG: <- OPTION event-signal=12 scdaemon[7412.0] DBG: -> OK scdaemon[7412.0] DBG: <- SERIALNO openpgp but with this scdaemon.conf debug 10 debug 2048 debug 3070 debug-ccid-driver disable-ccid I've this in the scdaemon.log : 2009-10-15 11:24:33 scdaemon[7900] listening on socket `/tmp/gpg-rpZwiI/S.scdaemon' 2009-10-15 11:24:33 scdaemon[7900] handler for fd -1 started 2009-10-15 11:24:33 scdaemon[7900] reader slot 0: not connected 2009-10-15 11:24:33 scdaemon[7900] slot 0: ATR=3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C scdaemon[7900.0] DBG: -> OK GNU Privacy Guard's Smartcard server ready scdaemon[7900.0] DBG: <- GETINFO socket_name scdaemon[7900.0] DBG: -> D /tmp/gpg-rpZwiI/S.scdaemon scdaemon[7900.0] DBG: -> OK scdaemon[7900.0] DBG: <- OPTION event-signal=12 scdaemon[7900.0] DBG: -> OK scdaemon[7900.0] DBG: <- SERIALNO openpgp Could you add this reader in your ccid-driver or could you add IFDHSetProtocolParameters function like as PCSC-lite in ifdhandler.c file ? Or could you modify ccid_get_atr to support PC/SC readers : ? Actually : if (!got_param) { /* FIXME: Get those values from the ATR. */ Thanks in advanced for your return. Best Regards From tux.tsndcb at free.fr Thu Oct 15 17:07:27 2009 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Thu, 15 Oct 2009 17:07:27 +0200 (CEST) Subject: g13 and LUKS ? In-Reply-To: <1220220115.10123391255619212400.JavaMail.root@zimbra7-e1.priv.proxad.net> Message-ID: <2123567158.10123641255619247002.JavaMail.root@zimbra7-e1.priv.proxad.net> Hello Werner, I've see than you work on EncFS support with g13, do you think your can also add LUKS support ? Thanks in advanced for your answer. Best Regards. From mat69 at gmx.net Thu Oct 15 17:32:20 2009 From: mat69 at gmx.net (Matthias Fuchs) Date: Thu, 15 Oct 2009 17:32:20 +0200 Subject: GPGME: Signature summary Message-ID: <200910151732.20959.mat69@gmx.net> Hi, I do a verification of a file and what baffles me is the summary of the signature. If I use a wrong file it correctly outputs GPGME_SIGSUM_RED, yet if the file is correct it outputs 0 instead of GPGME_SIGSUM_VALID (==1). I wonder if that is a bug somewhere in GPGME. Just to be sure that it is not an error in my code I post it here (removed error handling/cleaning up to make it more readable): std::cout << "Version: " << gpgme_check_version(0) << std::endl; gpgme_ctx_t ctx = 0; gpgme_error_t err = gpgme_new(&ctx); err = gpgme_engine_check_version(GPGME_PROTOCOL_OpenPGP); if (gpgme_set_protocol(ctx, GPGME_PROTOCOL_OpenPGP)) { std::cerr << "ERROR: Setting protocol failed." << std::endl; return; } gpgme_data_t data; std::FILE *dataFile; dataFile = std::fopen("/home/kde-devel/test-meta/pgp/patch-2.6.31.gz", "r"); err = gpgme_data_new_from_stream(&data, dataFile); gpgme_data_t sig; std::FILE *sigFile; sigFile = std::fopen("/home/kde-devel/test-meta/pgp/patch-2.6.31.gz.sign", "r"); err = gpgme_data_new_from_stream(&sig, sigFile); err = gpgme_op_verify(ctx, sig, data, 0); const gpgme_verify_result_t result = gpgme_op_verify_result(ctx); gpgme_signature_t signature = result->signatures; while (signature) { std::cout << "Status: " << gpgme_err_code(signature->status) << " summary: " << signature->summary << std::endl; signature = signature->next; } It reports "Status: 0 summary: 0", while it should imo be "Status: 0 summary: 1" Cheers, matthias From mat69 at gmx.net Thu Oct 15 18:12:43 2009 From: mat69 at gmx.net (Matthias Fuchs) Date: Thu, 15 Oct 2009 18:12:43 +0200 Subject: GPGME: Signature summary In-Reply-To: <200910151732.20959.mat69@gmx.net> References: <200910151732.20959.mat69@gmx.net> Message-ID: <200910151812.43100.mat69@gmx.net> On Thursday 15 October 2009 17:32:20 Matthias Fuchs wrote: > Hi, > > I do a verification of a file and what baffles me is the summary of the > signature. If I use a wrong file it correctly outputs GPGME_SIGSUM_RED, yet > if the file is correct it outputs 0 instead of GPGME_SIGSUM_VALID (==1). I > wonder if that is a bug somewhere in GPGME. OK, I mixed up something, imo it should be GPGME_SIGSUM_GREEN because it is GPGME_VALIDITY_UNKNOWN. Imo the code in static void calc_sig_summary (gpgme_signature_t sig) verify.c:96++ is wrong. It should probably be something like: /* Calculate the red/green flag. */ if (sig->validity == GPGME_VALIDITY_FULL || sig->validity == GPGME_VALIDITY_ULTIMATE) { if (gpg_err_code (sig->status) == GPG_ERR_NO_ERROR) sum |= GPGME_SIGSUM_VALID; else if(gpg_err_code (sig->status) == GPG_ERR_SIG_EXPIRED || gpg_err_code (sig->status) == GPG_ERR_KEY_EXPIRED) sum |= GPGME_SIGSUM_GREEN; } else if (sig->validity == GPGME_VALIDITY_NEVER) { if (gpg_err_code (sig->status) == GPG_ERR_NO_ERROR || gpg_err_code (sig->status) == GPG_ERR_SIG_EXPIRED || gpg_err_code (sig->status) == GPG_ERR_KEY_EXPIRED) sum |= GPGME_SIGSUM_RED; } else if (sig->validity == GPGME_VALIDITY_UNKNOWN) { if (gpg_err_code (sig->status) == GPG_ERR_NO_ERROR) || gpg_err_code (sig->status) == GPG_ERR_SIG_EXPIRED || gpg_err_code (sig->status) == GPG_ERR_KEY_EXPIRED) sum |= GPGME_SIGSUM_GREEN; } else if (gpg_err_code (sig->status) == GPG_ERR_BAD_SIGNATURE) sum |= GPGME_SIGSUM_RED; Btw. I don't get what this is for and think that it does not work: if ((sum & GPGME_SIGSUM_GREEN) && !(sum & ~GPGME_SIGSUM_GREEN)) sum |= GPGME_SIGSUM_VALID; If you want to check wether GPGME_SIGSUM_GREEN is the only flag set you should do it imo differently, I did not try it though, but I think that it works: if (sum == GPGME_SIGSUM_GREEN) sum = GPGME_SIGSUM_VALID; Cheers, matthias From wk at gnupg.org Thu Oct 15 20:11:43 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 15 Oct 2009 20:11:43 +0200 Subject: g13 and LUKS ? In-Reply-To: <2123567158.10123641255619247002.JavaMail.root@zimbra7-e1.priv.proxad.net> (tux tsndcb's message of "Thu, 15 Oct 2009 17:07:27 +0200 (CEST)") References: <2123567158.10123641255619247002.JavaMail.root@zimbra7-e1.priv.proxad.net> Message-ID: <87iqegttls.fsf@vigenere.g10code.de> On Thu, 15 Oct 2009 17:07, tux.tsndcb at free.fr said: > I've see than you work on EncFS support with g13, do you think your can also add LUKS support ? The idea is to support a wide range of backends. I have some doubts that support for LUKS is the right think because G13 does exactly the same as LUKS: A common key management interface for all kind of crypto file systems etc. The advantage of G13 is that, in addition to symmetric keys, we can also use asymmetric keys all using a matured key management system like GPG (or GPGSM). We currently work with EncFS because it seems to be the easiest system we can deploy. We also looked at Truecrypt but figured that it will be a bit harder to support. For the project G13 will initially be used with, a fixed sized container is a suboptimal solution. A drawback of the current implementation of EncFS is that we can't bypass the key derivation function (KDF) used by EncFS or to provide a MAC key. What we do is to generate 32 random bytes as a key and replace Nul and LF characters. That key is then used as the passphrase. From a cryptographic point of view the KDF used by EncFS is not necessary if a random key can be presented. Actually it is a bit annoying because the KDF is designed to burn some time to mitigate dictionary attacks. It is not a practical problem, though. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From mat69 at gmx.net Thu Oct 15 19:07:06 2009 From: mat69 at gmx.net (Matthias Fuchs) Date: Thu, 15 Oct 2009 19:07:06 +0200 Subject: GPGME: Signature summary In-Reply-To: <200910151812.43100.mat69@gmx.net> References: <200910151732.20959.mat69@gmx.net> <200910151812.43100.mat69@gmx.net> Message-ID: <200910151907.06805.mat69@gmx.net> Btw. my changes still do not handle all gpgme_validity_t, but imo they should all be handled. From wk at gnupg.org Thu Oct 15 21:37:28 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 15 Oct 2009 21:37:28 +0200 Subject: GPGME: Signature summary In-Reply-To: <200910151732.20959.mat69@gmx.net> (Matthias Fuchs's message of "Thu, 15 Oct 2009 17:32:20 +0200") References: <200910151732.20959.mat69@gmx.net> Message-ID: <87aazstpmv.fsf@vigenere.g10code.de> On Thu, 15 Oct 2009 17:32, mat69 at gmx.net said: > I do a verification of a file and what baffles me is the summary of the > signature. If I use a wrong file it correctly outputs > GPGME_SIGSUM_RED, yet if There are a couple of reasons for this. I took this opportunity to write a litte test program which prints almost all information we get back from a signature verification. Maybe the output will be helpful. $ ./run-verify foo.sig foo Original file name: [none] Signature 0 status ....: Success summary ...: valid green fingerprint: 7B96D396E6471601754BE4DB53B620D01CE0C630 created ...: 1255634851 expires ...: 0 validity ..: full val.reason : Success pubkey algo: 1 digest algo: 2 pka address: [none] pka trust .: n/a other flags: notations .: no Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: run-verify.c Type: text/x-csrc Size: 6696 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: run-support.h Type: text/x-chdr Size: 4624 bytes Desc: not available URL: From mat69 at gmx.net Thu Oct 15 19:47:46 2009 From: mat69 at gmx.net (Matthias Fuchs) Date: Thu, 15 Oct 2009 19:47:46 +0200 Subject: GPGME: Signature summary In-Reply-To: <87aazstpmv.fsf@vigenere.g10code.de> References: <200910151732.20959.mat69@gmx.net> <87aazstpmv.fsf@vigenere.g10code.de> Message-ID: <200910151947.46452.mat69@gmx.net> On Thursday 15 October 2009 21:37:28 Werner Koch wrote: > On Thu, 15 Oct 2009 17:32, mat69 at gmx.net said: > > I do a verification of a file and what baffles me is the summary of the > > signature. If I use a wrong file it correctly outputs > > GPGME_SIGSUM_RED, yet if > > There are a couple of reasons for this. I took this opportunity to > write a litte test program which prints almost all information we get > back from a signature verification. Maybe the output will be helpful. I do understand the output, though imo static void calc_sig_summary (gpgme_signature_t sig) does not correctly handle the gpgme_sigsum_t, as it can return something that actually is not a gpgme_sigsum_t as I outlined in the answer to my own mail. From mat69 at gmx.net Thu Oct 15 22:16:29 2009 From: mat69 at gmx.net (Matthias Fuchs) Date: Thu, 15 Oct 2009 22:16:29 +0200 Subject: hkp Message-ID: <200910152216.29197.mat69@gmx.net> Hi, Not sure if that is the correct ml, if not sorry in advance. I don't want to use hkp, but rather http e.g. http://stinkfoot.org:11371/pks/lookup?op=get&search=0x517D0F0E that works nicely, though I want to get the machine readable text, though adding "&options=mr" does not work. Is there a way to get mr code? Cheers, matthias From John at Mozilla-Enigmail.org Fri Oct 16 00:55:04 2009 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Thu, 15 Oct 2009 17:55:04 -0500 Subject: hkp In-Reply-To: <200910152216.29197.mat69@gmx.net> References: <200910152216.29197.mat69@gmx.net> Message-ID: <4AD7A848.1060200@Mozilla-Enigmail.org> [cc to sks-devel as this may be a SKS issue] Matthias Fuchs wrote: > Hi, > > Not sure if that is the correct ml, if not sorry in advance. > > I don't want to use hkp, but rather http e.g. > http://stinkfoot.org:11371/pks/lookup?op=get&search=0x517D0F0E hkp is just http over port 11371. hkp:// is nothing more than http://:11371 by definition. > that works nicely, though I want to get the machine readable text, though > adding "&options=mr" does not work. Is there a way to get mr code? Hmm, this should probably go to the sks-devel list. There is code in place for checking for the mr option and implementing it. If it's not working, it's a SKS issue. (request.ml & dbserver.ml,) It may be specific to the SKS version. keyserver.stinkfoot.org is running 1.0.10 which is known to have at least one other issue. Does the mr work if you try a 1.1.0 version (pgp.mit.edu, pgp.surfnet.nl) or 1.1.1 (keyserver.gingerbear.net, keyserver.kim-minh.com) -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 679 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Fri Oct 16 01:40:10 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 15 Oct 2009 19:40:10 -0400 Subject: [Sks-devel] Re: hkp In-Reply-To: <4AD7A848.1060200@Mozilla-Enigmail.org> References: <200910152216.29197.mat69@gmx.net> <4AD7A848.1060200@Mozilla-Enigmail.org> Message-ID: <22AF374E-7DF0-4711-95C2-BFE07CF0FEF1@jabberwocky.com> On Oct 15, 2009, at 6:55 PM, John Clizbe wrote: > [cc to sks-devel as this may be a SKS issue] > > Matthias Fuchs wrote: >> Hi, >> >> Not sure if that is the correct ml, if not sorry in advance. >> >> I don't want to use hkp, but rather http e.g. >> http://stinkfoot.org:11371/pks/lookup?op=get&search=0x517D0F0E > > hkp is just http over port 11371. hkp:// is > nothing more > than http://:11371 by definition. > >> that works nicely, though I want to get the machine readable text, >> though >> adding "&options=mr" does not work. Is there a way to get mr code? > > Hmm, this should probably go to the sks-devel list. There is code in > place for > checking for the mr option and implementing it. If it's not working, > it's a SKS > issue. (request.ml & dbserver.ml,) options=mr only pertains to op=index and op=vindex. It is not meaningful for op=get. What would you expect to get differently for op=get&options=mr ? The output of a get is already machine readable. David From wk at gnupg.org Fri Oct 16 12:31:01 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 16 Oct 2009 12:31:01 +0200 Subject: GPGME: Signature summary In-Reply-To: <200910151812.43100.mat69@gmx.net> (Matthias Fuchs's message of "Thu, 15 Oct 2009 18:12:43 +0200") References: <200910151732.20959.mat69@gmx.net> <200910151812.43100.mat69@gmx.net> Message-ID: <87skdjsk9m.fsf@vigenere.g10code.de> On Thu, 15 Oct 2009 18:12, mat69 at gmx.net said: > It should probably be something like: > > /* Calculate the red/green flag. */ > if (sig->validity == GPGME_VALIDITY_FULL > || sig->validity == GPGME_VALIDITY_ULTIMATE) > { > if (gpg_err_code (sig->status) == GPG_ERR_NO_ERROR) > sum |= GPGME_SIGSUM_VALID; Nope. Check the definition: @item GPGME_SIGSUM_VALID The signature is fully valid. @item GPGME_SIGSUM_GREEN The signature is good but one might want to display some extra information. Check the other bits. If you set the VALID flag here you would need to reset it later if any other special conditions are figured out. For example later you see: /* Check other flags. */ if (sig->wrong_key_usage) sum |= GPGME_SIGSUM_BAD_POLICY; This sets another bit and thus the VALID flag is not anymore correct. GREEN says: Fine, but check the other flags. GREEN/RED is a simple thumb up/down indicator to give a basic indication on the status of a signature. In contrast, VALID says: The system has no doubts whatsoever on the validity of the signature. Note that there is also an implicit YELLOW status which should be assumed if neither GREEN or RED is set. It means that there are not enough information to say something about the signature status. KMail uses these colors to render a frame around the message. > If you want to check wether GPGME_SIGSUM_GREEN is the only flag set you should > do it imo differently, I did not try it though, but I think that it works: Sure this is the same but some folks may ask: Did you forgot that this is about a bit vector, so by doing an explicit bit test this makes it clear ;-). A reason for this code might be that we once changed the test and it used to test other bits as well. I added comment to make clean what we are doing. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From mat69 at gmx.net Fri Oct 16 11:22:36 2009 From: mat69 at gmx.net (Matthias Fuchs) Date: Fri, 16 Oct 2009 11:22:36 +0200 Subject: GPGME: Signature summary In-Reply-To: <87skdjsk9m.fsf@vigenere.g10code.de> References: <200910151732.20959.mat69@gmx.net> <200910151812.43100.mat69@gmx.net> <87skdjsk9m.fsf@vigenere.g10code.de> Message-ID: <200910161122.36504.mat69@gmx.net> On Friday 16 October 2009 12:31:01 Werner Koch wrote: > If you set the VALID flag here you would need to reset it later if any > other special conditions are figured out. For example later you see: > > /* Check other flags. */ > if (sig->wrong_key_usage) > sum |= GPGME_SIGSUM_BAD_POLICY; > > This sets another bit and thus the VALID flag is not anymore correct. This would imo apply to the current code as well. > GREEN says: Fine, but check the other flags. GREEN/RED is a simple > thumb up/down indicator to give a basic indication on the status of a > signature. In contrast, VALID says: The system has no doubts whatsoever > on the validity of the signature. > > Note that there is also an implicit YELLOW status which should be > assumed if neither GREEN or RED is set. It means that there are not > enough information to say something about the signature status. KMail > uses these colors to render a frame around the message. The problem I have still remains though and is unadressed, namely summary returning 0, a value that is not defined for gpgme_sigsum_t and imo that is not a good practice as it leaves the user in the cold of what is the case. So my code might not be the solution but something has to change there. And as I have pointed out this happens when GPGME_VALIDITY_UNKNOWN is set. Even if the signature is correct. So what is one supposed to do when summary returns 0? Cheers Matthias From wk at gnupg.org Fri Oct 16 14:26:38 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 16 Oct 2009 14:26:38 +0200 Subject: GPGME: Signature summary Message-ID: <87fx9jsewx.fsf@vigenere.g10code.de> On Fri, 16 Oct 2009 11:22, mat69 at gmx.net said: >> This sets another bit and thus the VALID flag is not anymore correct. > This would imo apply to the current code as well. Nope. The code sets the valid bit at the end of the function _only_ if no other bits but GREEN is set. That is what VALID is about. > The problem I have still remains though and is unadressed, namely summary > returning 0, a value that is not defined for gpgme_sigsum_t and imo that is > not a good practice as it leaves the user in the cold of what is the case. So I already mentioned that this indicates: Not enough information to tell anything about the validity of the signature. > And as I have pointed out this happens when GPGME_VALIDITY_UNKNOWN is set. > Even if the signature is correct. So what is one supposed to do when summary > returns 0? You can't tell anything without further digging into the subject. The mathematical correctness of the signature does not tell you anything. It is not more than a checksum to spot errors on the transport channel. What some programs do is to check the key used to create the signature against a database of known keys and from that deduce that this is a valid signature. This is what I mean with YELLOW state: Use other means to see whether you driver trough the crossing / take the signature as valid. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From mat69 at gmx.net Fri Oct 16 15:51:29 2009 From: mat69 at gmx.net (Matthias Fuchs) Date: Fri, 16 Oct 2009 15:51:29 +0200 Subject: GPGME: Signature summary In-Reply-To: <87fx9jsewx.fsf@vigenere.g10code.de> References: <87fx9jsewx.fsf@vigenere.g10code.de> Message-ID: <200910161551.30028.mat69@gmx.net> On Friday 16 October 2009 14:26:38 Werner Koch wrote: > On Fri, 16 Oct 2009 11:22, mat69 at gmx.net said: > >> This sets another bit and thus the VALID flag is not anymore correct. > > > > This would imo apply to the current code as well. > > Nope. The code sets the valid bit at the end of the function _only_ if > no other bits but GREEN is set. That is what VALID is about. Oh, sorry, obviously I did not look at it good enough. > > The problem I have still remains though and is unadressed, namely summary > > returning 0, a value that is not defined for gpgme_sigsum_t and imo that > > is not a good practice as it leaves the user in the cold of what is the > > case. So > > I already mentioned that this indicates: Not enough information to tell > anything about the validity of the signature. > > > And as I have pointed out this happens when GPGME_VALIDITY_UNKNOWN is > > set. Even if the signature is correct. So what is one supposed to do when > > summary returns 0? > > You can't tell anything without further digging into the subject. The > mathematical correctness of the signature does not tell you anything. > It is not more than a checksum to spot errors on the transport channel. So I have to assume that 0 tells me that it is mathematical correct, as it would be e.g. 4 otherwise? I thought it was more than a checksum but rather telling me that the file was signed with a key of which I have the public version, if the owner of that key is who I think he is would be a different story... > What some programs do is to check the key used to create the signature > against a database of known keys and from that deduce that this is a > valid signature. This is what I mean with YELLOW state: Use other means > to see whether you driver trough the crossing / take the signature as > valid. In that case it would be great if the documentation could be adapted to this, mentioning when it would be zero. Btw. case GPG_ERR_SIG_EXPIRED: if (gpg_err_code (sig->status) & GPG_ERR_KEY_EXPIRED) sum |= GPGME_SIGSUM_KEY_EXPIRED; sum |= GPGME_SIGSUM_SIG_EXPIRED; break; case GPG_ERR_KEY_EXPIRED: if (gpg_err_code (sig->status) & GPG_ERR_SIG_EXPIRED) sum |= GPGME_SIGSUM_KEY_EXPIRED; sum |= GPGME_SIGSUM_SIG_EXPIRED; break; would fix the FIXME, it is not nice but keeps the switch. Cheers, matthias From wk at gnupg.org Fri Oct 16 18:32:55 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 16 Oct 2009 18:32:55 +0200 Subject: GPGME: Signature summary In-Reply-To: <200910161551.30028.mat69@gmx.net> (Matthias Fuchs's message of "Fri, 16 Oct 2009 15:51:29 +0200") References: <87fx9jsewx.fsf@vigenere.g10code.de> <200910161551.30028.mat69@gmx.net> Message-ID: <87bpk7s3ig.fsf@vigenere.g10code.de> On Fri, 16 Oct 2009 15:51, mat69 at gmx.net said: > So I have to assume that 0 tells me that it is mathematical correct, as it > would be e.g. 4 otherwise? Depends. > I thought it was more than a checksum but rather telling me that the file was > signed with a key of which I have the public version, if the owner of that key Right. However gpg can't tell you whether you know the key if you have not told gpg that you know the key (signing it or through the WoT or via a tight controlled keyring like gpgv does). > In that case it would be great if the documentation could be adapted to this, > mentioning when it would be zero. This is a bit vector and not a scalar value you may compare to 0. The bit flags are all documented. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From klaus at flittner.org Mon Oct 19 19:55:13 2009 From: klaus at flittner.org (Klaus Flittner) Date: Mon, 19 Oct 2009 19:55:13 +0200 Subject: OpenPGP card and 4096 bit keys Message-ID: <20091019195513.3bd0f90d@earth.lan> Hi, i have a openpgp card that supports 4096 keys (even the one from kernelconcepts seems to support them). But the usage with gpg is restricted to 3072 bit due to limits from the communication protocol between gpg, gpg-agent and scdaemon. As far as i've looked into the code the only two commands that cause a problem are: - genkey: Public Key is returned via status lines - decrypt: encrypted message is passed as an extra command In my opinion there are two possible ways to fix this limitation: 1. Increase the assuan line length limit (>1037 instead of 1000 bytes) 2. Change the protocol used for genkey and decrypt - genkey would then return the publich key like readkey as s-expression - decrypt would inquire the encrypted message instead of a setdata before the call of decrypt Has any of these two options a chance to be included in gnupg? Regards Klaus Flittner From wk at gnupg.org Tue Oct 20 09:36:25 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Oct 2009 09:36:25 +0200 Subject: OpenPGP card and 4096 bit keys In-Reply-To: <20091019195513.3bd0f90d@earth.lan> (Klaus Flittner's message of "Mon, 19 Oct 2009 19:55:13 +0200") References: <20091019195513.3bd0f90d@earth.lan> Message-ID: <87oco27c06.fsf@vigenere.g10code.de> On Mon, 19 Oct 2009 19:55, klaus at flittner.org said: > i have a openpgp card that supports 4096 keys (even the one from > kernelconcepts seems to support them). But the usage with gpg is Note that cards up to a s/n of 0x15a (346) from Zeitcontrol ahve a bug in that decryption does not work with keys larger than 2048 bit. > As far as i've looked into the code the only two commands that cause a > problem are: > - genkey: Public Key is returned via status lines > - decrypt: encrypted message is passed as an extra command Right. > In my opinion there are two possible ways to fix this limitation: > 1. Increase the assuan line length limit (>1037 instead of 1000 bytes) No. > 2. Change the protocol used for genkey and decrypt > - genkey would then return the publich key like readkey as s-expression > - decrypt would inquire the encrypted message instead of a setdata > before the call of decrypt Right. However, the change will be easier: We send the key using several status lines. This will go into GnuPG 2.1 as time permits. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From marcus.brinkmann at ruhr-uni-bochum.de Tue Oct 20 16:29:43 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 20 Oct 2009 16:29:43 +0200 Subject: Why Is libassuan still a static lib? 2009 Edition In-Reply-To: <20090823230429.GB4557@gambit> References: <20090816225940.GA16229@gambit> <87vdkm3faz.fsf@wheatstone.g10code.de> <20090823230429.GB4557@gambit> Message-ID: <4ADDC957.5020906@ruhr-uni-bochum.de> Eric Dorland wrote: > * Werner Koch (wk at gnupg.org) wrote: >> On Mon, 17 Aug 2009 00:59, eric at debian.org said: >> >>> was still not stabilized. It's now 3 years later nearly and as far as >>> I can tell the API hasn't changed very much. Can we revisit this? I'm >>> happy to provide the patch :) >> It is more than a patch. Actually we have this in the works for several >> months now. However other projects required too much attention (gpg4win >> in particular :-(). >> >> More on this soon. > > What about it is more than a patch to build system? Hi, as you can see in the SVN repository, there have been extensive changes. In particular, one goal was to allow GPGME to use an external libassuan, and that required replacing some system code in libassuan at run-time on a per-context basis. The main changes have been done now, and things seem to work (under GNU/Linux at least). More testing has to be done, but we are getting closer. Please check out the new libassuan interface, and if you can see problems, let us know. Thanks, Marcus From tmz at pobox.com Thu Oct 22 21:48:13 2009 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 22 Oct 2009 15:48:13 -0400 Subject: Setting digest-algo for a signature via gpgme? Message-ID: <20091022194813.GC5222@inocybe.localdomain> Is it possible to set the digest-algo used via gpgme when creating some clearsigned text? The goal would be to generate a signature and ensure that, say, SHA-256 is used. It can be done if a config file is created, but for the case where this is being done, I am told setting up config files would be nice to avoid. In the end this will be done via pygpgme, but I want to check if it's even possible with gpgme first because after reading through the documentation, I don't have a good feeling for whether it is. Thanks for any pointers. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Never let your sense of morals keep you from doing what is right. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From marcus.brinkmann at ruhr-uni-bochum.de Fri Oct 23 00:58:24 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 23 Oct 2009 00:58:24 +0200 Subject: Setting digest-algo for a signature via gpgme? In-Reply-To: <20091022194813.GC5222@inocybe.localdomain> References: <20091022194813.GC5222@inocybe.localdomain> Message-ID: <4AE0E390.8020006@ruhr-uni-bochum.de> Todd Zullinger wrote: > Is it possible to set the digest-algo used via gpgme when creating > some clearsigned text? The goal would be to generate a signature and > ensure that, say, SHA-256 is used. It can be done if a config file is > created, but for the case where this is being done, I am told setting > up config files would be nice to avoid. GPGME doesn't provide this option. If you set up a gnupg config directory, you can use it setting the home_dir option. Thanks, Marcus From klaus at flittner.org Sat Oct 24 18:49:34 2009 From: klaus at flittner.org (Klaus Flittner) Date: Sat, 24 Oct 2009 18:49:34 +0200 Subject: [PATCH] Fix memory leak in scdaemon Message-ID: <20091024184934.4acadace@earth.lan> Hi, in scd/command.c the buffer allocated by cmd_setdata is never freed. The attached patch frees the buffer after use and before a second use of setdata. Regards Klaus Flittner -------------- next part -------------- A non-text attachment was scrubbed... Name: scdaemon_fix_memory_leak.patch Type: text/x-patch Size: 1474 bytes Desc: not available URL: From wk at gnupg.org Sun Oct 25 16:11:29 2009 From: wk at gnupg.org (Werner Koch) Date: Sun, 25 Oct 2009 16:11:29 +0100 Subject: [PATCH] Fix memory leak in scdaemon In-Reply-To: <20091024184934.4acadace@earth.lan> (Klaus Flittner's message of "Sat, 24 Oct 2009 18:49:34 +0200") References: <20091024184934.4acadace@earth.lan> Message-ID: <87ljiz33vi.fsf@vigenere.g10code.de> On Sat, 24 Oct 2009 18:49, klaus at flittner.org said: > in scd/command.c the buffer allocated by cmd_setdata is never freed. > The attached patch frees the buffer after use and before a second use > of setdata. Good catch. The fix is eaven easier than yours; see below. Shalom-Salam, Werner Index: scd/command.c =================================================================== --- scd/command.c (revision 5172) +++ scd/command.c (working copy) @@ -804,6 +804,7 @@ if (!buf) return out_of_core (); + xfree (ctrl->in_data.value); ctrl->in_data.value = buf; ctrl->in_data.valuelen = n; for (p=line, n=0; n < ctrl->in_data.valuelen; p += 2, n++) Index: scd/scdaemon.c =================================================================== --- scd/scdaemon.c (revision 5172) +++ scd/scdaemon.c (working copy) @@ -892,7 +892,11 @@ static void scd_deinit_default_ctrl (ctrl_t ctrl) { - (void)ctrl; + if (!ctrl) + return; + xfree (ctrl->in_data.value); + ctrl->in_data.value = NULL; + ctrl->in_data.valuelen = 0; } -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From Thomas-Bahn at gmx.net Tue Oct 27 21:28:45 2009 From: Thomas-Bahn at gmx.net (Thomas-Bahn) Date: Tue, 27 Oct 2009 21:28:45 +0100 Subject: - invalid length of cacheID Message-ID: <200910272128.45993.Thomas-Bahn@gmx.net> Hello, i have the problem, that gpg-agent throws errors when launching the pinentry. I analyzed the problem and would give you my results in the hope, that the bug can be fixed. I have no idea what else can be faulty? I searched the code snippet for you to help simplify the work on this problem as good as i can. I think its the code snippet that causes this error but i can't analyze this furthermore because my skills not as good as needed. Following the gpg-agent.conf: debug-level guru log-file socket:///home/thomas/.gnupg/log-socket pinentry-program /usr/bin/pinentry-gtk-2 no-grab default-cache-ttl 1800 The settings are correct i'm sure. Here is a part of the log from KWatchGnuPG: 5 - 2009-10-27 19:22:17 gpg-agent[3840.9] DBG: <- GET_PASSPHRASE --data --repeat=0 -- X X Passphrase: Please+enter+the+passphrase+to+unprotect+the+PKCS#12+object. 5 - 2009-10-27 19:22:17 gpg-agent[3840]: starting a new PIN Entry 5 - 2009-10-27 19:22:17 gpg-agent[3840]: DBG: connection to PIN entry established 5 - 2009-10-27 19:22:17 gpg-agent[3840.9] DBG: -> INQUIRE PINENTRY_LAUNCHED 4205 5 - 2009-10-27 19:22:17 gpg-agent[3840.9] DBG: <- END 5 - 2009-10-27 19:22:17 gpg-agent[3840]: command get_passphrase failed: End of File 5 - 2009-10-27 19:22:17 gpg-agent[3840.9] DBG: -> OK closing connection But this log wasn't enough information so i looked for reproducing the error directly in gpg-agent. And i found gpg-connect-agent. Here the error when i connect to gpg-agent and give him the command: gpg-connect-agent > GET_PASSPHRASE ERR 67109144 IPC Parameterfehler - invalid length of cacheID > This error was enough information for me and i found following code in gnupg-2.0.13/agent/command.c : In function cmd_get_passphrase: static int cmd_get_passphrase (assuan_context_t ctx, char *line) { ctrl_t ctrl = assuan_get_pointer (ctx); int rc; const char *pw; char *response; char *cacheid = NULL, *desc = NULL, *prompt = NULL, *errtext = NULL; const char *desc2 = _("Please re-enter this passphrase"); char *p; void *cache_marker; int opt_data, opt_check, opt_no_ask, opt_qualbar; int opt_repeat = 0; char *repeat_errtext = NULL; opt_data = has_option (line, "--data"); opt_check = has_option (line, "--check"); opt_no_ask = has_option (line, "--no-ask"); if (has_option_name (line, "--repeat")) { p = option_value (line, "--repeat"); if (p) opt_repeat = atoi (p); else opt_repeat = 1; } opt_qualbar = has_option (line, "--qualitybar"); line = skip_options (line); cacheid = line; p = strchr (cacheid, ' '); if (p) { *p++ = 0; while (*p == ' ') p++; errtext = p; p = strchr (errtext, ' '); if (p) { *p++ = 0; while (*p == ' ') p++; prompt = p; p = strchr (prompt, ' '); if (p) { *p++ = 0; while (*p == ' ') p++; desc = p; p = strchr (desc, ' '); if (p) *p = 0; /* Ignore trailing garbage. */ } } } if (!cacheid || !*cacheid || strlen (cacheid) > 50) return set_error (GPG_ERR_ASS_PARAMETER, "invalid length of cacheID"); if (!desc) return set_error (GPG_ERR_ASS_PARAMETER, "no description given"); --- CUT --- (the pasted code is long enough ;)) if (!cacheid || !*cacheid || strlen (cacheid) > 50) return set_error (GPG_ERR_ASS_PARAMETER, "invalid length of cacheID"); This statement must be the cause of the error... but what value was in cacheid and why it can be faulty? I can't answer this question and hope you can? From wk at gnupg.org Thu Oct 29 13:28:15 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 29 Oct 2009 13:28:15 +0100 Subject: - invalid length of cacheID In-Reply-To: <200910272128.45993.Thomas-Bahn@gmx.net> (Thomas-Bahn@gmx.net's message of "Tue, 27 Oct 2009 21:28:45 +0100") References: <200910272128.45993.Thomas-Bahn@gmx.net> Message-ID: <87r5smxu3k.fsf@vigenere.g10code.de> On Tue, 27 Oct 2009 21:28, Thomas-Bahn at gmx.net said: > gpg-connect-agent > > GET_PASSPHRASE > ERR 67109144 IPC Parameterfehler - invalid length of cacheID You need to give the mandatory arguments. If you don't one of them you give a 'X', like this: > GET_PASSPHRASE X X X X OK 616263 or this > GET_PASSPHRASE --data X X X X D abc OK Sorry, I can't look into you pinentry problems. Using a wrapper script as pinentry is usually helpful in this case. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From Thomas-Bahn at gmx.net Thu Oct 29 18:48:25 2009 From: Thomas-Bahn at gmx.net (Thomas-Bahn) Date: Thu, 29 Oct 2009 18:48:25 +0100 Subject: - invalid length of cacheID In-Reply-To: <87r5smxu3k.fsf@vigenere.g10code.de> References: <200910272128.45993.Thomas-Bahn@gmx.net> <87r5smxu3k.fsf@vigenere.g10code.de> Message-ID: <200910291848.26056.Thomas-Bahn@gmx.net> Oh, excuse me, with the arguments it gives me the prompt as it should. But whats then the problem? I will reseach it and give you more information when its time. Thank you, this helped me a lot ;) > On Tue, 27 Oct 2009 21:28, Thomas-Bahn at gmx.net said: > > gpg-connect-agent > > > > > GET_PASSPHRASE > > > > ERR 67109144 IPC Parameterfehler - invalid length of > > cacheID > > You need to give the mandatory arguments. If you don't one of them you > > give a 'X', like this: > > GET_PASSPHRASE X X X X > > OK 616263 > > or this > > > GET_PASSPHRASE --data X X X X > > D abc > OK > > Sorry, I can't look into you pinentry problems. Using a wrapper script > as pinentry is usually helpful in this case. > > > Shalom-Salam, > > Werner >