From hans at guardianproject.info Tue Sep 4 19:58:09 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 04 Sep 2012 13:58:09 -0400 Subject: GPGME_DEBUG on Android, which makes env vars hard In-Reply-To: <504118FF.3080308@guardianproject.info> References: <504118FF.3080308@guardianproject.info> Message-ID: <50464131.2000608@guardianproject.info> I was just looking at gpgme/debug.c. Something like gpgme_set_debug_level(int level) and gpgme_set_debug_log(char* logfilename) would be perfect. gpgme_set_debug_level() looks trivial since it would just update the static var debug_level and would take effect immediately. gpgme_set_debug_log() would be a little more work since the file opening logic in debug_init() would have to be changed. Another idea would be for setting this from a conf file somewhere, but I'm not sure if there is a gpgme conf file. .hc On 08/31/2012 04:05 PM, Hans-Christoph Steiner wrote: > > So this kind of thing would be super helpful for me to debug the > GnuPG-for-Android app, but since Android apps are Java, and they are > launched from a mysterious non-UNIX process, using environment variables > is difficult at best. > > I would like to do exactly this: > GPGME_DEBUG=9:/tmp/gpgme.debug > > Is there anyway to do this in C code? Like an option to the gpg_engine? > > .hc > From wking at tremily.us Fri Sep 14 16:08:18 2012 From: wking at tremily.us (W. Trevor King) Date: Fri, 14 Sep 2012 10:08:18 -0400 Subject: [PATCH] gpgme-tool: use the default handlers for INPUT and OUTPUT. Message-ID: <20120914140818.GB16987@odin.tremily.us> I proposed this change back in April, and Marcus was going to take a look at at. Unfortunately with the g10 shuffling, he no longer has the time, so I'm punting back to the main list. I've attached the original patch/message for anyone who doesn't want to go digging back through the archives. I've been using the patched version locally (via my pyassuan [1], which I use from my `pinentry.py` [1] and pgp-mime [2]) without problems since I wrote up the patch back in April. I'd really like to get this patch upstreamed so I can move forward and use pgp-mime projects destined for public consumption. Cheers, Trevor [1]: http://blog.tremily.us/posts/pyassuan/ [2]: http://blog.tremily.us/posts/pgp-mime/ -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- An embedded message was scrubbed... From: "W. Trevor King" Subject: [PATCH] gpgme-tool: use the default handlers for INPUT and OUTPUT. Date: Sat, 21 Apr 2012 07:29:24 -0400 Size: 4613 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From devurandom at gmx.net Mon Sep 17 23:46:09 2012 From: devurandom at gmx.net (Dennis Schridde) Date: Mon, 17 Sep 2012 23:46:09 +0200 Subject: [PATCH] Generate and install a pkg-config file for gpg-error Message-ID: <3248727.B0QHaV41EX@ernie> Hello! Attached patches make libgpg-error install a pkg-config file. This aids in cross-compiling, where the output of gpg-error-config cannot directly be used, e.g. because the paths may need an additional prefix. Best regards, Dennis Schridde -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Generate-and-install-a-pkg-config-file.patch Type: text/x-patch Size: 1697 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From devurandom at gmx.net Mon Sep 17 23:52:32 2012 From: devurandom at gmx.net (Dennis Schridde) Date: Mon, 17 Sep 2012 23:52:32 +0200 Subject: [PATCH] Generate and install a pkg-config file for gpg-error Message-ID: <1860443.FNmYAXFElz@ernie> Hello! Attached patches make libgpg-error install a pkg-config file. This aids in cross-compiling, where the output of gpg-error-config cannot directly be used, e.g. because the paths may need an additional prefix. Best regards, Dennis Schridde -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Generate-and-install-a-pkg-config-file.patch Type: text/x-patch Size: 1696 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Tue Sep 18 09:07:04 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 18 Sep 2012 09:07:04 +0200 Subject: [PATCH] Generate and install a pkg-config file for gpg-error In-Reply-To: <3248727.B0QHaV41EX@ernie> (Dennis Schridde's message of "Mon, 17 Sep 2012 23:46:09 +0200") References: <3248727.B0QHaV41EX@ernie> Message-ID: <87r4pzizc7.fsf@vigenere.g10code.de> On Mon, 17 Sep 2012 23:46, devurandom at gmx.net said: > Attached patches make libgpg-error install a pkg-config file. This has been discussed several times in the last years. > This aids in cross-compiling, where the output of gpg-error-config cannot > directly be used, e.g. because the paths may need an additional prefix. It is quite interesting that we are cross compiling the whole GnuPG system for a decade without any problems: ./configure --prefix=${sysroot} \ --with-gpg-error-prefix=${sysroot} Package using pkgconfig require a wrapper to fix the paths. Checkout the Gpg4win meta installer for details. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From devurandom at gmx.net Tue Sep 18 09:37:22 2012 From: devurandom at gmx.net (Dennis Schridde) Date: Tue, 18 Sep 2012 09:37:22 +0200 Subject: [PATCH] Generate and install a pkg-config file for gpg-error In-Reply-To: <87r4pzizc7.fsf@vigenere.g10code.de> References: <3248727.B0QHaV41EX@ernie> <87r4pzizc7.fsf@vigenere.g10code.de> Message-ID: <1542452.RME2mZBnYN@samson> Hi Werner! Am Dienstag, 18. September 2012, 09:07:04 schrieb Werner Koch: > On Mon, 17 Sep 2012 23:46, devurandom at gmx.net said: > > This aids in cross-compiling, where the output of gpg-error-config cannot > > directly be used, e.g. because the paths may need an additional prefix. > > It is quite interesting that we are cross compiling the whole GnuPG > system for a decade without any problems: > > ./configure --prefix=${sysroot} \ > --with-gpg-error-prefix=${sysroot} Doesn't --prefix specify a path within the target system? E.g. /usr? Won't the paths within the software come out wrongly if used like that? I.e. what if the software is later run not from the system that built it inside $sysroot, but if it is actually being booted? Then its own -config script would report wrong paths, wouldn't it? In particular, my issue was that gpg-error-config reported its library as /usr/lib/libgpg-error.so -- relative to the $sysroot it was installed into. Obviously that does not work, since the library at that location is for a different architecture. So I would have to wrap the -config script by something that mangles the paths to start with $sysroot. Doing that with pkg-config is easy (in fact it comes included), but if I am not using it, I have to wrap each and every package's - config script using my own sed magic. On the other hand including a pkg-config file with libgpg-error and libgcrypt is easy and not too much of a maintainance burden, especially since it changes almost never. Best regards, Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From hans at guardianproject.info Wed Sep 19 04:23:30 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 18 Sep 2012 22:23:30 -0400 Subject: pinentry for Android questions In-Reply-To: <4F5B5DA7.8060608@ruhr-uni-bochum.de> References: <9333EDAB-36A0-4061-8430-E27EC6C9D566@guardianproject.info> <4F5A26D8.9000309@ruhr-uni-bochum.de> <1E4A9464-47B4-4D8C-BDC4-62A210F83F95@guardianproject.info> <4F5A4812.3090603@ruhr-uni-bochum.de> <4F5ACBFB.1010102@guardianproject.info> <4F5B5DA7.8060608@ruhr-uni-bochum.de> Message-ID: <50592CA2.3090501@guardianproject.info> On 03/10/2012 08:56 AM, Marcus Brinkmann wrote: > On 03/10/2012 04:35 AM, Hans-Christoph Steiner wrote: >> >> >> On 03/09/2012 01:12 PM, Marcus Brinkmann wrote: >>> On 03/09/2012 06:37 PM, Hans-Christoph Steiner wrote: >>>> >>>> I've been looking through the examples, those are hard to generalize >>>> from for this use case since they are all pure C and can all be linked >>>> together into a single program. What I would love to see is an >>>> example transcript of the assuan dialog between a pinentry program and >>>> gpg-agent, since I think I'll have to implement the whole pinentry lib >>>> in Java. Or perhaps I could wrap the pinentry C code in JNI for Java. >>>> >>> >>> It's a lot easier to make pinentry.c/pinentry.h in a library and wrap >>> that than to wrap libassuan or reimplement libassuan in Java. >>> >>> gpg-agent can be configured to log its assuan communication with >>> pinentry. >> >> I forgot to mention, we're going to be using gpgme in this. It looks >> like gpgme somehow handle > > Thanks, > Marcus > > s the pinentry stuff with callbacks, or am I >> reading it wrong? If we are using gpgme, do we still need a custom >> pinentry? > > The callbacks are "old school" and not functional for gpg2 with > gpg-agent. :) > > So a custom pinentry is indeed needed, and you don't need to set a gpgme > passphrase callback (it would never be called). > > Thanks for the list of issues, btw, it's a big help as the mailing list > threads were getting a tiny bit unwieldy. I'm back on this and still not quite seeing how to do it. From what I've seen, it seems that gpg-agent executes pinentry, then communicates with it via stdin/stdout. This is not possible in Android because you cannot directly launch a GUI program in Android from the terminal. The only way I've found to start an Android GUI screen from the terminal is to launch an Activity (which is a Java Class representing a GUI screen) using the 'am start' command. Its not blocking, and there is no stdin/stdout to attach to. What I think need to happen is that gpg-agent calls "am start PassphraseActivity", then PassphraseActivity starts and connects to the gpg-agent UNIX socket and does its communication there. It would also be possible to have pinentry create its own UNIX socket and point gpg-agent to it. I have no idea how to do that, all of the existing pinentry programs seem to work the exact same way. Any pointers? .hc From abel at guardianproject.info Wed Sep 19 18:30:00 2012 From: abel at guardianproject.info (Abel Luck) Date: Wed, 19 Sep 2012 16:30:00 +0000 Subject: pinentry for Android questions In-Reply-To: <50592CA2.3090501@guardianproject.info> References: <9333EDAB-36A0-4061-8430-E27EC6C9D566@guardianproject.info> <4F5A26D8.9000309@ruhr-uni-bochum.de> <1E4A9464-47B4-4D8C-BDC4-62A210F83F95@guardianproject.info> <4F5A4812.3090603@ruhr-uni-bochum.de> <4F5ACBFB.1010102@guardianproject.info> <4F5B5DA7.8060608@ruhr-uni-bochum.de> <50592CA2.3090501@guardianproject.info> Message-ID: <5059F308.6010609@guardianproject.info> Hans-Christoph Steiner: > > > On 03/10/2012 08:56 AM, Marcus Brinkmann wrote: >> On 03/10/2012 04:35 AM, Hans-Christoph Steiner wrote: >>> >>> >>> On 03/09/2012 01:12 PM, Marcus Brinkmann wrote: >>>> On 03/09/2012 06:37 PM, Hans-Christoph Steiner wrote: >>>>> >>>>> I've been looking through the examples, those are hard to generalize >>>>> from for this use case since they are all pure C and can all be linked >>>>> together into a single program. What I would love to see is an >>>>> example transcript of the assuan dialog between a pinentry program and >>>>> gpg-agent, since I think I'll have to implement the whole pinentry lib >>>>> in Java. Or perhaps I could wrap the pinentry C code in JNI for Java. >>>>> >>>> >>>> It's a lot easier to make pinentry.c/pinentry.h in a library and wrap >>>> that than to wrap libassuan or reimplement libassuan in Java. >>>> >>>> gpg-agent can be configured to log its assuan communication with >>>> pinentry. >>> >>> I forgot to mention, we're going to be using gpgme in this. It looks >>> like gpgme somehow handle >> >> Thanks, >> Marcus >> >> > s the pinentry stuff with callbacks, or am I >>> reading it wrong? If we are using gpgme, do we still need a custom >>> pinentry? >> >> The callbacks are "old school" and not functional for gpg2 with >> gpg-agent. :) >> >> So a custom pinentry is indeed needed, and you don't need to set a gpgme >> passphrase callback (it would never be called). >> >> Thanks for the list of issues, btw, it's a big help as the mailing list >> threads were getting a tiny bit unwieldy. > > I'm back on this and still not quite seeing how to do it. From what > I've seen, it seems that gpg-agent executes pinentry, then communicates > with it via stdin/stdout. This is not possible in Android because you > cannot directly launch a GUI program in Android from the terminal. > > The only way I've found to start an Android GUI screen from the terminal > is to launch an Activity (which is a Java Class representing a GUI > screen) using the 'am start' command. Its not blocking, and there is no > stdin/stdout to attach to. > A thought I had when I looked at this was to create an 'am start' wrapper program, 'pinentry-android' for example. This program would: 1. launch the activity (non-blocking) 2. block, as other pinentry programs do 3. communicate with the activity somehow (maybe suingsome shared memory, mmap) 4. communicate with gpg-agent via stdin/out #3 is the trickiest bit I think, but this method would work well if non-blocking pineentry programs that communicate over the gpg-agent socket aren't possible. ~abel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 626 bytes Desc: OpenPGP digital signature URL: From hans at guardianproject.info Wed Sep 19 21:11:36 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 19 Sep 2012 15:11:36 -0400 Subject: pinentry for Android questions In-Reply-To: <5059F308.6010609@guardianproject.info> References: <9333EDAB-36A0-4061-8430-E27EC6C9D566@guardianproject.info> <4F5A26D8.9000309@ruhr-uni-bochum.de> <1E4A9464-47B4-4D8C-BDC4-62A210F83F95@guardianproject.info> <4F5A4812.3090603@ruhr-uni-bochum.de> <4F5ACBFB.1010102@guardianproject.info> <4F5B5DA7.8060608@ruhr-uni-bochum.de> <50592CA2.3090501@guardianproject.info> <5059F308.6010609@guardianproject.info> Message-ID: <505A18E8.7090908@guardianproject.info> On 09/19/2012 12:30 PM, Abel Luck wrote: > Hans-Christoph Steiner: >> >> >> On 03/10/2012 08:56 AM, Marcus Brinkmann wrote: >>> On 03/10/2012 04:35 AM, Hans-Christoph Steiner wrote: >>>> >>>> >>>> On 03/09/2012 01:12 PM, Marcus Brinkmann wrote: >>>>> On 03/09/2012 06:37 PM, Hans-Christoph Steiner wrote: >>>>>> >>>>>> I've been looking through the examples, those are hard to generalize >>>>>> from for this use case since they are all pure C and can all be linked >>>>>> together into a single program. What I would love to see is an >>>>>> example transcript of the assuan dialog between a pinentry program and >>>>>> gpg-agent, since I think I'll have to implement the whole pinentry lib >>>>>> in Java. Or perhaps I could wrap the pinentry C code in JNI for Java. >>>>>> >>>>> >>>>> It's a lot easier to make pinentry.c/pinentry.h in a library and wrap >>>>> that than to wrap libassuan or reimplement libassuan in Java. >>>>> >>>>> gpg-agent can be configured to log its assuan communication with >>>>> pinentry. >>>> >>>> I forgot to mention, we're going to be using gpgme in this. It looks >>>> like gpgme somehow handle >>> >>> Thanks, >>> Marcus >>> >>> >> s the pinentry stuff with callbacks, or am I >>>> reading it wrong? If we are using gpgme, do we still need a custom >>>> pinentry? >>> >>> The callbacks are "old school" and not functional for gpg2 with >>> gpg-agent. :) >>> >>> So a custom pinentry is indeed needed, and you don't need to set a gpgme >>> passphrase callback (it would never be called). >>> >>> Thanks for the list of issues, btw, it's a big help as the mailing list >>> threads were getting a tiny bit unwieldy. >> >> I'm back on this and still not quite seeing how to do it. From what >> I've seen, it seems that gpg-agent executes pinentry, then communicates >> with it via stdin/stdout. This is not possible in Android because you >> cannot directly launch a GUI program in Android from the terminal. >> >> The only way I've found to start an Android GUI screen from the terminal >> is to launch an Activity (which is a Java Class representing a GUI >> screen) using the 'am start' command. Its not blocking, and there is no >> stdin/stdout to attach to. >> > > A thought I had when I looked at this was to create an 'am start' > wrapper program, 'pinentry-android' for example. > > This program would: > > 1. launch the activity (non-blocking) > 2. block, as other pinentry programs do > 3. communicate with the activity somehow (maybe suingsome shared memory, > mmap) > 4. communicate with gpg-agent via stdin/out > > #3 is the trickiest bit I think, but this method would work well if > non-blocking pineentry programs that communicate over the gpg-agent > socket aren't possible. Abel and I discussed this on IRC, so I'm posting it here to get feedback on the best approach here: _hc: The thing is that all of the pinentry impls that I found use the pinentry 'lib' _hc: that pinentry lib makes it really easy to write a pinentry that is launched via gpg-agent which communicates via stdin/stdout _hc: the pinentry lib handles all of the conversation in the assuan protocol _hc: and it seems that conversation is pretty elaborate _hc: so we'll want to try to include the pinentry 'lib' _hc: I guess the Activity could launch its own pinentry process and intercept stdin/stdout _hc: then that needs to be ferried back somehow, I guess that's your #3 14:55 abeluck: hm, thats not quite what i had in mind abeluck: the CLI program gpg-agent would launch uses pinentry lib abeluck: and is a middleman between gpg and the Activity _hc: ok, so pinentry-android does exec("am start info.guardianproject.gpg.PassphraseActivity); abeluck: gpg-agent <--pinentry lib--> pinentry-android-blocking <--mmap/other socket--> Java Activity abeluck: yes abeluck: yes, it starts the activity abeluck: and bridges communication between gpg-agent abeluck: and the activity abeluck: using mmap/or socket to talk to the activity abeluck: and using stdin/out to talk to gpg abeluck: or s/stdin\out/pineentry-lib/ if necessary _hc: right, ok _hc: I guess pinentry-android makes it own UNIX socket, which the PinEntryActivity connects to once it starts abeluck: yes _hc: ok, this is seeming doable abeluck: its pretty elegant really _hc: hmm, elegant considering the options abeluck: indeed _hc: if android just let you write a cmd line program that showed an Activity, this would be done abeluck: the savings there doesnt seem any more difficult than doing it this way abeluck: 'am start' is effectively that _hc: it would be nice if gpg-agent could just call 'am start ...', then the PinEntryActivity could just connect directly to the gpg-agent UNIX socket and do everything there. abeluck: the fact you have to communicate asyncly isn't a big deal imo _hc: async isn't the problem, its adding another socket _hc: just seems messy abeluck: yea, that would be nice, but infeasible atm _hc: but the only feasible approach right now .hc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 937 bytes Desc: OpenPGP digital signature URL: From wking at tremily.us Thu Sep 20 19:13:18 2012 From: wking at tremily.us (W. Trevor King) Date: Thu, 20 Sep 2012 13:13:18 -0400 Subject: fleshing out the XML result of gpgme-tool's KEYLIST command Message-ID: <20120920171317.GG22536@odin.tremily.us> The current keylist XML of gpgme-tool is not very useful: S: OK GPGME-Tool 1.3.1-git62bbe58 ready C: ARMOR true S: OK C: KEYLIST 2F73DE2E S: D key:B2EDBE0E771A4B8708DD16A7511AEDA64332B6E3%0A S: OK C: RESULT 2F73DE2E S: D %0A\x00 S: D %0A\x00 S: D %0A S: D %0A S: D %0A S: D %0A\x00 S: OK C: BYE S: OK closing connection disconnecting This is using my gpgme with the INPUT/OUTPUT patch [1], but I haven't touched the `result_keylist_to_xml` function. I'd like the result to include all the information about the requested keys (although it doesn't need to recurse through subkeys). I could write up a patch to create this XML, but I'd like an estimate of how likely it would be that the patch would get accepted, considering: 1. My INPUT/OUTPUT patch has been languishing for five months. 2. Deciding on and XML representation for keys may require a lot of bike-shed-level decisions. 3. Having useful XML would be nice, but is not critical to my pygrader [2]. So perhaps it would be better for me to wait and let someone closer to the core handle this? I could also let this sit, and bring it up again in six months when people might have more time? Cheers, Trevor [1]: http://thread.gmane.org/gmane.comp.encryption.gpg.devel/17104 [2]: https://pypi.python.org/pypi/pygrader/ -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From jeanjacquesbrucker at gmail.com Fri Sep 21 14:46:53 2012 From: jeanjacquesbrucker at gmail.com (jbar) Date: Fri, 21 Sep 2012 14:46:53 +0200 Subject: [gpgme][Feature Request] indicate option to gpgme_op_import* Message-ID: <20120921144653.892dd222.jeanjacquesbrucker@gmail.com> I would like to try making a patch, but even with cscope, I didn't have found the real code used in the engine when a gpgme_op_import* is called. (:-/) I would like to use some gpgme_op_import_ext* function with an additional flag parameter to do like the "--import-options" of GnuPG. (ie mainly to clean or minimalize an imported key). We really need to clean keys in our program (eg "ludd node", and we will also need to minimalize some keys in the futur). But today the only solution I see is to make an ulgy system("gpg ...") call. :'-( May you please help ? -- jbar -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From wk at gnupg.org Fri Sep 21 15:33:57 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 21 Sep 2012 15:33:57 +0200 Subject: [gpgme][Feature Request] indicate option to gpgme_op_import* In-Reply-To: <20120921144653.892dd222.jeanjacquesbrucker@gmail.com> (jbar's message of "Fri, 21 Sep 2012 14:46:53 +0200") References: <20120921144653.892dd222.jeanjacquesbrucker@gmail.com> Message-ID: <87vcf7cxfe.fsf@vigenere.g10code.de> On Fri, 21 Sep 2012 14:46, jeanjacquesbrucker at gmail.com said: > I would like to try making a patch, but even with cscope, I didn't > have found the real code used in the engine when a gpgme_op_import* is > called. (:-/) The command is build using the add_arg() functions in engine-gpg.c which are finally used by the start() function. styart() is then called by gpg_import(). > We really need to clean keys in our program (eg "ludd node", and we will also need to minimalize some keys in the futur). > But today the only solution I see is to make an ulgy system("gpg ...") > call. : You may simply provide a different configuration file by setting a another homedir with a specialized configuraion file with gpgme_set_engine_info. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Sep 21 15:59:23 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 21 Sep 2012 15:59:23 +0200 Subject: [PATCH] Generate and install a pkg-config file for gpg-error In-Reply-To: <1542452.RME2mZBnYN@samson> (Dennis Schridde's message of "Tue, 18 Sep 2012 09:37:22 +0200") References: <3248727.B0QHaV41EX@ernie> <87r4pzizc7.fsf@vigenere.g10code.de> <1542452.RME2mZBnYN@samson> Message-ID: <87obkzcw90.fsf@vigenere.g10code.de> On Tue, 18 Sep 2012 09:37, devurandom at gmx.net said: > Doesn't --prefix specify a path within the target system? E.g. /usr? Well for the host system. /target/ is usually the target system of a compiler, whereas /host/ is the system on which the software you are building will actually run. I mentioned prefixt only because for Windows it is easier than to use make install prefix=INSTALLPREFIX --with-gpg-error-prefix is unrelated to --prefix; it describes where the gpg-error development files for software running on /host/ are installed on the /build/ system. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jeanjacquesbrucker at gmail.com Fri Sep 21 17:31:59 2012 From: jeanjacquesbrucker at gmail.com (jbar) Date: Fri, 21 Sep 2012 17:31:59 +0200 Subject: [gpgme][Feature Request] indicate option to gpgme_op_import* In-Reply-To: <87vcf7cxfe.fsf@vigenere.g10code.de> References: <20120921144653.892dd222.jeanjacquesbrucker@gmail.com> <87vcf7cxfe.fsf@vigenere.g10code.de> Message-ID: <20120921173159.f0ffb35e.jeanjacquesbrucker@gmail.com> You means that gpgme will use the gpg.conf of its context homedir, and so that I just need to add such line to that file ? : | import-options import-clean Thanks a lot, gonna try it with gpgme. Note: whith gpg 1.4.12 or 2.0.18 the import-clean option works on --import, but not on --recv-keys. It is not annoying for me, but what is please exactly the reason ? -- jbar On Fri, 21 Sep 2012 15:33:57 +0200 Werner Koch wrote: > On Fri, 21 Sep 2012 14:46, jeanjacquesbrucker at gmail.com said: > > I would like to try making a patch, but even with cscope, I didn't > > have found the real code used in the engine when a gpgme_op_import* is > > called. (:-/) > > The command is build using the add_arg() functions in engine-gpg.c which > are finally used by the start() function. styart() is then called by > gpg_import(). > > > We really need to clean keys in our program (eg "ludd node", and we will also need to minimalize some keys in the futur). > > But today the only solution I see is to make an ulgy system("gpg ...") > > call. : > > You may simply provide a different configuration file by setting a > another homedir with a specialized configuraion file with > gpgme_set_engine_info. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From jacob at appelbaum.net Mon Sep 24 01:43:06 2012 From: jacob at appelbaum.net (Jacob Appelbaum) Date: Sun, 23 Sep 2012 23:43:06 +0000 Subject: SOCKS4A/SOCKS5 proxy support? Message-ID: <505F9E8A.5000807@appelbaum.net> Hi there, This is a rather messy issue which could be resolved in a few different ways - I've been thinking that the right answer is to enhance GnuPG's proxy support. In developing TorBirdy ( https://trac.torproject.org/projects/tor/wiki/torbirdy and https://addons.mozilla.org/en-US/thunderbird/addon/torbirdy/ ), we have come across an issue where a Thunderbird user with Enigmail may invoke GnuPG in a way that directly connects to the internet ( https://trac.torproject.org/projects/tor/ticket/6940 ). We found that setting an HTTP proxy as a gpg commandline flag worked perfectly fine but only if the user has a properly configured HTTP proxy. Sadly, around zero users have this configuration and so we've removed the configuration. Even more sadly, we now have no way to invoke GPG and route it through Tor - Engimail will gladly set any commandline flag we wish but it appears that GnuPG does not support any kind of proxy beyond HTTP. Are there any plans to add support to gpg for SOCKS5? Would such a thing be a welcome patch? All the best, Jacob From wk at gnupg.org Mon Sep 24 12:11:54 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Sep 2012 12:11:54 +0200 Subject: SOCKS4A/SOCKS5 proxy support? In-Reply-To: <505F9E8A.5000807@appelbaum.net> (Jacob Appelbaum's message of "Sun, 23 Sep 2012 23:43:06 +0000") References: <505F9E8A.5000807@appelbaum.net> Message-ID: <87y5jzbuhh.fsf@vigenere.g10code.de> On Mon, 24 Sep 2012 01:43, jacob at appelbaum.net said: > Are there any plans to add support to gpg for SOCKS5? Would such a thing > be a welcome patch? Does Curl support SOCKS? Then GnuPG should benefit from it directy. Well unless you are talking about Windows, where we don't build with Curl support. Patches are subject to the usual FSF copyright assignment problem. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Sep 24 12:14:19 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Sep 2012 12:14:19 +0200 Subject: [gpgme][Feature Request] indicate option to gpgme_op_import* In-Reply-To: <20120921173159.f0ffb35e.jeanjacquesbrucker@gmail.com> (jbar's message of "Fri, 21 Sep 2012 17:31:59 +0200") References: <20120921144653.892dd222.jeanjacquesbrucker@gmail.com> <87vcf7cxfe.fsf@vigenere.g10code.de> <20120921173159.f0ffb35e.jeanjacquesbrucker@gmail.com> Message-ID: <87txunbudg.fsf@vigenere.g10code.de> On Fri, 21 Sep 2012 17:31, jeanjacquesbrucker at gmail.com said: > You means that gpgme will use the gpg.conf of its context homedir, > and so that I just need to add such line to that file ? : > | import-options import-clean Sure (without the pipe symbol). > Note: whith gpg 1.4.12 or 2.0.18 the import-clean option works on --import, > but not on --recv-keys. It is not annoying for me, but what is please > exactly the reason ? I don't think there is a particular reason and iirc we fixed recently for 2.x. Not sure whether we did it also for 2.x. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Sep 24 12:25:27 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Sep 2012 12:25:27 +0200 Subject: pinentry for Android questions In-Reply-To: <50592CA2.3090501@guardianproject.info> (Hans-Christoph Steiner's message of "Tue, 18 Sep 2012 22:23:30 -0400") References: <9333EDAB-36A0-4061-8430-E27EC6C9D566@guardianproject.info> <4F5A26D8.9000309@ruhr-uni-bochum.de> <1E4A9464-47B4-4D8C-BDC4-62A210F83F95@guardianproject.info> <4F5A4812.3090603@ruhr-uni-bochum.de> <4F5ACBFB.1010102@guardianproject.info> <4F5B5DA7.8060608@ruhr-uni-bochum.de> <50592CA2.3090501@guardianproject.info> Message-ID: <87pq5bbtuw.fsf@vigenere.g10code.de> On Wed, 19 Sep 2012 04:23, hans at guardianproject.info said: > I'm back on this and still not quite seeing how to do it. From what > I've seen, it seems that gpg-agent executes pinentry, then communicates > with it via stdin/stdout. This is not possible in Android because you Right. Pretty standard thing. > cannot directly launch a GUI program in Android from the terminal. What is the reason? It is kind of funny that the whole GnuPG system works nicely on Windows Mobile 6.x (the old one) but you can't make it work on a free software Linux Platform. > I have no idea how to do that, all of the existing pinentry programs > seem to work the exact same way. Any pointers? I would first investigate how to start a GUI application i the first place (without the Java crap). If you really can't find a solution the common workaround for such problems are daemon: Start a daemonized pinentry version and use a stub pinentry program which is called by gpg-agent and then communicates with the pinentry-daemon via whatever-mechanism you like. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dshaw at jabberwocky.com Mon Sep 24 17:50:49 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 24 Sep 2012 11:50:49 -0400 Subject: SOCKS4A/SOCKS5 proxy support? In-Reply-To: <87y5jzbuhh.fsf@vigenere.g10code.de> References: <505F9E8A.5000807@appelbaum.net> <87y5jzbuhh.fsf@vigenere.g10code.de> Message-ID: <9B6CB08E-523C-4EA1-8617-9D3EC2646586@jabberwocky.com> On Sep 24, 2012, at 6:11 AM, Werner Koch wrote: > On Mon, 24 Sep 2012 01:43, jacob at appelbaum.net said: > >> Are there any plans to add support to gpg for SOCKS5? Would such a thing >> be a welcome patch? > > Does Curl support SOCKS? Then GnuPG should benefit from it directy. > Well unless you are talking about Windows, where we don't build with > Curl support. If your curl is recent enough (7.21.7 and later), then you can set the proxy to something like "socks5://your-proxy-here.example.com" and it should do the right thing. (Except on Windows, like you said). David From jacob at appelbaum.net Mon Sep 24 21:18:45 2012 From: jacob at appelbaum.net (Jacob Appelbaum) Date: Mon, 24 Sep 2012 19:18:45 +0000 Subject: SOCKS4A/SOCKS5 proxy support? In-Reply-To: <87y5jzbuhh.fsf@vigenere.g10code.de> References: <505F9E8A.5000807@appelbaum.net> <87y5jzbuhh.fsf@vigenere.g10code.de> Message-ID: <5060B215.7000500@appelbaum.net> Werner Koch: > On Mon, 24 Sep 2012 01:43, jacob at appelbaum.net said: > >> Are there any plans to add support to gpg for SOCKS5? Would such a thing >> be a welcome patch? > > Does Curl support SOCKS? Then GnuPG should benefit from it directy. I think it does but only in more recent versions. > Well unless you are talking about Windows, where we don't build with > Curl support. How is proxy support handled on Windows? > > Patches are subject to the usual FSF copyright assignment problem. > If I wrote a patch, I'd do whatever rain dance was required of me to help the commons, etc. All the best, Jake From jacob at appelbaum.net Mon Sep 24 21:22:48 2012 From: jacob at appelbaum.net (Jacob Appelbaum) Date: Mon, 24 Sep 2012 19:22:48 +0000 Subject: SOCKS4A/SOCKS5 proxy support? In-Reply-To: <9B6CB08E-523C-4EA1-8617-9D3EC2646586@jabberwocky.com> References: <505F9E8A.5000807@appelbaum.net> <87y5jzbuhh.fsf@vigenere.g10code.de> <9B6CB08E-523C-4EA1-8617-9D3EC2646586@jabberwocky.com> Message-ID: <5060B308.8050809@appelbaum.net> David Shaw: > On Sep 24, 2012, at 6:11 AM, Werner Koch wrote: > >> On Mon, 24 Sep 2012 01:43, jacob at appelbaum.net said: >> >>> Are there any plans to add support to gpg for SOCKS5? Would such >>> a thing be a welcome patch? >> >> Does Curl support SOCKS? Then GnuPG should benefit from it >> directy. Well unless you are talking about Windows, where we don't >> build with Curl support. > > If your curl is recent enough (7.21.7 and later), then you can set > the proxy to something like "socks5://your-proxy-here.example.com" > and it should do the right thing. > That is great news. I guess we'd want a way to set the SOCKS proxy in GnuPG and then properly set the SOCKS argument in the curl library usage. If that was done, I guess we'd have SOCKS support on all platforms other than Windows - which I think is a reasonable start. Is there anything I should consider before getting started on a patch? All the best, Jake From dshaw at jabberwocky.com Mon Sep 24 21:31:11 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 24 Sep 2012 15:31:11 -0400 Subject: SOCKS4A/SOCKS5 proxy support? In-Reply-To: <5060B308.8050809@appelbaum.net> References: <505F9E8A.5000807@appelbaum.net> <87y5jzbuhh.fsf@vigenere.g10code.de> <9B6CB08E-523C-4EA1-8617-9D3EC2646586@jabberwocky.com> <5060B308.8050809@appelbaum.net> Message-ID: On Sep 24, 2012, at 3:22 PM, Jacob Appelbaum wrote: > David Shaw: >> On Sep 24, 2012, at 6:11 AM, Werner Koch wrote: >> >>> On Mon, 24 Sep 2012 01:43, jacob at appelbaum.net said: >>> >>>> Are there any plans to add support to gpg for SOCKS5? Would such >>>> a thing be a welcome patch? >>> >>> Does Curl support SOCKS? Then GnuPG should benefit from it >>> directy. Well unless you are talking about Windows, where we don't >>> build with Curl support. >> >> If your curl is recent enough (7.21.7 and later), then you can set >> the proxy to something like "socks5://your-proxy-here.example.com" >> and it should do the right thing. >> > > That is great news. > > I guess we'd want a way to set the SOCKS proxy in GnuPG and then > properly set the SOCKS argument in the curl library usage. If that was > done, I guess we'd have SOCKS support on all platforms other than > Windows - which I think is a reasonable start. > > Is there anything I should consider before getting started on a patch? You shouldn't need to patch anything. Try this in your gpg.conf file: keyserver-options http-proxy=socks5://your-proxy-here Or on the command line: gpg --keyserver-options http-proxy=socks5://your-proxy-here Or just set the "http_proxy" environment variable. David From dshaw at jabberwocky.com Mon Sep 24 22:58:50 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 24 Sep 2012 16:58:50 -0400 Subject: SOCKS4A/SOCKS5 proxy support? In-Reply-To: <5060C46F.4070902@appelbaum.net> References: <505F9E8A.5000807@appelbaum.net> <87y5jzbuhh.fsf@vigenere.g10code.de> <9B6CB08E-523C-4EA1-8617-9D3EC2646586@jabberwocky.com> <5060B308.8050809@appelbaum.net> <5060C46F.4070902@appelbaum.net> Message-ID: On Sep 24, 2012, at 4:37 PM, Jacob Appelbaum wrote: > David Shaw: >> On Sep 24, 2012, at 3:22 PM, Jacob Appelbaum wrote: >> >>> David Shaw: >>>> On Sep 24, 2012, at 6:11 AM, Werner Koch wrote: >>>> >>>>> On Mon, 24 Sep 2012 01:43, jacob at appelbaum.net said: >>>>> >>>>>> Are there any plans to add support to gpg for SOCKS5? Would such >>>>>> a thing be a welcome patch? >>>>> >>>>> Does Curl support SOCKS? Then GnuPG should benefit from it >>>>> directy. Well unless you are talking about Windows, where we don't >>>>> build with Curl support. >>>> >>>> If your curl is recent enough (7.21.7 and later), then you can set >>>> the proxy to something like "socks5://your-proxy-here.example.com" >>>> and it should do the right thing. >>>> >>> >>> That is great news. >>> >>> I guess we'd want a way to set the SOCKS proxy in GnuPG and then >>> properly set the SOCKS argument in the curl library usage. If that was >>> done, I guess we'd have SOCKS support on all platforms other than >>> Windows - which I think is a reasonable start. >>> >>> Is there anything I should consider before getting started on a patch? >> >> You shouldn't need to patch anything. Try this in your gpg.conf file: >> > > > I'd like to make sure that there is an option to specifically set a > SOCKS5 proxy and have things fail closed if it doesn't work as expected. > > >> keyserver-options http-proxy=socks5://your-proxy-here >> >> Or on the command line: >> >> gpg --keyserver-options http-proxy=socks5://your-proxy-here >> >> Or just set the "http_proxy" environment variable. >> > > I did try the above ( > https://trac.torproject.org/projects/tor/ticket/6940#comment:26 ) and > found that it wasn't working. The output is in that ticket. > > Looking at my gpg I see that Ubuntu's build doesn't link against curl (?): Correct, it doesn't. > It does appear that gpg2 links against libcurl-gnutls.so.4 but it > doesn't work as expected either: > > gpg2 --keyserver-options > http-proxy=socks5://127.0.0.1:9050,debug,verbose --search > jacob at appelbaum.net > gpg: searching for "jacob at appelbaum.net" from hkp server > pool.sks-keyservers.net > gpgkeys: curl version = libcurl/7.21.3 GnuTLS/2.8.6 zlib/1.2.3.4 libidn/1.18 It's linked against libcurl 7.21.3. The socks5:// URL type was added in 7.21.7. David From hans at guardianproject.info Mon Sep 24 23:35:00 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 24 Sep 2012 17:35:00 -0400 Subject: pinentry for Android questions In-Reply-To: <87pq5bbtuw.fsf@vigenere.g10code.de> References: <9333EDAB-36A0-4061-8430-E27EC6C9D566@guardianproject.info> <4F5A26D8.9000309@ruhr-uni-bochum.de> <1E4A9464-47B4-4D8C-BDC4-62A210F83F95@guardianproject.info> <4F5A4812.3090603@ruhr-uni-bochum.de> <4F5ACBFB.1010102@guardianproject.info> <4F5B5DA7.8060608@ruhr-uni-bochum.de> <50592CA2.3090501@guardianproject.info> <87pq5bbtuw.fsf@vigenere.g10code.de> Message-ID: <5060D204.30400@guardianproject.info> On 09/24/2012 06:25 AM, Werner Koch wrote: > On Wed, 19 Sep 2012 04:23, hans at guardianproject.info said: > >> I'm back on this and still not quite seeing how to do it. From what >> I've seen, it seems that gpg-agent executes pinentry, then communicates >> with it via stdin/stdout. This is not possible in Android because you > > Right. Pretty standard thing. > >> cannot directly launch a GUI program in Android from the terminal. > > What is the reason? It is kind of funny that the whole GnuPG system > works nicely on Windows Mobile 6.x (the old one) but you can't make it > work on a free software Linux Platform. >> I have no idea how to do that, all of the existing pinentry programs >> seem to work the exact same way. Any pointers? > > I would first investigate how to start a GUI application i the first > place (without the Java crap). If you really can't find a solution the > common workaround for such problems are daemon: Start a daemonized > pinentry version and use a stub pinentry program which is called by > gpg-agent and then communicates with the pinentry-daemon via > whatever-mechanism you like. Android is really quite a different operating system from GNU/Linux, *BSD, and even Windows. I know nothing about Windows Mobile, so I can't speak to that. Yes, there is a Linux kernel and a super minimal pseudo-UNIX environment, its really not UNIX and is missing lots of basic things, like command line programs launching GUIs. The only way you launch a GUI program in Android is to send a message, known as an Intent requesting a certain generic action or specific Activity. That message goes to 'system_server', which requests 'zygote' to fork off the process containing the right Activity. 'system_server' then waits for the new process to contact 'system_server' via IPC, then requests the right Activity from the process. We can send the Intent, but we can't control the starting of the process. So we could go with the idea Abel outlined, which sounds like what you are proposing. I just think that the ideal solution would be having gpg-agent launch the GUI Activity using "am start", then that GUI Activity could talk directly to the gpg-agent UNIX socket, and that would make the whole setup simpler. If that is not feasible, I'm OK with going with the 'pinentry' that talks with the GUI Activity via its own UNIX socket. .hc From jacob at appelbaum.net Mon Sep 24 22:37:03 2012 From: jacob at appelbaum.net (Jacob Appelbaum) Date: Mon, 24 Sep 2012 20:37:03 +0000 Subject: SOCKS4A/SOCKS5 proxy support? In-Reply-To: References: <505F9E8A.5000807@appelbaum.net> <87y5jzbuhh.fsf@vigenere.g10code.de> <9B6CB08E-523C-4EA1-8617-9D3EC2646586@jabberwocky.com> <5060B308.8050809@appelbaum.net> Message-ID: <5060C46F.4070902@appelbaum.net> David Shaw: > On Sep 24, 2012, at 3:22 PM, Jacob Appelbaum wrote: > >> David Shaw: >>> On Sep 24, 2012, at 6:11 AM, Werner Koch wrote: >>> >>>> On Mon, 24 Sep 2012 01:43, jacob at appelbaum.net said: >>>> >>>>> Are there any plans to add support to gpg for SOCKS5? Would such >>>>> a thing be a welcome patch? >>>> >>>> Does Curl support SOCKS? Then GnuPG should benefit from it >>>> directy. Well unless you are talking about Windows, where we don't >>>> build with Curl support. >>> >>> If your curl is recent enough (7.21.7 and later), then you can set >>> the proxy to something like "socks5://your-proxy-here.example.com" >>> and it should do the right thing. >>> >> >> That is great news. >> >> I guess we'd want a way to set the SOCKS proxy in GnuPG and then >> properly set the SOCKS argument in the curl library usage. If that was >> done, I guess we'd have SOCKS support on all platforms other than >> Windows - which I think is a reasonable start. >> >> Is there anything I should consider before getting started on a patch? > > You shouldn't need to patch anything. Try this in your gpg.conf file: > I'd like to make sure that there is an option to specifically set a SOCKS5 proxy and have things fail closed if it doesn't work as expected. > keyserver-options http-proxy=socks5://your-proxy-here > > Or on the command line: > > gpg --keyserver-options http-proxy=socks5://your-proxy-here > > Or just set the "http_proxy" environment variable. > I did try the above ( https://trac.torproject.org/projects/tor/ticket/6940#comment:26 ) and found that it wasn't working. The output is in that ticket. Looking at my gpg I see that Ubuntu's build doesn't link against curl (?): ldd /usr/bin/gpg linux-vdso.so.1 => (0x00007fff80391000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f33f4c6f000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f33f4a57000) libbz2.so.1.0 => /lib/libbz2.so.1.0 (0x00007f33f4846000) libreadline.so.6 => /lib/libreadline.so.6 (0x00007f33f4604000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f33f4400000) libusb-0.1.so.4 => /lib/libusb-0.1.so.4 (0x00007f33f41f6000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f33f3e61000) libncurses.so.5 => /lib/libncurses.so.5 (0x00007f33f3c1d000) /lib64/ld-linux-x86-64.so.2 (0x00007f33f4eb3000) I find this confusing as ltrace over gpg says something about "malloc(gpgkeys: curl version = GnuPG curl-shim" which clearly is from /usr/lib/gnupg/gpgkeys_hkp - That also appears to be without libcurl: /usr/lib/gnupg/gpgkeys_hkp --version gpgkeys_hkp (GnuPG) 1.4.11 Uses: GnuPG curl-shim ldd /usr/lib/gnupg/gpgkeys_hkp linux-vdso.so.1 => (0x00007fff511ff000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f1afa0b8000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1af9d23000) /lib64/ld-linux-x86-64.so.2 (0x00007f1afa2fc000) The same is true for gpgkeys_curl ldd gpgkeys_curl linux-vdso.so.1 => (0x00007fff277ff000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fe322b55000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe3227c0000) /lib64/ld-linux-x86-64.so.2 (0x00007fe322d99000) It does appear that gpg2 links against libcurl-gnutls.so.4 but it doesn't work as expected either: gpg2 --keyserver-options http-proxy=socks5://127.0.0.1:9050,debug,verbose --search jacob at appelbaum.net gpg: searching for "jacob at appelbaum.net" from hkp server pool.sks-keyservers.net gpgkeys: curl version = libcurl/7.21.3 GnuTLS/2.8.6 zlib/1.2.3.4 libidn/1.18 gpgkeys: search type is 0, and key is "jacob at appelbaum.net" * About to connect() to proxy 127.0.0.1 port 9050 (#0) * Trying 127.0.0.1... * connected * Connected to 127.0.0.1 (127.0.0.1) port 9050 (#0) > GET http://pool.sks-keyservers.net:11371/pks/lookup?op=index&options=mr&search=jacob%40appelbaum.net HTTP/1.1 Host: pool.sks-keyservers.net:11371 Accept: */* Proxy-Connection: Keep-Alive Pragma: no-cache Cache-Control: no-cache * HTTP 1.0, assume close after body < HTTP/1.0 501 Tor is not an HTTP Proxy < Content-Type: text/html; charset=iso-8859-1 < * Closing connection #0 gpg: key "jacob at appelbaum.net" not found on keyserver All the best, Jake From jacob at appelbaum.net Mon Sep 24 23:02:43 2012 From: jacob at appelbaum.net (Jacob Appelbaum) Date: Mon, 24 Sep 2012 21:02:43 +0000 Subject: SOCKS4A/SOCKS5 proxy support? In-Reply-To: References: <505F9E8A.5000807@appelbaum.net> <87y5jzbuhh.fsf@vigenere.g10code.de> <9B6CB08E-523C-4EA1-8617-9D3EC2646586@jabberwocky.com> <5060B308.8050809@appelbaum.net> Message-ID: <5060CA73.7070008@appelbaum.net> David Shaw: > On Sep 24, 2012, at 3:22 PM, Jacob Appelbaum wrote: > >> David Shaw: >>> On Sep 24, 2012, at 6:11 AM, Werner Koch wrote: >>> >>>> On Mon, 24 Sep 2012 01:43, jacob at appelbaum.net said: >>>> >>>>> Are there any plans to add support to gpg for SOCKS5? Would such >>>>> a thing be a welcome patch? >>>> >>>> Does Curl support SOCKS? Then GnuPG should benefit from it >>>> directy. Well unless you are talking about Windows, where we don't >>>> build with Curl support. >>> >>> If your curl is recent enough (7.21.7 and later), then you can set >>> the proxy to something like "socks5://your-proxy-here.example.com" >>> and it should do the right thing. >>> >> >> That is great news. >> >> I guess we'd want a way to set the SOCKS proxy in GnuPG and then >> properly set the SOCKS argument in the curl library usage. If that was >> done, I guess we'd have SOCKS support on all platforms other than >> Windows - which I think is a reasonable start. >> >> Is there anything I should consider before getting started on a patch? > > You shouldn't need to patch anything. Try this in your gpg.conf file: So as a pointer to others with a recent gpg version and linked against curl (with Debian or Ubuntu package gnupg-curl) - this should be safe for use with Tor: gpg --keyserver-options http-proxy=socks5-hostname://127.0.0.1:9050 --search jacob at appelbaum.net I haven't yet found a machine where it worked but in theory it should work and not leak DNS. I'd still think a patch to set --socks-proxy=127.0.0.1:9050 would be useful as we could ensure SOCKS is actually in use or able to be used at all. All the best, Jake From jacob at appelbaum.net Mon Sep 24 23:10:42 2012 From: jacob at appelbaum.net (Jacob Appelbaum) Date: Mon, 24 Sep 2012 21:10:42 +0000 Subject: SOCKS4A/SOCKS5 proxy support? In-Reply-To: References: <505F9E8A.5000807@appelbaum.net> <87y5jzbuhh.fsf@vigenere.g10code.de> <9B6CB08E-523C-4EA1-8617-9D3EC2646586@jabberwocky.com> <5060B308.8050809@appelbaum.net> <5060C46F.4070902@appelbaum.net> Message-ID: <5060CC52.6050708@appelbaum.net> David Shaw: > On Sep 24, 2012, at 4:37 PM, Jacob Appelbaum wrote: > >> David Shaw: >>> On Sep 24, 2012, at 3:22 PM, Jacob Appelbaum wrote: >>> >>>> David Shaw: >>>>> On Sep 24, 2012, at 6:11 AM, Werner Koch wrote: >>>>> >>>>>> On Mon, 24 Sep 2012 01:43, jacob at appelbaum.net said: >>>>>> >>>>>>> Are there any plans to add support to gpg for SOCKS5? Would such >>>>>>> a thing be a welcome patch? >>>>>> >>>>>> Does Curl support SOCKS? Then GnuPG should benefit from it >>>>>> directy. Well unless you are talking about Windows, where we don't >>>>>> build with Curl support. >>>>> >>>>> If your curl is recent enough (7.21.7 and later), then you can set >>>>> the proxy to something like "socks5://your-proxy-here.example.com" >>>>> and it should do the right thing. >>>>> >>>> >>>> That is great news. >>>> >>>> I guess we'd want a way to set the SOCKS proxy in GnuPG and then >>>> properly set the SOCKS argument in the curl library usage. If that was >>>> done, I guess we'd have SOCKS support on all platforms other than >>>> Windows - which I think is a reasonable start. >>>> >>>> Is there anything I should consider before getting started on a patch? >>> >>> You shouldn't need to patch anything. Try this in your gpg.conf file: >>> >> >> >> I'd like to make sure that there is an option to specifically set a >> SOCKS5 proxy and have things fail closed if it doesn't work as expected. >> >> >>> keyserver-options http-proxy=socks5://your-proxy-here >>> >>> Or on the command line: >>> >>> gpg --keyserver-options http-proxy=socks5://your-proxy-here >>> >>> Or just set the "http_proxy" environment variable. >>> >> >> I did try the above ( >> https://trac.torproject.org/projects/tor/ticket/6940#comment:26 ) and >> found that it wasn't working. The output is in that ticket. >> >> Looking at my gpg I see that Ubuntu's build doesn't link against curl (?): > > Correct, it doesn't. The gpg-curl package resolves this issue on Ubuntu/Debian systems. > >> It does appear that gpg2 links against libcurl-gnutls.so.4 but it >> doesn't work as expected either: >> >> gpg2 --keyserver-options >> http-proxy=socks5://127.0.0.1:9050,debug,verbose --search >> jacob at appelbaum.net >> gpg: searching for "jacob at appelbaum.net" from hkp server >> pool.sks-keyservers.net >> gpgkeys: curl version = libcurl/7.21.3 GnuTLS/2.8.6 zlib/1.2.3.4 libidn/1.18 > > It's linked against libcurl 7.21.3. The socks5:// URL type was added in 7.21.7. Sorry, my mistake. I see that and understand why it isn't working. :) All the best, Jake From hans at guardianproject.info Tue Sep 25 01:05:37 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 24 Sep 2012 19:05:37 -0400 Subject: SOCKS4A/SOCKS5 proxy support? In-Reply-To: <5060CC52.6050708@appelbaum.net> References: <505F9E8A.5000807@appelbaum.net> <87y5jzbuhh.fsf@vigenere.g10code.de> <9B6CB08E-523C-4EA1-8617-9D3EC2646586@jabberwocky.com> <5060B308.8050809@appelbaum.net> <5060C46F.4070902@appelbaum.net> <5060CC52.6050708@appelbaum.net> Message-ID: <5060E741.8080303@guardianproject.info> On 09/24/2012 05:10 PM, Jacob Appelbaum wrote: > David Shaw: >> On Sep 24, 2012, at 4:37 PM, Jacob Appelbaum wrote: >> >>> David Shaw: >>>> On Sep 24, 2012, at 3:22 PM, Jacob Appelbaum wrote: >>>> >>>>> David Shaw: >>>>>> On Sep 24, 2012, at 6:11 AM, Werner Koch wrote: >>>>>> >>>>>>> On Mon, 24 Sep 2012 01:43, jacob at appelbaum.net said: >>>>>>> >>>>>>>> Are there any plans to add support to gpg for SOCKS5? Would such >>>>>>>> a thing be a welcome patch? >>>>>>> >>>>>>> Does Curl support SOCKS? Then GnuPG should benefit from it >>>>>>> directy. Well unless you are talking about Windows, where we don't >>>>>>> build with Curl support. >>>>>> >>>>>> If your curl is recent enough (7.21.7 and later), then you can set >>>>>> the proxy to something like "socks5://your-proxy-here.example.com" >>>>>> and it should do the right thing. >>>>>> >>>>> >>>>> That is great news. >>>>> >>>>> I guess we'd want a way to set the SOCKS proxy in GnuPG and then >>>>> properly set the SOCKS argument in the curl library usage. If that was >>>>> done, I guess we'd have SOCKS support on all platforms other than >>>>> Windows - which I think is a reasonable start. >>>>> >>>>> Is there anything I should consider before getting started on a patch? >>>> >>>> You shouldn't need to patch anything. Try this in your gpg.conf file: >>>> >>> >>> >>> I'd like to make sure that there is an option to specifically set a >>> SOCKS5 proxy and have things fail closed if it doesn't work as expected. >>> >>> >>>> keyserver-options http-proxy=socks5://your-proxy-here >>>> >>>> Or on the command line: >>>> >>>> gpg --keyserver-options http-proxy=socks5://your-proxy-here >>>> >>>> Or just set the "http_proxy" environment variable. >>>> >>> >>> I did try the above ( >>> https://trac.torproject.org/projects/tor/ticket/6940#comment:26 ) and >>> found that it wasn't working. The output is in that ticket. >>> >>> Looking at my gpg I see that Ubuntu's build doesn't link against curl (?): >> >> Correct, it doesn't. > > The gpg-curl package resolves this issue on Ubuntu/Debian systems. > >> >>> It does appear that gpg2 links against libcurl-gnutls.so.4 but it >>> doesn't work as expected either: >>> >>> gpg2 --keyserver-options >>> http-proxy=socks5://127.0.0.1:9050,debug,verbose --search >>> jacob at appelbaum.net >>> gpg: searching for "jacob at appelbaum.net" from hkp server >>> pool.sks-keyservers.net >>> gpgkeys: curl version = libcurl/7.21.3 GnuTLS/2.8.6 zlib/1.2.3.4 libidn/1.18 >> >> It's linked against libcurl 7.21.3. The socks5:// URL type was added in 7.21.7. > > Sorry, my mistake. I see that and understand why it isn't working. :) FYI, the gnupg-for-android port already includes libcurl 7.23, so this support should be included already. .hc From jacob at appelbaum.net Tue Sep 25 01:45:27 2012 From: jacob at appelbaum.net (Jacob Appelbaum) Date: Mon, 24 Sep 2012 23:45:27 +0000 Subject: SOCKS4A/SOCKS5 proxy support? In-Reply-To: <5060E741.8080303@guardianproject.info> References: <505F9E8A.5000807@appelbaum.net> <87y5jzbuhh.fsf@vigenere.g10code.de> <9B6CB08E-523C-4EA1-8617-9D3EC2646586@jabberwocky.com> <5060B308.8050809@appelbaum.net> <5060C46F.4070902@appelbaum.net> <5060CC52.6050708@appelbaum.net> <5060E741.8080303@guardianproject.info> Message-ID: <5060F097.90609@appelbaum.net> Hans-Christoph Steiner: > FYI, the gnupg-for-android port already includes libcurl 7.23, so this > support should be included already. > I did some more testing and with a local HTTP proxy and I still see DNS SRV requests. I didn't build gpg with './configure --disable-dns-srv' though. I tried to tell it to stop looking things up with 'gpg --no-auto-key-locate' but that didn't seem to do the trick. The seemingly undocumented 'no-try-dns-srv' keyserver option did the trick: eg: gpg --keyserver-options no-try-dns-srv,http-proxy=http://127.0.0.1:8119,debug,verbose --search jacob at appelbaum.net I'm using packages for these tests. If you are building GnuPG and plan on using it with Tor over SOCKS or HTTP, I guess you'd want to cripple any chance of a stray DNS packet leaking out: ./configure \ --disable-dns-cert \ --disable-dns-pka \ --disable-dns-srv If you don't want to disable those at run time, I guess 'no-try-dns-srv' should also work. I checked and the table for Mac OS X and SOCKS proxy support is quite bleak: Mac OS X 10.8.x - curl 7.24.0 Mac OS X 10.7.4 - curl 7.21.4 Mac OS X 10.6 - curl 7.19.0 Mac OS X 10.5 - curl 7.16.2 Mac OS X 10.4 (intel) - curl 7.13.0 I think that means that other than on Mac OS X 10.8.x, gpg won't be able to use SOCKS at all. My version numbers might be a bit off as I had to compile that table from man pages (whee!) on Apple's developer site. If curl isn't used on Windows (?) and the win32 builds aren't supporting proxies, I guess the problem is the same. Does anyone have am idea about proxy support on Windows? Is there anything at all? The rest of the GNU/Linux and BSD operating systems will probably leak DNS depending on build options. The vanilla configure will leak DNS requests by default. In theory this is a good thing but in practice Tor users and other proxy users will want to use 'no-try-dns-srv' I think. As a side note - 'no-try-dns-srv' makes gpg go a lot faster - even over Tor! All the best, Jake From wk at gnupg.org Tue Sep 25 10:09:23 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 25 Sep 2012 10:09:23 +0200 Subject: SOCKS4A/SOCKS5 proxy support? In-Reply-To: <5060F097.90609@appelbaum.net> (Jacob Appelbaum's message of "Mon, 24 Sep 2012 23:45:27 +0000") References: <505F9E8A.5000807@appelbaum.net> <87y5jzbuhh.fsf@vigenere.g10code.de> <9B6CB08E-523C-4EA1-8617-9D3EC2646586@jabberwocky.com> <5060B308.8050809@appelbaum.net> <5060C46F.4070902@appelbaum.net> <5060CC52.6050708@appelbaum.net> <5060E741.8080303@guardianproject.info> <5060F097.90609@appelbaum.net> Message-ID: <87pq5aa5ho.fsf@vigenere.g10code.de> On Tue, 25 Sep 2012 01:45, jacob at appelbaum.net said: > If curl isn't used on Windows (?) and the win32 builds aren't supporting > proxies, I guess the problem is the same. Does anyone have am idea about > proxy support on Windows? Is there anything at all? Yes, we have proxy support. However we are using our own HTTP code. Need to look at it. Can you please open a bug for it? > The rest of the GNU/Linux and BSD operating systems will probably leak > DNS depending on build options. The vanilla configure will leak DNS > requests by default. In theory this is a good thing but in practice Tor > users and other proxy users will want to use 'no-try-dns-srv' I think. Given that a safe configuration is a bit complex, shouldn't we add a option to enable all these configuration settings? However it will take some time until all deployed gpg versions have been updated - thus it might make more sense to add this only to 2.1. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Sep 25 10:25:19 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 25 Sep 2012 10:25:19 +0200 Subject: pinentry for Android questions In-Reply-To: <5060D204.30400@guardianproject.info> (Hans-Christoph Steiner's message of "Mon, 24 Sep 2012 17:35:00 -0400") References: <9333EDAB-36A0-4061-8430-E27EC6C9D566@guardianproject.info> <4F5A26D8.9000309@ruhr-uni-bochum.de> <1E4A9464-47B4-4D8C-BDC4-62A210F83F95@guardianproject.info> <4F5A4812.3090603@ruhr-uni-bochum.de> <4F5ACBFB.1010102@guardianproject.info> <4F5B5DA7.8060608@ruhr-uni-bochum.de> <50592CA2.3090501@guardianproject.info> <87pq5bbtuw.fsf@vigenere.g10code.de> <5060D204.30400@guardianproject.info> Message-ID: <87lifya4r4.fsf@vigenere.g10code.de> On Mon, 24 Sep 2012 23:35, hans at guardianproject.info said: > then waits for the new process to contact 'system_server' via IPC, then > requests the right Activity from the process. We can send the Intent, > but we can't control the starting of the process. Okay, so a simple two way communication is not possible. > are proposing. I just think that the ideal solution would be having > gpg-agent launch the GUI Activity using "am start", then that GUI > Activity could talk directly to the gpg-agent UNIX socket, and that We use a simple stdin/stdout server for the pinentry because it reduces the complexity in gpg-agent. The pinentry can't use the ~/.gnupg/S.gpg-agent socket because that one is for the client's (gpg) communication with the agent. If we would use that socket also for pinentry communication, we would need to synchronize the actions of two clients (the regular client and the pinentry). That defeats the idea of having a simple and easy to audit communication with gpg-agent. Using an extra socket for pinentry would be possible but this also adds more complexity. Thus I am very in favor of having a wrapper pinentry to mediate between gpg-agent and an Android based pinentry. I hope there is no limit on the number of processes on Android like we have on WindowsCE. Adding such a daemonized version to the pinentry package and thus re-using some of the pinentry logic is no problem. We don't require any legal BS for pinentry. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Sep 25 16:13:16 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 25 Sep 2012 16:13:16 +0200 Subject: GPGME_DEBUG on Android, which makes env vars hard In-Reply-To: <50464131.2000608@guardianproject.info> (Hans-Christoph Steiner's message of "Tue, 04 Sep 2012 13:58:09 -0400") References: <504118FF.3080308@guardianproject.info> <50464131.2000608@guardianproject.info> Message-ID: <87fw668a2r.fsf@vigenere.g10code.de> On Tue, 4 Sep 2012 19:58, hans at guardianproject.info said: > Another idea would be for setting this from a conf file somewhere, but > I'm not sure if there is a gpgme conf file. I just pushed a new function to set debugging. -- Function: int gpgme_set_global_flag (const char *NAME, const char *VALUE) On some systems it is not easy to set environment variables and thus hard to use GPGME's internal trace facility for debugging. This function has been introduced as an alternative way to enable debugging. It is important to assure that only one thread accesses GPGME functions between a call to this function and after the return from the call to `gpgme_check_version'. To enable debugging, you need to call this function as early as possible -- even before `gpgme_check_version' -- with the string "debug" for NAME and VALUE identical to the value used with the environment variable `GPGME_DEBUG'. This function returns `0' on success. In contrast to other functions the non-zero return value on failure does not convey any error code. For setting "debug" the only possible error cause is an out of memory condition; which would exhibit itself later anyway. Thus the return value may be ignored. Thus your init code may look like this: void init_gpgme (void) { /* Initialize the locale environment. */ setlocale (LC_ALL, ""); if (debug_gpgme) gpgme_set_global_flag ("debug", "9:/tmp/gpgme.log"); gpgme_check_version (NULL); gpgme_set_locale (NULL, LC_CTYPE, setlocale (LC_CTYPE, NULL)); #ifdef LC_MESSAGES gpgme_set_locale (NULL, LC_MESSAGES, setlocale (LC_MESSAGES, NULL)); #endif } Does this make sense? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Sep 25 17:46:21 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 25 Sep 2012 17:46:21 +0200 Subject: [PATCH] gpgme-tool: use the default handlers for INPUT and OUTPUT. In-Reply-To: <20120914140818.GB16987@odin.tremily.us> (W. Trevor King's message of "Fri, 14 Sep 2012 10:08:18 -0400") References: <20120914140818.GB16987@odin.tremily.us> Message-ID: <878vby85rm.fsf@vigenere.g10code.de> On Fri, 14 Sep 2012 16:08, wking at tremily.us said: > With the current gpgme-tool, this doesn't work, because the input and > output file descriptors get stored in server->input_fd where they are > never heard from again. You are right, there is a bug. We should not use assuan_get_input_fd but get it from SERVER_FD. > With this patch, we use the default handlers, which store the file > descriptors where they will be used for the cryptographic operations. Removing the handlers is a bad idea - your code will work but all other stuff will break: Using a filename as well as passing an encoding. There is a reason whey we have the input and output handlers. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Sep 25 18:06:54 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 25 Sep 2012 18:06:54 +0200 Subject: fleshing out the XML result of gpgme-tool's KEYLIST command In-Reply-To: <20120920171317.GG22536@odin.tremily.us> (W. Trevor King's message of "Thu, 20 Sep 2012 13:13:18 -0400") References: <20120920171317.GG22536@odin.tremily.us> Message-ID: <874nmm84td.fsf@vigenere.g10code.de> On Thu, 20 Sep 2012 19:13, wking at tremily.us said: > The current keylist XML of gpgme-tool is not very useful: It depends on what you expect. After all gpgme-tool is a debugging tool to present the GPGME API using an Assuan interface. > C: KEYLIST 2F73DE2E > S: D key:B2EDBE0E771A4B8708DD16A7511AEDA64332B6E3%0A > S: OK Here you get the output of the keylist operation. > C: RESULT 2F73DE2E > S: D %0A\x00 > S: D %0A\x00 > S: D %0A > S: D %0A > S: D %0A > S: D %0A\x00 > S: OK > C: BYE > S: OK closing connection > disconnecting and here the result values of the last gpgme operation, which in that case was a gpgme_op_keylist_next. The result values are a kind of extended return code. Don't mix them up with the output of a function. The result object for the keylist operation is: struct _gpgme_op_keylist_result { unsigned int truncated : 1; /* Internal to GPGME, do not use. */ unsigned int _unused : 31; }; Thus I can't see what is missing from the result value. > I'd like the result to include all the information about the requested > keys (although it doesn't need to recurse through subkeys). I could Okay, that is changing the output format. Makes sense. In fact the code remarks that more work is needed. char buf[100]; /* FIXME: More data. */ snprintf (buf, sizeof (buf), "key:%s\n", key->subkeys->fpr); /* Write data and flush so that we see one D line for each key. This does not change the semantics but is easier to read by organic eyes. */ I don't know how you want to format the output, it might resemble what "gpg --with-colons --list-keys" does or some XML or SXML format. > 1. My INPUT/OUTPUT patch has been languishing for five months. It does not fix the bug you are seeing. > 2. Deciding on and XML representation for keys may require a lot of > bike-shed-level decisions. Keep me out of this ;-). > So perhaps it would be better for me to wait and let someone closer to > the core handle this? I could also let this sit, and bring it up > again in six months when people might have more time? Go ahead. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From abel at guardianproject.info Tue Sep 25 20:09:19 2012 From: abel at guardianproject.info (Abel Luck) Date: Tue, 25 Sep 2012 18:09:19 +0000 Subject: SOCKS4A/SOCKS5 proxy support? In-Reply-To: <5060F097.90609@appelbaum.net> References: <505F9E8A.5000807@appelbaum.net> <87y5jzbuhh.fsf@vigenere.g10code.de> <9B6CB08E-523C-4EA1-8617-9D3EC2646586@jabberwocky.com> <5060B308.8050809@appelbaum.net> <5060C46F.4070902@appelbaum.net> <5060CC52.6050708@appelbaum.net> <5060E741.8080303@guardianproject.info> <5060F097.90609@appelbaum.net> Message-ID: <5061F34F.1030701@guardianproject.info> Jacob Appelbaum: > As a side note - 'no-try-dns-srv' makes gpg go a lot faster - even over Tor! Jumped the gun, this is an option to the keyserver so the correct line is: keyserver-options no-try-dns-srv,http-proxy=http://127.0.0.1:8118 (I'm running a local privoxy instance on 8118) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From abel at guardianproject.info Tue Sep 25 20:01:16 2012 From: abel at guardianproject.info (Abel Luck) Date: Tue, 25 Sep 2012 18:01:16 +0000 Subject: SOCKS4A/SOCKS5 proxy support? In-Reply-To: <5060F097.90609@appelbaum.net> References: <505F9E8A.5000807@appelbaum.net> <87y5jzbuhh.fsf@vigenere.g10code.de> <9B6CB08E-523C-4EA1-8617-9D3EC2646586@jabberwocky.com> <5060B308.8050809@appelbaum.net> <5060C46F.4070902@appelbaum.net> <5060CC52.6050708@appelbaum.net> <5060E741.8080303@guardianproject.info> <5060F097.90609@appelbaum.net> Message-ID: <5061F16C.6020707@guardianproject.info> Jacob Appelbaum: > As a side note - 'no-try-dns-srv' makes gpg go a lot faster - even over Tor! I popped 'no-try-dns-srv' in gpg.conf, and it looks like this option doesn't exist in my version (debian testing) :-( In which versions does it exist? $ gpg2 --version gpg (GnuPG) 2.0.19 ~abel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From wking at tremily.us Tue Sep 25 20:33:37 2012 From: wking at tremily.us (W. Trevor King) Date: Tue, 25 Sep 2012 14:33:37 -0400 Subject: [PATCH] gpgme-tool: use the default handlers for INPUT and OUTPUT. In-Reply-To: <878vby85rm.fsf@vigenere.g10code.de> References: <20120914140818.GB16987@odin.tremily.us> <878vby85rm.fsf@vigenere.g10code.de> Message-ID: <20120925183337.GA2616@odin.tremily.us> On Tue, Sep 25, 2012 at 05:46:21PM +0200, Werner Koch wrote: > On Fri, 14 Sep 2012 16:08, wking at tremily.us said: > > With this patch, we use the default handlers, which store the file > > descriptors where they will be used for the cryptographic operations. > > Removing the handlers is a bad idea - your code will work but all other > stuff will break: Using a filename as well as passing an encoding. > There is a reason whey we have the input and output handlers. I'm not removing the handlers, I'm removing the override and using the default libassuan handlers (`std_handler_input` and `std_handler_output` in `src/assuan-handler.c`). The default handlers should already do the right thing. If we need filename/encoding handlers, can we move that over to libassuan? Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From wking at tremily.us Tue Sep 25 20:43:48 2012 From: wking at tremily.us (W. Trevor King) Date: Tue, 25 Sep 2012 14:43:48 -0400 Subject: fleshing out the XML result of gpgme-tool's KEYLIST command In-Reply-To: <874nmm84td.fsf@vigenere.g10code.de> References: <20120920171317.GG22536@odin.tremily.us> <874nmm84td.fsf@vigenere.g10code.de> Message-ID: <20120925184348.GB2616@odin.tremily.us> On Tue, Sep 25, 2012 at 06:06:54PM +0200, Werner Koch wrote: > On Thu, 20 Sep 2012 19:13, wking at tremily.us said: > > [snip client/server exchange] > > and here the result values of the last gpgme operation, which in that > case was a gpgme_op_keylist_next. The result values are a kind of > extended return code. Don't mix them up with the output of a function. Ok, but? > > I'd like the result to include all the information about the requested > > keys (although it doesn't need to recurse through subkeys). I could > > Okay, that is changing the output format. Makes sense. In fact the > code remarks that more work is needed. ?should I redesign the output of RESULT or KEYLIST? Perhaps the problem here is that gpgme-tool bundles a number of GPGME commands into its KEYLIST command, and RESULT gives more information about the last constituent command instead of giving more information about the whole bundle. > I don't know how you want to format the output, it might resemble what > "gpg --with-colons --list-keys" does or some XML or SXML format. > > 2. Deciding on and XML representation for keys may require a lot of > > bike-shed-level decisions. > > Keep me out of this ;-). > > > So perhaps it would be better for me to wait and let someone closer to > > the core handle this? I could also let this sit, and bring it up > > again in six months when people might have more time? > > Go ahead. Will do. I just didn't want to spend a bunch of time on it and then hear that I'd done it all wrong ;). I'll post back once I've come up with a draft output format. Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Sep 26 09:01:31 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Sep 2012 09:01:31 +0200 Subject: [PATCH] gpgme-tool: use the default handlers for INPUT and OUTPUT. In-Reply-To: <20120925183337.GA2616@odin.tremily.us> (W. Trevor King's message of "Tue, 25 Sep 2012 14:33:37 -0400") References: <20120914140818.GB16987@odin.tremily.us> <878vby85rm.fsf@vigenere.g10code.de> <20120925183337.GA2616@odin.tremily.us> Message-ID: <87haql6zec.fsf@vigenere.g10code.de> On Tue, 25 Sep 2012 20:33, wking at tremily.us said: > `std_handler_output` in `src/assuan-handler.c`). The default handlers > should already do the right thing. If we need filename/encoding > handlers, can we move that over to libassuan? No we can't because that is application specific. And weel, the realy fix is much easier. Let me see ... Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Sep 26 09:39:45 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Sep 2012 09:39:45 +0200 Subject: [PATCH] gpgme-tool: use the default handlers for INPUT and OUTPUT. In-Reply-To: <20120925183337.GA2616@odin.tremily.us> (W. Trevor King's message of "Tue, 25 Sep 2012 14:33:37 -0400") References: <20120914140818.GB16987@odin.tremily.us> <878vby85rm.fsf@vigenere.g10code.de> <20120925183337.GA2616@odin.tremily.us> Message-ID: <87d3196xmm.fsf@vigenere.g10code.de> Hi, here is a patch which should solve the bug. I did only a quick tests, though. Salam-Shalom, Werner >From 193eb62538b9413e0dfbd04c075f871d5aa9130b Mon Sep 17 00:00:00 2001 From: Werner Koch Date: Wed, 26 Sep 2012 09:37:22 +0200 Subject: [PATCH] gpgme-tool: Fix handling of file descriptors * src/gpgme-tool.c (server_reset_fds): Use close/CloseHandle instead of the assuan close functions. (_cmd_decrypt_verify, _cmd_sign_encrypt, cmd_verify, cmd_import) (cmd_export, cmd_genkey, cmd_getauditlog): Use SERVER object instead of assuan_get_*_fd functions. -- Although we used our own handlers for INPUT and OUTPUT, we still used assuan_get_input_fd, assuan_get_output_fd and their close functions. That clearly can't work because libassuan does not have any values for them. --- src/gpgme-tool.c | 51 +++++++++++++++++++++++++++++++++++---------------- 1 files changed, 35 insertions(+), 16 deletions(-) diff --git a/src/gpgme-tool.c b/src/gpgme-tool.c index 75b7c9e..3a02065 100644 --- a/src/gpgme-tool.c +++ b/src/gpgme-tool.c @@ -1900,7 +1900,10 @@ server_write_data (void *hook, const void *buf, size_t len) } - +/* Wrapper around assuan_command_parse_fd to also handle a + "file=FILENAME" argument. On success either a filename is returned + at FILENAME or a file descriptor at RFD; the other one is set to + NULL respective ASSUAN_INVALID_FD. */ static gpg_error_t server_parse_fd (assuan_context_t ctx, char *line, assuan_fd_t *rfd, char **filename) @@ -1974,8 +1977,24 @@ server_reset_fds (struct server *server) /* assuan closes the input and output FDs for us when doing a RESET, but we use this same function after commands, so repeat it here. */ - assuan_close_input_fd (server->assuan_ctx); - assuan_close_output_fd (server->assuan_ctx); + if (server->input_fd != ASSUAN_INVALID_FD) + { +#if HAVE_W32_SYSTEM + CloseHandle (server->input_fd); +#else + close (server->input_fd); +#endif + server->input_fd = ASSUAN_INVALID_FD; + } + if (server->output_fd != ASSUAN_INVALID_FD) + { +#if HAVE_W32_SYSTEM + CloseHandle (server->output_fd); +#else + close (server->output_fd); +#endif + server->output_fd = ASSUAN_INVALID_FD; + } if (server->message_fd != ASSUAN_INVALID_FD) { /* FIXME: Assuan should provide a close function. */ @@ -2331,11 +2350,11 @@ _cmd_decrypt_verify (assuan_context_t ctx, char *line, int verify) gpgme_data_t inp_data; gpgme_data_t out_data; - inp_fd = assuan_get_input_fd (ctx); + inp_fd = server->input_fd; inp_fn = server->input_filename; if (inp_fd == ASSUAN_INVALID_FD && !inp_fn) return GPG_ERR_ASS_NO_INPUT; - out_fd = assuan_get_output_fd (ctx); + out_fd = server->output_fd; out_fn = server->output_filename; if (out_fd == ASSUAN_INVALID_FD && !out_fn) return GPG_ERR_ASS_NO_OUTPUT; @@ -2411,9 +2430,9 @@ _cmd_sign_encrypt (assuan_context_t ctx, char *line, int sign) if (strstr (line, "--expect-sign")) flags |= GPGME_ENCRYPT_EXPECT_SIGN; - inp_fd = assuan_get_input_fd (ctx); + inp_fd = server->input_fd; inp_fn = server->input_filename; - out_fd = assuan_get_output_fd (ctx); + out_fd = server->output_fd; out_fn = server->output_filename; if (inp_fd != ASSUAN_INVALID_FD || inp_fn) { @@ -2502,11 +2521,11 @@ cmd_sign (assuan_context_t ctx, char *line) if (strstr (line, "--detach")) mode = GPGME_SIG_MODE_DETACH; - inp_fd = assuan_get_input_fd (ctx); + inp_fd = server->input_fd; inp_fn = server->input_filename; if (inp_fd == ASSUAN_INVALID_FD && !inp_fn) return GPG_ERR_ASS_NO_INPUT; - out_fd = assuan_get_output_fd (ctx); + out_fd = server->output_fd; out_fn = server->output_filename; if (out_fd == ASSUAN_INVALID_FD && !out_fn) return GPG_ERR_ASS_NO_OUTPUT; @@ -2555,13 +2574,13 @@ cmd_verify (assuan_context_t ctx, char *line) gpgme_data_t msg_data = NULL; gpgme_data_t out_data = NULL; - inp_fd = assuan_get_input_fd (ctx); + inp_fd = server->input_fd; inp_fn = server->input_filename; if (inp_fd == ASSUAN_INVALID_FD && !inp_fn) return GPG_ERR_ASS_NO_INPUT; msg_fd = server->message_fd; msg_fn = server->message_filename; - out_fd = assuan_get_output_fd (ctx); + out_fd = server->output_fd; out_fn = server->output_filename; err = server_data_obj (inp_fd, inp_fn, 0, server->input_enc, &inp_data, @@ -2628,7 +2647,7 @@ cmd_import (assuan_context_t ctx, char *line) char *inp_fn; gpgme_data_t inp_data; - inp_fd = assuan_get_input_fd (ctx); + inp_fd = server->input_fd; inp_fn = server->input_filename; if (inp_fd == ASSUAN_INVALID_FD && !inp_fn) return GPG_ERR_ASS_NO_INPUT; @@ -2664,7 +2683,7 @@ cmd_export (assuan_context_t ctx, char *line) gpgme_export_mode_t mode = 0; const char *pattern[2]; - out_fd = assuan_get_output_fd (ctx); + out_fd = server->output_fd; out_fn = server->output_filename; if (out_fd == ASSUAN_INVALID_FD && !out_fn) return GPG_ERR_ASS_NO_OUTPUT; @@ -2724,11 +2743,11 @@ cmd_genkey (assuan_context_t ctx, char *line) gpgme_data_t parms_data = NULL; const char *parms; - inp_fd = assuan_get_input_fd (ctx); + inp_fd = server->input_fd; inp_fn = server->input_filename; if (inp_fd == ASSUAN_INVALID_FD && !inp_fn) return GPG_ERR_ASS_NO_INPUT; - out_fd = assuan_get_output_fd (ctx); + out_fd = server->output_fd; out_fn = server->output_filename; err = server_data_obj (inp_fd, inp_fn, 0, server->input_enc, &inp_data, @@ -2899,7 +2918,7 @@ cmd_getauditlog (assuan_context_t ctx, char *line) gpgme_data_t out_data; unsigned int flags = 0; - out_fd = assuan_get_output_fd (ctx); + out_fd = server->output_fd; out_fn = server->output_filename; if (out_fd == ASSUAN_INVALID_FD && !out_fn) return GPG_ERR_ASS_NO_OUTPUT; -- 1.7.7.1 -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Sep 26 09:43:54 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Sep 2012 09:43:54 +0200 Subject: fleshing out the XML result of gpgme-tool's KEYLIST command In-Reply-To: <20120925184348.GB2616@odin.tremily.us> (W. Trevor King's message of "Tue, 25 Sep 2012 14:43:48 -0400") References: <20120920171317.GG22536@odin.tremily.us> <874nmm84td.fsf@vigenere.g10code.de> <20120925184348.GB2616@odin.tremily.us> Message-ID: <878vbx6xfp.fsf@vigenere.g10code.de> On Tue, 25 Sep 2012 20:43, wking at tremily.us said: > ?should I redesign the output of RESULT or KEYLIST? Perhaps the > problem here is that gpgme-tool bundles a number of GPGME commands > into its KEYLIST command, and RESULT gives more information about the > last constituent command instead of giving more information about the > whole bundle. RESULT returns what the gpgme API knows about the operation. If you want to more information, like number of listed keys and such, feel free to do so. It is probably useful to have separate container objects for data returned by GPGME's result data structure and statistics you gathered while running the gpgme_op_keylist loop. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Sep 26 09:59:38 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Sep 2012 09:59:38 +0200 Subject: gpgme_data_seek with SEEK_END on memory-based data fails In-Reply-To: <5032BD12.4080300@gmail.com> (Leo Gaspard's message of "Tue, 21 Aug 2012 00:41:22 +0200") References: <501434CA.3090208@gmail.com> <501447BF.1070005@ruhr-uni-bochum.de> <50145736.3040109@gmail.com> <87lii29a5o.fsf@vigenere.g10code.de> <50158011.1080201@gmail.com> <87d33d8vtf.fsf@vigenere.g10code.de> <50166515.4020701@gmail.com> <87y5m16wng.fsf@vigenere.g10code.de> <50291819.30601@gmail.com> <87txw6k5x0.fsf@vigenere.g10code.de> <502E6A93.3010702@gmail.com> <5032BD12.4080300@gmail.com> Message-ID: <874nml6wph.fsf@vigenere.g10code.de> On Tue, 21 Aug 2012 00:41, ekleog at gmail.com said: > Yes. But concentrating the charge of all "my" users on a single server isn't > very good, and at my house round-robin DNS such as keys.gnupg.net have a really > long response time, while e.g. pgp.mit.edu is really fast. The problem here is that we have the external keyserver helpers which are stateless. They need to do the DNS queries again and again. With 2.1 this will go a way because the dirmngr takes care of keyserver access and is able to maintain a list of responsive keyservers from a round-robin address. > We already have GPGME_KEYLIST_MODE_EXTERN, which specifies from where to look > for the keys. This could also be considered as a GnuPG implementation detail. No where to look for the keys but to do an external lookup. External lookups have different properties: They may take long, they may return inconsistent results over time, and they have privacy implications. The initial reason for having such a flag is for X.509 LDAP lookups We try to GPGME's API protocol neutral: One API for all protocols. Keyservers are very OpenPGP specific. > But setting the keyserver is almost as useful : it allows to use a local > keyserver, or to use some keyserver not synchronizing with the others > (keyserver.pgp.net ?), etc. Now, why to you want to change it with every operation? I still consider it a configuration option and not a property of a concrete operation. > As a last statement, I believe (but that's only my humble opinion) that GPGME > should offer as much options as GPG does, so that one doesn't have to hesitate > between parsing GPG's output (developper-time-consuming, error-prone), GPG has way too many options. GPGME allows to access a subset of the configuration options using its configuration API. If there is a useful runtime option, we can consider to add it to GPGME. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wking at tremily.us Thu Sep 27 01:26:00 2012 From: wking at tremily.us (W. Trevor King) Date: Wed, 26 Sep 2012 19:26:00 -0400 Subject: [PATCH] gpgme-tool: Initialize invalid input_fd and output_fd In-Reply-To: <87d3196xmm.fsf@vigenere.g10code.de> <87haql6zec.fsf@vigenere.g10code.de> Message-ID: <20120926232600.GC3956@odin.tremily.us> * src/gpgme-tool.c (gpgme_server): Initialize input_fd and output_fd to ASSUAN_INVALID_FD. Otherwise input and output may both try to open file descriptor 0. Signed-off-by: W. Trevor King --- On Wed, Sep 26, 2012 at 09:01:31AM +0200, Werner Koch wrote: > On Tue, 25 Sep 2012 20:33, wking at tremily.us said: > > `std_handler_output` in `src/assuan-handler.c`). The default handlers > > should already do the right thing. If we need filename/encoding > > handlers, can we move that over to libassuan? > > No we can't because that is application specific. Wanting to avoid file descriptors and use filenames is application specific? Ahh, I see the (undocumented?) encoding options *are* GPGME-specific. On Wed, Sep 26, 2012 at 09:39:45AM +0200, Werner Koch wrote: > here is a patch which should solve the bug. I checked this with pgp-mime and it almost works for me. I'm submitting this supplemental patch, after which pgp-mime passes all its unit tests again. src/gpgme-tool.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/gpgme-tool.c b/src/gpgme-tool.c index 3a02065..19dedb6 100644 --- a/src/gpgme-tool.c +++ b/src/gpgme-tool.c @@ -3121,6 +3121,8 @@ gpgme_server (gpgme_tool_t gt) static const char hello[] = ("GPGME-Tool " VERSION " ready"); memset (&server, 0, sizeof (server)); + server.input_fd = ASSUAN_INVALID_FD; + server.output_fd = ASSUAN_INVALID_FD; server.message_fd = ASSUAN_INVALID_FD; server.input_enc = GPGME_DATA_ENCODING_NONE; server.output_enc = GPGME_DATA_ENCODING_NONE; -- 1.7.8.6 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From wking at tremily.us Thu Sep 27 03:43:53 2012 From: wking at tremily.us (W. Trevor King) Date: Wed, 26 Sep 2012 21:43:53 -0400 Subject: [PATCH] gpgme-tool: Return more detailed XML from KEYLIST In-Reply-To: <878vbx6xfp.fsf@vigenere.g10code.de> References: <20120920171317.GG22536@odin.tremily.us> <874nmm84td.fsf@vigenere.g10code.de> <20120925184348.GB2616@odin.tremily.us> <878vbx6xfp.fsf@vigenere.g10code.de> Message-ID: <20120927014353.GA8797@odin.tremily.us> src/gpgme-tool.c (cmd_keylist): Convert output from a list of "key:" lines to more detailed XML. There's still missing data under subkeys and uids. (xml_preamble1, xml_preamble2, xml_end): Make global--instead of local to gt_result--so other functions can use them too. (result_add_protocol, result_add_validity): New functions for generating XML from GPGME types. (result_add_string): Treat NULL strings as "", to avoid having to check each value before calling this function. (result_xml_tag_data): Make 'data' a 'const char' so we can use the value returned by gpgme_get_protocol_name directly. This makes the fact that result_xml_tag_data does not alter the input string explicit. Signed-off-by: W. Trevor King --- Here's a first pass at returning most of the gpgme_key_t data from the KEYLIST call. On Wed, Sep 26, 2012 at 09:43:54AM +0200, Werner Koch wrote: > On Tue, 25 Sep 2012 20:43, wking at tremily.us said: > > > ?should I redesign the output of RESULT or KEYLIST? Perhaps the > > problem here is that gpgme-tool bundles a number of GPGME commands > > into its KEYLIST command, and RESULT gives more information about the > > last constituent command instead of giving more information about the > > whole bundle. > > RESULT returns what the gpgme API knows about the operation. If you want > to more information, like number of listed keys and such, feel free to > do so. It is probably useful to have separate container objects for > data returned by GPGME's result data structure and statistics you > gathered while running the gpgme_op_keylist loop. Since the gpgme API doesn't know about the individual keys in the gpgme_op_keylist loop, I'm putting the extra information into the KEYLIST command itself. Here's a first pass at that, which increases the number of output lines by a factor of ~50. Does this look like a useful direction (in which case I can fill in the subkeys and uids stubs), or would you like me to handle this in a different manner entirely? src/gpgme-tool.c | 134 ++++++++++++++++++++++++++++++++++++++++++++++++------ 1 files changed, 120 insertions(+), 14 deletions(-) diff --git a/src/gpgme-tool.c b/src/gpgme-tool.c index 19dedb6..23122e8 100644 --- a/src/gpgme-tool.c +++ b/src/gpgme-tool.c @@ -565,6 +565,12 @@ skip_options (char *line) typedef gpg_error_t (*result_xml_write_cb_t) (void *hook, const void *buf, size_t len); +static char xml_preamble1[] = "\n"; +static const char xml_preamble2[] = "\n"; +static const char xml_end[] = "\n"; + + struct result_xml_state { int indent; @@ -653,7 +659,7 @@ result_xml_tag_start (struct result_xml_state *state, char *name, ...) gpg_error_t -result_xml_tag_data (struct result_xml_state *state, char *data) +result_xml_tag_data (struct result_xml_state *state, const char *data) { result_xml_write_cb_t cb = state->cb; void *hook = state->hook; @@ -813,6 +819,60 @@ result_add_sig_mode (struct result_xml_state *state, char *name, gpg_error_t +result_add_protocol (struct result_xml_state *state, char *name, + gpgme_protocol_t protocol) +{ + const char *str; + char code[20]; + + snprintf (code, sizeof (code) - 1, "%i", protocol); + str = gpgme_get_protocol_name(protocol); + if (!str) + str = "invalid"; + result_xml_tag_start (state, name, "value", code, NULL); + result_xml_tag_data (state, str); + result_xml_tag_end (state); + return 0; +} + + +gpg_error_t +result_add_validity (struct result_xml_state *state, char *name, + gpgme_validity_t validity) +{ + const char *str; + char code[20]; + + snprintf (code, sizeof (code) - 1, "%i", validity); + switch (validity) + { + case GPGME_VALIDITY_UNDEFINED: + str ="undefined"; + break; + case GPGME_VALIDITY_NEVER: + str ="never"; + break; + case GPGME_VALIDITY_MARGINAL: + str ="marginal"; + break; + case GPGME_VALIDITY_FULL: + str ="full"; + break; + case GPGME_VALIDITY_ULTIMATE: + str ="ultimate"; + break; + default: + str ="unknown"; + } + + result_xml_tag_start (state, name, "value", code, NULL); + result_xml_tag_data (state, str); + result_xml_tag_end (state); + return 0; +} + + +gpg_error_t result_add_value (struct result_xml_state *state, char *name, unsigned int val) { @@ -829,6 +889,8 @@ gpg_error_t result_add_string (struct result_xml_state *state, char *name, char *str) { + if (!str) + str = ""; result_xml_tag_start (state, name, NULL); result_xml_tag_data (state, str); result_xml_tag_end (state); @@ -1820,10 +1882,6 @@ gt_passwd (gpgme_tool_t gt, char *fpr) gpg_error_t gt_result (gpgme_tool_t gt, unsigned int flags) { - static const char xml_preamble1[] = "\n"; - static const char xml_preamble2[] = "\n"; - static const char xml_end[] = "\n"; int indent = 2; gt_write_data (gt, xml_preamble1, sizeof (xml_preamble1)); @@ -2840,9 +2898,11 @@ cmd_keylist (assuan_context_t ctx, char *line) { #define MAX_CMD_KEYLIST_PATTERN 20 struct server *server = assuan_get_pointer (ctx); + gpgme_tool_t gt = server->gt; + struct result_xml_state state; gpg_error_t err; int secret_only = 0; - int idx; + int idx, indent=2; const char *pattern[MAX_CMD_KEYLIST_PATTERN+1]; const char optstr[] = "--secret-only"; char *p; @@ -2872,10 +2932,19 @@ cmd_keylist (assuan_context_t ctx, char *line) } pattern[idx] = NULL; + gt_write_data (gt, xml_preamble1, sizeof (xml_preamble1)); + gt_write_data (gt, NULL, 0); + gt_write_data (gt, xml_preamble2, sizeof (xml_preamble2)); + gt_write_data (gt, NULL, 0); + result_init (&state, indent, (result_xml_write_cb_t) gt_write_data, gt); + result_xml_tag_start (&state, "keylist", NULL); + err = gt_keylist_start (server->gt, pattern, secret_only); while (! err) { gpgme_key_t key; + gpgme_subkey_t subkey; + gpgme_user_id_t uid; err = gt_keylist_next (server->gt, &key); if (gpg_err_code (err) == GPG_ERR_EOF) @@ -2885,18 +2954,55 @@ cmd_keylist (assuan_context_t ctx, char *line) } else if (! err) { - char buf[100]; - /* FIXME: More data. */ - snprintf (buf, sizeof (buf), "key:%s\n", key->subkeys->fpr); - /* Write data and flush so that we see one D line for each - key. This does not change the semantics but is easier to - read by organic eyes. */ - if (!assuan_send_data (ctx, buf, strlen (buf))) - assuan_send_data (ctx, NULL, 0); + result_xml_tag_start (&state, "key", NULL); + result_add_value (&state, "revoked", key->revoked); + result_add_value (&state, "expired", key->expired); + result_add_value (&state, "disabled", key->disabled); + result_add_value (&state, "invalid", key->invalid); + result_add_value (&state, "can-encrypt", key->can_encrypt); + result_add_value (&state, "can-sign", key->can_sign); + result_add_value (&state, "can-certify", key->can_certify); + result_add_value (&state, "can-authenticate", key->can_authenticate); + result_add_value (&state, "is-qualified", key->is_qualified); + result_add_value (&state, "secret", key->secret); + result_add_protocol (&state, "protocol", key->protocol); + result_xml_tag_start (&state, "issuer", NULL); + result_add_string (&state, "serial", key->issuer_serial); + result_add_string (&state, "name", key->issuer_name); + result_xml_tag_end (&state); /* issuer */ + result_add_string (&state, "chain_id", key->chain_id); + result_add_validity (&state, "owner-trust", key->owner_trust); + result_xml_tag_start (&state, "subkeys", NULL); + subkey = key->subkeys; + while (subkey) { + result_xml_tag_start (&state, "subkey", NULL); + /* FIXME: more data */ + result_add_fpr (&state, "fpr", subkey->fpr); + result_xml_tag_end (&state); /* subkey */ + subkey = subkey->next; + } + result_xml_tag_end (&state); /* subkeys */ + result_xml_tag_start (&state, "uids", NULL); + uid = key->uids; + while (uid) { + result_xml_tag_start (&state, "uid", NULL); + /* FIXME: more data */ + result_add_string (&state, "uid", uid->uid); + result_add_string (&state, "name", uid->name); + result_add_string (&state, "email", uid->email); + result_add_string (&state, "comment", uid->comment); + result_xml_tag_end (&state); /* uid */ + uid = uid->next; + } + result_xml_tag_end (&state); /* uids */ + result_xml_tag_end (&state); /* key */ gpgme_key_unref (key); } } + result_xml_tag_end (&state); /* keylist */ + gt_write_data (gt, xml_end, sizeof (xml_end)); + server_reset_fds (server); return err; -- 1.7.8.6 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Sep 27 16:54:39 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 27 Sep 2012 16:54:39 +0200 Subject: [Announce] Libksba 1.3.0 released Message-ID: <87r4pn4its.fsf@vigenere.g10code.de> Hello! I am pleased to announce version 1.3.0 of Libksba. Libksba is an X.509 and CMS (PKCS#7) library. It is for example required to build the S/MIME part of GnuPG-2 (gpgsm). The only build requirement for Libksba itself is the libgpg-error package. There are no other dependencies; actual cryptographic operations need to be done by the user. Libksba is distributed under the LGPLv3+/GPLv2+. There are no user tools accompanying this software, thus it is mostly relevant to developers. The main reason for this release is the change to the GNU Lesser General Public License. You may download the library and its OpenPGP signature from: ftp://ftp.gnupg.org/gcrypt/libksba/libksba-1.3.0.tar.bz2 (610k) ftp://ftp.gnupg.org/gcrypt/libksba/libksba-1.3.0.tar.bz2.sig As an alternative you may use a patch file to upgrade the previous version of the library: ftp://ftp.gnupg.org/gcrypt/libksba/libksba-1.2.0-1.3.0.diff.bz2 (217k) SHA-1 checksums are: 241afcb2dfbf3f3fc27891a53a33f12d9084d772 libksba-1.3.0.tar.bz2 17f6e5fe2fdf6f9205cdec9de0e17194f4ece048 libksba-1.2.0-1.3.0.diff.bz2 Noteworthy changes in version 1.3.0 (2012-09-27) ------------------------------------------------ * Changed the license of the library from GPLv3 to LGPLv3/GPLv2; see the file AUTHORS for details. * Minor bug fixes. Commercial support contracts for Libksba are available, and they help finance continued maintenance. g10 Code, a Duesseldorf based company owned and headed by Libksba's principal author, is currently funding its development. We are always looking for interesting development projects. See also http://www.gnupg.org/service.html . Happy hacking, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 203 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Fri Sep 28 08:46:42 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 28 Sep 2012 08:46:42 +0200 Subject: [PATCH] gpgme-tool: Return more detailed XML from KEYLIST In-Reply-To: <20120927014353.GA8797@odin.tremily.us> (W. Trevor King's message of "Wed, 26 Sep 2012 21:43:53 -0400") References: <20120920171317.GG22536@odin.tremily.us> <874nmm84td.fsf@vigenere.g10code.de> <20120925184348.GB2616@odin.tremily.us> <878vbx6xfp.fsf@vigenere.g10code.de> <20120927014353.GA8797@odin.tremily.us> Message-ID: <87vcey3ar1.fsf@vigenere.g10code.de> On Thu, 27 Sep 2012 03:43, wking at tremily.us said: > src/gpgme-tool.c (cmd_keylist): Convert output from a list of > "key:" lines to more detailed XML. There's still > missing data under subkeys and uids. Please don't describe the changes in detail. If such a description is required, put them into comments in the code. See how I applied them. The commit logs are used to generate the ChangeLog for tarball releases. If you want to add more stuff, you may do it after a tear-off line, like: gpgme-tool: Return more detailed XML from KEYLIST gpgme-tools.c (foo): New. (main): Add new option --example. -- This, won't go into the ChangeLog but is ofthen useful to describe the change in more detail. The ChangeLog is only there to satisfy the requement of the GPL, whereas the commit message should be useful for the developing and maintaining the code. If you don't want a ChangeLog entry at all, use commit message similar to: gpgme-tool: Fix typos -- I should consider to use fly-spell mode to avoid all these typo fix commits ;-) Signed-off-by: foo at example.org > the number of output lines by a factor of ~50. Does this look like a > useful direction (in which case I can fill in the subkeys and uids > stubs), or would you like me to handle this in a different manner Yes. Eventually I would like to have a --summary or --brief option which prints just one line per key. Might be easier for debugging. But don't bother, if I feel the need for it I can quickly do it myself. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.