From jeanjacquesbrucker at gmail.com Wed Oct 3 17:42:12 2012 From: jeanjacquesbrucker at gmail.com (jbar) Date: Wed, 3 Oct 2012 17:42:12 +0200 Subject: [gpgme]Bug when getting signatures !? Message-ID: <20121003174212.c82d7034.jeanjacquesbrucker@gmail.com> I first did met the same problem as described here : http://lists.gnupg.org/pipermail/gnupg-devel/2005-May/022055.html Then I have had such call: gpgme_set_keylist_mode(...|GPGME_KEYLIST_MODE_SIGS); But mykey->uids->signatures was still NULL !! I finnaly try to get from public key instead of private (gpgme_get_key(...,0) instead of gpgme_get_key(...,1)) ... and... It works ! That's seems like a little bug, and the workaround is a bit tricky (ie: call 2 times gpgme_get_key...). (NB: still using libgpgme 1.3.1). /* create context */ gpgerr = gpgme_new(&main_gpgctx); if ( gpgerr != GPG_ERR_NO_ERROR ) DIE(1,"gpgme_new - %s",gpgme_strerror(gpgerr)); /* add GPGME_KEYLIST_MODE_SIGS to the keylist mode */ gpgerr = gpgme_set_keylist_mode(main_gpgctx,gpgme_get_keylist_mode(main_gpgctx)|GPGME_KEYLIST_MODE_LOCAL|GPGME_KEYLIST_MODE_SIGS|GPGME_KEYLIST_MODE_SIG_NOTATIONS); if ( gpgerr != GPG_ERR_NO_ERROR ) DIE(1,gpgme_strerror(gpgerr)); /* get the bot key */ gpgerr = gpgme_get_key (main_gpgctx,myself.fpr,&mygpgkey,1); if ( gpgerr != GPG_ERR_NO_ERROR ) { DIE(1,"gpgme_get_key(%s) - %s",myself.fpr,gpgme_strerror(gpgerr)); } sigs=mygpgkey->uids->signatures; while (sigs) { warnx("sig: %s",sigs->uid); (...) } -- 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 Thu Oct 4 12:10:41 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 04 Oct 2012 12:10:41 +0200 Subject: [gpgme]Bug when getting signatures !? In-Reply-To: <20121003174212.c82d7034.jeanjacquesbrucker@gmail.com> (jbar's message of "Wed, 3 Oct 2012 17:42:12 +0200") References: <20121003174212.c82d7034.jeanjacquesbrucker@gmail.com> Message-ID: <87obkiwnry.fsf@vigenere.g10code.de> On Wed, 3 Oct 2012 17:42, jeanjacquesbrucker at gmail.com said: > I finnaly try to get from public key instead of private (gpgme_get_key(...,0) instead of gpgme_get_key(...,1)) ... and... It works ! That problem will go away with GnuPG 2.1. Gpg < 2.1 uses separate code for private and public keys - despite that the private key is just the public key plus the private parts. Keeping them in sync is too hard and thus we opted not to do this. GPG >= 2.1 uses the same code for both listing types with --list-secret-keys being just a filter showing only those public keys where a corresponding private key is available. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wking at tremily.us Sat Oct 6 15:33:30 2012 From: wking at tremily.us (W. Trevor King) Date: Sat, 06 Oct 2012 09:33:30 -0400 Subject: [PATCH] gpgme-tool: Fix chain_id -> chain-id in KEYLIST XML. In-Reply-To: <20120927014353.GA8797@odin.tremily.us> 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: <20121006133329.GA29769@odin.tremily.us> src/gpgme-tool.c (cmd_keylist): Use instead of . -- All the other tags map struct attribute underscores to hyphens, so fixing follows the priciple of least surprise. Signed-off-by: W. Trevor King --- src/gpgme-tool.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gpgme-tool.c b/src/gpgme-tool.c index 23122e8..d37088c 100644 --- a/src/gpgme-tool.c +++ b/src/gpgme-tool.c @@ -2970,7 +2970,7 @@ cmd_keylist (assuan_context_t ctx, char *line) 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_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; -- 1.7.12 -------------- 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 Sat Oct 6 16:37:43 2012 From: wking at tremily.us (W. Trevor King) Date: Sat, 06 Oct 2012 10:37:43 -0400 Subject: [PATCH] gpgme-tool: escape special characters in output XML data (<, >, and &). Message-ID: <20121006143743.GB29769@odin.tremily.us> src/gpgme-tool.c (result_xml_escape_replacement, result_xml_escape): New. (result_xml_tag_data): Use result_xml_escape() to escape data. -- This is a general solution for generating valid XML, but the specific output that inspired the change was from the KEYLIST command: William Trevor King Now the uids are properly escaped: William Trevor King <wking at tremily.us> Signed-off-by: W. Trevor King --- src/gpgme-tool.c | 67 +++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 66 insertions(+), 1 deletion(-) diff --git a/src/gpgme-tool.c b/src/gpgme-tool.c index d37088c..502b94e 100644 --- a/src/gpgme-tool.c +++ b/src/gpgme-tool.c @@ -657,12 +657,71 @@ result_xml_tag_start (struct result_xml_state *state, char *name, ...) return 0; } +const char * +result_xml_escape_replacement(char c) +{ + switch (c) + { + case '<': + return "<"; + case '>': + return ">"; + case '&': + return "&"; + default: + return NULL; + } +} + +gpg_error_t +result_xml_escape (const char *data, char **buf) +{ + int data_len, i, j = 1; + const char *r; + char *b; + + data_len = strlen (data); + for (i = 0; i < data_len; i++) + { + r = result_xml_escape_replacement(data[i]); + if (r) + j += strlen (r); + else + j += 1; + } + + b = (char *) malloc (j); + if (! b) + return gpg_error_from_syserror (); + + j = 0; + for (i = 0; i < data_len; i++) + { + r = result_xml_escape_replacement(data[i]); + if (r) + { + strcpy (b + j, r); + j += strlen (r); + } + else + { + b[j] = data[i]; + j += 1; + } + } + b[j] = 0; + *buf = b; + + return 0; +} gpg_error_t result_xml_tag_data (struct result_xml_state *state, const char *data) { + gpg_error_t err; result_xml_write_cb_t cb = state->cb; void *hook = state->hook; + char *buf = NULL; if (state->had_data[state->next_tag - 1]) { @@ -674,7 +733,13 @@ result_xml_tag_data (struct result_xml_state *state, const char *data) (*cb) (hook, ">", 1); state->had_data[state->next_tag - 1] = 2; - (*cb) (hook, data, strlen (data)); + err = result_xml_escape(data, &buf); + if (err) + return err; + + (*cb) (hook, buf, strlen (buf)); + + free (buf); return 0; } -- 1.7.12 -------------- 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 Sat Oct 6 17:30:21 2012 From: wking at tremily.us (W. Trevor King) Date: Sat, 06 Oct 2012 11:30:21 -0400 Subject: [PATCH v2] gpgme-tool: escape special characters in output XML data (<, >, and &). In-Reply-To: <20121006143743.GB29769@odin.tremily.us> References: <20121006143743.GB29769@odin.tremily.us> Message-ID: <20121006153021.GC29769@odin.tremily.us> src/gpgme-tool.c (result_xml_escape_replacement, result_xml_escape): New. (result_xml_tag_data): Use result_xml_escape() to escape data. (result_add_error): Use unescaped < and >. -- This is a general solution for generating valid XML, but the specific output that inspired the change was from the KEYLIST command: William Trevor King Now the uids are properly escaped: William Trevor King <wking at tremily.us> Signed-off-by: W. Trevor King --- Changes since v1: * Avoid double-escaping in result_add_error(). src/gpgme-tool.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 67 insertions(+), 2 deletions(-) diff --git a/src/gpgme-tool.c b/src/gpgme-tool.c index d37088c..b745294 100644 --- a/src/gpgme-tool.c +++ b/src/gpgme-tool.c @@ -657,12 +657,71 @@ result_xml_tag_start (struct result_xml_state *state, char *name, ...) return 0; } +const char * +result_xml_escape_replacement(char c) +{ + switch (c) + { + case '<': + return "<"; + case '>': + return ">"; + case '&': + return "&"; + default: + return NULL; + } +} + +gpg_error_t +result_xml_escape (const char *data, char **buf) +{ + int data_len, i, j = 1; + const char *r; + char *b; + + data_len = strlen (data); + for (i = 0; i < data_len; i++) + { + r = result_xml_escape_replacement(data[i]); + if (r) + j += strlen (r); + else + j += 1; + } + + b = (char *) malloc (j); + if (! b) + return gpg_error_from_syserror (); + + j = 0; + for (i = 0; i < data_len; i++) + { + r = result_xml_escape_replacement(data[i]); + if (r) + { + strcpy (b + j, r); + j += strlen (r); + } + else + { + b[j] = data[i]; + j += 1; + } + } + b[j] = 0; + *buf = b; + + return 0; +} gpg_error_t result_xml_tag_data (struct result_xml_state *state, const char *data) { + gpg_error_t err; result_xml_write_cb_t cb = state->cb; void *hook = state->hook; + char *buf = NULL; if (state->had_data[state->next_tag - 1]) { @@ -674,7 +733,13 @@ result_xml_tag_data (struct result_xml_state *state, const char *data) (*cb) (hook, ">", 1); state->had_data[state->next_tag - 1] = 2; - (*cb) (hook, data, strlen (data)); + err = result_xml_escape(data, &buf); + if (err) + return err; + + (*cb) (hook, buf, strlen (buf)); + + free (buf); return 0; } @@ -714,7 +779,7 @@ result_add_error (struct result_xml_state *state, char *name, gpg_error_t err) char code[20]; char msg[1024]; snprintf (code, sizeof (code) - 1, "0x%x", err); - snprintf (msg, sizeof (msg) - 1, "%s <%s>", + snprintf (msg, sizeof (msg) - 1, "%s <%s>", gpg_strerror (err), gpg_strsource (err)); result_xml_tag_start (state, name, "value", code, NULL); result_xml_tag_data (state, msg); -- 1.7.12 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Sun Oct 7 15:34:16 2012 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Sun, 07 Oct 2012 15:34:16 +0200 Subject: GnuPG 2.1 - import of secret key fail with IPC error Message-ID: <507184D8.50204@sumptuouscapital.com> Hi, This might have been reported before, but just a heads up regarding the move to gpg-agent store of keys in GnuPG 2.1 . Ignoring the warnings of it being a development version (I'm not sure how stable 2.1 is becoming now, so how much emphasis should be put on this warning? anyhow, this is on a secure box and its the only way to properly test it) When trying to import one of my more non-standard (in the sense that it is a 15360 bits RSA/ElGamal key pair) I get "Too much data for IPC layer" as shown in #Snippet 1# below. The key is fully functional in GnuPG 1.4 and 2.0. Any hint on where to start debugging this? From what I can tell this would be in libassuan? ## Snippet 1 ## $ gpg2 --import sec_largekey.asc gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: key 7EF326AE43E67CF7: "Kristian Fiskerstrand (Large key) " not changed gpg: key 7EF326AE43E67CF7/7EF326AE43E67CF7: error sending to agent: Too much data for IPC layer gpg: error building skey array: Too much data for IPC layer gpg: Total number processed: 3 gpg: unchanged: 1 gpg: secret keys read: 3 -- ---------------------------- Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk ---------------------------- Bene diagnoscitur, bene curatur Something that is well diagnosed can be cured well ---------------------------- This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ ---------------------------- Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature URL: From wking at tremily.us Mon Oct 8 00:36:01 2012 From: wking at tremily.us (W. Trevor King) Date: Sun, 07 Oct 2012 18:36:01 -0400 Subject: [PATCH] Fix FDPASSIN -> FDPASSING typo in the documentation. Message-ID: <20121007223601.GA8362@odin.tremily.us> Signed-off-by: W. Trevor King --- doc/assuan.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/assuan.texi b/doc/assuan.texi index ddac37a..735e843 100644 --- a/doc/assuan.texi +++ b/doc/assuan.texi @@ -1121,7 +1121,7 @@ Make a connection to the Unix domain socket @var{name} and return a new Assuan context at @var{ctx}. @var{server_pid} is currently not used but may become handy in the future; if you don't know the server's process ID (PID), pass @code{ASSUAN_INVALID_PID}. With - at var{flags} set to @code{ASSUAN_SOCKET_CONNECT_FDPASSIN}, + at var{flags} set to @code{ASSUAN_SOCKET_CONNECT_FDPASSING}, @code{sendmsg} and @code{recvmesg} are used for input and output and thereby enable the use of descriptor passing. -- 1.7.12 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From JPClizbe at gingerbear.net Mon Oct 8 00:08:49 2012 From: JPClizbe at gingerbear.net (John Clizbe) Date: Sun, 07 Oct 2012 17:08:49 -0500 Subject: Fwd: [Sks-devel] [Announcement] SKS 1.1.4 Released In-Reply-To: <5071E4FB.4090805@sumptuouscapital.com> References: <5071E4FB.4090805@sumptuouscapital.com> Message-ID: <5071FD71.2000709@GingerBear.net> Kristain left these groups off the initial email -John -------- Original Message -------- Subject: [Sks-devel] [Announcement] SKS 1.1.4 Released Date: Sun, 07 Oct 2012 22:24:27 +0200 From: Kristian Fiskerstrand To: sks-devel Hello, We are pleased to announce the availability of a new stable SKS release: Version 1.1.4. SKS is an OpenPGP keyserver whose goal is to provide easy to deploy, decentralized, and highly reliable synchronization. That means that a key submitted to one SKS server will quickly be distributed to all key servers, and even wildly out-of-date servers, or servers that experience spotty connectivity, can fully synchronize with rest of the system. What's New in 1.1.4 ==================== - Fix X-HKP-Results-Count so that limit=0 returns no results, but include the header, to let a client poll for how many results exist, without retrieving any. Submitted by Phil Pennock. See: http://lists.nongnu.org/archive/html/sks-devel/2010-11/msg00015.html - Add UPGRADING document to explain upgrading Berkeley DB without rebuilding. System bdb versions often change with new SKS releases for .deb and .rpm distros. - Cleanup build errors for bdb/bdb_stubs.c. Patch from Mike Doty - Update cryptokit from version 1.0 to 1.5 without requiring OASIS build system or other additional dependencies - build, fastbuild, & pbuild fixed to ignore signals USR1 and USR2 - common.ml and reconSC.ml were using different values for minumimum compatible version. This has been fixed. - Added new server mime-types, and trying another default document (Issue 6) In addition to the new MIME types added in 1.1.[23], the server now looks over a list and and serves the first index file that it finds Current list: index.html, index.htm, index.xhtml, index.xhtm, index.xml. - options=mr now works on get as well as (v)index operations. This is described in http://tools.ietf.org/html/draft-shaw-openpgp-hkp-00 sections 3.2.1.1. and 5.1. - Updated copyright notices in source files - Added sksclient tool, similar to old pksclient - Add no-cache instructions to HTTP response (in order for reverse proxies not to cache the output from SKS) - Use unique timestamps for keydb to reduce occurrances of Ptree corruption. - Added Interface specifications (.mli files) for modules that were missing them - Yaron pruned some no longer needed source files from the tree. - Improved the HTTP status and HTTP error codes returned for various situations and added checks for more error conditions. - Add a suffix to version (+) indicating non-release or development builds - Add an option to specify the contact details of the server administrator that shows in the status page of the server. The information is in the form of an OpenPGP KeyID and set by server_contact: in sksconf - Add a `sks version` command to provide information on the setup. - Added configuration settings for the remaining database table files. If no pagesize settings are in sksconf, SKS will use 2048 bytes for key and 512 for ptree. The remainining files' pagesize will be set by BDB based on the filesystem settings, typically this is 4096 bytes. See sampleConfig/sksconf.typical for settings recommended by db_tuner. - Makefile: Added distclean target. Dropped autogenerated file from VCS. - Allow tuning BDB environment before creation in [fast]build and pbuild. If DB_CONFIG exists in basedir, copy it to DB dir before DB creation. Preference is given to DB_CONFIG.KDB and DB_CONFIG.PTree over DB_CONFIG. - Add support for Elliptic Curve Public keys (ECDSA, ECDH) - Add check if an upload is a revocation certificate, and if it is, produce an error message tailored for this. Note when upgrading from earlier versions of SKS ==================== The default values for pagesize settings have changed. To continue using an existing DB without rebuilding, explicit settings have to be added to the sksconf file. pagesize: 4 ptree_pagesize: 1 Getting the Software ==================== SKS can be downloaded from https://bitbucket.org/skskeyserver/sks-keyserver Prerequisites ==================== There are a few prerequisites to building this code. You need: * ocaml-3.10.2 or later. Get it from ocaml-3.12.x is recommended, ocaml-4.x is not recommended at this time * Berkeley DB version 4.6.* or later, whereby 4.8 or later is recommended. You can find the appropriate versions at Verifying the integrity of the download ==================== Releases of SKS are signed using the SKS Keyserver Signing Key available on public keyservers with the KeyID 0x41259773973A612A and has a fingerprint of C90E F143 0B3A C0DF D00E 6EA5 4125 9773 973A 612A. Using GnuPG, verification can be accomplished by, first, retrieving the signing key using gpg --keyserver pool.sks-keyservers.net --recv-key 0x41259773973A612A followed by verifying that you have the correct key gpg --keyid-format long --fingerprint 0x41259773973A612A should produce: pub 4096R/41259773973A612A 2012-06-27 Key fingerprint = C90E F143 0B3A C0DF D00E 6EA5 4125 9773 973A 612A A check should also be made that the key is signed by trustworthy other keys; gpg --list-sigs 0x41259773973A612A and the fingerprint should be verified through other trustworthy sources. Once you are certain that you have the correct key downloaded, you can create a local signature, in order to remember that you have verified the key. gpg --lsign-key 0x41259773973A612A Finally; verifying the downloaded file can be done using gpg --keyid-format long --verify sks-x.y.z.tgz.asc The resulting output should be similar to gpg: Signature made Wed Jun 27 12:52:39 2012 CEST gpg: using RSA key 41259773973A612A gpg: Good signature from "SKS Keyserver Signing Key" Checksums for sks-1.1.4.tgz SHA1: d0b3b387653115d106ebbcae13aeda06f0034909 SHA256: baa79be8c1983544518e8a72ccecacb2837d52ae4015dc7cf364cddb53220c76 Thanks ==================== We have to thank all the people who helped with this release, by discussions on the mailing list, submitting patches, or opening issues for items that needed our attention. Happy Hacking, The SKS Team (Yaron, John, Kristian, Phil, and the other contributors) _______________________________________________ Sks-devel mailing list Sks-devel at nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: OpenPGP digital signature URL: From wking at tremily.us Mon Oct 8 01:41:41 2012 From: wking at tremily.us (W. Trevor King) Date: Sun, 07 Oct 2012 19:41:41 -0400 Subject: gpgme-tool socket interface In-Reply-To: <20120407155808.GA23354@odin.tremily.us> <20120407152358.GB22965@odin.tremily.us> Message-ID: <20121007234141.GB8362@odin.tremily.us> With Python 3.3 officially released, I can now use socket.sendmsg() to send FDs to Assuan servers listening on Unix sockets. This means pgp-mime can communicate with a persistent gpgme-tool server (sweet!), where I used to use subprocess.Popen() to fork/exec a client for every transaction and pass the file descriptors via process inheritance (yuck!). This works on my local system, with a patched version of gpgme-tool that uses the cues off the existing -s/--server option to run as a fork/exec server listening on a Unix socket instead of running as a pipe server. The problem is getting this to a releasable state without forking gpgme-tool. We discussed this back in April [1], but I was pushing for additional socket-server utility code in libassuan, and that didn't seem to be going over very well. I still think that's the best way to go, but if changes to GPGME are more likely to be accepted, I can go that way instead. I'll volunteer myself to work up patches for any of the following: a) libassuan: Some variation on my original suggestion: a helper function to spawn an Assuan server (either pipe or socket) which handles all the usual setup/teardown internally. Both gpg-agent and gpgme-tool would then use this function, so it would have to be sufficiently flexible to handle both cases. API to-be-determined. b) gpgme: copy gpg-agent's socket handling code into gpgme-tool (with copy-paste commits for proper attribution, followed by integration commits by me). c) same as (b), but I'll write up the socket handling from scratch (man pages, etc.) to keep the code-base distinct from GnuPG. Since I can't look at gpg-agent's code, I'll probably someone else to handle the MS Windows side, if people want that to be supported. Since we're just adding functionality, I see no reason why Windows *must* be supported. d) Other approaches? Of course, if someone else wants to do the legwork, I'm happy to sit back and use your code ;). Cheers, Trevor [1]: http://thread.gmane.org/gmane.comp.encryption.gpg.devel/16843/focus=16865 -- 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 roberto.c.aguilar at gmail.com Mon Oct 8 01:07:00 2012 From: roberto.c.aguilar at gmail.com (Roberto Aguilar) Date: Sun, 7 Oct 2012 16:07:00 -0700 Subject: GPGME install requirements Message-ID: Hello, I have been struggling to get an OS X application to use GPGME. Per the instructions I found on the Internet, I built and installed libassuan, libgpg-error, and gpgme. Just those three fail with the message "invalid crypto engine". Further searching suggested installing gpg2, which I did from source, but then had trouble with pinentry. As a last ditch effort, I installed the GPGTools package [1], rebuilt gpgme, and now the program that uses gpgme works. >From here I'm trying to deduce what libraries from within the GPGTools package is gpgme requiring. I've done some cursory tests and confirm that if the binary gpg2 is not available GPGME does not work. Does gpgme shell out to gpg2 internally? Thanks for the help! -Roberto. [1] http://gpgtools.org/ From wk at gnupg.org Mon Oct 8 11:20:04 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 08 Oct 2012 11:20:04 +0200 Subject: GnuPG 2.1 - import of secret key fail with IPC error In-Reply-To: <507184D8.50204@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Sun, 07 Oct 2012 15:34:16 +0200") References: <507184D8.50204@sumptuouscapital.com> Message-ID: <87bogduxq3.fsf@vigenere.g10code.de> On Sun, 7 Oct 2012 15:34, kristian.fiskerstrand at sumptuouscapital.com said: > When trying to import one of my more non-standard (in the sense that it > is a 15360 bits RSA/ElGamal key pair) I get "Too much data for IPC > layer" as shown in #Snippet 1# below. The key is fully functional in Well, the error message could be better. At least it detects such DoS style keys ;-) Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Oct 8 14:13:26 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 08 Oct 2012 14:13:26 +0200 Subject: GPGME install requirements In-Reply-To: (Roberto Aguilar's message of "Sun, 7 Oct 2012 16:07:00 -0700") References: Message-ID: <877gr1upp5.fsf@vigenere.g10code.de> On Mon, 8 Oct 2012 01:07, roberto.c.aguilar at gmail.com said: > I've done some cursory tests and confirm that if the binary gpg2 is > not available GPGME does not work. Does gpgme shell out to gpg2 > internally? Sure. GPGME delegates its actual work to a crypto engine, which is gpgsm for S/MIME and gpg for OpenPGP. GnuPG 2.x installs by default under the name gpg2 and GPGME may or may not know about this - it depends on how you built it (cf. configure option --with-gpg=NAME). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Tue Oct 9 05:44:00 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 09 Oct 2012 12:44:00 +0900 Subject: NeuG and FST-01 Message-ID: <1349754240.2669.6.camel@cfw2.gniibe.org> Hello, Version 0.03 of NeuG, a True Random Number Generator Implementation (for STM32F103), is released. While my intention of developing NeuG is for use as part of Gnuk, I think that stand alone version of NeuG device (it runs as /dev/ttyACM0) is also useful to feed entropy to your computer. For example, it is useful when you generate many GnuPG keys. I wrote a page for NeuG: http://www.gniibe.org/memo/development/gnuk/rng/neug Your comments will be appreciated. Besides, the hardware, FST-01 (evaluation board) is available now. Last year, I designed this board for Gnuk, and the design of its PCB is freely available. So far, only the prototype version of the hardware has existed, but now, the mass production version is available. Please visit our WiKi page for FST-01. http://www.seeedstudio.com/wiki/FST-01 Happy Hacking, -- From wking at tremily.us Wed Oct 10 17:22:41 2012 From: wking at tremily.us (W. Trevor King) Date: Wed, 10 Oct 2012 11:22:41 -0400 Subject: gpgme-tool socket interface In-Reply-To: <20121007234141.GB8362@odin.tremily.us> References: <20120407155808.GA23354@odin.tremily.us> <20120407152358.GB22965@odin.tremily.us> <20121007234141.GB8362@odin.tremily.us> Message-ID: <20121010152241.GA21706@odin.tremily.us> On Sun, Oct 07, 2012 at 07:41:41PM -0400, W. Trevor King wrote: > b) gpgme: copy gpg-agent's socket handling code into gpgme-tool (with > copy-paste commits for proper attribution, followed by integration > commits by me). > > c) same as (b), but I'll write up the socket handling from scratch > (man pages, etc.) to keep the code-base distinct from GnuPG. Since > I can't look at gpg-agent's code, I'll probably someone else to > handle the MS Windows side, if people want that to be supported. > Since we're just adding functionality, I see no reason why Windows > *must* be supported. A very rough commit along the lines of (c) is in my `socket` branch [1], if anyone wants to poke about. [1]: http://git.tremily.us/?p=gpgme.git -- 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 Thu Oct 11 17:05:52 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 11 Oct 2012 17:05:52 +0200 Subject: [PATCH v2] gpgme-tool: escape special characters in output XML data (<, >, and &). In-Reply-To: <20121006153021.GC29769@odin.tremily.us> (W. Trevor King's message of "Sat, 06 Oct 2012 11:30:21 -0400") References: <20121006143743.GB29769@odin.tremily.us> <20121006153021.GC29769@odin.tremily.us> Message-ID: <87k3uxrqun.fsf@vigenere.g10code.de> On Sat, 6 Oct 2012 17:30, wking at tremily.us said: > src/gpgme-tool.c (result_xml_escape_replacement, result_xml_escape): > New. > (result_xml_tag_data): Use result_xml_escape() to escape data. > (result_add_error): Use unescaped < and >. Applied. I also commited an additional change to make the code more robust. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Oct 11 17:18:30 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 11 Oct 2012 17:18:30 +0200 Subject: gpgme-tool socket interface In-Reply-To: <20121007234141.GB8362@odin.tremily.us> (W. Trevor King's message of "Sun, 07 Oct 2012 19:41:41 -0400") References: <20121007234141.GB8362@odin.tremily.us> Message-ID: <87fw5lrq9l.fsf@vigenere.g10code.de> On Mon, 8 Oct 2012 01:41, wking at tremily.us said: > for additional socket-server utility code in libassuan, and that > didn't seem to be going over very well. I still think that's the best Right, it is too hard to get this into Libassuan in a flexible way. You would end up with something as complicated as the gpgme event code. > a) libassuan: Some variation on my original suggestion: a helper > function to spawn an Assuan server (either pipe or socket) which > handles all the usual setup/teardown internally. Both gpg-agent If it ever turns out that this is required by a lot of other code, we can revisit this then. > b) gpgme: copy gpg-agent's socket handling code into gpgme-tool (with > copy-paste commits for proper attribution, followed by integration Fine. However, gpg-agent heavily relies on nPth semantics. This is probably not what you want. > c) same as (b), but I'll write up the socket handling from scratch > (man pages, etc.) to keep the code-base distinct from GnuPG. Since > I can't look at gpg-agent's code, I'll probably someone else to > handle the MS Windows side, if people want that to be supported. Actually we have a platform independent socket abstraction in libassuan for that purpose. Check out how it is done in dirmngr or gpg-agent. > Since we're just adding functionality, I see no reason why Windows > *must* be supported. We can talk about neglecting WindowsCE, but Windows is a/the mainstream platform and thus we should support it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Oct 11 17:20:24 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 11 Oct 2012 17:20:24 +0200 Subject: gpgme-tool socket interface In-Reply-To: <20121010152241.GA21706@odin.tremily.us> (W. Trevor King's message of "Wed, 10 Oct 2012 11:22:41 -0400") References: <20120407155808.GA23354@odin.tremily.us> <20120407152358.GB22965@odin.tremily.us> <20121007234141.GB8362@odin.tremily.us> <20121010152241.GA21706@odin.tremily.us> Message-ID: <87bog9rq6f.fsf@vigenere.g10code.de> On Wed, 10 Oct 2012 17:22, wking at tremily.us said: > A very rough commit along the lines of (c) is in my `socket` branch Is there a reason why you do not use assuan_sock_new et al? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wking at tremily.us Thu Oct 11 21:07:43 2012 From: wking at tremily.us (W. Trevor King) Date: Thu, 11 Oct 2012 15:07:43 -0400 Subject: gpgme-tool socket interface In-Reply-To: <87bog9rq6f.fsf@vigenere.g10code.de> <87fw5lrq9l.fsf@vigenere.g10code.de> Message-ID: <20121011190743.GC15735@odin.tremily.us> On Thu, Oct 11, 2012 at 05:18:30PM +0200, Werner Koch wrote: > > b) gpgme: copy gpg-agent's socket handling code into gpgme-tool (with > > copy-paste commits for proper attribution, followed by integration > > Fine. However, gpg-agent heavily relies on nPth semantics. This is > probably not what you want. The socket setup and teardown shouldn't be too tied up in the threading, so I'll take a look. > > c) same as (b), but I'll write up the socket handling from scratch > > (man pages, etc.) to keep the code-base distinct from GnuPG. Since > > I can't look at gpg-agent's code, I'll probably someone else to > > handle the MS Windows side, if people want that to be supported. > > Actually we have a platform independent socket abstraction in libassuan > for that purpose. Check out how it is done in dirmngr or gpg-agent. Good point. I'm talking a look at that now. On Thu, Oct 11, 2012 at 05:20:24PM +0200, Werner Koch wrote: > On Wed, 10 Oct 2012 17:22, wking at tremily.us said: > > A very rough commit along the lines of (c) is in my `socket` branch > > Is there a reason why you do not use assuan_sock_new et al? I didn't read the libassuan manual thoroughly enough ;). I'm a bit confused about how to handle listen() and accept(), which are not wrapped by libassuan. libassuan's test/ce-server.c uses SOCKET2HANDLE() and HANDLE2SOCKET() defined in assuan-def.h to convert between `assuan_fd_t`s and `int`s, while gpg-agent uses INT2FD() and FD2INT() defined in sysutils.h to convert between `gnupg_fd_t`s and `int`s. Perhaps I should be using assuan_fdopen() instead of INT2FD()? I'm not sure what the most idomatic approach is. I've rebased my socket branch against the new master, and slacked off on commit messages. I'll beat them back into shape once the code gets to a merge-able state. -- 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 Thu Oct 11 21:59:06 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 11 Oct 2012 21:59:06 +0200 Subject: gpgme-tool socket interface In-Reply-To: <20121011190743.GC15735@odin.tremily.us> (W. Trevor King's message of "Thu, 11 Oct 2012 15:07:43 -0400") References: <20121011190743.GC15735@odin.tremily.us> Message-ID: <87sj9krd9x.fsf@vigenere.g10code.de> On Thu, 11 Oct 2012 21:07, wking at tremily.us said: > I'm a bit confused about how to handle listen() and accept(), which There was no immediate need to wrap them. We can do that of course. > are not wrapped by libassuan. libassuan's test/ce-server.c uses > SOCKET2HANDLE() and HANDLE2SOCKET() defined in assuan-def.h to convert > between `assuan_fd_t`s and `int`s, while gpg-agent uses INT2FD() and > FD2INT() defined in sysutils.h to convert between `gnupg_fd_t`s and That is all a mess. The casting won't work on 64 bit Windows due to sizeof(void*) > sizeof(int); i.e. HANDLE vs. int. There are also a lot of other maintenance problems with them due to the non-unified usage of file descriptors in Windows (System handles, several different libc fd, sockets, etc). Back then when I ported GnuPG to CE, the plan was to soon start with a clean way of addressing this. However a 64 bit GnuPG port is not on the horizon anymore. The code in Libassuan is likely better. > `int`s. Perhaps I should be using assuan_fdopen() instead of > INT2FD()? I'm not sure what the most idomatic approach is. Better try to stay away from that mess ;-). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wking at tremily.us Thu Oct 11 22:15:20 2012 From: wking at tremily.us (W. Trevor King) Date: Thu, 11 Oct 2012 16:15:20 -0400 Subject: gpgme-tool socket interface In-Reply-To: <87sj9krd9x.fsf@vigenere.g10code.de> References: <20121011190743.GC15735@odin.tremily.us> <87sj9krd9x.fsf@vigenere.g10code.de> Message-ID: <20121011201520.GD15735@odin.tremily.us> On Thu, Oct 11, 2012 at 09:59:06PM +0200, Werner Koch wrote: > On Thu, 11 Oct 2012 21:07, wking at tremily.us said: > > > I'm a bit confused about how to handle listen() and accept(), which > > There was no immediate need to wrap them. We can do that of course. > > [snip discussion of ce-server.c vs. gpg-agent] > > The code in Libassuan is likely better. I've updated my socket branch to use the libassuan socket wrappers. -- 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 bisson at archlinux.org Fri Oct 12 05:48:42 2012 From: bisson at archlinux.org (Gaetan Bisson) Date: Fri, 12 Oct 2012 14:48:42 +1100 Subject: Issue1402 - gpg-protect-tool doesn't pass DISPLAY to agent Message-ID: <20121012034842.GA20908@gyoza.vesath.org> Dear GnuPG developers, I was wondering if you had made a decision regarding: https://bugs.g10code.com/gnupg/issue1402 The reporter suggested a simple patch, but apparently could not find the time to explain it; however he has done so concisely there: https://bugzilla.redhat.com/show_bug.cgi?id=548528#c43 "The problem was gpg-protect-tool (PKCS#12 helper called by gpgsm to decrypt the source bundle) was not initialising session_env properly and that prevented send_pinentry_environment() from doing its job (passing relevant environment vars like DISPLAY to agent and in turn, pinentry), so pinentry-qt had no clue which X session to use and either bailed out or possibly popped the curses fallback interface somewhere." I believe Fedora has applied that patch to their recent packages, and we (Arch Linux) are contemplating doing the same as our users have been hitting the same issue lately. But I wanted to double check the status of that patch with you before actually applying it. Cheers. -- Gaetan From christian at quelltextlich.at Sun Oct 14 20:56:25 2012 From: christian at quelltextlich.at (Christian Aistleitner) Date: Sun, 14 Oct 2012 20:56:25 +0200 Subject: [PATCH libgpg-error] Fix honoring --with-libgpg-error-prefix Message-ID: <20121014185625.GA20911@quelltextlich.at> * src/gpg-error.m4: Stop --with-gpg-error-prefix from resetting gpg_error_config_prefix and thereby from ignoring --with-libgpg-error-prefix. --- src/gpg-error.m4 | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/gpg-error.m4 b/src/gpg-error.m4 index f0b9f1f..092c9bb 100644 --- a/src/gpg-error.m4 +++ b/src/gpg-error.m4 @@ -27,7 +27,7 @@ AC_DEFUN([AM_PATH_GPG_ERROR], dnl --with-libgpg-error-prefix above, for backwards compatibility, dnl but do not document this old, inconsistently-named option. AC_ARG_WITH(gpg-error-prefix,, - gpg_error_config_prefix="$withval", gpg_error_config_prefix="") + gpg_error_config_prefix="$withval") if test x$gpg_error_config_prefix != x ; then if test x${GPG_ERROR_CONFIG+set} != xset ; then -- 1.7.8.6 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From christian at quelltextlich.at Sun Oct 14 20:27:00 2012 From: christian at quelltextlich.at (Christian Aistleitner) Date: Sun, 14 Oct 2012 20:27:00 +0200 Subject: Fixing honoring --cert-digest-algo when recreating a cert Message-ID: <20121014182700.GA17677@quelltextlich.at> Dear list, when updating a keysig packet, and the original keysig's algorithm and the algorithm of --cert-digest-algo differ, g10/sign.c:update_keysig_packet does not properly respect --cert-digest-algo, but instead: * For STABLE-BRANCH-1-4: Creates a keysig packet carrying the orignal keysig's algorithm identifier in the hashed data, but computes the hash using --cert-digest-algo's algorithm, which results in a broken keysig packet. * For master, and STABLE-BRANCH-2-0: --cert-digest-algo gets straight away ignored. The resulting signature is valid, however uses the original keysig's algorithm. The followup emails contain patches fixing the issue for those three branches. All the best, Christian -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian at quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From christian at quelltextlich.at Sun Oct 14 20:31:41 2012 From: christian at quelltextlich.at (Christian Aistleitner) Date: Sun, 14 Oct 2012 20:31:41 +0200 Subject: [PATCH STABLE-BRANCH-2-0] Fix honoring --cert-digest-algo when recreating a cert In-Reply-To: <20121014182700.GA17677@quelltextlich.at> References: <20121014182700.GA17677@quelltextlich.at> Message-ID: <20121014183141.GC17677@quelltextlich.at> * g10/sign.c (update_keysig_packet): Override original signature's digest algo in hashed data and for hash computation. -- --- g10/sign.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/g10/sign.c b/g10/sign.c index a464bb6..65f1d0c 100644 --- a/g10/sign.c +++ b/g10/sign.c @@ -1517,7 +1517,7 @@ update_keysig_packet( PKT_signature **ret_sig, else digest_algo = orig_sig->digest_algo; - if ( gcry_md_open (&md, orig_sig->digest_algo, 0 ) ) + if ( gcry_md_open (&md, digest_algo, 0 ) ) BUG (); /* Hash the public key certificate and the user id. */ @@ -1531,6 +1531,8 @@ update_keysig_packet( PKT_signature **ret_sig, /* create a new signature packet */ sig = copy_signature (NULL, orig_sig); + sig->digest_algo=digest_algo; + /* We need to create a new timestamp so that new sig expiration calculations are done correctly... */ sig->timestamp=make_timestamp(); -- 1.7.8.6 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From christian at quelltextlich.at Sun Oct 14 20:33:00 2012 From: christian at quelltextlich.at (Christian Aistleitner) Date: Sun, 14 Oct 2012 20:33:00 +0200 Subject: [PATCH STABLE-BRANCH-1-4] Fix honoring --cert-digest-algo when recreating a cert In-Reply-To: <20121014182700.GA17677@quelltextlich.at> References: <20121014182700.GA17677@quelltextlich.at> Message-ID: <20121014183259.GD17677@quelltextlich.at> * g10/sign.c (update_keysig_packet): Override original signature's digest algo in hashed data. -- --- g10/sign.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/g10/sign.c b/g10/sign.c index 462392d..05b90e8 100644 --- a/g10/sign.c +++ b/g10/sign.c @@ -1515,6 +1515,8 @@ update_keysig_packet( PKT_signature **ret_sig, /* create a new signature packet */ sig = copy_signature (NULL, orig_sig); + sig->digest_algo=digest_algo; + /* We need to create a new timestamp so that new sig expiration calculations are done correctly... */ sig->timestamp=make_timestamp(); -- 1.7.8.6 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From christian at quelltextlich.at Sun Oct 14 20:30:20 2012 From: christian at quelltextlich.at (Christian Aistleitner) Date: Sun, 14 Oct 2012 20:30:20 +0200 Subject: [PATCH master] Fix honoring --cert-digest-algo when recreating a cert In-Reply-To: <20121014182700.GA17677@quelltextlich.at> References: <20121014182700.GA17677@quelltextlich.at> Message-ID: <20121014183020.GB17677@quelltextlich.at> * g10/sign.c (update_keysig_packet): Override original signature's digest algo in hashed data and for hash computation. -- --- g10/sign.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/g10/sign.c b/g10/sign.c index 6238ce8..b259511 100644 --- a/g10/sign.c +++ b/g10/sign.c @@ -1589,7 +1589,7 @@ update_keysig_packet( PKT_signature **ret_sig, else digest_algo = orig_sig->digest_algo; - if ( gcry_md_open (&md, orig_sig->digest_algo, 0 ) ) + if ( gcry_md_open (&md, digest_algo, 0 ) ) BUG (); /* Hash the public key certificate and the user id. */ @@ -1603,6 +1603,8 @@ update_keysig_packet( PKT_signature **ret_sig, /* create a new signature packet */ sig = copy_signature (NULL, orig_sig); + sig->digest_algo=digest_algo; + /* We need to create a new timestamp so that new sig expiration calculations are done correctly... */ sig->timestamp=make_timestamp(); -- 1.7.8.6 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From reven1280 at gmail.com Mon Oct 15 12:15:58 2012 From: reven1280 at gmail.com (tom m) Date: Mon, 15 Oct 2012 12:15:58 +0200 Subject: Gnupg-devel Digest, Vol 109, Issue 3 In-Reply-To: References: Message-ID: Den 11. okt. 2012 21.08 skrev f?lgende: > > Send Gnupg-devel mailing list submissions to > gnupg-devel at gnupg.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > or, via email, send a message with subject or body 'help' to > gnupg-devel-request at gnupg.org > > You can reach the person managing the list at > gnupg-devel-owner at gnupg.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Gnupg-devel digest..." > > Today's Topics: > > 1. Re: gpgme-tool socket interface (W. Trevor King) > 2. GPGME install requirements (Roberto Aguilar) > 3. Re: GnuPG 2.1 - import of secret key fail with IPC error > (Werner Koch) > 4. Re: GPGME install requirements (Werner Koch) > 5. NeuG and FST-01 (NIIBE Yutaka) > 6. Re: gpgme-tool socket interface (W. Trevor King) > 7. Re: [PATCH v2] gpgme-tool: escape special characters in > output XML data (<, >, and &). (Werner Koch) > 8. Re: gpgme-tool socket interface (Werner Koch) > 9. Re: gpgme-tool socket interface (Werner Koch) > 10. Re: gpgme-tool socket interface (W. Trevor King) > > > ---------- Forwarded message ---------- > From: "W. Trevor King" > To: gnupg-devel at gnupg.org > Cc: > Date: Sun, 07 Oct 2012 19:41:41 -0400 > Subject: Re: gpgme-tool socket interface > With Python 3.3 officially released, I can now use socket.sendmsg() to > send FDs to Assuan servers listening on Unix sockets. This means > pgp-mime can communicate with a persistent gpgme-tool server (sweet!), > where I used to use subprocess.Popen() to fork/exec a client for every > transaction and pass the file descriptors via process inheritance > (yuck!). > > This works on my local system, with a patched version of gpgme-tool > that uses the cues off the existing -s/--server option to run as a > fork/exec server listening on a Unix socket instead of running as a > pipe server. > > The problem is getting this to a releasable state without forking > gpgme-tool. We discussed this back in April [1], but I was pushing > for additional socket-server utility code in libassuan, and that > didn't seem to be going over very well. I still think that's the best > way to go, but if changes to GPGME are more likely to be accepted, I > can go that way instead. I'll volunteer myself to work up patches for > any of the following: > > a) libassuan: Some variation on my original suggestion: a helper > function to spawn an Assuan server (either pipe or socket) which > handles all the usual setup/teardown internally. Both gpg-agent > and gpgme-tool would then use this function, so it would have to be > sufficiently flexible to handle both cases. API to-be-determined. > > b) gpgme: copy gpg-agent's socket handling code into gpgme-tool (with > copy-paste commits for proper attribution, followed by integration > commits by me). > > c) same as (b), but I'll write up the socket handling from scratch > (man pages, etc.) to keep the code-base distinct from GnuPG. Since > I can't look at gpg-agent's code, I'll probably someone else to > handle the MS Windows side, if people want that to be supported. > Since we're just adding functionality, I see no reason why Windows > *must* be supported. > > d) Other approaches? > > Of course, if someone else wants to do the legwork, I'm happy to sit > back and use your code ;). > > Cheers, > Trevor > > [1]: http://thread.gmane.org/gmane.comp.encryption.gpg.devel/16843/focus=16865 > > -- > 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 > > > ---------- Forwarded message ---------- > From: Roberto Aguilar > To: gnupg-devel at gnupg.org > Cc: > Date: Sun, 7 Oct 2012 16:07:00 -0700 > Subject: GPGME install requirements > Hello, > > I have been struggling to get an OS X application to use GPGME. Per > the instructions I found on the Internet, I built and installed > libassuan, libgpg-error, and gpgme. Just those three fail with the > message "invalid crypto engine". > > Further searching suggested installing gpg2, which I did from source, > but then had trouble with pinentry. > > As a last ditch effort, I installed the GPGTools package [1], rebuilt > gpgme, and now the program that uses gpgme works. > > >From here I'm trying to deduce what libraries from within the GPGTools > package is gpgme requiring. > > I've done some cursory tests and confirm that if the binary gpg2 is > not available GPGME does not work. Does gpgme shell out to gpg2 > internally? > > Thanks for the help! > -Roberto. > > [1] http://gpgtools.org/ > > > > > ---------- Forwarded message ---------- > From: Werner Koch > To: Kristian Fiskerstrand > Cc: GnuPG Development List > Date: Mon, 08 Oct 2012 11:20:04 +0200 > Subject: Re: GnuPG 2.1 - import of secret key fail with IPC error > On Sun, 7 Oct 2012 15:34, kristian.fiskerstrand at sumptuouscapital.com > said: > > > When trying to import one of my more non-standard (in the sense that it > > is a 15360 bits RSA/ElGamal key pair) I get "Too much data for IPC > > layer" as shown in #Snippet 1# below. The key is fully functional in > > Well, the error message could be better. At least it detects such DoS > style keys ;-) > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > > > > ---------- Forwarded message ---------- > From: Werner Koch > To: Roberto Aguilar > Cc: gnupg-devel at gnupg.org > Date: Mon, 08 Oct 2012 14:13:26 +0200 > Subject: Re: GPGME install requirements > On Mon, 8 Oct 2012 01:07, roberto.c.aguilar at gmail.com said: > > > I've done some cursory tests and confirm that if the binary gpg2 is > > not available GPGME does not work. Does gpgme shell out to gpg2 > > internally? > > Sure. GPGME delegates its actual work to a crypto engine, which is > gpgsm for S/MIME and gpg for OpenPGP. GnuPG 2.x installs by default > under the name gpg2 and GPGME may or may not know about this - it > depends on how you built it (cf. configure option --with-gpg=NAME). > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > > > > ---------- Forwarded message ---------- > From: NIIBE Yutaka > To: gnupg-devel at gnupg.org > Cc: > Date: Tue, 09 Oct 2012 12:44:00 +0900 > Subject: NeuG and FST-01 > Hello, > > Version 0.03 of NeuG, a True Random Number Generator Implementation > (for STM32F103), is released. > > While my intention of developing NeuG is for use as part of Gnuk, I > think that stand alone version of NeuG device (it runs as > /dev/ttyACM0) is also useful to feed entropy to your computer. For > example, it is useful when you generate many GnuPG keys. > > I wrote a page for NeuG: > > http://www.gniibe.org/memo/development/gnuk/rng/neug > > Your comments will be appreciated. > > > Besides, the hardware, FST-01 (evaluation board) is available now. > Last year, I designed this board for Gnuk, and the design of its PCB > is freely available. So far, only the prototype version of the > hardware has existed, but now, the mass production version is > available. Please visit our WiKi page for FST-01. > > http://www.seeedstudio.com/wiki/FST-01 > > Happy Hacking, > -- > > > > > > > > ---------- Forwarded message ---------- > From: "W. Trevor King" > To: gnupg-devel at gnupg.org > Cc: > Date: Wed, 10 Oct 2012 11:22:41 -0400 > Subject: Re: gpgme-tool socket interface > On Sun, Oct 07, 2012 at 07:41:41PM -0400, W. Trevor King wrote: > > b) gpgme: copy gpg-agent's socket handling code into gpgme-tool (with > > copy-paste commits for proper attribution, followed by integration > > commits by me). > > > > c) same as (b), but I'll write up the socket handling from scratch > > (man pages, etc.) to keep the code-base distinct from GnuPG. Since > > I can't look at gpg-agent's code, I'll probably someone else to > > handle the MS Windows side, if people want that to be supported. > > Since we're just adding functionality, I see no reason why Windows > > *must* be supported. > > A very rough commit along the lines of (c) is in my `socket` branch > [1], if anyone wants to poke about. > > [1]: http://git.tremily.us/?p=gpgme.git > > -- > 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 > > > ---------- Forwarded message ---------- > From: Werner Koch > To: "W. Trevor King" > Cc: GnuPG > Date: Thu, 11 Oct 2012 17:05:52 +0200 > Subject: Re: [PATCH v2] gpgme-tool: escape special characters in output XML data (<, >, and &). > On Sat, 6 Oct 2012 17:30, wking at tremily.us said: > > src/gpgme-tool.c (result_xml_escape_replacement, result_xml_escape): > > New. > > (result_xml_tag_data): Use result_xml_escape() to escape data. > > (result_add_error): Use unescaped < and >. > > Applied. I also commited an additional change to make the code more > robust. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > > > > ---------- Forwarded message ---------- > From: Werner Koch > To: "W. Trevor King" > Cc: gnupg-devel at gnupg.org > Date: Thu, 11 Oct 2012 17:18:30 +0200 > Subject: Re: gpgme-tool socket interface > On Mon, 8 Oct 2012 01:41, wking at tremily.us said: > > > for additional socket-server utility code in libassuan, and that > > didn't seem to be going over very well. I still think that's the best > > Right, it is too hard to get this into Libassuan in a flexible way. You > would end up with something as complicated as the gpgme event code. > > > a) libassuan: Some variation on my original suggestion: a helper > > function to spawn an Assuan server (either pipe or socket) which > > handles all the usual setup/teardown internally. Both gpg-agent > > If it ever turns out that this is required by a lot of other code, we > can revisit this then. > > > b) gpgme: copy gpg-agent's socket handling code into gpgme-tool (with > > copy-paste commits for proper attribution, followed by integration > > Fine. However, gpg-agent heavily relies on nPth semantics. This is > probably not what you want. > > > c) same as (b), but I'll write up the socket handling from scratch > > (man pages, etc.) to keep the code-base distinct from GnuPG. Since > > I can't look at gpg-agent's code, I'll probably someone else to > > handle the MS Windows side, if people want that to be supported. > > Actually we have a platform independent socket abstraction in libassuan > for that purpose. Check out how it is done in dirmngr or gpg-agent. > > > Since we're just adding functionality, I see no reason why Windows > > *must* be supported. > > We can talk about neglecting WindowsCE, but Windows is a/the mainstream > platform and thus we should support it. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > > > > ---------- Forwarded message ---------- > From: Werner Koch > To: "W. Trevor King" > Cc: gnupg-devel at gnupg.org > Date: Thu, 11 Oct 2012 17:20:24 +0200 > Subject: Re: gpgme-tool socket interface > On Wed, 10 Oct 2012 17:22, wking at tremily.us said: > > > A very rough commit along the lines of (c) is in my `socket` branch > > Is there a reason why you do not use assuan_sock_new et al? > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > > > > ---------- Forwarded message ---------- > From: "W. Trevor King" > To: gnupg-devel at gnupg.org > Cc: > Date: Thu, 11 Oct 2012 15:07:43 -0400 > Subject: Re: gpgme-tool socket interface > On Thu, Oct 11, 2012 at 05:18:30PM +0200, Werner Koch wrote: > > > b) gpgme: copy gpg-agent's socket handling code into gpgme-tool (with > > > copy-paste commits for proper attribution, followed by integration > > > > Fine. However, gpg-agent heavily relies on nPth semantics. This is > > probably not what you want. > > The socket setup and teardown shouldn't be too tied up in the > threading, so I'll take a look. > > > > c) same as (b), but I'll write up the socket handling from scratch > > > (man pages, etc.) to keep the code-base distinct from GnuPG. Since > > > I can't look at gpg-agent's code, I'll probably someone else to > > > handle the MS Windows side, if people want that to be supported. > > > > Actually we have a platform independent socket abstraction in libassuan > > for that purpose. Check out how it is done in dirmngr or gpg-agent. > > Good point. I'm talking a look at that now. > > On Thu, Oct 11, 2012 at 05:20:24PM +0200, Werner Koch wrote: > > On Wed, 10 Oct 2012 17:22, wking at tremily.us said: > > > A very rough commit along the lines of (c) is in my `socket` branch > > > > Is there a reason why you do not use assuan_sock_new et al? > > I didn't read the libassuan manual thoroughly enough ;). > > I'm a bit confused about how to handle listen() and accept(), which > are not wrapped by libassuan. libassuan's test/ce-server.c uses > SOCKET2HANDLE() and HANDLE2SOCKET() defined in assuan-def.h to convert > between `assuan_fd_t`s and `int`s, while gpg-agent uses INT2FD() and > FD2INT() defined in sysutils.h to convert between `gnupg_fd_t`s and > `int`s. Perhaps I should be using assuan_fdopen() instead of > INT2FD()? I'm not sure what the most idomatic approach is. > > I've rebased my socket branch against the new master, and slacked off > on commit messages. I'll beat them back into shape once the code gets > to a merge-able state. > > -- > 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 > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans at guardianproject.info Tue Oct 16 23:51:24 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 16 Oct 2012 17:51:24 -0400 Subject: GPGME_DEBUG on Android, which makes env vars hard In-Reply-To: <87fw668a2r.fsf@vigenere.g10code.de> References: <504118FF.3080308@guardianproject.info> <50464131.2000608@guardianproject.info> <87fw668a2r.fsf@vigenere.g10code.de> Message-ID: <507DD6DC.9000402@guardianproject.info> On 09/25/2012 10:13 AM, Werner Koch wrote: > 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? OMG, thank you! Its working for me. This makes life soooo much easier, rather than flying blind. Here's how I used it: ... setlocale(LC_ALL, ""); gpgme_set_global_flag("debug", "9:/data/data/info.guardianproject.gpg/app_log/gpgme.log"); const char* version = gpgme_check_version(NULL); ... .hc From hans at guardianproject.info Wed Oct 17 00:54:32 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 16 Oct 2012 18:54:32 -0400 Subject: gpgme_op_keylist_start: error: Invalid crypto engine Message-ID: <507DE5A8.9010505@guardianproject.info> So the gpgme logging did give me some insight into what gpgme is doing, from that I added 'g13' to the build, so now that's included. But unfortunately the log doesn't give any more detail about the "Invalid crypto engine" error that is the show stopper. I have the debug level set to 9, I think that's the highest level. This is what I get right before: GPGME 2012-09-14 23:07:55 <0x0d6e> gpgme_new: enter: r_ctx=0xbef116d4 GPGME 2012-09-14 23:07:55 <0x0d6e> gpgme_new: leave: ctx=0x2a0d7f18 GPGME 2012-09-14 23:07:55 <0x0d6e> gpgme_set_armor: call: ctx=0x2a0d7f18, use_armor=1 (yes) GPGME 2012-09-14 23:07:55 <0x0d6e> gpgme_set_textmode: call: ctx=0x2a0d7f18, use_textmode=1 (yes) GPGME 2012-09-14 23:07:55 <0x0d6e> gpgme_set_keylist_mode: call: ctx=0x2a0d7f18, keylist_mode=0x5 GPGME 2012-09-14 23:08:11 <0x0d6e> gpgme_op_keylist_start: enter: ctx=0x2a0d7f18, pattern=search-tring, secret_only=0 GPGME 2012-09-14 23:08:11 <0x0d6e> gpgme_op_keylist_start: error: Invalid crypto engine The whole log is attached. .hc -------------- next part -------------- A non-text attachment was scrubbed... Name: gpgme.log.bz2 Type: application/x-bzip Size: 1069 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 937 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Oct 17 18:59:03 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Oct 2012 18:59:03 +0200 Subject: gpgme_op_keylist_start: error: Invalid crypto engine In-Reply-To: <507DE5A8.9010505@guardianproject.info> (Hans-Christoph Steiner's message of "Tue, 16 Oct 2012 18:54:32 -0400") References: <507DE5A8.9010505@guardianproject.info> Message-ID: <87ehkxm3vs.fsf@vigenere.g10code.de> On Wed, 17 Oct 2012 00:54, hans at guardianproject.info said: > So the gpgme logging did give me some insight into what gpgme is doing, > from that I added 'g13' to the build, so now that's included. But I doubt that you need it; it currently works only with encfs and has not been tested for a long time. However, that is not your problem. > unfortunately the log doesn't give any more detail about the "Invalid > crypto engine" error that is the show stopper. Argh, that damned catch-all error code. > GPGME 2012-09-14 23:08:11 <0x0d6e> gpgme_op_keylist_start: error: > Invalid crypto engine I guess this comes directly from engine-gpg.c. What I would do is to replace gpg2 by a wrapper script to log the environment and args. Something like this: ==== #!/bin/sh echo ============ >>/tmp/gpg2.log echo === BEGIN == >>/tmp/gpg2.log echo ============ >>/tmp/gpg2.log printenv >>/tmp/gpg2.log echo "$@" >>/tmp/gpg2.log exec /foo/bar/gpg2-real "$@" ===== Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Thu Oct 18 00:49:37 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 17 Oct 2012 18:49:37 -0400 Subject: gpgme_op_keylist_start: error: Invalid crypto engine In-Reply-To: <87ehkxm3vs.fsf@vigenere.g10code.de> References: <507DE5A8.9010505@guardianproject.info> <87ehkxm3vs.fsf@vigenere.g10code.de> Message-ID: <507F3601.2040203@guardianproject.info> On 10/17/2012 12:59 PM, Werner Koch wrote: > On Wed, 17 Oct 2012 00:54, hans at guardianproject.info said: > >> So the gpgme logging did give me some insight into what gpgme is doing, >> from that I added 'g13' to the build, so now that's included. But > > I doubt that you need it; it currently works only with encfs and has not > been tested for a long time. However, that is not your problem. > >> unfortunately the log doesn't give any more detail about the "Invalid >> crypto engine" error that is the show stopper. > > Argh, that damned catch-all error code. > >> GPGME 2012-09-14 23:08:11 <0x0d6e> gpgme_op_keylist_start: error: >> Invalid crypto engine > > I guess this comes directly from engine-gpg.c. What I would do is to > replace gpg2 by a wrapper script to log the environment and args. > > Something like this: > ==== > #!/bin/sh > > echo ============ >>/tmp/gpg2.log > echo === BEGIN == >>/tmp/gpg2.log > echo ============ >>/tmp/gpg2.log > printenv >>/tmp/gpg2.log > echo "$@" >>/tmp/gpg2.log > exec /foo/bar/gpg2-real "$@" > ===== That worked for getting logs, but I'm not seeing anything in the gpg2.log that's coming from the gpgme startup. Here are the logs (they are also attached): dirmngr.log ---------------------------- 2012-10-17 19:57:48 dirmngr[957.0] listening on socket '/data/data/info.guardianproject.gpg/app_opt/var/run/gnupg/S.dirmngr' 2012-10-17 19:57:48 dirmngr[958.0] permanently loaded certificates: 0 2012-10-17 19:57:48 dirmngr[958.0] runtime cached certificates: 0 gpg2.log ---------------------------- ============ === BEGIN == ============ ANDROID_ROOT=/system LD_LIBRARY_PATH=/vendor/lib:/system/lib PATH=/sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin LOOP_MOUNTPOINT=/mnt/obb ASEC_MOUNTPOINT=/mnt/asec ANDROID_SOCKET_zygote=9 BOOTCLASSPATH=/system/framework/core.jar:/system/framework/core-junit.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/apache-xml.jar ANDROID_BOOTLOGO=1 ANDROID_ASSETS=/system/app EXTERNAL_STORAGE=/mnt/sdcard ANDROID_DATA=/data ANDROID_PROPERTY_WORKSPACE=8,32768 --version gpg-agent.log ---------------------------- 2012-10-17 19:57:47 gpg-agent[946] listening on socket '/data/data/info.guardianproject.gpg/app_home/.gnupg/S.gpg-agent' 2012-10-17 19:57:47 gpg-agent[956] gpg-agent (GnuPG) 2.1.0-beta82 started 2012-10-17 19:58:50 gpg-agent[956] handler 0x563d0 for fd 6 started 2012-10-17 19:58:50 gpg-agent[956] DBG: chan_6 -> OK Pleased to meet you, process 956 2012-10-17 19:58:50 gpg-agent[956] DBG: chan_5 <- OK Pleased to meet you, process 956 2012-10-17 19:58:50 gpg-agent[956] DBG: chan_5 -> GETINFO pid 2012-10-17 19:58:50 gpg-agent[956] DBG: chan_6 <- GETINFO pid 2012-10-17 19:58:50 gpg-agent[956] DBG: chan_6 -> D 956 2012-10-17 19:58:50 gpg-agent[956] DBG: chan_5 <- D 956 2012-10-17 19:58:50 gpg-agent[956] DBG: chan_6 -> OK 2012-10-17 19:58:50 gpg-agent[956] DBG: chan_5 <- OK 2012-10-17 19:58:50 gpg-agent[956] DBG: chan_5 -> BYE 2012-10-17 19:58:50 gpg-agent[956] DBG: chan_6 <- BYE 2012-10-17 19:58:50 gpg-agent[956] DBG: chan_6 -> OK closing connection 2012-10-17 19:58:50 gpg-agent[956] handler 0x563d0 for fd 6 terminated 2012-10-17 19:59:50 gpg-agent[956] handler 0x563d0 for fd 6 started 2012-10-17 19:59:50 gpg-agent[956] DBG: chan_6 -> OK Pleased to meet you, process 956 2012-10-17 19:59:50 gpg-agent[956] DBG: chan_5 <- OK Pleased to meet you, process 956 2012-10-17 19:59:50 gpg-agent[956] DBG: chan_5 -> GETINFO pid 2012-10-17 19:59:50 gpg-agent[956] DBG: chan_6 <- GETINFO pid 2012-10-17 19:59:50 gpg-agent[956] DBG: chan_6 -> D 956 2012-10-17 19:59:50 gpg-agent[956] DBG: chan_5 <- D 956 2012-10-17 19:59:50 gpg-agent[956] DBG: chan_6 -> OK 2012-10-17 19:59:50 gpg-agent[956] DBG: chan_5 <- OK 2012-10-17 19:59:50 gpg-agent[956] DBG: chan_5 -> BYE 2012-10-17 19:59:50 gpg-agent[956] DBG: chan_6 <- BYE 2012-10-17 19:59:50 gpg-agent[956] DBG: chan_6 -> OK closing connection 2012-10-17 19:59:50 gpg-agent[956] handler 0x563d0 for fd 6 terminated gpgme.log ---------------------------- GPGME 2012-10-17 15:57:45 <0x0391> gpgme_debug: level=9 GPGME 2012-10-17 15:57:45 <0x0391> gpgme_check_version: call: 0=0x0, req_version=(null), VERSION=1.3.3-git83e7420 GPGME 2012-10-17 15:57:45 <0x0391> gpgme_check_version_internal: call: 0=0x0, req_version=(null), offset_sig_validity=32 GPGME 2012-10-17 15:57:45 <0x0391> gpgme_set_locale: enter: ctx=0x0, category=0, value=(null) GPGME 2012-10-17 15:57:45 <0x0391> gpgme_set_locale: leave GPGME 2012-10-17 15:57:45 <0x0391> gpgme_set_locale: enter: ctx=0x0, category=5, value=(null) GPGME 2012-10-17 15:57:45 <0x0391> gpgme_set_locale: leave GPGME 2012-10-17 15:57:45 <0x0391> _gpgme_io_pipe: enter: filedes=0xbeac65dc, inherit_idx=1 (GPGME uses it for reading) GPGME 2012-10-17 15:57:45 <0x0391> _gpgme_io_pipe: leave: read=0x25, write=0x26 GPGME 2012-10-17 15:57:45 <0x0391> _gpgme_io_spawn: enter: path=0x4a2ea798, path=/data/data/info.guardianproject.gpg/app_opt/bin/gpg2 GPGME 2012-10-17 15:57:45 <0x0391> _gpgme_io_spawn: check: path=0x4a2ea798, argv[ 0] = /data/data/info.guardianproject.gpg/app_opt/bin/gpg2 GPGME 2012-10-17 15:57:45 <0x0391> _gpgme_io_spawn: check: path=0x4a2ea798, argv[ 1] = --version GPGME 2012-10-17 15:57:45 <0x0391> _gpgme_io_spawn: check: path=0x4a2ea798, fd[0] = 0x26 -> 0x1 GPGME 2012-10-17 15:57:45 <0x0391> _gpgme_io_spawn: check: path=0x4a2ea798, waiting for child process pid=941 GPGME 2012-10-17 15:57:45 <0x03ae> gpgme:max_fds: call: 0=0x0, max fds=1024 (RLIMIT_NOFILE) GPGME 2012-10-17 15:57:45 <0x0391> _gpgme_io_close: enter: fd=0x26 GPGME 2012-10-17 15:57:45 <0x0391> _gpgme_io_close: leave: result=0 GPGME 2012-10-17 15:57:45 <0x0391> _gpgme_io_spawn: leave: result=0 GPGME 2012-10-17 15:57:45 <0x0391> _gpgme_io_read: enter: fd=0x25, buffer=0xbeac65e4, count=79 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_read: leave: result=0 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_close: enter: fd=0x25 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_close: leave: result=0 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_pipe: enter: filedes=0xbeac65dc, inherit_idx=1 (GPGME uses it for reading) GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_pipe: leave: read=0x25, write=0x26 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_spawn: enter: path=0x4a2ea7d0, path=/data/data/info.guardianproject.gpg/app_opt/bin/gpgsm GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_spawn: check: path=0x4a2ea7d0, argv[ 0] = /data/data/info.guardianproject.gpg/app_opt/bin/gpgsm GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_spawn: check: path=0x4a2ea7d0, argv[ 1] = --version GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_spawn: check: path=0x4a2ea7d0, fd[0] = 0x26 -> 0x1 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_spawn: check: path=0x4a2ea7d0, waiting for child process pid=948 GPGME 2012-10-17 15:57:46 <0x03b5> gpgme:max_fds: call: 0=0x0, max fds=1024 (RLIMIT_NOFILE) GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_close: enter: fd=0x26 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_close: leave: result=0 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_spawn: leave: result=0 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_read: enter: fd=0x25, buffer=0xbeac65e4, count=79 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_read: leave: result=0 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_close: enter: fd=0x25 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_close: leave: result=0 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_pipe: enter: filedes=0xbeac65dc, inherit_idx=1 (GPGME uses it for reading) GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_pipe: leave: read=0x25, write=0x26 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_spawn: enter: path=0x4a2ea808, path=/data/data/info.guardianproject.gpg/app_opt/bin/gpgconf GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_spawn: check: path=0x4a2ea808, argv[ 0] = /data/data/info.guardianproject.gpg/app_opt/bin/gpgconf GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_spawn: check: path=0x4a2ea808, argv[ 1] = --version GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_spawn: check: path=0x4a2ea808, fd[0] = 0x26 -> 0x1 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_spawn: check: path=0x4a2ea808, waiting for child process pid=950 GPGME 2012-10-17 15:57:46 <0x03b7> gpgme:max_fds: call: 0=0x0, max fds=1024 (RLIMIT_NOFILE) GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_close: enter: fd=0x26 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_close: leave: result=0 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_spawn: leave: result=0 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_read: enter: fd=0x25, buffer=0xbeac65e4, count=79 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_read: leave: result=0 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_close: enter: fd=0x25 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_close: leave: result=0 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_pipe: enter: filedes=0xbeac6204, inherit_idx=1 (GPGME uses it for reading) GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_pipe: leave: read=0x25, write=0x26 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_spawn: enter: path=0x4a2ea808, path=/data/data/info.guardianproject.gpg/app_opt/bin/gpgconf GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_spawn: check: path=0x4a2ea808, argv[ 0] = /data/data/info.guardianproject.gpg/app_opt/bin/gpgconf GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_spawn: check: path=0x4a2ea808, argv[ 1] = --list-dirs GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_spawn: check: path=0x4a2ea808, fd[0] = 0x26 -> 0x1 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_spawn: check: path=0x4a2ea808, waiting for child process pid=952 GPGME 2012-10-17 15:57:46 <0x03b9> gpgme:max_fds: call: 0=0x0, max fds=1024 (RLIMIT_NOFILE) GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_close: enter: fd=0x26 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_close: leave: result=0 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_spawn: leave: result=0 GPGME 2012-10-17 15:57:46 <0x0391> _gpgme_io_read: enter: fd=0x25, buffer=0xbeac6218, count=1023 GPGME 2012-10-17 15:57:47 <0x0391> _gpgme_io_read: leave: result=0 GPGME 2012-10-17 15:57:47 <0x0391> _gpgme_io_close: enter: fd=0x25 GPGME 2012-10-17 15:57:47 <0x0391> _gpgme_io_close: leave: result=0 GPGME 2012-10-17 15:57:47 <0x0391> _gpgme_io_pipe: enter: filedes=0xbeac65dc, inherit_idx=1 (GPGME uses it for reading) GPGME 2012-10-17 15:57:47 <0x0391> _gpgme_io_pipe: leave: read=0x25, write=0x26 GPGME 2012-10-17 15:57:47 <0x0391> _gpgme_io_spawn: enter: path=0x4a2ea840, path=/data/data/info.guardianproject.gpg/app_opt/bin/g13 GPGME 2012-10-17 15:57:47 <0x0391> _gpgme_io_spawn: check: path=0x4a2ea840, argv[ 0] = /data/data/info.guardianproject.gpg/app_opt/bin/g13 GPGME 2012-10-17 15:57:47 <0x0391> _gpgme_io_spawn: check: path=0x4a2ea840, argv[ 1] = --version GPGME 2012-10-17 15:57:47 <0x0391> _gpgme_io_spawn: check: path=0x4a2ea840, fd[0] = 0x26 -> 0x1 GPGME 2012-10-17 15:57:47 <0x0391> _gpgme_io_spawn: check: path=0x4a2ea840, waiting for child process pid=954 GPGME 2012-10-17 15:57:47 <0x03bb> gpgme:max_fds: call: 0=0x0, max fds=1024 (RLIMIT_NOFILE) GPGME 2012-10-17 15:57:47 <0x0391> _gpgme_io_close: enter: fd=0x26 GPGME 2012-10-17 15:57:47 <0x0391> _gpgme_io_close: leave: result=0 GPGME 2012-10-17 15:57:47 <0x0391> _gpgme_io_spawn: leave: result=0 GPGME 2012-10-17 15:57:47 <0x0391> _gpgme_io_read: enter: fd=0x25, buffer=0xbeac65e4, count=79 GPGME 2012-10-17 15:57:47 <0x0391> _gpgme_io_read: leave: result=0 GPGME 2012-10-17 15:57:47 <0x0391> _gpgme_io_close: enter: fd=0x25 GPGME 2012-10-17 15:57:47 <0x0391> _gpgme_io_close: leave: result=0 GPGME 2012-10-17 15:57:47 <0x0391> gpgme_new: enter: r_ctx=0xbeac66d4 GPGME 2012-10-17 15:57:47 <0x0391> gpgme_new: leave: ctx=0x2a0d89a8 GPGME 2012-10-17 15:57:47 <0x0391> gpgme_set_armor: call: ctx=0x2a0d89a8, use_armor=1 (yes) GPGME 2012-10-17 15:57:47 <0x0391> gpgme_set_textmode: call: ctx=0x2a0d89a8, use_textmode=1 (yes) GPGME 2012-10-17 15:57:47 <0x0391> gpgme_set_keylist_mode: call: ctx=0x2a0d89a8, keylist_mode=0x5 GPGME 2012-10-17 15:58:25 <0x0391> gpgme_op_keylist_start: enter: ctx=0x2a0d89a8, pattern=hans, secret_only=0 GPGME 2012-10-17 15:58:25 <0x0391> gpgme_op_keylist_start: error: Invalid crypto engine -------------- next part -------------- A non-text attachment was scrubbed... Name: gpg-logs.tar.bz2 Type: application/x-bzip Size: 1975 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 937 bytes Desc: OpenPGP digital signature URL: From l.stelmach at samsung.com Thu Oct 18 17:52:00 2012 From: l.stelmach at samsung.com (=?utf-8?Q?=C5=81ukasz?= Stelmach) Date: Thu, 18 Oct 2012 17:52:00 +0200 Subject: start gpg-agent with systemd Message-ID: <87d30fzskf.fsf@samsung.com> Hi. I work on systemd integration both as a replacement for init as well as user session manager. I've tried to start gpg-agent as a part of user serssion and found it does not fit well there. Agent's default behavior (socket in a randomly named directory) and the information printed on stdout or saved in a file is hard to handle. I'd like create a patch for the agent to make it work well with systemd, preferably with its socket activation feature. I'd like/need to know: 1. Do you, Gnupg developers, want such a feature and will you accept such a patch (of course only if it meets your quality standards). 2. Other systemd syservices use $XDG_RUNTIME_DIR[fn:1] to put their runtime stuff (sockets, flags). I'd like gpg-agent to use it too. 3. GPG_AGENT_INFO variable holds agent's PID. It is passed to assuan library function that connects to a socket but isn't used there. Is it going to be required in the future? Passing this information during parlell startup "sequence" without locking and waiting for the agent to start is impossible as well as during socket-activated start. Please, give me your comments. The most important for me at the moment is the 1st question ;) Footnotes: [fn:1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html -- ?ukasz Stelmach Software wizzard Samsung Poland R&D Center Al. Armii Ludowej 26, 00-609 Warszawa http://www.rd.samsung.pl From wk at gnupg.org Thu Oct 18 21:00:20 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 18 Oct 2012 21:00:20 +0200 Subject: start gpg-agent with systemd In-Reply-To: <87d30fzskf.fsf@samsung.com> (=?utf-8?Q?=22=C5=81ukasz?= Stelmach"'s message of "Thu, 18 Oct 2012 17:52:00 +0200") References: <87d30fzskf.fsf@samsung.com> Message-ID: <87d30fli63.fsf@vigenere.g10code.de> On Thu, 18 Oct 2012 17:52, l.stelmach at samsung.com said: > I work on systemd integration both as a replacement for init as well as > user session manager. I've tried to start gpg-agent as a part of user > serssion and found it does not fit well there. Agent's default behavior > (socket in a randomly named directory) and the information printed on > stdout or saved in a file is hard to handle. For quite some time now this default may be changed with a configure option. 2.1 will make this the new default. The rationale for this change is that the majority of systems do not use remote mounted home directories which won't work with local sockets. Those installations with these problems will anyway be controlled by sysadmins who can change the default (with a gpg-agent.conf option). > 1. Do you, Gnupg developers, want such a feature and will you accept > such a patch (of course only if it meets your quality standards). No. If systemd does not adhere to Unix standards, it is the problem of systemd. GnuPG is a portable application and in no way limited to Linux. > 2. Other systemd syservices use $XDG_RUNTIME_DIR[fn:1] to put their > runtime stuff (sockets, flags). I'd like gpg-agent to use it too. If that becomes part of POSIX, we can talk about it. > 3. GPG_AGENT_INFO variable holds agent's PID. It is passed to assuan > library function that connects to a socket but isn't used there. Is it > going to be required in the future? Passing this information during > parlell startup "sequence" without locking and waiting for the agent to > start is impossible as well as during socket-activated start. It is not used. But, as mentioned above: The new default will be an on demand started gpg-agent and that should solve all your problems. In fact we use that on Windows for many years now. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Oct 18 21:06:36 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 18 Oct 2012 21:06:36 +0200 Subject: gpgme_op_keylist_start: error: Invalid crypto engine In-Reply-To: <507F3601.2040203@guardianproject.info> (Hans-Christoph Steiner's message of "Wed, 17 Oct 2012 18:49:37 -0400") References: <507DE5A8.9010505@guardianproject.info> <87ehkxm3vs.fsf@vigenere.g10code.de> <507F3601.2040203@guardianproject.info> Message-ID: <878vb3lhvn.fsf@vigenere.g10code.de> On Thu, 18 Oct 2012 00:49, hans at guardianproject.info said: > gpg2.log > ---------------------------- > ============ > === BEGIN == > ============ [...] > --version That is the first call of gpgme to gpg - it checks the version of gpg. I have no idea why we see that problem. I guess the easiest way will be to do printf debugging. Let me know if I should prepare a patch tomorrow morning. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Thu Oct 18 21:25:29 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 18 Oct 2012 15:25:29 -0400 Subject: gpgme_op_keylist_start: error: Invalid crypto engine In-Reply-To: <878vb3lhvn.fsf@vigenere.g10code.de> References: <507DE5A8.9010505@guardianproject.info> <87ehkxm3vs.fsf@vigenere.g10code.de> <507F3601.2040203@guardianproject.info> <878vb3lhvn.fsf@vigenere.g10code.de> Message-ID: <508057A9.2090403@guardianproject.info> On 10/18/2012 03:06 PM, Werner Koch wrote: > On Thu, 18 Oct 2012 00:49, hans at guardianproject.info said: > >> gpg2.log >> ---------------------------- >> ============ >> === BEGIN == >> ============ > [...] > >> --version > > That is the first call of gpgme to gpg - it checks the version of gpg. > I have no idea why we see that problem. I guess the easiest way will be > to do printf debugging. Let me know if I should prepare a patch > tomorrow morning. I'll dig some more and see what I can come up with. Still learning my way around this code. .hc From hans at guardianproject.info Fri Oct 19 06:26:16 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 19 Oct 2012 00:26:16 -0400 Subject: gpgme_op_keylist_start: error: Invalid crypto engine In-Reply-To: <508057A9.2090403@guardianproject.info> References: <507DE5A8.9010505@guardianproject.info> <87ehkxm3vs.fsf@vigenere.g10code.de> <507F3601.2040203@guardianproject.info> <878vb3lhvn.fsf@vigenere.g10code.de> <508057A9.2090403@guardianproject.info> Message-ID: <5080D668.9070807@guardianproject.info> On 10/18/2012 03:25 PM, Hans-Christoph Steiner wrote: > > > On 10/18/2012 03:06 PM, Werner Koch wrote: >> On Thu, 18 Oct 2012 00:49, hans at guardianproject.info said: >> >>> gpg2.log >>> ---------------------------- >>> ============ >>> === BEGIN == >>> ============ >> [...] >> >>> --version >> >> That is the first call of gpgme to gpg - it checks the version of gpg. >> I have no idea why we see that problem. I guess the easiest way will be >> to do printf debugging. Let me know if I should prepare a patch >> tomorrow morning. > > I'll dig some more and see what I can come up with. Still learning my > way around this code. I didn't get very far today. A patch with printf()s would be much appreciated. .hc From l.stelmach at samsung.com Fri Oct 19 08:37:55 2012 From: l.stelmach at samsung.com (=?utf-8?Q?=C5=81ukasz?= Stelmach) Date: Fri, 19 Oct 2012 08:37:55 +0200 Subject: start gpg-agent with systemd In-Reply-To: <87d30fli63.fsf@vigenere.g10code.de> References: <87d30fzskf.fsf@samsung.com> <87d30fli63.fsf@vigenere.g10code.de> Message-ID: <878vb3rmpo.fsf@samsung.com> It was <2012-10-18 czw 21:00>, when Werner Koch wrote: > On Thu, 18 Oct 2012 17:52, l.stelmach at samsung.com said: Thank you for your reply. Let me ask, however, few more questions and describe my idea in greater details. >> I work on systemd integration both as a replacement for init as well as >> user session manager. I've tried to start gpg-agent as a part of user >> serssion and found it does not fit well there. Agent's default behavior >> (socket in a randomly named directory) and the information printed on >> stdout or saved in a file is hard to handle. > > For quite some time now this default may be changed with a configure > option. 2.1 will make this the new default. The rationale for this > change is that the majority of systems do not use remote mounted home > directories which won't work with local sockets. Those installations > with these problems will anyway be controlled by sysadmins who can > change the default (with a gpg-agent.conf option). Yes I've seen it I and wanted use this code path and check if XDG_RUNTIME_DIR is set and prefer it over opt.homedir. I was wondering why the option named --use-standard-socket is an option :) >> 1. Do you, Gnupg developers, want such a feature and will you accept >> such a patch (of course only if it meets your quality standards). > > No. If systemd does not adhere to Unix standards, it is the problem of > systemd. GnuPG is a portable application and in no way limited to > Linux. In what parts (that would affect gpg-agent) in your opinion systemd does not adhere to Unix standards? (I am simply curious.) >> 2. Other systemd syservices use $XDG_RUNTIME_DIR[fn:1] to put their >> runtime stuff (sockets, flags). I'd like gpg-agent to use it too. > > If that becomes part of POSIX, we can talk about it. Could there be an option to place the socket(s) in an arbitrary directory and not necessarily choose between /tmp/gnupg-XXXX/ and ~/.gnupg? Of course systemd can create a socket in ~/.gnupg/ too. >> 3. GPG_AGENT_INFO variable holds agent's PID. It is passed to assuan >> library function that connects to a socket but isn't used there. Is it >> going to be required in the future? Passing this information during >> parlell startup "sequence" without locking and waiting for the agent to >> start is impossible as well as during socket-activated start. > > It is not used. But, as mentioned above: The new default will be an on > demand started gpg-agent and that should solve all your problems. In > fact we use that on Windows for many years now. I see. With the socket in a standard place this is feasible. However, it is only systemd's socket activation that could start gpg-agent on reqest from ssh client. The change required to use the socket activation isn't IMHO big. Systemd binds a Unix socket and starts listening. When a new conection comes then, depending on the value of Accept[1] option: true - it accepts the connection and spawns a server process to handle it and passes a *connected* socket as stdin/stdout, and keeps listening. false - it spawns the server and passes the *listening* socket as stdin/stdout and it is servers responsibility to accept(2) the connection. systemd starts listening again only when the server exits. My idea was to use Accept=false (think inted's wait) and change the code path for the --server option to check if the stdin is a socket and wait for another connection rather than exit upon BYE. On the other hand some changes to systemd might be required to to handle two sockets with one server. Best regards. Footnotes: [1] http://www.freedesktop.org/software/systemd/man/systemd.socket.html -- ?ukasz Stelmach Software wizzard Samsung Poland R&D Center Al. Armii Ludowej 26, 00-609 Warszawa http://www.rd.samsung.pl From wk at gnupg.org Fri Oct 19 11:28:41 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 19 Oct 2012 11:28:41 +0200 Subject: gpgme_op_keylist_start: error: Invalid crypto engine In-Reply-To: <5080D668.9070807@guardianproject.info> (Hans-Christoph Steiner's message of "Fri, 19 Oct 2012 00:26:16 -0400") References: <507DE5A8.9010505@guardianproject.info> <87ehkxm3vs.fsf@vigenere.g10code.de> <507F3601.2040203@guardianproject.info> <878vb3lhvn.fsf@vigenere.g10code.de> <508057A9.2090403@guardianproject.info> <5080D668.9070807@guardianproject.info> Message-ID: <87vce6kdyu.fsf@vigenere.g10code.de> On Fri, 19 Oct 2012 06:26, hans at guardianproject.info said: > I didn't get very far today. A patch with printf()s would be much > appreciated. Okay, I did something more general. bd24fea Trace the use of GPG_ERR_INV_ENGINE. * src/debug.h: Include "gpgme.h" (_gpgme_trace_gpgme_error): New. (trace_gpg_error): New macro. Use it in all files where we return GPG_ERR_INV_ENGINE; also "include debug.h" as needed. -- This is a pretty common error code but often it is hard to figure out the actual cause. With debug level 4 we now print the file name and line number where this error code is generated by gpgme. Along with the git revision printed in the first log lines, this should give us an easier way to track down the problems related to this error code. Sample output is now engine-gpg.c:1272: returning error: Invalid crypto engine gpgme_op_keylist_start: error: Invalid crypto engine With the exact location it should be easy to figure out what's going wrong. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jeanjacquesbrucker at gmail.com Fri Oct 19 13:58:38 2012 From: jeanjacquesbrucker at gmail.com (jbar) Date: Fri, 19 Oct 2012 13:58:38 +0200 Subject: patch to reveal bug and strange behaviours when GPGME_EXPORT_MODE_EXTERN is set Message-ID: <20121019135838.d06960e6.jeanjacquesbrucker@gmail.com> First as attachement u have my gpgme/tests/run-export.c and its diff from git://git.gnupg.org/gpgme.git You will see that Now "./run-export --extern USERID" doesn't send anymore key (But gpgme_op_export doesn't return any error). But, and that what is strange: "./run-export --extern KEY_IDS or FPRS " really send keys. - Why ?? If you compile with an added flag GET_KEY_FROM_ID it also works as expected. (But I didn't expect that since that's the procedure I use in my own program... where my "gpgme_op_export_keys(...GPGME_EXPORT_MODE_EXTERN...)" call fail without returning an error :'-( ). Also please give me some tips to understand why the procedure in my programm may behave like this !? Thanks, -- jbar -------------- next part -------------- A non-text attachment was scrubbed... Name: run-export.c.diff Type: application/octet-stream Size: 3181 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: run-export.c Type: text/x-c Size: 4754 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From bernd at wauland.de Fri Oct 19 19:49:39 2012 From: bernd at wauland.de (Bernd R. Fix) Date: Fri, 19 Oct 2012 19:49:39 +0200 Subject: Looking for GnuPG-compatible library for server application Message-ID: <508192B3.7000209@wauland.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 In a server application that is developed for one of the projects we are funding, the code currently uses a GnuPG wrapper (not GPGME but something similar) to perform key generation and encrytion/decryption of messages within the application. Although this approach works technically, the project team is not satisfied with the runtime behaviour of the crypto operations that take longer then necessary due to the fact that new instances of GnuPG have to be created for every operation. We are therefore looking for a library that provides GnuPG (OpenPGP) functionality and that can be used in a server application (Python/C) - but we can't find anything suitabe for our requirements: * C/C++ based OpenPGP functions (callable from Python) * support for ECC (as defined in RFC 6637) * full support of GnuPG functionality, especially anonymous multi-recipient messages * abstract keyring and trustdb handling (database persistence preferred as the current number of private keys is some 20'000 keys) Is there any plan to create such a library within the GnuPG project (as such a library could also be an abstraction layer between libgcrypt and the GnuPG executables)? Are any GnuPG developers willing to code such a library? The project has financial resources to aid the development within reasonable bounds if necessary. Thanks for your attention, Bernd P.S.: If such a library already exists and has just slipped our attention, please provide any pointer/link to it. >Y< - -- Wau-Holland-Stiftung W Postfach 65 04 43 H O L L A N D 22364 Hamburg/Germany S T I F T U N G http://www.wauland.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJQgZKrAAoJEN1A8liqzgHpWU8H/2xtqL/Ctinw9sWlXD0xq2K7 DldyVHzva4QiFbjWd9Lg5SoNejUqjAUuUkg+Gbc5L9M7tTOnW5e3I6JxeetTAlDf 7W0Uva0HbQE34Yv/PAZjfuk+anM2M+SvPe51F3DXJs6C6EOVZDKFI30VLe8FvCHQ mehX8P/PlcMlVB1zMUbTHD5qw8/7UaB1TbPKOuBXiSBFKeeJBY08rQZk8Hb5GIL8 W53MfWGfjajafg/T+TQBfMdVse3yMSRaBqVMqg7WBlt3tXXL+qB8wNmtJYwDnsol tyui0St9yNPZAtTHlpoGQJUvq6/DWgHlAFtpAPolOzQ9qAzQnb0l4UXZAKgsjCA= =pdYi -----END PGP SIGNATURE----- From wk at gnupg.org Fri Oct 19 22:34:02 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 19 Oct 2012 22:34:02 +0200 Subject: Looking for GnuPG-compatible library for server application In-Reply-To: <508192B3.7000209@wauland.de> (Bernd R. Fix's message of "Fri, 19 Oct 2012 19:49:39 +0200") References: <508192B3.7000209@wauland.de> Message-ID: <87k3umi4lh.fsf@vigenere.g10code.de> On Fri, 19 Oct 2012 19:49, bernd at wauland.de said: > Although this approach works technically, the project team is not > satisfied with the runtime behaviour of the crypto operations that take > longer then necessary due to the fact that new instances of GnuPG have > to be created for every operation. Technically this is not required. GPGME has been designed to allow running the engines as co-process, communicating over pipes with gpg. This has already been implemented for gpgsm (aka S/MIME), but not yet for gpg. That plan is to also have gpg running as a co-process. There is already some code in gpg to do this for verify but it needs to be extended. > Is there any plan to create such a library within the GnuPG project (as I once started tgpg as a simple OpenPGP library; but that is not what you want. > Are any GnuPG developers willing to code such a library? The project has My I race my hand ;-) Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Fri Oct 19 22:49:23 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 19 Oct 2012 16:49:23 -0400 Subject: Looking for GnuPG-compatible library for server application In-Reply-To: <87k3umi4lh.fsf@vigenere.g10code.de> References: <508192B3.7000209@wauland.de> <87k3umi4lh.fsf@vigenere.g10code.de> Message-ID: <5081BCD3.6040000@sixdemonbag.org> On 10/19/2012 4:34 PM, Werner Koch wrote: > GPGME has been designed to allow running the engines as co-process, > communicating over pipes with gpg. Speaking of GPGME, would it be possible for the next release of GPG4WIN to include the necessary headers for Win32 development against GPGME? From wk at gnupg.org Fri Oct 19 23:44:06 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 19 Oct 2012 23:44:06 +0200 Subject: Looking for GnuPG-compatible library for server application In-Reply-To: <5081BCD3.6040000@sixdemonbag.org> (Robert J. Hansen's message of "Fri, 19 Oct 2012 16:49:23 -0400") References: <508192B3.7000209@wauland.de> <87k3umi4lh.fsf@vigenere.g10code.de> <5081BCD3.6040000@sixdemonbag.org> Message-ID: <87wqymgms9.fsf@vigenere.g10code.de> On Fri, 19 Oct 2012 22:49, rjh at sixdemonbag.org said: > Speaking of GPGME, would it be possible for the next release of GPG4WIN > to include the necessary headers for Win32 development against GPGME? Sure, we should do that. The only problem I see is that you need to put the gpg4win installation directory into the DLLPATH. For binaries we have the "pub" directory to be included in PATH. Those binaries are actually wrappers to call the real binaries from the above directory (poor man's symlink). I am not sure how to do it with DLLs - maybe we can use hardlinks or the new Windows symlinks. But neither work on some file servers. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Sat Oct 20 01:54:07 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 19 Oct 2012 19:54:07 -0400 Subject: Looking for GnuPG-compatible library for server application In-Reply-To: <87wqymgms9.fsf@vigenere.g10code.de> References: <508192B3.7000209@wauland.de> <87k3umi4lh.fsf@vigenere.g10code.de> <5081BCD3.6040000@sixdemonbag.org> <87wqymgms9.fsf@vigenere.g10code.de> Message-ID: <5081E81F.8010500@sixdemonbag.org> On 10/19/2012 5:44 PM, Werner Koch wrote: > Sure, we should do that. The only problem I see is that you need to put > the gpg4win installation directory into the DLLPATH. For binaries we > have the "pub" directory to be included in PATH. Those binaries are > actually wrappers to call the real binaries from the above directory > (poor man's symlink). I am not sure how to do it with DLLs - maybe we > can use hardlinks or the new Windows symlinks. But neither work on some > file servers. I feel like I'm missing something important here: why would we need to do that at all? What's wrong with providing the DLLs, the necessary header files, and telling people "if you want to develop against GPGME on Win32, feel free, but you will have to distribute the DLLs with your application and comply with the licensing terms"? (Admittedly, this is a bit of a return to the DLL hell problem.) From wk at gnupg.org Sat Oct 20 06:06:13 2012 From: wk at gnupg.org (Werner Koch) Date: Sat, 20 Oct 2012 06:06:13 +0200 Subject: Looking for GnuPG-compatible library for server application In-Reply-To: <5081E81F.8010500@sixdemonbag.org> (Robert J. Hansen's message of "Fri, 19 Oct 2012 19:54:07 -0400") References: <508192B3.7000209@wauland.de> <87k3umi4lh.fsf@vigenere.g10code.de> <5081BCD3.6040000@sixdemonbag.org> <87wqymgms9.fsf@vigenere.g10code.de> <5081E81F.8010500@sixdemonbag.org> Message-ID: <87happhjnu.fsf@vigenere.g10code.de> On Sat, 20 Oct 2012 01:54, rjh at sixdemonbag.org said: > I feel like I'm missing something important here: why would we need to > do that at all? What's wrong with providing the DLLs, the necessary The gpg4win installation directory is populated with huge number of DLLs and EXEs which should not be available in the PATH. For EXEs we might have only name conflicts but for DLLs it will be worse: Some of the software in Gpg4win uses a lot of DLLS without proper versioning. For example if you install a second KDE based project, it might pick up a wrong version of a DLL (i.e. from gpg4win, while it expected it from somewhere else) and you run in all kind of subtle or severe error. That is actually a real world experience (e.g. Kolab for Windows). Once there used to be the idea of a package manager for Windows, but the different groups were not able to agree on a common solution. The right thing to do would be to use MSI, which is the package manager for Windows. However, we can't yet cross-build MSI and maintaining MSI is a lot of work for us, given that we all rely on each other but have no central control instance. Thus I consider it better to publish (put into a PATH directory) only those DLLs and headers with proper versioning. And a few well known binaries. I guess that hardlinks will be the say to go. The only open question is how we can do it if a DLL is currently in use. NSIS has some support for overwriting, but I have not checked how this can be done if we use CreateHardLink. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernd at wauland.de Sat Oct 20 13:35:40 2012 From: bernd at wauland.de (Bernd R. Fix) Date: Sat, 20 Oct 2012 13:35:40 +0200 Subject: Looking for GnuPG-compatible library for server application In-Reply-To: <87k3umi4lh.fsf@vigenere.g10code.de> References: <508192B3.7000209@wauland.de> <87k3umi4lh.fsf@vigenere.g10code.de> Message-ID: <50828C8C.9040603@wauland.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 19.10.2012 22:34, schrieb Werner Koch: > Technically this is not required. GPGME has been designed to allow > running the engines as co-process, communicating over pipes with > gpg. This has already been implemented for gpgsm (aka S/MIME), but > not yet for gpg. That plan is to also have gpg running as a > co-process. There is already some code in gpg to do this for verify > but it needs to be extended. Understood and I don't mind if the problem can be solved without a linkable OpenPGP library - as long as the requirements are meet: The server application uses 384-bit ECDSA/ECDH keypairs, so this approach will also require some additional work on the GnuPG-2.1 release itself (aside from making it possible to run it as a co-process within GPGME). Am I correct that each server thread requires its own GPGME/GnuPG instance? If that is the case, it would be nice if instances can be pooled as threads come and go frequently. But to be honest: I am not sure if gpg2 (with the mandatory gpg-agent instance to handle private keys) is suitable at all for a server environment where there are some 20'000 *private* keys (and counting). - From our experience gpg2 does not scale well with increasing number of private keys (although I have to admit that the project uses a very early GnuPG-2.1 implementation and not the latest from the unstable branch). But maybe I shouldn't bother the whole list with such details and I will try to explain our problems and requirements in a private email to anyone willing to help. >> Are any GnuPG developers willing to code such a library? The >> project has > > My I race my hand ;-) I appriciate your offer to help. I will describe the problem, financial issues and timetables in a private email. I have to travel a lot the next five days (including meetings), so I am not sure if I can send that email before the next weekend. Hope you don't mind. Cheers, Bernd. - -- Wau-Holland-Stiftung W Postfach 65 04 43 H O L L A N D 22364 Hamburg/Germany S T I F T U N G http://www.wauland.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJQgoyEAAoJEN1A8liqzgHpEboIALW0S4Oa9FQZJG2mcILjpYF4 0VC2uG7pm5Vl8wQphyNFsYXkdutdFaPMvZyFW0m16872uC6zdFFEZ6GBBmXllnm9 RrY8VT37PnctKAsMoCECluYR1kOugyGpZxOl4Run6tSV9iEBLT/e/Kb45qzsnjVL ts69i1S3qI1BvnuyOU5bGkiW6zDnxgSkgIBaoJFiB2oUfMQ88KrMaQY9WM4vAxpz 5N6I0O0tc2k4tlAlXydRs+gXIHPdPUsdjFQ2SADhZYmunTPgN6XXjcSaF+l6HXr6 TOIkLYn/WG0To+auIoHnXdbHEuogiV98qPRWb/piMQ/MSa3JKGLIgVp6Q4c9rJk= =38eR -----END PGP SIGNATURE----- From nicholas.cole at gmail.com Sat Oct 20 23:31:30 2012 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Sat, 20 Oct 2012 22:31:30 +0100 Subject: Looking for GnuPG-compatible library for server application In-Reply-To: <50828C8C.9040603@wauland.de> References: <508192B3.7000209@wauland.de> <87k3umi4lh.fsf@vigenere.g10code.de> <50828C8C.9040603@wauland.de> Message-ID: > But to be honest: I am not sure if gpg2 (with the mandatory gpg-agent > instance to handle private keys) is suitable at all for a server > environment where there are some 20'000 *private* keys (and counting). > - From our experience gpg2 does not scale well with increasing number of > private keys (although I have to admit that the project uses a very > early GnuPG-2.1 implementation and not the latest from the unstable branch). Pure curiosity on my part, I'll freely confess. But what sort of application requires a server to handle 20,000 private keys? Would there be any way to sensibly generate different keyrings, so that gpg2 only ever had to deal with smaller groups of keys? Nicholas From bernd at wauland.de Sun Oct 21 01:16:14 2012 From: bernd at wauland.de (Bernd R. Fix) Date: Sun, 21 Oct 2012 01:16:14 +0200 Subject: Looking for GnuPG-compatible library for server application In-Reply-To: References: <508192B3.7000209@wauland.de> <87k3umi4lh.fsf@vigenere.g10code.de> <50828C8C.9040603@wauland.de> Message-ID: <508330BE.5080701@wauland.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 20.10.2012 23:31, schrieb Nicholas Cole: >> But to be honest: I am not sure if gpg2 (with the mandatory >> gpg-agent instance to handle private keys) is suitable at all for a >> server environment where there are some 20'000 *private* keys (and >> counting). - From our experience gpg2 does not scale well with >> increasing number of private keys (although I have to admit that >> the project uses a very early GnuPG-2.1 implementation and not the >> latest from the unstable branch). > > Pure curiosity on my part, I'll freely confess. But what sort of > application requires a server to handle 20,000 private keys? It is a kind of "closed user group social network" application where all exchanged and stored information needs to be encrypted and is only visible within a group of users. The application was designed last year somewhat in a haste and had to be online within three month, so some design decisions were guided by that timeframe and not by "best pracice"; for example encryption takes place on the web server and not in the client's browser (a design decision that will hopefully be revised somewhen in the future - but for now we have to deal with it the way it is). Although the keys are stored on the server, access to the private keys is only possible with a passphrase supplied by the client - as promised the server application does not store or log passphrases (something the user has to believe the project, even when the appication source code will be available as open-source soon). > Would there be any way to sensibly generate different keyrings, so > that gpg2 only ever had to deal with smaller groups of keys? Since the predecessor of the current GnuPG-2.1 still used a single secure keyring file to store keys (which does not scale at all!), the server application already splits that up for operations involving the private key (each key has its own keyring actually, stored in a hierachical directory structure) and ignores the associated trustdb completely on all operations. Cheers, Bernd. - -- Wau-Holland-Stiftung W Postfach 65 04 43 H O L L A N D 22364 Hamburg/Germany S T I F T U N G http://www.wauland.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJQgzCzAAoJEN1A8liqzgHpNvMIAKNpJyZ8uzDswSBXbMjy5OE9 Y7YdLa5iiXQ9KzcfkxUgVkyyzdXaUesNJOaovaBUT9bvKwUBcDRiVQFNB1lm45Ke pp1G1Od4D1kQYqwi2MbFRWby2WIxls8fDINPJIX1DO2r6Jbi8/uSEmLzLB6w4vw3 SxLZKm3Yqyy6tobGtPGVesYK50W3JqkrmfXuhnKQyGpCjevoxJ38HIWeHiPJwLq4 r7Z2Ait04eTXHf5UHqk/1SyYjW2pQJi5bmqkEx7Gq4xlaI6zH5RxsSPOI8AO3iaX aI1orqeGoOgKKK8BFxBg/LH+3iWq4rDTajq3di70aJXyZkvuICcJw52F9PuAp28= =BEXZ -----END PGP SIGNATURE----- From hans at guardianproject.info Mon Oct 22 06:02:47 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 22 Oct 2012 00:02:47 -0400 Subject: gpgme_op_keylist_start: error: Invalid crypto engine In-Reply-To: <87vce6kdyu.fsf@vigenere.g10code.de> References: <507DE5A8.9010505@guardianproject.info> <87ehkxm3vs.fsf@vigenere.g10code.de> <507F3601.2040203@guardianproject.info> <878vb3lhvn.fsf@vigenere.g10code.de> <508057A9.2090403@guardianproject.info> <5080D668.9070807@guardianproject.info> <87vce6kdyu.fsf@vigenere.g10code.de> Message-ID: <5084C567.2070304@guardianproject.info> On 10/19/2012 05:28 AM, Werner Koch wrote: > On Fri, 19 Oct 2012 06:26, hans at guardianproject.info said: > >> I didn't get very far today. A patch with printf()s would be much >> appreciated. > > Okay, I did something more general. > > bd24fea Trace the use of GPG_ERR_INV_ENGINE. > > * src/debug.h: Include "gpgme.h" > (_gpgme_trace_gpgme_error): New. > (trace_gpg_error): New macro. Use it in all files where we return > GPG_ERR_INV_ENGINE; also "include debug.h" as needed. > -- > > This is a pretty common error code but often it is hard to figure out > the actual cause. With debug level 4 we now print the file name and > line number where this error code is generated by gpgme. Along with > the git revision printed in the first log lines, this should give us > an easier way to track down the problems related to this error code. > > > Sample output is now > > engine-gpg.c:1272: returning error: Invalid crypto engine > gpgme_op_keylist_start: error: Invalid crypto engine > > With the exact location it should be easy to figure out what's going > wrong. That is getting more information, its stopping here: GPGME 2012-10-17 20:48:00 <0x0909> gpgme_op_keylist_start: enter: ctx=0x2a0d8818, pattern=ans, secret_only=0 GPGME 2012-10-17 20:48:00 <0x0909> engine.c:456: returning error: Invalid crypto engine GPGME 2012-10-17 20:48:00 <0x0909> gpgme_op_keylist_start: error: Invalid crypto engine 448 _gpgme_engine_new (gpgme_engine_info_t info, engine_t *r_engine) 449 { 450 engine_t engine; 451 452 if (!info->file_name) 453 return trace_gpg_error (GPG_ERR_INV_ENGINE); 454 455 if (!info->version) 456 return trace_gpg_error (GPG_ERR_INV_ENGINE); I split them up to get the exact var. So the version is not getting set. The code is using gpgme_check_version(NULL) like the example says: JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { _jvm = vm; // TODO set locale from the JavaVM's config setlocale(LC_ALL, ""); gpgme_set_global_flag("debug", "9:/data/data/info.guardianproject.gpg/app_log/gpgme.log"); const char* version = gpgme_check_version(NULL); fprintf(stderr, "VERSION: %s\n", version); gpgme_set_locale(NULL, LC_CTYPE, setlocale(LC_CTYPE, NULL)); So next thing might be to try setting a version, but its late and I'm going to bed. Would that be something like: const char* version = gpgme_check_version("1.3.0"); .hc From wk at gnupg.org Mon Oct 22 10:14:28 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Oct 2012 10:14:28 +0200 Subject: gpgme_op_keylist_start: error: Invalid crypto engine In-Reply-To: <5084C567.2070304@guardianproject.info> (Hans-Christoph Steiner's message of "Mon, 22 Oct 2012 00:02:47 -0400") References: <507DE5A8.9010505@guardianproject.info> <87ehkxm3vs.fsf@vigenere.g10code.de> <507F3601.2040203@guardianproject.info> <878vb3lhvn.fsf@vigenere.g10code.de> <508057A9.2090403@guardianproject.info> <5080D668.9070807@guardianproject.info> <87vce6kdyu.fsf@vigenere.g10code.de> <5084C567.2070304@guardianproject.info> Message-ID: <87y5iygbyz.fsf@vigenere.g10code.de> On Mon, 22 Oct 2012 06:02, hans at guardianproject.info said: > I split them up to get the exact var. So the version is not getting set. The Right. > So next thing might be to try setting a version, but its late and I'm going to > bed. Would that be something like: > > const char* version = gpgme_check_version("1.3.0"); No, that only adds a runtime check to assert the actual version of gpgme is at least 1.3.0. I always use this to avoid problem od accidently using a different version at runtime than at build time (e.g. due to messed up SO names). I can't see that this matters. We need to look closer at engine_get_version et al. I will add more trace calls. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Oct 22 11:13:48 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Oct 2012 11:13:48 +0200 Subject: gpgme_op_keylist_start: error: Invalid crypto engine In-Reply-To: <5084C567.2070304@guardianproject.info> (Hans-Christoph Steiner's message of "Mon, 22 Oct 2012 00:02:47 -0400") References: <507DE5A8.9010505@guardianproject.info> <87ehkxm3vs.fsf@vigenere.g10code.de> <507F3601.2040203@guardianproject.info> <878vb3lhvn.fsf@vigenere.g10code.de> <508057A9.2090403@guardianproject.info> <5080D668.9070807@guardianproject.info> <87vce6kdyu.fsf@vigenere.g10code.de> <5084C567.2070304@guardianproject.info> Message-ID: <878vayg983.fsf@vigenere.g10code.de> Hi, looking closer at the logs shows that none of the tools return any information for a call with EGNINE --version. <0x0391> _gpgme_io_spawn: check: path=0x4a2ea798, argv[ 0] = /data/data/info.guardianproject.gpg/app_opt/bin/gpg2 <0x0391> _gpgme_io_spawn: check: path=0x4a2ea798, argv[ 1] = --version <0x0391> _gpgme_io_spawn: check: path=0x4a2ea798, fd[0] = 0x26 -> 0x1 Setup everything for an exec. Register to connect stdout of gpg2 to the pipe. <0x0391> _gpgme_io_spawn: check: path=0x4a2ea798, waiting for child process pid=941 Wait in the parent for gpg to finish. <0x03ae> gpgme:max_fds: call: 0=0x0, max fds=1024 (RLIMIT_NOFILE) The child is about to close all file descriptors. Actually this is the grandchild because gpgme uses double forking to let init reap the children. <0x0391> _gpgme_io_close: enter: fd=0x26 <0x0391> _gpgme_io_close: leave: result=0 Close other end of the pipe in the parent. <0x0391> _gpgme_io_spawn: leave: result=0 Finished. <0x0391> _gpgme_io_read: enter: fd=0x25, buffer=0xbeac65e4, count=79 <0x0391> _gpgme_io_read: leave: result=0 Read end of the pipe was called with a 79 byte buffer but returned nothing. Here is what you should have seen between these two log lines: <0x0391> _gpgme_io_read: check: 6770672028476e75 50472920312e342e gpg (GnuPG) 1.4 [...] I assume you already verified that $ /data/data/info.guardianproject.gpg/app_opt/bin/gpg2 --version return something to stdout. The next step would be to enable the trace calls in src/posix-io.c:gpgme_io_spawn . The are all "#if 0"-ed to avoid problems with pthread. Change the all to "#if 1" and check the logs again. How long would it take me to setup a test environment? Does that make sense? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Oct 22 16:50:03 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Oct 2012 16:50:03 +0200 Subject: Looking for GnuPG-compatible library for server application In-Reply-To: <50828C8C.9040603@wauland.de> (Bernd R. Fix's message of "Sat, 20 Oct 2012 13:35:40 +0200") References: <508192B3.7000209@wauland.de> <87k3umi4lh.fsf@vigenere.g10code.de> <50828C8C.9040603@wauland.de> Message-ID: <87txtmef38.fsf@vigenere.g10code.de> On Sat, 20 Oct 2012 13:35, bernd at wauland.de said: > Am I correct that each server thread requires its own GPGME/GnuPG > instance? If that is the case, it would be nice if instances can be > pooled as threads come and go frequently. As of now each gpgme_ctx_t context object uses its own instance of an engine (e.g. a gpg process). Thus you can setup your own CPU mapping by using one context per CPU. There is however only one gpg-agent running; if you handle only short messages, gpg-agent will be bottleneck, because it is not multi-threaded but serializes all requests from all running gpg processes. It should be possible to change the system so that it works with several gpg-agents and may this way distribute the workload onto several CPUs. Pooling at the gpgme level can be done by the application. Due to the 1-to-1 relation between a context object and an engine, the caller may put a context object into a pool (instead of releasing it) and later pick it up from another thread. > environment where there are some 20'000 *private* keys (and counting). > From our experience gpg2 does not scale well with increasing number of > private keys (although I have to admit that the project uses a very That depends a bit on how you use it. If you do a key listing for each operation, this might be a problem: Neither gpg, nor gpg-agent cache the check for the private key file. 20000 private keys are not a very common usage pattern. Given that the private key check is is nothing more than an access(3) with some IPC glue code; I doubt that the number of private keys is actually the problem. The actual problem is the access to public key, which still requires a linear search and parsing of the entire keyring. We can do much faster here but the code is not yet complete (no real need). Eventually we may add a DB backend to access the keys; the code is well layered and can thus easily extended. > I appriciate your offer to help. I will describe the problem, financial > issues and timetables in a private email. I have to travel a lot the > next five days (including meetings), so I am not sure if I can send that > email before the next weekend. Hope you don't mind. No problem. You may also phone me during office hours . Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Mon Oct 22 22:19:06 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 22 Oct 2012 16:19:06 -0400 Subject: gpgme_op_keylist_start: error: Invalid crypto engine In-Reply-To: <878vayg983.fsf@vigenere.g10code.de> References: <507DE5A8.9010505@guardianproject.info> <87ehkxm3vs.fsf@vigenere.g10code.de> <507F3601.2040203@guardianproject.info> <878vb3lhvn.fsf@vigenere.g10code.de> <508057A9.2090403@guardianproject.info> <5080D668.9070807@guardianproject.info> <87vce6kdyu.fsf@vigenere.g10code.de> <5084C567.2070304@guardianproject.info> <878vayg983.fsf@vigenere.g10code.de> Message-ID: <5085AA3A.7010702@guardianproject.info> On 10/22/2012 05:13 AM, Werner Koch wrote: > Hi, > > looking closer at the logs shows that none of the tools return any > information for a call with EGNINE --version. > > <0x0391> _gpgme_io_spawn: check: path=0x4a2ea798, argv[ 0] = /data/data/info.guardianproject.gpg/app_opt/bin/gpg2 > <0x0391> _gpgme_io_spawn: check: path=0x4a2ea798, argv[ 1] = --version > <0x0391> _gpgme_io_spawn: check: path=0x4a2ea798, fd[0] = 0x26 -> 0x1 > > Setup everything for an exec. Register to connect stdout of gpg2 to the > pipe. > > <0x0391> _gpgme_io_spawn: check: path=0x4a2ea798, waiting for child > process pid=941 > > Wait in the parent for gpg to finish. > > <0x03ae> gpgme:max_fds: call: 0=0x0, max fds=1024 (RLIMIT_NOFILE) > > The child is about to close all file descriptors. Actually this is the > grandchild because gpgme uses double forking to let init reap the > children. > > <0x0391> _gpgme_io_close: enter: fd=0x26 > <0x0391> _gpgme_io_close: leave: result=0 > > Close other end of the pipe in the parent. > > <0x0391> _gpgme_io_spawn: leave: result=0 > > Finished. > > <0x0391> _gpgme_io_read: enter: fd=0x25, buffer=0xbeac65e4, count=79 > <0x0391> _gpgme_io_read: leave: result=0 > > Read end of the pipe was called with a 79 byte buffer but returned > nothing. Here is what you should have seen between these two log lines: > > <0x0391> _gpgme_io_read: check: 6770672028476e75 50472920312e342e gpg (GnuPG) 1.4 > [...] > > > I assume you already verified that > > $ /data/data/info.guardianproject.gpg/app_opt/bin/gpg2 --version I have a menu item in the test Android app that downloads a key from a keyserver using the gpg2 command line binary. That has been working fine for a while now. In case you're curious, I ran this from 'adb shell', i.e. a terminal to an Android emulator: # export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/data/data/info.guardianproject.gpg/app_opt/lib # /data/data/info.guardianproject.gpg/app_opt/bin/gpg2 --version gpg (GnuPG) 2.1.0-beta82 libgcrypt 1.6.0-git38fcd59 NOTE: THIS IS A DEVELOPMENT VERSION! It is only intended for test purposes and should NOT be used in a production environment or with production keys! Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA Cipher: 3DES, CAST5, BLOWFISH, AES128, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB > return something to stdout. The next step would be to enable the trace > calls in src/posix-io.c:gpgme_io_spawn . The are all "#if 0"-ed to > avoid problems with pthread. Change the all to "#if 1" and check the > logs again. I'll run that now. > How long would it take me to setup a test environment? Does that make > sense? If you are interested in GnuPG on Android beyond just this problem, I think it does make sense. If you are running a Debian-deriv, its not too bad to setup, I think the whole thing might take no more than an hour, if you ignore the Eclipse setup: apt-get install ia32-libs (only if running amd64 64-bit) apt-get install autoconf automake libtool transfig wget patch \ texinfo ant gettext build-essential bison cd /path/to/folder/for/your/android/tools wget https://dl.google.com/android/ndk/android-ndk-r8b-linux-x86.tar.bz2 tar xjf android-ndk-r8b-linux-x86.tar.bz2 wget https://dl.google.com/android/android-sdk_r20.0.3-linux.tgz tar xjf android-sdk_r20.0.3-linux.tgz I source a ~/.android/bashrc file to set the relevant vars for locating the NDK and SDK, I attached the one I use. Next you need to install setup an emulator, unless you have an Android phone you want to use: http://developer.android.com/sdk/installing/adding-packages.html Then it should just be: git clone https://github.com/guardianproject/gnupg-for-android cd gnupg-for-android . /path/to/your/android-bashrc make -C external/ distclean make -C external/ gnupg-install make -C external/ gnupg-static make -C external/ gpgme-install make -C external/ android-assets ndk-build android update project --path . --target android-8 --name GnuPrivacyGuard ant clean debug adb install bin/info.guardianproject.gpg.GnuPrivacyGuard.apk .hc -------------- next part -------------- export NDK_BASE=/opt/android-ndk export NDK_ROOT=$NDK_BASE export NDK_TOOLCHAIN_BASE=${NDK_BASE}/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86 export NDK_SYSROOT=$NDK_BASE/platforms/android-$NDK_PLATFORM_VERSION/arch-arm export SDK_BASE=/opt/android-sdk export SDK_ROOT=$SDK_BASE export SDK_TOOLS=${SDK_BASE}/tools export SDK_PLATFORM_TOOLS=${SDK_BASE}/platform-tools export PATH="${PATH}:${NDK_BASE}:${NDK_TOOLCHAIN_BASE}/bin:${SDK_TOOLS}:${SDK_PLATFORM_TOOLS}" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 937 bytes Desc: OpenPGP digital signature URL: From hans at guardianproject.info Tue Oct 23 03:46:03 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 22 Oct 2012 21:46:03 -0400 Subject: gpgme_op_keylist_start: error: Invalid crypto engine In-Reply-To: <5085AA3A.7010702@guardianproject.info> References: <507DE5A8.9010505@guardianproject.info> <87ehkxm3vs.fsf@vigenere.g10code.de> <507F3601.2040203@guardianproject.info> <878vb3lhvn.fsf@vigenere.g10code.de> <508057A9.2090403@guardianproject.info> <5080D668.9070807@guardianproject.info> <87vce6kdyu.fsf@vigenere.g10code.de> <5084C567.2070304@guardianproject.info> <878vayg983.fsf@vigenere.g10code.de> <5085AA3A.7010702@guardianproject.info> Message-ID: <5085F6DB.5020603@guardianproject.info> On 10/22/2012 04:19 PM, Hans-Christoph Steiner wrote: > > > On 10/22/2012 05:13 AM, Werner Koch wrote: >> Hi, >> >> looking closer at the logs shows that none of the tools return any >> information for a call with EGNINE --version. >> >> <0x0391> _gpgme_io_spawn: check: path=0x4a2ea798, argv[ 0] = /data/data/info.guardianproject.gpg/app_opt/bin/gpg2 >> <0x0391> _gpgme_io_spawn: check: path=0x4a2ea798, argv[ 1] = --version >> <0x0391> _gpgme_io_spawn: check: path=0x4a2ea798, fd[0] = 0x26 -> 0x1 >> >> Setup everything for an exec. Register to connect stdout of gpg2 to the >> pipe. >> >> <0x0391> _gpgme_io_spawn: check: path=0x4a2ea798, waiting for child >> process pid=941 >> >> Wait in the parent for gpg to finish. >> >> <0x03ae> gpgme:max_fds: call: 0=0x0, max fds=1024 (RLIMIT_NOFILE) >> >> The child is about to close all file descriptors. Actually this is the >> grandchild because gpgme uses double forking to let init reap the >> children. >> >> <0x0391> _gpgme_io_close: enter: fd=0x26 >> <0x0391> _gpgme_io_close: leave: result=0 >> >> Close other end of the pipe in the parent. >> >> <0x0391> _gpgme_io_spawn: leave: result=0 >> >> Finished. >> >> <0x0391> _gpgme_io_read: enter: fd=0x25, buffer=0xbeac65e4, count=79 >> <0x0391> _gpgme_io_read: leave: result=0 >> >> Read end of the pipe was called with a 79 byte buffer but returned >> nothing. Here is what you should have seen between these two log lines: >> >> <0x0391> _gpgme_io_read: check: 6770672028476e75 50472920312e342e gpg (GnuPG) 1.4 >> [...] >> >> >> I assume you already verified that >> >> $ /data/data/info.guardianproject.gpg/app_opt/bin/gpg2 --version > > I have a menu item in the test Android app that downloads a key from a > keyserver using the gpg2 command line binary. That has been working fine for > a while now. In case you're curious, I ran this from 'adb shell', i.e. a > terminal to an Android emulator: > > # export > LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/data/data/info.guardianproject.gpg/app_opt/lib > # /data/data/info.guardianproject.gpg/app_opt/bin/gpg2 --version > gpg (GnuPG) 2.1.0-beta82 > libgcrypt 1.6.0-git38fcd59 > NOTE: THIS IS A DEVELOPMENT VERSION! > It is only intended for test purposes and should NOT be > used in a production environment or with production keys! > Copyright (C) 2011 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Home: ~/.gnupg > Supported algorithms: > Pubkey: RSA, ELG, DSA, ECDH, ECDSA > Cipher: 3DES, CAST5, BLOWFISH, AES128, AES192, AES256, TWOFISH, CAMELLIA128, > CAMELLIA192, CAMELLIA256 > Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 > Compression: Uncompressed, ZIP, ZLIB > > >> return something to stdout. The next step would be to enable the trace >> calls in src/posix-io.c:gpgme_io_spawn . The are all "#if 0"-ed to >> avoid problems with pthread. Change the all to "#if 1" and check the >> logs again. > > I'll run that now. > >> How long would it take me to setup a test environment? Does that make >> sense? > > If you are interested in GnuPG on Android beyond just this problem, I think it > does make sense. If you are running a Debian-deriv, its not too bad to setup, > I think the whole thing might take no more than an hour, if you ignore the > Eclipse setup: > > apt-get install ia32-libs (only if running amd64 64-bit) > apt-get install autoconf automake libtool transfig wget patch \ > texinfo ant gettext build-essential bison > > cd /path/to/folder/for/your/android/tools > wget https://dl.google.com/android/ndk/android-ndk-r8b-linux-x86.tar.bz2 > tar xjf android-ndk-r8b-linux-x86.tar.bz2 > wget https://dl.google.com/android/android-sdk_r20.0.3-linux.tgz > tar xjf android-sdk_r20.0.3-linux.tgz > > I source a ~/.android/bashrc file to set the relevant vars for locating the > NDK and SDK, I attached the one I use. > > Next you need to install setup an emulator, unless you have an Android phone > you want to use: > http://developer.android.com/sdk/installing/adding-packages.html Then it > should just be: I forgot the submodules: git clone https://github.com/guardianproject/gnupg-for-android cd gnupg-for-android git submodule init git submodule update . /path/to/your/android-bashrc make -C external/ distclean make -C external/ gnupg-install make -C external/ gnupg-static make -C external/ gpgme-install make -C external/ android-assets ndk-build android update project --path . --target android-8 --name GnuPrivacyGuard ant clean debug adb install bin/info.guardianproject.gpg.GnuPrivacyGuard.apk .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 hans at guardianproject.info Tue Oct 23 05:39:49 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 22 Oct 2012 23:39:49 -0400 Subject: gpgme_op_keylist_start: error: Invalid crypto engine In-Reply-To: <878vayg983.fsf@vigenere.g10code.de> References: <507DE5A8.9010505@guardianproject.info> <87ehkxm3vs.fsf@vigenere.g10code.de> <507F3601.2040203@guardianproject.info> <878vb3lhvn.fsf@vigenere.g10code.de> <508057A9.2090403@guardianproject.info> <5080D668.9070807@guardianproject.info> <87vce6kdyu.fsf@vigenere.g10code.de> <5084C567.2070304@guardianproject.info> <878vayg983.fsf@vigenere.g10code.de> Message-ID: <50861185.7070409@guardianproject.info> On 10/22/2012 05:13 AM, Werner Koch wrote: > Hi, > > looking closer at the logs shows that none of the tools return any > information for a call with EGNINE --version. > > <0x0391> _gpgme_io_spawn: check: path=0x4a2ea798, argv[ 0] = /data/data/info.guardianproject.gpg/app_opt/bin/gpg2 > <0x0391> _gpgme_io_spawn: check: path=0x4a2ea798, argv[ 1] = --version > <0x0391> _gpgme_io_spawn: check: path=0x4a2ea798, fd[0] = 0x26 -> 0x1 > > Setup everything for an exec. Register to connect stdout of gpg2 to the > pipe. > > <0x0391> _gpgme_io_spawn: check: path=0x4a2ea798, waiting for child > process pid=941 > > Wait in the parent for gpg to finish. > > <0x03ae> gpgme:max_fds: call: 0=0x0, max fds=1024 (RLIMIT_NOFILE) > > The child is about to close all file descriptors. Actually this is the > grandchild because gpgme uses double forking to let init reap the > children. > > <0x0391> _gpgme_io_close: enter: fd=0x26 > <0x0391> _gpgme_io_close: leave: result=0 > > Close other end of the pipe in the parent. > > <0x0391> _gpgme_io_spawn: leave: result=0 > > Finished. > > <0x0391> _gpgme_io_read: enter: fd=0x25, buffer=0xbeac65e4, count=79 > <0x0391> _gpgme_io_read: leave: result=0 > > Read end of the pipe was called with a 79 byte buffer but returned > nothing. Here is what you should have seen between these two log lines: > > <0x0391> _gpgme_io_read: check: 6770672028476e75 50472920312e342e gpg (GnuPG) 1.4 > [...] > > > I assume you already verified that > > $ /data/data/info.guardianproject.gpg/app_opt/bin/gpg2 --version > > return something to stdout. The next step would be to enable the trace > calls in src/posix-io.c:gpgme_io_spawn . The are all "#if 0"-ed to > avoid problems with pthread. Change the all to "#if 1" and check the > logs again. Arg, I should have taken this as a hint. That indeed was the problem. One annoying thing about Android is that the only way that executables can find the dynamic libs they need is via the LD_LIBRARY_PATH env var. I had already set this for launching dirmngr and gpg-agent, and also when calling gpg2 directly from Java. BUT! gpgme calls gpg2, etc. so I wasn't setting LD_LIBRARY_PATH for gpgme, so when it calls any of the cmd line utils, they didn't work since they couldn't find their dynamic libs... Thanks for your help, I knew it would be something stupid. Hopefully it'll be smooth sailing from here :) .hc From hans at guardianproject.info Tue Oct 23 19:33:47 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 23 Oct 2012 13:33:47 -0400 Subject: how to make dirmngr a singleton Message-ID: <5086D4FB.9040705@guardianproject.info> In the Android app, gpg-agent and dirmngr are both started in their own threads. They often stay alive when the app itself quits. gpg-agent seems to automatically find whether its running and refuse to start a second one, that's good. But dirmngr does not seem to do that, so after starting and stopping the app, there will be multiple dirmngrs running. I can write code to kill old ones or detect if one is running before starting another, but I wanted to check first to make sure that there isn't already a way to do that. .hc From hans at guardianproject.info Wed Oct 24 01:19:39 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 23 Oct 2012 19:19:39 -0400 Subject: ttyname in gpgme when running Android Message-ID: <5087260B.9050302@guardianproject.info> So with gnupg we went thru this also, and looks like the same issue in gpgme. I built the gpgme tests and ran them by hand on the emulator: $ ./run-keylist FIX ME! implement ttyname_r() bionic/libc/bionic/stubs.c:466 run-keylist: file run-keylist.c line 154: Unknown system error Android's bionic lib has neither ttyname_r() nor ttyname(). I tried to make sense of m4/gnupg-ttyname.m4 but my m4 skills are very weak, and didn't have any tangible results. So to get things working, I resorted to a quick macro test which gives me a working ./run-keylist test :-D diff --git a/src/ttyname_r.c b/src/ttyname_r.c index 105e0af..fa49a6b 100644 --- a/src/ttyname_r.c +++ b/src/ttyname_r.c @@ -35,7 +35,7 @@ int _gpgme_ttyname_r (int fd, char *buf, size_t buflen) { -#if HAVE_TTYNAME_R +#if HAVE_TTYNAME_R && !defined __ANDROID__ # if HAVE_BROKEN_TTYNAME_R /* Solaris fails if BUFLEN is less than 128. OSF/1 5.1 completely ignores BUFLEN. We use a large buffer to woraround this. */ @@ -110,7 +110,7 @@ _gpgme_ttyname_r (int fd, char *buf, size_t buflen) #else /*!HAVE_TTYNAME_R*/ char *tty; -# if HAVE_W32_SYSTEM +# if HAVE_W32_SYSTEM || defined __ANDROID__ /* We use this default one for now. AFAICS we only need it to be passed to gpg and in turn to pinentry. Providing a replacement is needed because elsewhere we bail out on error. If we .hc From hans at guardianproject.info Wed Oct 24 02:43:38 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 23 Oct 2012 20:43:38 -0400 Subject: ttyname in gpgme when running Android In-Reply-To: <5087260B.9050302@guardianproject.info> References: <5087260B.9050302@guardianproject.info> Message-ID: <508739BA.6040306@guardianproject.info> On 10/23/2012 07:19 PM, Hans-Christoph Steiner wrote: > > So with gnupg we went thru this also, and looks like the same issue in gpgme. > I built the gpgme tests and ran them by hand on the emulator: > > $ ./run-keylist > FIX ME! implement ttyname_r() bionic/libc/bionic/stubs.c:466 > run-keylist: file run-keylist.c line 154: Unknown system error > > Android's bionic lib has neither ttyname_r() nor ttyname(). I tried to make > sense of m4/gnupg-ttyname.m4 but my m4 skills are very weak, and didn't have > any tangible results. So to get things working, I resorted to a quick macro > test which gives me a working ./run-keylist test :-D > > diff --git a/src/ttyname_r.c b/src/ttyname_r.c > index 105e0af..fa49a6b 100644 > --- a/src/ttyname_r.c > +++ b/src/ttyname_r.c > @@ -35,7 +35,7 @@ > int > _gpgme_ttyname_r (int fd, char *buf, size_t buflen) > { > -#if HAVE_TTYNAME_R > +#if HAVE_TTYNAME_R && !defined __ANDROID__ > # if HAVE_BROKEN_TTYNAME_R > /* Solaris fails if BUFLEN is less than 128. OSF/1 5.1 completely > ignores BUFLEN. We use a large buffer to woraround this. */ > @@ -110,7 +110,7 @@ _gpgme_ttyname_r (int fd, char *buf, size_t buflen) > #else /*!HAVE_TTYNAME_R*/ > char *tty; > > -# if HAVE_W32_SYSTEM > +# if HAVE_W32_SYSTEM || defined __ANDROID__ > /* We use this default one for now. AFAICS we only need it to be > passed to gpg and in turn to pinentry. Providing a replacement > is needed because elsewhere we bail out on error. If we I think I figured out m4 enough to get something working, and it might even be an acceptable patch. I attached it in "git format-patch" style. .hc -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Android-does-not-have-ttyname-or-ttyname_r-use-repla.patch Type: text/x-patch Size: 2009 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 937 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Wed Oct 24 05:05:24 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 23 Oct 2012 23:05:24 -0400 Subject: Request: GPGME cross-compile on non-Debian Message-ID: <50875AF4.3060903@sixdemonbag.org> A bit ago there was some talk about things to go into the next GPG4WIN release (development headers for GPGME development on Win32 being my request). I just remembered why I wanted this capability in the first place: because, at present, GPGME can only be cross-compiled on a Debian system. So, here's another request: "make it possible to cross-compile GPGME on a Fedora and/or Ubuntu system." That might be a lot simpler than providing a native Win32 development capability, and would still serve my purposes completely well. Thanks very much for the consideration! From rjh at sixdemonbag.org Wed Oct 24 05:25:04 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 23 Oct 2012 23:25:04 -0400 Subject: Request: GPGME cross-compile on non-Debian In-Reply-To: <50875D82.7040302@fifthhorseman.net> References: <50875AF4.3060903@sixdemonbag.org> <50875D82.7040302@fifthhorseman.net> Message-ID: <50875F90.60401@sixdemonbag.org> On 10/23/2012 11:16 PM, Daniel Kahn Gillmor wrote: > Are you suggesting that the debian instructions for > cross-compiling don't work on an Ubuntu system? If so, where do > they fail? I didn't think I was "suggesting" so much as explicitly stating: yes, they fail, on both Fedora and Ubuntu systems. :) http://lists.gnupg.org/pipermail/gnupg-users/2012-June/044884.html may be a good place to begin looking. http://lists.gnupg.org/pipermail/gnupg-users/2012-June/044891.html may also be useful. I'm no libtool maven, but something about that just struck me as being potentially quite wrong. I don't have any documentation lying about to confirm that the F17 problems were also present under Ubuntu 12.04, but my recollection is that I tested it out and got the same sort of problem. It would not be impossible for my recollection to be in error, though. From dkg at fifthhorseman.net Wed Oct 24 05:16:18 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 23 Oct 2012 23:16:18 -0400 Subject: Request: GPGME cross-compile on non-Debian In-Reply-To: <50875AF4.3060903@sixdemonbag.org> References: <50875AF4.3060903@sixdemonbag.org> Message-ID: <50875D82.7040302@fifthhorseman.net> On 10/23/2012 11:05 PM, Robert J. Hansen wrote: > A bit ago there was some talk about things to go into the next GPG4WIN > release (development headers for GPGME development on Win32 being my > request). I just remembered why I wanted this capability in the first > place: because, at present, GPGME can only be cross-compiled on a Debian > system. > > So, here's another request: "make it possible to cross-compile GPGME on > a Fedora and/or Ubuntu system." Are you suggesting that the debian instructions for cross-compiling don't work on an Ubuntu system? If so, where do they fail? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Oct 24 15:15:33 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 24 Oct 2012 15:15:33 +0200 Subject: how to make dirmngr a singleton In-Reply-To: <5086D4FB.9040705@guardianproject.info> (Hans-Christoph Steiner's message of "Tue, 23 Oct 2012 13:33:47 -0400") References: <5086D4FB.9040705@guardianproject.info> Message-ID: <87txtkc8p6.fsf@vigenere.g10code.de> On Tue, 23 Oct 2012 19:33, hans at guardianproject.info said: > threads. They often stay alive when the app itself quits. gpg-agent seems to > automatically find whether its running and refuse to start a second one, > that's good. But dirmngr does not seem to do that, so after starting and > stopping the app, there will be multiple dirmngrs running. Please configure GnuPG with --enable-dirmngr-auto-start this does what you want. It should be the default for 2.1, though. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Oct 24 15:32:10 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 24 Oct 2012 15:32:10 +0200 Subject: ttyname in gpgme when running Android In-Reply-To: <508739BA.6040306@guardianproject.info> (Hans-Christoph Steiner's message of "Tue, 23 Oct 2012 20:43:38 -0400") References: <5087260B.9050302@guardianproject.info> <508739BA.6040306@guardianproject.info> Message-ID: <87pq48c7xh.fsf@vigenere.g10code.de> On Wed, 24 Oct 2012 02:43, hans at guardianproject.info said: > I think I figured out m4 enough to get something working, and it might even be > an acceptable patch. I attached it in "git format-patch" style. Do you remember how we fixed this for GnuPG. AFAICS, we only disable the regression tests. In GnuPG we also define HAVE_ANDROID_SYSTEM but it is not used. Let me define such a HAVE_ANDROID_SYSTEM macro and use it similar to your patch. Okay? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Wed Oct 24 15:42:56 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 24 Oct 2012 09:42:56 -0400 Subject: ttyname in gpgme when running Android In-Reply-To: <87pq48c7xh.fsf@vigenere.g10code.de> References: <5087260B.9050302@guardianproject.info> <508739BA.6040306@guardianproject.info> <87pq48c7xh.fsf@vigenere.g10code.de> Message-ID: <5087F060.70600@guardianproject.info> On 10/24/2012 09:32 AM, Werner Koch wrote: > On Wed, 24 Oct 2012 02:43, hans at guardianproject.info said: > >> I think I figured out m4 enough to get something working, and it might even be >> an acceptable patch. I attached it in "git format-patch" style. > > Do you remember how we fixed this for GnuPG. AFAICS, we only disable > the regression tests. In GnuPG we also define HAVE_ANDROID_SYSTEM but > it is not used. > > Let me define such a HAVE_ANDROID_SYSTEM macro and use it similar to > your patch. Okay? Sure, that should work fine for the autoconf stuff, but in ttyname.c, it'll need to either have that __ANDROID__ macro, or a macro like FAKE_TTYNAME which is defined for both Win32 and Android. .hc From hans at guardianproject.info Wed Oct 24 16:27:27 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 24 Oct 2012 10:27:27 -0400 Subject: how to make dirmngr a singleton In-Reply-To: <87txtkc8p6.fsf@vigenere.g10code.de> References: <5086D4FB.9040705@guardianproject.info> <87txtkc8p6.fsf@vigenere.g10code.de> Message-ID: <5087FACF.7060004@guardianproject.info> On 10/24/2012 09:15 AM, Werner Koch wrote: > On Tue, 23 Oct 2012 19:33, hans at guardianproject.info said: > >> threads. They often stay alive when the app itself quits. gpg-agent seems to >> automatically find whether its running and refuse to start a second one, >> that's good. But dirmngr does not seem to do that, so after starting and >> stopping the app, there will be multiple dirmngrs running. > > Please configure GnuPG with > > --enable-dirmngr-auto-start > > this does what you want. It should be the default for 2.1, though. There are definitely multiple dirmngrs spawning, and I'm using gnupg from git. I'll try adding that ./configure flag. Do you want to try debugging the current situation, or wait and see the results of that flag? .hc From wk at gnupg.org Wed Oct 24 16:56:42 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 24 Oct 2012 16:56:42 +0200 Subject: Request: GPGME cross-compile on non-Debian In-Reply-To: <50875AF4.3060903@sixdemonbag.org> (Robert J. Hansen's message of "Tue, 23 Oct 2012 23:05:24 -0400") References: <50875AF4.3060903@sixdemonbag.org> Message-ID: <87lievdil1.fsf@vigenere.g10code.de> On Wed, 24 Oct 2012 05:05, rjh at sixdemonbag.org said: > A bit ago there was some talk about things to go into the next GPG4WIN > release (development headers for GPGME development on Win32 being my > request). I just remembered why I wanted this capability in the first > place: because, at present, GPGME can only be cross-compiled on a Debian Actually we have the problem on new Debian systems that the hyperlatex package is not anymore available. Thus we need to rework the instructions anyway. In general it should build on all systems which provide the required tools. I will look at your specific issues once I can start working on Gpg4win again. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Wed Oct 24 17:03:09 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 24 Oct 2012 11:03:09 -0400 Subject: Request: GPGME cross-compile on non-Debian In-Reply-To: <87lievdil1.fsf@vigenere.g10code.de> References: <50875AF4.3060903@sixdemonbag.org> <87lievdil1.fsf@vigenere.g10code.de> Message-ID: <5088032D.3060400@sixdemonbag.org> On 10/24/12 10:56 AM, Werner Koch wrote: > I will look at your specific issues once I can start working on Gpg4win > again. That would be very much appreciated: thank you. :) From wk at gnupg.org Wed Oct 24 17:10:27 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 24 Oct 2012 17:10:27 +0200 Subject: how to make dirmngr a singleton In-Reply-To: <5087FACF.7060004@guardianproject.info> (Hans-Christoph Steiner's message of "Wed, 24 Oct 2012 10:27:27 -0400") References: <5086D4FB.9040705@guardianproject.info> <87txtkc8p6.fsf@vigenere.g10code.de> <5087FACF.7060004@guardianproject.info> Message-ID: <87hapjdhy4.fsf@vigenere.g10code.de> On Wed, 24 Oct 2012 16:27, hans at guardianproject.info said: > There are definitely multiple dirmngrs spawning, and I'm using gnupg from git. > I'll try adding that ./configure flag. Do you want to try debugging the > current situation, or wait and see the results of that flag? Wait. The flag enables enables code similar to code used to start the gpg-agent. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Oct 24 17:12:01 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 24 Oct 2012 17:12:01 +0200 Subject: ttyname in gpgme when running Android In-Reply-To: <5087F060.70600@guardianproject.info> (Hans-Christoph Steiner's message of "Wed, 24 Oct 2012 09:42:56 -0400") References: <5087260B.9050302@guardianproject.info> <508739BA.6040306@guardianproject.info> <87pq48c7xh.fsf@vigenere.g10code.de> <5087F060.70600@guardianproject.info> Message-ID: <87d307dhvi.fsf@vigenere.g10code.de> On Wed, 24 Oct 2012 15:42, hans at guardianproject.info said: > Sure, that should work fine for the autoconf stuff, but in ttyname.c, it'll > need to either have that __ANDROID__ macro, or a macro like FAKE_TTYNAME which > is defined for both Win32 and Android. Pull master. I basically used HAVE_ANDROID_SYSTEM instead of __ANDROID__. This is to make it similar to Windows where we also don't use the __WIN32__ macro. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mailinglists at gusnan.se Wed Oct 24 17:43:55 2012 From: mailinglists at gusnan.se (Andreas =?UTF-8?B?UsO2bm5xdWlzdA==?=) Date: Wed, 24 Oct 2012 17:43:55 +0200 Subject: [GPA] another list searching patch Message-ID: <20121024174355.248bc523@debian.localdomain> Hi! This time fixes to the signature list, patch makes the list searchable on both key and name, very much similar to my previous patch for the keylist - unfortunately the search function cannot be reused, since there are different keys in this list. Git patch attached. regards /Andreas R?nnquist gusnan at gusnan.se mailinglists at gusnan.se -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-siglist-search-both-key-and-name.patch Type: text/x-patch Size: 1865 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From hans at guardianproject.info Thu Oct 25 04:39:40 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 24 Oct 2012 22:39:40 -0400 Subject: ttyname in gpgme when running Android In-Reply-To: <87d307dhvi.fsf@vigenere.g10code.de> References: <5087260B.9050302@guardianproject.info> <508739BA.6040306@guardianproject.info> <87pq48c7xh.fsf@vigenere.g10code.de> <5087F060.70600@guardianproject.info> <87d307dhvi.fsf@vigenere.g10code.de> Message-ID: <5088A66C.2040500@guardianproject.info> On 10/24/2012 11:12 AM, Werner Koch wrote: > On Wed, 24 Oct 2012 15:42, hans at guardianproject.info said: > >> Sure, that should work fine for the autoconf stuff, but in ttyname.c, it'll >> need to either have that __ANDROID__ macro, or a macro like FAKE_TTYNAME which >> is defined for both Win32 and Android. > > Pull master. I basically used HAVE_ANDROID_SYSTEM instead of > __ANDROID__. This is to make it similar to Windows where we also don't > use the __WIN32__ macro. This worked fine for me. .hc From hans at guardianproject.info Thu Oct 25 04:42:38 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 24 Oct 2012 22:42:38 -0400 Subject: how to make dirmngr a singleton In-Reply-To: <87txtkc8p6.fsf@vigenere.g10code.de> References: <5086D4FB.9040705@guardianproject.info> <87txtkc8p6.fsf@vigenere.g10code.de> Message-ID: <5088A71E.7060407@guardianproject.info> On 10/24/2012 09:15 AM, Werner Koch wrote: > On Tue, 23 Oct 2012 19:33, hans at guardianproject.info said: > >> threads. They often stay alive when the app itself quits. gpg-agent seems to >> automatically find whether its running and refuse to start a second one, >> that's good. But dirmngr does not seem to do that, so after starting and >> stopping the app, there will be multiple dirmngrs running. > > Please configure GnuPG with > > --enable-dirmngr-auto-start > > this does what you want. It should be the default for 2.1, though. Using the --enable-dirmngr-auto-start flag seems to have enabled the singleton mode. If that mode is meant to the be the default, that didn't work before i added the flag. .hc From hans at guardianproject.info Thu Oct 25 04:47:39 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 24 Oct 2012 22:47:39 -0400 Subject: how to make dirmngr a singleton In-Reply-To: <5088A71E.7060407@guardianproject.info> References: <5086D4FB.9040705@guardianproject.info> <87txtkc8p6.fsf@vigenere.g10code.de> <5088A71E.7060407@guardianproject.info> Message-ID: <5088A84B.10408@guardianproject.info> On 10/24/2012 10:42 PM, Hans-Christoph Steiner wrote: > > > On 10/24/2012 09:15 AM, Werner Koch wrote: >> On Tue, 23 Oct 2012 19:33, hans at guardianproject.info said: >> >>> threads. They often stay alive when the app itself quits. gpg-agent seems to >>> automatically find whether its running and refuse to start a second one, >>> that's good. But dirmngr does not seem to do that, so after starting and >>> stopping the app, there will be multiple dirmngrs running. >> >> Please configure GnuPG with >> >> --enable-dirmngr-auto-start >> >> this does what you want. It should be the default for 2.1, though. > > > Using the --enable-dirmngr-auto-start flag seems to have enabled the singleton > mode. If that mode is meant to the be the default, that didn't work before i > added the flag. Hmm, ok, this might be due to my code. The android code runs a gpg-agent and a dirmngr at startup. It seems that gpg-agent checks if another one is running and quits, while dirmngr does not. If that's the case, I can handle this differently, that should be easy to do on the Android side. .hc From wk at gnupg.org Thu Oct 25 10:45:04 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 25 Oct 2012 10:45:04 +0200 Subject: how to make dirmngr a singleton In-Reply-To: <5088A84B.10408@guardianproject.info> (Hans-Christoph Steiner's message of "Wed, 24 Oct 2012 22:47:39 -0400") References: <5086D4FB.9040705@guardianproject.info> <87txtkc8p6.fsf@vigenere.g10code.de> <5088A71E.7060407@guardianproject.info> <5088A84B.10408@guardianproject.info> Message-ID: <874nljc54f.fsf@vigenere.g10code.de> On Thu, 25 Oct 2012 04:47, hans at guardianproject.info said: > Hmm, ok, this might be due to my code. The android code runs a gpg-agent and > a dirmngr at startup. It seems that gpg-agent checks if another one is > running and quits, while dirmngr does not. If that's the case, I can handle The thing is that the new Dirmngr in GnuPG is not yet finished. The goal is to either have Dirmngr running as a system daemon for all users or start it on demand per user. For a single user OS like Android that would make no difference and thus I think it is better to go with the start on demand option. Start on demand has the advantage that it is only started if needed and that on a crash it will be automagically restarted. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Oct 25 10:58:59 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 25 Oct 2012 10:58:59 +0200 Subject: [GPA] another list searching patch In-Reply-To: <20121024174355.248bc523@debian.localdomain> ("Andreas =?utf-8?Q?R=C3=B6nnquist=22's?= message of "Wed, 24 Oct 2012 17:43:55 +0200") References: <20121024174355.248bc523@debian.localdomain> Message-ID: <87zk3bapws.fsf@vigenere.g10code.de> On Wed, 24 Oct 2012 17:43, mailinglists at gusnan.se said: > Git patch attached. Thanks. Applied. Please remember to put ChnageLog entries into the git commite message; I did it for you this time. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ldv at altlinux.org Sat Oct 27 00:12:47 2012 From: ldv at altlinux.org (Dmitry V. Levin) Date: Sat, 27 Oct 2012 02:12:47 +0400 Subject: [PATCH] Fix potential heap corruption in "gpg -v --version" Message-ID: <20121026221247.GA18127@altlinux.org> * g10/gpg.c (build_list): Fix memory allocation arithmetics. --- Reproducer: env -i LANG=ru_RU.utf8 gpg -v --version Relevant to 2.0 and 1.4 stable branches as well. g10/gpg.c | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/g10/gpg.c b/g10/gpg.c index b614a94..b9253b1 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -904,9 +904,12 @@ build_list( const char *text, char letter, gcry_control (GCRYCTL_INIT_SECMEM, 0, 0); /* Drop setuid. */ for(i=0; i <= 110; i++ ) - if( !chkf(i) && (s=mapf(i)) ) - n += strlen(s) + 7 + 2; - list = xmalloc( 21 + n ); *list = 0; + if( !chkf(i) && (s=mapf(i)) ) { + n += strlen(s) + 2; + if(opt.verbose && letter) + n += 7; + } + list = xmalloc(n); *list = 0; for(p=NULL, i=0; i <= 110; i++ ) { if( !chkf(i) && (s=mapf(i)) ) { if( !p ) { @@ -917,18 +920,18 @@ build_list( const char *text, char letter, p = stpcpy( p, ", "); if(strlen(line)>60) { - int spaces=strlen(text); + size_t spaces = strlen(text); - list=xrealloc(list,n+spaces+1); + n += spaces + 1; + list = xrealloc(list, n); /* realloc could move the block, so find the end again */ - p=list; - while(*p) - p++; + p = list + strlen(list); p=stpcpy(p, "\n"); line=p; - for(;spaces;spaces--) - p=stpcpy(p, " "); + memset(p, ' ', spaces); + p += spaces; + *p = '\0'; } p = stpcpy(p, s ); -- ldv From wk at gnupg.org Sat Oct 27 18:45:20 2012 From: wk at gnupg.org (Werner Koch) Date: Sat, 27 Oct 2012 18:45:20 +0200 Subject: [PATCH] Fix potential heap corruption in "gpg -v --version" In-Reply-To: <20121026221247.GA18127@altlinux.org> (Dmitry V. Levin's message of "Sat, 27 Oct 2012 02:12:47 +0400") References: <20121026221247.GA18127@altlinux.org> Message-ID: <87d303c19b.fsf@vigenere.g10code.de> On Sat, 27 Oct 2012 00:12, ldv at altlinux.org said: > * g10/gpg.c (build_list): Fix memory allocation arithmetics. Please explain and provide a test case. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From tk at giga.or.at Sat Oct 27 19:56:08 2012 From: tk at giga.or.at (Thomas Klausner) Date: Sat, 27 Oct 2012 19:56:08 +0200 Subject: [PATCH 2/5] Support NetBSD/m68k. In-Reply-To: <1351360571-28331-1-git-send-email-tk@giga.or.at> References: <1351360571-28331-1-git-send-email-tk@giga.or.at> Message-ID: <1351360571-28331-3-git-send-email-tk@giga.or.at> From: Thomas Klausner --- mpi/config.links | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/mpi/config.links b/mpi/config.links index 2c57a0c..19a3006 100644 --- a/mpi/config.links +++ b/mpi/config.links @@ -194,6 +194,14 @@ case "${host}" in cat $srcdir/mpi/m68k/syntax.h >>./mpi/asm-syntax.h path="m68k" ;; + m68k*-*-netbsdelf) + echo '#define ELF_SYNTAX' >>./mpi/asm-syntax.h + cat $srcdir/mpi/m68k/syntax.h >>./mpi/asm-syntax.h + path="m68k" + if ! test x$M68060 = xYES; then + path="m68k/mc68020 m68k" + fi + ;; m68k-atari-mint) echo '#define MIT_SYNTAX' >>./mpi/asm-syntax.h cat $srcdir/mpi/m68k/syntax.h >>./mpi/asm-syntax.h -- 1.7.12.2 From tk at giga.or.at Sat Oct 27 19:56:07 2012 From: tk at giga.or.at (Thomas Klausner) Date: Sat, 27 Oct 2012 19:56:07 +0200 Subject: [PATCH 1/5] Only call dlerror() when dlsym() fails. In-Reply-To: <1351360571-28331-1-git-send-email-tk@giga.or.at> References: <1351360571-28331-1-git-send-email-tk@giga.or.at> Message-ID: <1351360571-28331-2-git-send-email-tk@giga.or.at> From: Thomas Klausner State of dlerror() is undefined otherwise, at least on NetBSD. --- cipher/idea-stub.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cipher/idea-stub.c b/cipher/idea-stub.c index 8996c75..c8036a4 100644 --- a/cipher/idea-stub.c +++ b/cipher/idea-stub.c @@ -131,9 +131,9 @@ load_module (const char *name) } sym = dlsym (handle, "idea_get_info"); - if (dlerror ()) + if ((sym == NULL) && dlerror()) sym = dlsym (handle, "_idea_get_info"); - if ((err=dlerror())) + if ((sym == NULL) && (err=dlerror())) goto failure; return (INFO_FNC)sym; -- 1.7.12.2 From tk at giga.or.at Sat Oct 27 19:56:10 2012 From: tk at giga.or.at (Thomas Klausner) Date: Sat, 27 Oct 2012 19:56:10 +0200 Subject: [PATCH 4/5] Deal with c99 inline semantics. In-Reply-To: <1351360571-28331-1-git-send-email-tk@giga.or.at> References: <1351360571-28331-1-git-send-email-tk@giga.or.at> Message-ID: <1351360571-28331-5-git-send-email-tk@giga.or.at> From: Thomas Klausner Needed for compilation with recent LLVM/Clang. --- mpi/mpi-inline.h | 4 ---- mpi/mpi-internal.h | 20 ++++++++++++++------ 2 files changed, 14 insertions(+), 10 deletions(-) diff --git a/mpi/mpi-inline.h b/mpi/mpi-inline.h index c32adae..31a6362 100644 --- a/mpi/mpi-inline.h +++ b/mpi/mpi-inline.h @@ -28,10 +28,6 @@ #ifndef G10_MPI_INLINE_H #define G10_MPI_INLINE_H -#ifndef G10_MPI_INLINE_DECL -#define G10_MPI_INLINE_DECL extern __inline__ -#endif - G10_MPI_INLINE_DECL mpi_limb_t mpihelp_add_1( mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, mpi_size_t s1_size, mpi_limb_t s2_limb) diff --git a/mpi/mpi-internal.h b/mpi/mpi-internal.h index c1df30a..38a624e 100644 --- a/mpi/mpi-internal.h +++ b/mpi/mpi-internal.h @@ -29,6 +29,14 @@ #ifndef G10_MPI_INTERNAL_H #define G10_MPI_INTERNAL_H +#ifndef G10_MPI_INLINE_DECL +#if defined(__GNUC_STDC_INLINE__) && __GNUC_STDC_INLINE__ +#define G10_MPI_INLINE_DECL __inline__ +#else +#define G10_MPI_INLINE_DECL extern __inline__ +#endif +#endif + #include "mpi.h" #include "mpi-asm-defs.h" @@ -198,19 +206,19 @@ void mpi_lshift_limbs( MPI a, unsigned int count ); /*-- mpihelp-add.c --*/ -mpi_limb_t mpihelp_add_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, +G10_MPI_INLINE_DECL mpi_limb_t mpihelp_add_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, mpi_size_t s1_size, mpi_limb_t s2_limb ); -mpi_limb_t mpihelp_add_n( mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, +G10_MPI_INLINE_DECL mpi_limb_t mpihelp_add_n( mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, mpi_ptr_t s2_ptr, mpi_size_t size); -mpi_limb_t mpihelp_add(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, mpi_size_t s1_size, +G10_MPI_INLINE_DECL mpi_limb_t mpihelp_add(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, mpi_size_t s1_size, mpi_ptr_t s2_ptr, mpi_size_t s2_size); /*-- mpihelp-sub.c --*/ -mpi_limb_t mpihelp_sub_1( mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, +G10_MPI_INLINE_DECL mpi_limb_t mpihelp_sub_1( mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, mpi_size_t s1_size, mpi_limb_t s2_limb ); -mpi_limb_t mpihelp_sub_n( mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, +G10_MPI_INLINE_DECL mpi_limb_t mpihelp_sub_n( mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, mpi_ptr_t s2_ptr, mpi_size_t size); -mpi_limb_t mpihelp_sub(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, mpi_size_t s1_size, +G10_MPI_INLINE_DECL mpi_limb_t mpihelp_sub(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, mpi_size_t s1_size, mpi_ptr_t s2_ptr, mpi_size_t s2_size); /*-- mpihelp-cmp.c --*/ -- 1.7.12.2 From tk at giga.or.at Sat Oct 27 19:56:09 2012 From: tk at giga.or.at (Thomas Klausner) Date: Sat, 27 Oct 2012 19:56:09 +0200 Subject: [PATCH 3/5] Remove unportable -c flag from chmod call. In-Reply-To: <1351360571-28331-1-git-send-email-tk@giga.or.at> References: <1351360571-28331-1-git-send-email-tk@giga.or.at> Message-ID: <1351360571-28331-4-git-send-email-tk@giga.or.at> From: Thomas Klausner --- scripts/autogen.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/autogen.sh b/scripts/autogen.sh index d820696..6423483 100755 --- a/scripts/autogen.sh +++ b/scripts/autogen.sh @@ -272,14 +272,14 @@ if [ -d .git ]; then and .git/hooks/pre-commit.sample out of the way. EOF cp -av .git/hooks/pre-commit.sample .git/hooks/pre-commit - chmod -c +x .git/hooks/pre-commit + chmod +x .git/hooks/pre-commit fi if [ -f scripts/git-hooks/commit-msg -a ! -f .git/hooks/commit-msg ] ; then cat <&2 *** Activating commit log message check hook. *** EOF cp -av scripts/git-hooks/commit-msg .git/hooks/commit-msg - chmod -c +x .git/hooks/commit-msg + chmod +x .git/hooks/commit-msg fi tmp=$(git config --get filter.cleanpo.clean) if [ "$tmp" != "awk '/^\"POT-Creation-Date:/&&!s{s=1;next};!/^#: /{print}'" ] -- 1.7.12.2 From tk at giga.or.at Sat Oct 27 19:56:06 2012 From: tk at giga.or.at (Thomas Klausner) Date: Sat, 27 Oct 2012 19:56:06 +0200 Subject: gnupg-1.4.12 patches from pkgsrc Message-ID: <1351360571-28331-1-git-send-email-tk@giga.or.at> This patchset contains all patches currently in pkgsrc for gnupg-1.4.12, applied to the git version of yesterday. Please add them to the git repository. From tk at giga.or.at Sat Oct 27 19:56:11 2012 From: tk at giga.or.at (Thomas Klausner) Date: Sat, 27 Oct 2012 19:56:11 +0200 Subject: [PATCH 5/5] Handle systems which have uint64_t but not the UINT64_C macro. In-Reply-To: <1351360571-28331-1-git-send-email-tk@giga.or.at> References: <1351360571-28331-1-git-send-email-tk@giga.or.at> Message-ID: <1351360571-28331-6-git-send-email-tk@giga.or.at> From: Thomas Klausner This could happen with UNIX98-type systems, such as the code on the netbsd-1-5 branch, and would prevent this package from building on such systems. --- include/types.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/include/types.h b/include/types.h index d6cd073..aea5515 100644 --- a/include/types.h +++ b/include/types.h @@ -102,7 +102,12 @@ typedef unsigned long u32; #undef u64 /* maybe there is a macro with this name */ #if SIZEOF_UINT64_T == 8 typedef uint64_t u64; +#ifdef UINT64_C #define U64_C(c) (UINT64_C(c)) +#else + /* make a best guess, could happen with UNIX98 */ +#define U64_C(c) (c) +#endif #define HAVE_U64_TYPEDEF #elif SIZEOF_UNSIGNED_INT == 8 typedef unsigned int u64; -- 1.7.12.2 From ldv at altlinux.org Sat Oct 27 22:07:24 2012 From: ldv at altlinux.org (Dmitry V. Levin) Date: Sun, 28 Oct 2012 00:07:24 +0400 Subject: [PATCH] Fix potential heap corruption in "gpg -v --version" In-Reply-To: <87d303c19b.fsf@vigenere.g10code.de> References: <20121026221247.GA18127@altlinux.org> <87d303c19b.fsf@vigenere.g10code.de> Message-ID: <20121027200724.GA26481@altlinux.org> On Sat, Oct 27, 2012 at 06:45:20PM +0200, Werner Koch wrote: > On Sat, 27 Oct 2012 00:12, ldv at altlinux.org said: > > * g10/gpg.c (build_list): Fix memory allocation arithmetics. > > Please explain I thought the patch is self-explanatory. Well, in short, build_list() fails to allocate required heap memory properly. In multibyte locales translated strings are usually longer (in bytes) than in C locale. The 1st argument of build_list() is a translated string. When it is long enough, build_list() attempts to produce a multi-line string with 2nd and other lines indented by the length of the 1st argument. The result looks ugly (because in a multibyte locale the length of a string in characters is less than its length in bytes) but the main problem is that build_list() fails to expand the buffer required to store this multi-line string: all it does is list=xrealloc(list,n+spaces+1); without updating "n" so the 2nd expand is no-op which unavoidably results to a heap corruption. Besides that, build_list() does other funny things with memory allocation and string operations, e.g. its only purpose of doing "xmalloc( 21 + n )" is confusing an observer because it doesn't need these extra 21 bytes, it does for(;spaces;spaces--) p=stpcpy(p, " "); to append "spaces" space bytes to the string "p", and so on. > and provide a test case. The reproducer is as simple as "env -i LANG=ru_RU.utf8 gpg -v --version". Do you want a patch for tests/openpgp/version.test that would invoke "gpg -v --version" in a multibyte locale? It would have to use po/*.mo files, which would be tricky. -- ldv -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From gniibe at fsij.org Mon Oct 29 07:11:22 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 29 Oct 2012 15:11:22 +0900 Subject: Smartcard readers / Tokens supported by the GnuPG CCID driver Message-ID: <1351491082.14385.1.camel@cfw2.gniibe.org> Hello, I created a WiKi page to collect information of supported Smartcard readers and tokens by the GnuPG's in-stock CCID driver: http://wiki.debian.org/GnuPG/CCID_Driver Please add information or correct mistakes. I found a page in "The GnuPG Smartcard HOWTO": http://www.gnupg.org/howtos/card-howto/en/ch02s03.html It suggests adding the file gnupg-ccid.rules, but it would be good if it just works out-of-box. -- From gniibe at fsij.org Tue Oct 30 02:25:58 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 30 Oct 2012 10:25:58 +0900 Subject: NeuG 0.04 In-Reply-To: <1349754240.2669.6.camel@cfw2.gniibe.org> References: <1349754240.2669.6.camel@cfw2.gniibe.org> Message-ID: <1351560358.2671.4.camel@cfw2.gniibe.org> NeuG version 0.04 is out. NeuG is an implementation of True Random Number Generator for STM32F103, which is based on quantization error of ADC. NeuG device is designed for "full entropy source", and it is useful when you need more entropy, such as generating GnuPG keys, or using ECC. Using Askbot, I created a Q&A site for FST-01, Gnuk, and NeuG. Please ask your questions there: http://no-passwd.net/askbot/questions/ There are only questions for FST-01 and Gnuk, currently, but questions for NeuG are also welcome. Here are the highlights of changes. * Update of ChibiOS/RT ChibiOS/RT is updated to newer 2.4.3. * Improved performance Improvement on generation speed, even when it's _not_ connected to USB 2.0 Hub. * Health tests run for NEUG_MODE_RAW Health tests run when NEUG_MODE_RAW (CRC32 filter output). * More runtime info: tool/neug_check.py Now, we can observe max counts of repeat count test, adaptive propotion test 64, and adaptive propotion test 4096. -- From gniibe at fsij.org Tue Oct 30 06:35:35 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 30 Oct 2012 14:35:35 +0900 Subject: [PATCH] open_pcsc_reader_wrapped should have same behavior as open_pcsc_reader_direct Message-ID: <1351575335.18008.2.camel@cfw2.gniibe.org> I think that open_pcsc_reader_wrapped should be as same as open_pcsc_reader_direct. Currently, pcsc_no_service is only set by open_pcsc_reader_direct. The patch below (against STABLE-BRANCH-2-0) fixes this. Compiled and tested lightly. Mostly same patch can be applied to master, too. diff --git a/scd/apdu.c b/scd/apdu.c index 0ce1c51..b369a26 100644 --- a/scd/apdu.c +++ b/scd/apdu.c @@ -221,6 +221,7 @@ static char (* DLSTDCALL CT_close) (unsigned short ctn); #define PCSC_E_SYSTEM_CANCELLED 0x80100012 #define PCSC_E_NOT_TRANSACTED 0x80100016 #define PCSC_E_READER_UNAVAILABLE 0x80100017 +#define PCSC_E_NO_SERVICE 0x8010001D #define PCSC_W_REMOVED_CARD 0x80100069 #define CM_IOCTL_GET_FEATURE_REQUEST (0x42000000 + 3400) @@ -1711,7 +1712,7 @@ open_pcsc_reader_direct (const char *portstr) pcsc_error_string (err), err); reader_table[slot].used = 0; unlock_slot (slot); - if (err == 0x8010001d) + if (err == PCSC_E_NO_SERVICE) pcsc_no_service = 1; return -1; } @@ -1819,6 +1820,7 @@ open_pcsc_reader_wrapped (const char *portstr) { log_error ("can't run PC/SC access module `%s': %s\n", wrapperpgm, strerror (errno)); + pcsc_no_service = 1; return -1; } @@ -1918,6 +1920,8 @@ open_pcsc_reader_wrapped (const char *portstr) ; #undef WAIT + pcsc_no_service = 1; + /* Now send the open request. */ msgbuf[0] = 0x01; /* OPEN command. */ len = portstr? strlen (portstr):0; @@ -1950,10 +1954,15 @@ open_pcsc_reader_wrapped (const char *portstr) { log_error ("PC/SC returned a too large ATR (len=%lx)\n", (unsigned long)len); + pcsc_no_service = 0; goto command_failed; } err = PCSC_ERR_MASK ((msgbuf[5] << 24) | (msgbuf[6] << 16) | (msgbuf[7] << 8 ) | msgbuf[8]); + + if (err != PCSC_E_NO_SERVICE) + pcsc_no_service = 0; + if (err) { log_error ("PC/SC OPEN failed: %s (0x%08x)\n", From wk at gnupg.org Tue Oct 30 11:08:13 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Oct 2012 11:08:13 +0100 Subject: [PATCH] Fix potential heap corruption in "gpg -v --version" In-Reply-To: <20121027200724.GA26481@altlinux.org> (Dmitry V. Levin's message of "Sun, 28 Oct 2012 00:07:24 +0400") References: <20121026221247.GA18127@altlinux.org> <87d303c19b.fsf@vigenere.g10code.de> <20121027200724.GA26481@altlinux.org> Message-ID: <87hapc8e7m.fsf@vigenere.g10code.de> On Sat, 27 Oct 2012 22:07, ldv at altlinux.org said: > In multibyte locales translated strings are usually longer (in bytes) than > in C locale. The 1st argument of build_list() is a translated string. Okay, that is the keyword which makes it clear. > Besides that, build_list() does other funny things with memory allocation > and string operations, e.g. its only purpose of doing "xmalloc( 21 + n )" > is confusing an observer because it doesn't need these extra 21 bytes, I'll look at this too. > Do you want a patch for tests/openpgp/version.test that would invoke "gpg > -v --version" in a multibyte locale? It would have to use po/*.mo files, No. That is currently too complicated. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Oct 30 11:05:09 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Oct 2012 11:05:09 +0100 Subject: [PATCH] open_pcsc_reader_wrapped should have same behavior as open_pcsc_reader_direct In-Reply-To: <1351575335.18008.2.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Tue, 30 Oct 2012 14:35:35 +0900") References: <1351575335.18008.2.camel@cfw2.gniibe.org> Message-ID: <87lieo8ecq.fsf@vigenere.g10code.de> On Tue, 30 Oct 2012 06:35, gniibe at fsij.org said: > The patch below (against STABLE-BRANCH-2-0) fixes this. Compiled > and tested lightly. > > Mostly same patch can be applied to master, too. The patch looks okay. Please go ahead and push to master and stable. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Wed Oct 31 03:11:31 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 31 Oct 2012 11:11:31 +0900 Subject: [PATCH] open_pcsc_reader_wrapped should have same behavior as open_pcsc_reader_direct In-Reply-To: <87lieo8ecq.fsf@vigenere.g10code.de> References: <1351575335.18008.2.camel@cfw2.gniibe.org> <87lieo8ecq.fsf@vigenere.g10code.de> Message-ID: <1351649491.2804.3.camel@cfw2.gniibe.org> On 2012-10-30 at 11:05 +0100, Werner Koch wrote: > On Tue, 30 Oct 2012 06:35, gniibe at fsij.org said: > > > The patch below (against STABLE-BRANCH-2-0) fixes this. Compiled > > and tested lightly. > > > > Mostly same patch can be applied to master, too. > > The patch looks okay. Please go ahead and push to master and stable. Done for both branches. -- From gniibe at fsij.org Wed Oct 31 08:09:06 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 31 Oct 2012 16:09:06 +0900 Subject: [PATCH] fix agent/findkey.c Message-ID: <1351667346.19651.1.camel@cfw2.gniibe.org> While I tested gpg-agent for 2.0 stable branch, it segfaulted when I did: $ gpg-connect-agent "READKEY 9277C5875C8AFFCB727661C18BE4E0A0DEED9260" /bye The keygrip 9277C5875C8AFFCB727661C18BE4E0A0DEED9260 was created by "monkeysphere s", which has a comment. It segfaluted in libgcrypt. So, I read the code of libgcrypt/src/sexp.c and I realized that the caller should offer pointer to the argument. Here is the fix (assuming libgcrypt is correct). Compiled and tested for 2.0 stable branch. Exactly same bug exists on the master branch, too. diff --git a/agent/findkey.c b/agent/findkey.c index 800db88..550e403 100644 --- a/agent/findkey.c +++ b/agent/findkey.c @@ -824,15 +824,15 @@ agent_public_key_from_file (ctrl_t ctrl, { p = stpcpy (p, "(uri %b)"); assert (argidx+1 < DIM (args)); - args[argidx++] = (void *)uri_length; - args[argidx++] = (void *)uri; + args[argidx++] = (void *)&uri_length; + args[argidx++] = (void *)&uri; } if (comment) { p = stpcpy (p, "(comment %b)"); assert (argidx+1 < DIM (args)); - args[argidx++] = (void *)comment_length; - args[argidx++] = (void*)comment; + args[argidx++] = (void *)&comment_length; + args[argidx++] = (void*)&comment; } *p++ = ')'; *p = 0; -- From wk at gnupg.org Wed Oct 31 14:17:23 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 31 Oct 2012 14:17:23 +0100 Subject: [PATCH] fix agent/findkey.c In-Reply-To: <1351667346.19651.1.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Wed, 31 Oct 2012 16:09:06 +0900") References: <1351667346.19651.1.camel@cfw2.gniibe.org> Message-ID: <87fw4u7pcs.fsf@vigenere.g10code.de> On Wed, 31 Oct 2012 08:09, gniibe at fsij.org said: > It segfaluted in libgcrypt. So, I read the code of > libgcrypt/src/sexp.c and I realized that the caller should offer > pointer to the argument. No, that is not the case. > - args[argidx++] = (void *)uri_length; > - args[argidx++] = (void *)uri; > + args[argidx++] = (void *)&uri_length; > + args[argidx++] = (void *)&uri; I would say, this is the correct fix: + args[argidx++] = (void *)((int)uri_length); + args[argidx++] = (void *)uri; The format string ("%b") expect an /int/ and an /const char */: else if (*p == 'b') { /* Insert a memory buffer. */ const char *astr; int alen; ARG_NEXT (alen, int); ARG_NEXT (astr, const char *); Thus the URI_LENGTH needs to be casted from size_t to int first. The /void*/ requirement is only to fit it into the array. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.