From dkg at fifthhorseman.net Tue Jun 2 04:52:23 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 1 Jun 2015 22:52:23 -0400 Subject: [PATCH] use g_debug(format, ...) safely Message-ID: <1433213543-18778-1-git-send-email-dkg@fifthhorseman.net> * pinentry/password-cache.c (password_cache_clear): use g_debug safely in case error->message is malformed. -- Without this change, with -Werror=format-security, we see: password-cache.c: In function ?password_cache_clear?: password-cache.c:153:7: error: format not a string literal and no format arguments [-Werror=format-security] g_debug(error->message); ^ --- pinentry/password-cache.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pinentry/password-cache.c b/pinentry/password-cache.c index 60a9c3a..70b33f4 100644 --- a/pinentry/password-cache.c +++ b/pinentry/password-cache.c @@ -150,7 +150,7 @@ password_cache_clear (const char *keygrip) { printf("Failed to clear password for key %s with secret service: %s\n", keygrip, error->message); - g_debug(error->message); + g_debug("%s", error->message); g_error_free (error); return -1; } -- 2.1.4 From gniibe at fsij.org Tue Jun 2 06:58:24 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 02 Jun 2015 13:58:24 +0900 Subject: [PATCH] scd: do_decipher change for OpenPGPcard v3.0 Message-ID: <556D37F0.80301@fsij.org> Hello, This is the change required by current draft of OpenPGPcard v3.0 specification. The decoration was not needed (for me), but, it would make sense, perhaps. I'm going to change Gnuk so that it will support both (w/ decoration or w/out decoration). diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 8520231..0e751e0 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -4046,6 +4046,7 @@ do_decipher (app_t app, const char *keyidstr, int exmode, le_value; unsigned char *fixbuf = NULL; int padind = 0; + int fixuplen = 0; if (!keyidstr || !*keyidstr || !indatalen) return gpg_error (GPG_ERR_INV_VALUE); @@ -4092,8 +4093,6 @@ do_decipher (app_t app, const char *keyidstr, if (app->app_local->keyattr[1].key_type == KEY_TYPE_RSA) { - int fixuplen; - /* We might encounter a couple of leading zeroes in the cryptogram. Due to internal use of MPIs these leading zeroes are stripped. However the OpenPGP card expects exactly 128 @@ -4146,7 +4145,26 @@ do_decipher (app_t app, const char *keyidstr, } } else if (app->app_local->keyattr[1].key_type == KEY_TYPE_ECC) - padind = -1; + { + fixuplen = 7; + fixbuf = xtrymalloc (fixuplen + indatalen); + if (!fixbuf) + return gpg_error_from_syserror (); + + /* Build 'Cipher DO' */ + fixbuf[0] = '\xa6'; + fixbuf[1] = (char)(indatalen+5); + fixbuf[2] = '\x7f'; + fixbuf[3] = '\x49'; + fixbuf[4] = (char)(indatalen+2); + fixbuf[5] = '\x86'; + fixbuf[6] = (char)indatalen; + memcpy (fixbuf+fixuplen, indata, indatalen); + indata = fixbuf; + indatalen = fixuplen + indatalen; + + padind = -1; + } else return gpg_error (GPG_ERR_INV_VALUE); -- From wk at gnupg.org Tue Jun 2 11:38:54 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jun 2015 11:38:54 +0200 Subject: [PATCH] use g_debug(format, ...) safely In-Reply-To: <1433213543-18778-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 1 Jun 2015 22:52:23 -0400") References: <1433213543-18778-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87y4k2qwk1.fsf@vigenere.g10code.de> On Tue, 2 Jun 2015 04:52, dkg at fifthhorseman.net said: > * pinentry/password-cache.c (password_cache_clear): use g_debug safely > in case error->message is malformed. Thanks. I also enabled more warnings to catch them in the future. Someone might want to check the warning for the Qt modules and add appropriate CPP (no-)warning options. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jun 2 15:23:06 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jun 2015 15:23:06 +0200 Subject: [Announce] GnuPG 2.0.28 "stable" released Message-ID: <87zj4ip7lx.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-2.0 release: Version 2.0.28. This is a maintenance release which fixes a couple of bugs. Update to this version is suggested. The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard as defined by RFC-4880 and better known as PGP. GnuPG, also known as GPG, allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. Since version 2 GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different versions of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features including support for ECC. - GnuPG "stable" (2.0) - which this is about - is the current stable version for general use. This is what most users are currently using. - GnuPG "classic" (1.4) is the old standalone version which is most suitable for older or embedded platforms. You may not install "modern" (2.1) and "stable" (2.0) at the same time. However, it is possible to install "classic" (1.4) along with any of the other versions. What's New in 2.0.28 ==================== * agent: Added support for an external password manager. * gpg: New command --list-gcrypt-config. * gpg: Issue NEWSIG status lines during signature verification. * gpgsm: The default hash algo for a CSR is now SHA-256 and the default encryption algo is AES-128. * scdaemon: Allow PC/SC reader selection by partial name match. * gpgtar: Fix extracting files with a size of a multiple of 512. * Fixed several other bugs. * Libgcrypt 1.5 is now required. Getting the Software ==================== Please follow the instructions found at https://gnupg.org/download/ or read on: GnuPG 2.0.28 may be downloaded from one of the GnuPG mirror sites or direct from . The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. On ftp.gnupg.org and on its mirrors you should find the following new files in the gnupg/ directory: - The GnuPG source code compressed using BZIP2 and its OpenPGP signature: gnupg-2.0.28.tar.bz2 (4332k) gnupg-2.0.28.tar.bz2.sig Note, that we don't distribute gzip compressed tarballs for GnuPG-2. A Windows version will eventually be released at https://gpg4win.org . If you are new to GnuPG please consider to use the "modern" version 2.1.4. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.0.28.tar.bz2 you would use this command: gpg --verify gnupg-2.0.28.tar.bz2.sig gnupg-2.0.28.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See below for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.0.28.tar.bz2, you would run the command like this: sha1sum gnupg-2.0.28.tar.bz2 and check that the output matches the next line: 9a1050f72b6c9afe2b4a0a3f2e9dca2abba8e4ef gnupg-2.0.28.tar.bz2 Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these files from the keyservers using this command gpg --recv-keys 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 using an already installed version of gpg. Remeber to check the fingerprints against the above list (which you also find on the flip side of our printed visit cards). The keys are also available at and in the released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed using my standard PGP key. Documentation ============= The file gnupg.info has the complete user manual of the system. Separate man pages are included as well; however they have not all the details available in the manual. It is also possible to read the complete manual online in HTML format at https://www.gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at https://www.gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. Support ======= Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . We also have a dedicated service directory at: https://www.gnupg.org/service.html If you are a developer and you may need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Maintenance and development of GnuPG is possible due to many individual and corporate donations; for a list of non-anonymous donors see . For the GnuPG hackers, Werner p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users 'at' gnupg.org mailing list. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From dkg at fifthhorseman.net Tue Jun 2 16:14:39 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 02 Jun 2015 10:14:39 -0400 Subject: [PATCH] Typo fix for gpg.texi In-Reply-To: <1409665400-14603-1-git-send-email-dkg@fifthhorseman.net> References: <1409665400-14603-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87oaky9oz4.fsf@alice.fifthhorseman.net> Hi GnuPG folks-- Thanks for the release of 2.0.28. The patch below still needs to be applied to the 2.0 branch: Regards, --dkg On Tue 2014-09-02 09:43:20 -0400, Daniel Kahn Gillmor wrote: > Originally reported by Jakub Wilk in https://bugs.debian.org/760273 > --- > doc/gpg.texi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/doc/gpg.texi b/doc/gpg.texi > index 7ac1613..e9bcff3 100644 > --- a/doc/gpg.texi > +++ b/doc/gpg.texi > @@ -3509,7 +3509,7 @@ sense. Although OpenPGP works with time intervals, GnuPG uses an > absolute value internally and thus the last year we can represent is > 2105. > > - at item Ceation-Date: @var{iso-date} > + at item Creation-Date: @var{iso-date} > Set the creation date of the key as stored in the key information and > which is also part of the fingerprint calculation. Either a date like > "1986-04-26" or a full timestamp like "19860426T042640" may be used. > -- > 2.1.0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Jun 2 16:16:31 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 02 Jun 2015 10:16:31 -0400 Subject: [PATCH] gpg: Fix segv due to NULL value stored as opaque MPI (BRANCH 2.0) In-Reply-To: <1424561024-22745-1-git-send-email-dkg@fifthhorseman.net> References: <1424561024-22745-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87lhg29ow0.fsf@alice.fifthhorseman.net> Hi GnuPG folks-- I believe the patch below still needs to be applied to the 2.0 branch. Regards, --dkg On Sat 2015-02-21 18:23:44 -0500, Daniel Kahn Gillmor wrote: > * g10/build-packet.c (do_secret_key): Check for NULL return from > gcry_mpi_get_opaque. > * g10/keyid.c (hash_public_key): Ditto. > -- > > This is a backport of 76c8122adfed0f0f443cce7bda702ba2b39661b3 from > master to the STABLE-BRANCH-2-0 > > On the STABLE-BRANCH-2-0, we may also want to patch g10/seckey-cert.c, > but that has not been done in this patch. > > This fix extends commmit 0835d2f44ef62eab51fce6a927908f544e01cf8f. > > gpg2 --export --no-default-keyring --keyring TESTDATA > > With TESTDATA being below after unpacking. > > -----BEGIN PGP ARMORED FILE----- > > mBMEhdkMmS8BcX8F//8F5voEhQAQmBMEnAAAZwAAo4D/f/8EhQAAAIAEnP8EhQAQ > iBMEnP8AAAAABf8jIID///8EhQYQmBMEnIUAEIgTBKT/AAAAAAUAACCA/f//BIUA > EJgTBJx/AP8ABPPzBJx/AP8ABPPz > =2yE0 > -----END PGP ARMORED FILE----- > > Reported-by: Jodie Cunningham > Signed-off-by: Daniel Kahn Gillmor > --- > g10/build-packet.c | 6 ++++-- > g10/keyid.c | 16 ++++++++++------ > 2 files changed, 14 insertions(+), 8 deletions(-) > > diff --git a/g10/build-packet.c b/g10/build-packet.c > index e986987..5cc03cf 100644 > --- a/g10/build-packet.c > +++ b/g10/build-packet.c > @@ -398,7 +398,8 @@ do_secret_key( IOBUF out, int ctb, PKT_secret_key *sk ) > > assert (gcry_mpi_get_flag (sk->skey[npkey], GCRYMPI_FLAG_OPAQUE)); > p = gcry_mpi_get_opaque (sk->skey[npkey], &ndatabits ); > - iobuf_write (a, p, (ndatabits+7)/8 ); > + if (p) > + iobuf_write (a, p, (ndatabits+7)/8 ); > } > else if ( sk->is_protected ) > { > @@ -410,7 +411,8 @@ do_secret_key( IOBUF out, int ctb, PKT_secret_key *sk ) > > assert (gcry_mpi_get_flag (sk->skey[i], GCRYMPI_FLAG_OPAQUE)); > p = gcry_mpi_get_opaque (sk->skey[i], &ndatabits); > - iobuf_write (a, p, (ndatabits+7)/8); > + if (p) > + iobuf_write (a, p, (ndatabits+7)/8); > } > write_16(a, sk->csum ); > } > diff --git a/g10/keyid.c b/g10/keyid.c > index 6af0f48..ef6ee1c 100644 > --- a/g10/keyid.c > +++ b/g10/keyid.c > @@ -115,14 +115,18 @@ hash_public_key( gcry_md_hd_t md, PKT_public_key *pk ) > if(npkey==0 && pk->pkey[0] > && gcry_mpi_get_flag (pk->pkey[0], GCRYMPI_FLAG_OPAQUE)) > { > - gcry_md_write (md, pp[0], nn[0]); > + if (pp[0]) > + gcry_md_write (md, pp[0], nn[0]); > } > else > - for(i=0; i < npkey; i++ ) > - { > - gcry_md_write ( md, pp[i], nn[i] ); > - xfree(pp[i]); > - } > + { > + for(i=0; i < npkey; i++ ) > + { > + if (pp[i]) > + gcry_md_write ( md, pp[i], nn[i] ); > + xfree(pp[i]); > + } > + } > } > > static gcry_md_hd_t > -- > 2.1.4 > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Jun 2 17:33:31 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 02 Jun 2015 11:33:31 -0400 Subject: s2k-cipher-mode default Message-ID: <87d21e9lbo.fsf@alice.fifthhorseman.net> Hi GnuPG devs-- I've been thinking about s2k-cipher-mode defaults. In 2.0 and 1.4 branches, this defaults to CAST5. In 2.1, it defaults to AES (aes128). I think it should change to AES256, with explanation below. When s2k-cipher-mode is used to select the cipher for secret key material, there is no interoperability concerns: this is relevant only for the system that it's on. Therefore, for ciphers that select the secret key, it should be the strongest symmetric cipher known to the running system. This is probably AES256, not CAST5 or AES128. Interoperability concerns may arise when this is applied to symmetric encryption intended for a remote recipient. In this case, it's possible that the peer doesn't have access to AES256. AES was standardized in 2001, 14 years ago. The underlying algorithm, Rijndael, was known for years before the standardization process. GnuPG added AES256 around 2002. PGP 7.0.3, from ~2001 supports AES256 (i have not checked earlier versions of PGP). Peers that do not support AES256 are either extremely rare or hopelessly out of date. Reducing the strength of the ciphers in use for the sake of preserving interop with these peers seems like a bad tradeoff. What do folks think about making this change to the defaults? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From wk at gnupg.org Tue Jun 2 18:31:24 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jun 2015 18:31:24 +0200 Subject: s2k-cipher-mode default In-Reply-To: <87d21e9lbo.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 02 Jun 2015 11:33:31 -0400") References: <87d21e9lbo.fsf@alice.fifthhorseman.net> Message-ID: <87mw0im5r7.fsf@vigenere.g10code.de> On Tue, 2 Jun 2015 17:33, dkg at fifthhorseman.net said: > I think it should change to AES256, with explanation below. I am fine to switch to AES-128 for 2.0 too. > secret key, it should be the strongest symmetric cipher known to the > running system. This is probably AES256, not CAST5 or AES128. Whether AES-256 is stronger than AES-128 in the real world is a pretty good bike shedding topic. Changing the default cipher to AES-256 should be the least problem for those who need such a kind of protection. Here is my reason why AES-128 is a better *default*: AES-128 | nanosecs/byte mebibytes/sec cycles/byte CFB enc | 1.77 ns/B 537.9 MiB/s 4.08 c/B CFB dec | 0.374 ns/B 2548.9 MiB/s 0.861 c/B OCB enc | 0.527 ns/B 1810.8 MiB/s 1.21 c/B OCB dec | 0.546 ns/B 1746.0 MiB/s 1.26 c/B AES-256 | nanosecs/byte mebibytes/sec cycles/byte CFB enc | 2.42 ns/B 393.6 MiB/s 5.57 c/B CFB dec | 0.543 ns/B 1755.1 MiB/s 1.25 c/B OCB enc | 0.695 ns/B 1372.9 MiB/s 1.60 c/B OCB dec | 0.728 ns/B 1310.2 MiB/s 1.67 c/B OpenPGP uses CFB mode. I listed OCB in case rfc4880bis will switch to that mode. Encrypting with AES-128 is 35% faster than with AES-256. Decrypting with AES-128 is 45% faster than with AES-256. It makes a difference whether you need 32 or 45 minutes to encrypt 1TiB. Yeah, I know this is theoretical because a backup is I/O bounded but nevertheless AES-256 takes up more CPU resources than AES-128. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jun 2 19:08:04 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jun 2015 19:08:04 +0200 Subject: passphrase callback In-Reply-To: <20150529070517.GC5163@belle.intranet.vanheusden.com> (folkert@vanheusden.com's message of "Fri, 29 May 2015 09:05:17 +0200") References: <20150527193008.GA5163@belle.intranet.vanheusden.com> <20150527210717.GB5163@belle.intranet.vanheusden.com> <87vbfdyyks.fsf@vigenere.g10code.de> <20150529070517.GC5163@belle.intranet.vanheusden.com> Message-ID: <87iob6m423.fsf@vigenere.g10code.de> On Fri, 29 May 2015 09:05, folkert at vanheusden.com said: > Ah so there's a mismatch between the gpgme and gpg2 version in debian > right? Can you confirm this? Then I'll create a debian bug report for GPGME is independent of GnuPG. In general GPGME checks the GnuPG version before using a new GnuPG feature. However, when I added the passphrase-mode feature to GPGME I assumed that it will only be used by users who require GnuPG 2.1 anyway and thus saved the overhead of checking the version. > Yeah but maybe it should emit an error or so. Maybe in debug-mode. Similar functions (e.g. gpgme_set_progress_cb) work exactly the same way. In fact they do not hav a way to return an error code. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jun 2 19:16:04 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jun 2015 19:16:04 +0200 Subject: for signing; selecting a specific private key In-Reply-To: <20150531181406.GF5163@belle.intranet.vanheusden.com> (folkert@vanheusden.com's message of "Sun, 31 May 2015 20:14:06 +0200") References: <20150531181406.GF5163@belle.intranet.vanheusden.com> Message-ID: <87eglum3or.fsf@vigenere.g10code.de> On Sun, 31 May 2015 20:14, folkert at vanheusden.com said: > In the key ring I have more then 1 private key so I want to select the > correct one. > This fails with: "Unusable secret key (117440566)". Tou run into this error: /* In this case at least one signatures was not created perhaps due to a bad passphrase etc. Thus the entire message is broken and should not be used. We add the already created signatures to the invalid signers list and thus this case can be detected. */ TRACE_LOG3 ("result: invalid signers: %u, signatures: %u, count: %u", inv_signers, signatures, gpgme_signers_count (ctx)); Please enable gpgme debugging at level 3 or higher to get detailed information. GPGME_DEBUG=4:/foo/bar/gpgme.log ./program Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Tue Jun 2 19:25:39 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 02 Jun 2015 13:25:39 -0400 Subject: s2k-cipher-mode default In-Reply-To: <87mw0im5r7.fsf@vigenere.g10code.de> References: <87d21e9lbo.fsf@alice.fifthhorseman.net> <87mw0im5r7.fsf@vigenere.g10code.de> Message-ID: <871thu9g4s.fsf@alice.fifthhorseman.net> On Tue 2015-06-02 12:31:24 -0400, Werner Koch wrote: > On Tue, 2 Jun 2015 17:33, dkg at fifthhorseman.net said: > >> I think it should change to AES256, with explanation below. > > I am fine to switch to AES-128 for 2.0 too. Any reason to avoid it for the 1.4 branch? >> secret key, it should be the strongest symmetric cipher known to the >> running system. This is probably AES256, not CAST5 or AES128. > > Whether AES-256 is stronger than AES-128 in the real world is a pretty > good bike shedding topic. Changing the default cipher to AES-256 should > be the least problem for those who need such a kind of protection. > > Here is my reason why AES-128 is a better *default*: > > AES-128 | nanosecs/byte mebibytes/sec cycles/byte > CFB enc | 1.77 ns/B 537.9 MiB/s 4.08 c/B > CFB dec | 0.374 ns/B 2548.9 MiB/s 0.861 c/B > OCB enc | 0.527 ns/B 1810.8 MiB/s 1.21 c/B > OCB dec | 0.546 ns/B 1746.0 MiB/s 1.26 c/B > > AES-256 | nanosecs/byte mebibytes/sec cycles/byte > CFB enc | 2.42 ns/B 393.6 MiB/s 5.57 c/B > CFB dec | 0.543 ns/B 1755.1 MiB/s 1.25 c/B > OCB enc | 0.695 ns/B 1372.9 MiB/s 1.60 c/B > OCB dec | 0.728 ns/B 1310.2 MiB/s 1.67 c/B > > OpenPGP uses CFB mode. I listed OCB in case rfc4880bis will switch to > that mode. > > Encrypting with AES-128 is 35% faster than with AES-256. > Decrypting with AES-128 is 45% faster than with AES-256. > > It makes a difference whether you need 32 or 45 minutes to encrypt > 1TiB. This is the case for symmetric backups. For secret key protection, the time difference is negligible compared to things like passphrase entry. Do you still think this argument is relevant for secret key protection? > Yeah, I know this is theoretical because a backup is I/O bounded but > nevertheless AES-256 takes up more CPU resources than AES-128. As you say, CPU is not the bottleneck on modern systems dealing with this kind of data, either large or small. So why not move to stronger protections against an adversary who might have visibility of the ciphertext? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From wk at gnupg.org Tue Jun 2 20:38:13 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jun 2015 20:38:13 +0200 Subject: s2k-cipher-mode default In-Reply-To: <871thu9g4s.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 02 Jun 2015 13:25:39 -0400") References: <87d21e9lbo.fsf@alice.fifthhorseman.net> <87mw0im5r7.fsf@vigenere.g10code.de> <871thu9g4s.fsf@alice.fifthhorseman.net> Message-ID: <877frmlzvu.fsf@vigenere.g10code.de> On Tue, 2 Jun 2015 19:25, dkg at fifthhorseman.net said: >> I am fine to switch to AES-128 for 2.0 too. > > Any reason to avoid it for the 1.4 branch? Can be done. > This is the case for symmetric backups. For secret key protection, the > time difference is negligible compared to things like passphrase entry. Secret key protection does not require that strength. Do you really thing anyone is using a passphrase (intended to be memorized) with more than 128 bit of entropy? Anywa, I won't care whether this is AES-256 or AES-128 - implementation wise it does not make a real difference to implement one or both. > As you say, CPU is not the bottleneck on modern systems dealing with > this kind of data, either large or small. So why not move to stronger Why using cycles and energy without a reason? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Tue Jun 2 21:01:21 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 02 Jun 2015 15:01:21 -0400 Subject: s2k-cipher-mode default In-Reply-To: <877frmlzvu.fsf@vigenere.g10code.de> References: <87d21e9lbo.fsf@alice.fifthhorseman.net> <87mw0im5r7.fsf@vigenere.g10code.de> <871thu9g4s.fsf@alice.fifthhorseman.net> <877frmlzvu.fsf@vigenere.g10code.de> Message-ID: <87twuq7x4u.fsf@alice.fifthhorseman.net> On Tue 2015-06-02 14:38:13 -0400, Werner Koch wrote: > On Tue, 2 Jun 2015 19:25, dkg at fifthhorseman.net said: > >>> I am fine to switch to AES-128 for 2.0 too. >> >> Any reason to avoid it for the 1.4 branch? > > Can be done. Thanks, making all the branches have the same defaults when they support the same algorithms seems reasonable to me. >> This is the case for symmetric backups. For secret key protection, the >> time difference is negligible compared to things like passphrase entry. > > Secret key protection does not require that strength. Do you really > thing anyone is using a passphrase (intended to be memorized) with more > than 128 bit of entropy? No, i suspect that most people are not. But (a) why limit them to it? and (b) as i mentioned to Robert, depending on the attacks against AES-128, and how much key material is intended to be protected, there may be attacks against AES that are significantly more effective than brute force over the entire keyspace. > Anywa, I won't care whether this is AES-256 or AES-128 - implementation > wise it does not make a real difference to implement one or both. Both are implemented already. I'm asking about what the default should be. >> As you say, CPU is not the bottleneck on modern systems dealing with >> this kind of data, either large or small. So why not move to stronger > > Why using cycles and energy without a reason? To protect data at rest against a powerful adversary, right? Regards, --dkg From gniibe at fsij.org Wed Jun 3 13:49:14 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 03 Jun 2015 20:49:14 +0900 Subject: Canonical Key Format for ECC? Message-ID: <556EE9BA.3040209@fsij.org> Hello, I'm testing OpenPGPcard specification v3.0 for ECC. Currently, I'm testing NIST P-256 curve. I got test key from: A. Jivsov, Sample Keys and Messages: https://sites.google.com/site/brainhub/pgpecckeys and imported. Then, the private key is created under .gnupg/private-keys-v1.d/E4403F3FD7A443FAC29FEF288FA0D20AC212851E.key in the format of: (private-key(ecc(curve 1.2.840.10045.3.1.7)....)) On the other hand, when we generate a key, it is in the format of: (private-key(ecc(curve NIST P-256)...)) Those two are same thing, but I think that it's better to use one. Shouldn't we fix the code (g10/import.c:transfer_secret_keys) to use the name of curve (instead of OID string)? -- From dkg at fifthhorseman.net Wed Jun 3 17:03:13 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 03 Jun 2015 11:03:13 -0400 Subject: Canonical Key Format for ECC? In-Reply-To: <556EE9BA.3040209@fsij.org> References: <556EE9BA.3040209@fsij.org> Message-ID: <87oakw7s26.fsf@alice.fifthhorseman.net> On Wed 2015-06-03 07:49:14 -0400, NIIBE Yutaka wrote: > Then, the private key is created under > .gnupg/private-keys-v1.d/E4403F3FD7A443FAC29FEF288FA0D20AC212851E.key > in the format of: > > (private-key(ecc(curve 1.2.840.10045.3.1.7)....)) > > On the other hand, when we generate a key, it is in the format of: > > (private-key(ecc(curve NIST P-256)...)) > > Those two are same thing, but I think that it's better to use one. > > Shouldn't we fix the code (g10/import.c:transfer_secret_keys) to use > the name of curve (instead of OID string)? I like the named format better than the OID format, just because it's more readable if someone looks in. I don't know anyone who has memorized the OID space, but i know that the string "NIST P-256" is meaningful to many of the people who might dig around inside ~/.gnupg/private-keys-v1.d. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From wk at gnupg.org Wed Jun 3 17:45:45 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Jun 2015 17:45:45 +0200 Subject: Canonical Key Format for ECC? In-Reply-To: <556EE9BA.3040209@fsij.org> (NIIBE Yutaka's message of "Wed, 03 Jun 2015 20:49:14 +0900") References: <556EE9BA.3040209@fsij.org> Message-ID: <877frkkd7a.fsf@vigenere.g10code.de> On Wed, 3 Jun 2015 13:49, gniibe at fsij.org said: > A. Jivsov, Sample Keys and Messages: > https://sites.google.com/site/brainhub/pgpecckeys FWIW, the same keys are available at gnupg/tests/openpgp/samplekeys/ecc-sample-*.asc > Shouldn't we fix the code (g10/import.c:transfer_secret_keys) to use > the name of curve (instead of OID string)? Given that Libgcrypt uses "NIST P-nnn" as canonical names and makes the OIDs only aliases, this changing makes sense. It requires a few lines of extra code and my laziness is the only reason I have not done it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Wed Jun 3 19:27:26 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 3 Jun 2015 13:27:26 -0400 Subject: [PATCH] pinentry_setbufferlen returns pin when already large enough Message-ID: <1433352446-6643-1-git-send-email-dkg@fifthhorseman.net> * pinentry/pinentry.c (pinentry_setbufferlen): when pin buffer is already large enough, return the buffer instead of NULL. pinentry-curses.c is the only place that checks this return value now, and it expects this behavior. -- Signed-Off-By: Daniel Kahn Gillmor Debian-Bug-Id: 787639 --- pinentry/pinentry.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pinentry/pinentry.c b/pinentry/pinentry.c index 9a6a090..94909dc 100644 --- a/pinentry/pinentry.c +++ b/pinentry/pinentry.c @@ -435,7 +435,7 @@ pinentry_setbufferlen (pinentry_t pin, int len) len = 2048; if (len <= pin->pin_len) - return NULL; + return pin->pin; newp = secmem_realloc (pin->pin, len); if (newp) -- 2.1.4 From gniibe at fsij.org Wed Jun 3 23:07:55 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 04 Jun 2015 06:07:55 +0900 Subject: [PATCH] scd: do_decipher change for OpenPGPcard v3.0 In-Reply-To: <556D37F0.80301@fsij.org> References: <556D37F0.80301@fsij.org> Message-ID: <556F6CAB.5060504@fsij.org> On 06/02/2015 01:58 PM, NIIBE Yutaka wrote: > This is the change required by current draft of OpenPGPcard v3.0 > specification. Well, it's published now. > The decoration was not needed (for me), but, it would make sense, > perhaps. > > I'm going to change Gnuk so that it will support both (w/ decoration > or w/out decoration). Tested with Gnuk 1.1.5 using NIST P-256 keys. OK to apply? -- From wk at gnupg.org Thu Jun 4 15:55:23 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 04 Jun 2015 15:55:23 +0200 Subject: [PATCH] scd: do_decipher change for OpenPGPcard v3.0 In-Reply-To: <556F6CAB.5060504@fsij.org> (NIIBE Yutaka's message of "Thu, 04 Jun 2015 06:07:55 +0900") References: <556D37F0.80301@fsij.org> <556F6CAB.5060504@fsij.org> Message-ID: <87sia7h92s.fsf@vigenere.g10code.de> On Wed, 3 Jun 2015 23:07, gniibe at fsij.org said: > Tested with Gnuk 1.1.5 using NIST P-256 keys. > > OK to apply? Sure, but in any case you decide. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Thu Jun 4 17:47:34 2015 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 04 Jun 2015 17:47:34 +0200 Subject: [PATCH] pinentry_setbufferlen returns pin when already large enough In-Reply-To: <1433352446-6643-1-git-send-email-dkg@fifthhorseman.net> References: <1433352446-6643-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87zj4fqxux.wl-neal@walfield.org> Hi Daniel, At Wed, 3 Jun 2015 13:27:26 -0400, Daniel Kahn Gillmor wrote: > > * pinentry/pinentry.c (pinentry_setbufferlen): when pin buffer is > already large enough, return the buffer instead of NULL. > pinentry-curses.c is the only place that checks this return value > now, and it expects this behavior. I've applied this with a slightly different change log. Thanks! :) Neal From dkg at fifthhorseman.net Thu Jun 4 19:36:30 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 04 Jun 2015 13:36:30 -0400 Subject: pinentry-gnome3 and gpg-agent 2.0.28 kbd accelerators not working Message-ID: <87bngv2x5t.fsf@alice.fifthhorseman.net> Hi Neal and other pinentry folks-- pinentry-gnome3 doesn't seem to be making proper use of the keyboard accelerators. Instead, it shows the prefixed underscores, and doesn't convert them into accelerator shortcuts. Here's a screenshot (look at "_OK", "_Cancel", and "_Save in Password manager"): -------------- next part -------------- A non-text attachment was scrubbed... Name: pinentry-gnome3.screenshot.small.jpg Type: image/jpeg Size: 24474 bytes Desc: pinentry-gnome3 showing (but not using) keyboard accelerators URL: -------------- next part -------------- I looked in the code, but I'm not sure how to fix this. Any pointers? This is when it is used against GnuPG 2.0.28 on debian unstable. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From neal at walfield.org Thu Jun 4 19:52:34 2015 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 04 Jun 2015 19:52:34 +0200 Subject: pinentry-gnome3 and gpg-agent 2.0.28 kbd accelerators not working In-Reply-To: <87bngv2x5t.fsf@alice.fifthhorseman.net> References: <87bngv2x5t.fsf@alice.fifthhorseman.net> Message-ID: <87wpzjqs2l.wl-neal@walfield.org> Hi Daniel, At Thu, 04 Jun 2015 13:36:30 -0400, Daniel Kahn Gillmor wrote: > Hi Neal and other pinentry folks-- > > pinentry-gnome3 doesn't seem to be making proper use of the keyboard > accelerators. Instead, it shows the prefixed underscores, and doesn't > convert them into accelerator shortcuts. > > Here's a screenshot (look at "_OK", "_Cancel", and "_Save in Password > manager"): > > > I looked in the code, but I'm not sure how to fix this. Any pointers? > > This is when it is used against GnuPG 2.0.28 on debian unstable. I just tried something similar on my system and the accelerators are displayed and work fine. There is probably a bug in the gcr backend that you are using. I'm on Xfce and thus (AIUI) I get the Gtk+ back end. :) Neal From dkg at fifthhorseman.net Thu Jun 4 20:11:20 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 04 Jun 2015 14:11:20 -0400 Subject: pinentry-gnome3 and gpg-agent 2.0.28 kbd accelerators not working In-Reply-To: <87wpzjqs2l.wl-neal@walfield.org> References: <87bngv2x5t.fsf@alice.fifthhorseman.net> <87wpzjqs2l.wl-neal@walfield.org> Message-ID: <87y4jz1gzb.fsf@alice.fifthhorseman.net> On Thu 2015-06-04 13:52:34 -0400, Neal H. Walfield wrote: > I just tried something similar on my system and the accelerators are > displayed and work fine. There is probably a bug in the gcr backend > that you are using. I'm on Xfce and thus (AIUI) I get the Gtk+ back > end. Thanks for the quick response, Neal. another twisty maze of dependencies for me to track down :/ Can you send a screenshot of what your xfce screenshot looks like? I'll try to reproduce it here too... --dkg From neal at walfield.org Thu Jun 4 20:28:20 2015 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 04 Jun 2015 20:28:20 +0200 Subject: pinentry-gnome3 and gpg-agent 2.0.28 kbd accelerators not working In-Reply-To: <87y4jz1gzb.fsf@alice.fifthhorseman.net> References: <87bngv2x5t.fsf@alice.fifthhorseman.net> <87wpzjqs2l.wl-neal@walfield.org> <87y4jz1gzb.fsf@alice.fifthhorseman.net> Message-ID: <87twunqqez.wl-neal@walfield.org> At Thu, 04 Jun 2015 14:11:20 -0400, Daniel Kahn Gillmor wrote: > > On Thu 2015-06-04 13:52:34 -0400, Neal H. Walfield wrote: > > > I just tried something similar on my system and the accelerators are > > displayed and work fine. There is probably a bug in the gcr backend > > that you are using. I'm on Xfce and thus (AIUI) I get the Gtk+ back > > end. > > Thanks for the quick response, Neal. another twisty maze of > dependencies for me to track down :/ > > Can you send a screenshot of what your xfce screenshot looks like? I'll > try to reproduce it here too... Here are the Assuan commands that I used: setok _OK setcancel _Cancel option default-pwmngr _Save in Password manager option allow-external-password-cache setkeyinfo Foo getpin The screenshot is attached. Interestingly, the check box's accelerator is not working, but the OK and Cancel buttons are. Neal -------------- next part -------------- A non-text attachment was scrubbed... Name: pinentry-gnome3.png Type: image/png Size: 14998 bytes Desc: not available URL: From neal at walfield.org Thu Jun 4 20:31:22 2015 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 04 Jun 2015 20:31:22 +0200 Subject: pinentry-gnome3 and gpg-agent 2.0.28 kbd accelerators not working In-Reply-To: <87sia71gf0.fsf@alice.fifthhorseman.net> References: <87bngv2x5t.fsf@alice.fifthhorseman.net> <87wpzjqs2l.wl-neal@walfield.org> <87y4jz1gzb.fsf@alice.fifthhorseman.net> <87sia71gf0.fsf@alice.fifthhorseman.net> Message-ID: <87sia7qq9x.wl-neal@walfield.org> Hi Daniel, At Thu, 04 Jun 2015 14:23:31 -0400, Daniel Kahn Gillmor wrote: > in this case, the accelerators work for Cancel and OK, but they don't > work for "_Save in password manager". > > What's different about our setups that they work for you? Sorry, as I mentioned in my other message just now, the buttons work for me, but the checkbox accelerator does not. > PS i notice one other issue under xfce4 that doesn't happen in gnome3: > in xfce4, the TAB key is treated as input to the password field, instead > of switching input fields. shift-TAB, however, does work to cycle > through the fields in reverse tab order. under GNOME, both TAB and > shift-TAB work as expected. weirdness... I just tried it and both tab and shift-tab seem to work normally. (I'm using Debian Jessie.) :) Neal From folkert at vanheusden.com Thu Jun 4 20:59:05 2015 From: folkert at vanheusden.com (folkert) Date: Thu, 4 Jun 2015 20:59:05 +0200 Subject: for signing; selecting a specific private key In-Reply-To: <87eglum3or.fsf@vigenere.g10code.de> References: <20150531181406.GF5163@belle.intranet.vanheusden.com> <87eglum3or.fsf@vigenere.g10code.de> Message-ID: <20150604185905.GC9362@belle.intranet.vanheusden.com> Hi, > > In the key ring I have more then 1 private key so I want to select the > > correct one. > > This fails with: "Unusable secret key (117440566)". > > Tou run into this error: > /* In this case at least one signatures was not created perhaps > due to a bad passphrase etc. Thus the entire message is > broken and should not be used. We add the already created > signatures to the invalid signers list and thus this case can > be detected. */ I've created a key both with gnupg and gnupg2 both have the same problem. > TRACE_LOG3 ("result: invalid signers: %u, signatures: %u, count: %u", > inv_signers, signatures, gpgme_signers_count (ctx)); This tracing does not appear in eighter the gpg nor the gpg2 key version. > Please enable gpgme debugging at level 3 or higher to get detailed > information. > GPGME_DEBUG=4:/foo/bar/gpgme.log ./program gpg key: ------- GPGME 2015-06-04 18:57:09 <0x1905> gpgme_debug: level=4 GPGME 2015-06-04 18:57:09 <0x1905> gpgme_check_version: call: 0=(nil), req_version=(null), VERSION=1.5.1 GPGME 2015-06-04 18:57:09 <0x1905> gpgme_check_version_internal: call: 0=(nil), req_version=(null), offset_sig_validity=60 GPGME 2015-06-04 18:57:09 <0x1905> gpgme_set_locale: enter: ctx=(nil), category=0, value=C GPGME 2015-06-04 18:57:09 <0x1905> gpgme_set_locale: leave GPGME 2015-06-04 18:57:09 <0x1905> gpgme_set_locale: enter: ctx=(nil), category=5, value=C GPGME 2015-06-04 18:57:09 <0x1905> gpgme_set_locale: leave GPGME 2015-06-04 18:57:09 <0x1905> gpgme-dinfo: gpgconf='/usr/bin/gpgconf' GPGME 2015-06-04 18:57:09 <0x1905> gpgme-dinfo: gpg='/usr/bin/gpg2' GPGME 2015-06-04 18:57:09 <0x1905> gpgme-dinfo: gpgsm='/usr/bin/gpgsm' GPGME 2015-06-04 18:57:09 <0x1905> gpgme-dinfo: homedir='/home/folkert/.gnupg' GPGME 2015-06-04 18:57:09 <0x1905> gpgme-dinfo: agent='/home/folkert/.gnupg/S.gpg-agent' GPGME 2015-06-04 18:57:09 <0x1905> gpgme-dinfo: uisrv='/home/folkert/.gnupg/S.uiserver' GPGME 2015-06-04 18:57:09 <0x1905> gpgme_new: enter: r_ctx=0x7ffdf87155a8 GPGME 2015-06-04 18:57:09 <0x1905> gpgme_new: leave: ctx=0x16c8810 GPGME 2015-06-04 18:57:09 <0x1905> gpgme_op_keylist_start: enter: ctx=0x16c8810, pattern=14B7E8E6, secret_only=1 GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_add_io_cb: call: ctx=0x16c8810, fd 4, dir=1 -> tag=0x16ca6b0 GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_add_io_cb: call: ctx=0x16c8810, fd 6, dir=1 -> tag=0x16ca800 GPGME 2015-06-04 18:57:09 <0x1905> gpgme:gpg_io_event: call: gpg=0x16c8c10, event 0x7f6a59a9dad0, type 0, type_data (nil) GPGME 2015-06-04 18:57:09 <0x1905> gpgme_op_keylist_start: leave GPGME 2015-06-04 18:57:09 <0x1905> gpgme_op_keylist_next: enter: ctx=0x16c8810 GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16ca820, need to check GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16ca820, handler (0x16c8c10, 6) GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16c8810, key = (nil), line = sec:u:1024:1:D2C2514414B7E8E6:1432752075:::u:::scESC:::::: GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16c8810, key = 0x16ca850, line = fpr:::::::::95C76C5EF83943DA2F322CF4D2C2514414B7E8E6: GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16c8810, key = 0x16ca850, line = uid:u::::1432752075::8ECF92C774CE2A15116BEB0B2038DE9D3CCA7A9E::testkey2 (testkey2) : GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16c8810, key = 0x16ca850, line = ssb:u:1024:1:2E197B51ED8059EA:1432752075::::::e:::::: GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16c8810, key = 0x16ca850, line = fpr:::::::::47AE514B363C3E225FD474022E197B51ED8059EA: GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16c8810, key = 0x16ca850, line = ssb:u:1024:1:7A26564274D6F5C6:1433074279::::::s:::::: GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16c8810, key = 0x16ca850, line = fpr:::::::::61F756F77290CBBCE30988567A26564274D6F5C6: GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16ca820, need to check GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16ca820, handler (0x16c8c10, 6) GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16c8810, key = 0x16ca850, line = (null) GPGME 2015-06-04 18:57:09 <0x1905> gpgme:gpg_io_event: call: gpg=0x16c8c10, event 0x7f6a59a9dad0, type 2, type_data 0x16ca850 GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_remove_io_cb: call: data=0x16ca800, setting fd 0x6 (item=0x16ca820) done GPGME 2015-06-04 18:57:09 <0x1905> gpgme_op_keylist_next: leave: key=0x16ca850 (95C76C5EF83943DA2F322CF4D2C2514414B7E8E6) GPGME 2015-06-04 18:57:09 <0x1905> gpgme_release: call: ctx=0x16c8810 GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_remove_io_cb: call: data=0x16ca6b0, setting fd 0x4 (item=0x16ca6d0) done GPGME 2015-06-04 18:57:09 <0x1905> gpgme_new: enter: r_ctx=0x7ffdf8715618 GPGME 2015-06-04 18:57:09 <0x1905> gpgme_new: leave: ctx=0x16ca210 GPGME 2015-06-04 18:57:09 <0x1905> gpgme_op_keylist_start: enter: ctx=0x16ca210, pattern=4BE78BDCF3F5352CF624A6DF3AD6F8118300CC02, secret_only=0 GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_add_io_cb: call: ctx=0x16ca210, fd 4, dir=1 -> tag=0x16c9f50 GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_add_io_cb: call: ctx=0x16ca210, fd 6, dir=1 -> tag=0x16c9fa0 GPGME 2015-06-04 18:57:09 <0x1905> gpgme:gpg_io_event: call: gpg=0x16c8c10, event 0x7f6a59a9dad0, type 0, type_data (nil) GPGME 2015-06-04 18:57:09 <0x1905> gpgme_op_keylist_start: leave GPGME 2015-06-04 18:57:09 <0x1905> gpgme_op_keylist_next: enter: ctx=0x16ca210 GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16c9fc0, need to check GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16c9fc0, handler (0x16c8c10, 6) GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16ca210, key = (nil), line = tru::0:1433443869:2410285847:3:1:5 GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16ca210, key = (nil), line = pub:-:1024:17:3AD6F8118300CC02:1039074767:::-:::scESC:::::: GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16ca210, key = 0x16cac20, line = fpr:::::::::4BE78BDCF3F5352CF624A6DF3AD6F8118300CC02: GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16ca210, key = 0x16cac20, line = uid:-::::1203999932::275AAD3E991F1962AD510CC96760907BE70FE668::Bla : GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16ca210, key = 0x16cac20, line = uid:-::::1203999938::59689891229F1817EF66BFC63D9D0BB2F45F5209::Bla : GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16ca210, key = 0x16cac20, line = uid:r::::::8A709552E7AB85B53DDAE18A48C0978E5EBF5547::Bla : GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16ca210, key = 0x16cac20, line = sub:-:2048:16:942E547C12A6B1C2:1039075030::::::e:::::: GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16ca210, key = 0x16cac20, line = fpr:::::::::E69EF5226BBF7EC14F1D7D96942E547C12A6B1C2: GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16c9f70, need to check GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16c9f70, handler (0x16c8c10, 4) GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_remove_io_cb: call: data=0x16c9f50, setting fd 0x4 (item=0x16c9f70) done GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16c9fc0, need to check GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16c9fc0, handler (0x16c8c10, 6) GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16ca210, key = 0x16cac20, line = (null) GPGME 2015-06-04 18:57:09 <0x1905> gpgme:gpg_io_event: call: gpg=0x16c8c10, event 0x7f6a59a9dad0, type 2, type_data 0x16cac20 GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_remove_io_cb: call: data=0x16c9fa0, setting fd 0x6 (item=0x16c9fc0) done GPGME 2015-06-04 18:57:09 <0x1905> gpgme:gpg_io_event: call: gpg=0x16c8c10, event 0x7f6a59a9dad0, type 1, type_data 0x7ffdf8715560 GPGME 2015-06-04 18:57:09 <0x1905> gpgme_op_keylist_next: leave: key=0x16cac20 (4BE78BDCF3F5352CF624A6DF3AD6F8118300CC02) GPGME 2015-06-04 18:57:09 <0x1905> gpgme_release: call: ctx=0x16ca210 GPGME 2015-06-04 18:57:09 <0x1905> gpgme_new: enter: r_ctx=0x7ffdf87155c8 GPGME 2015-06-04 18:57:09 <0x1905> gpgme_new: leave: ctx=0x16ca550 GPGME 2015-06-04 18:57:09 <0x1905> gpgme_set_passphrase_cb: call: ctx=0x16ca550, passphrase_cb=(nil)/(nil) GPGME 2015-06-04 18:57:09 <0x1905> gpgme_set_pinentry_mode: call: ctx=0x16ca550, pinentry_mode=4 GPGME 2015-06-04 18:57:09 <0x1905> gpgme_set_passphrase_cb: call: ctx=0x16ca550, passphrase_cb=0x403420/0x16c8058 GPGME 2015-06-04 18:57:09 <0x1905> gpgme_set_passphrase_cb: call: ctx=0x16ca550, passphrase_cb=0x403420/0x16c8058 GPGME 2015-06-04 18:57:09 <0x1905> gpgme_new: enter: r_ctx=0x7ffdf8715568 GPGME 2015-06-04 18:57:09 <0x1905> gpgme_new: leave: ctx=0x16c8810 GPGME 2015-06-04 18:57:09 <0x1905> gpgme_op_keylist_start: enter: ctx=0x16c8810, pattern=14B7E8E6, secret_only=0 GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_add_io_cb: call: ctx=0x16c8810, fd 4, dir=1 -> tag=0x16cd080 GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_add_io_cb: call: ctx=0x16c8810, fd 6, dir=1 -> tag=0x16cd1d0 GPGME 2015-06-04 18:57:09 <0x1905> gpgme:gpg_io_event: call: gpg=0x16c9d50, event 0x7f6a59a9dad0, type 0, type_data (nil) GPGME 2015-06-04 18:57:09 <0x1905> gpgme_op_keylist_start: leave GPGME 2015-06-04 18:57:09 <0x1905> gpgme_op_keylist_next: enter: ctx=0x16c8810 GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16cd1f0, need to check GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16cd1f0, handler (0x16c9d50, 6) GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16c8810, key = (nil), line = tru::0:1433443869:2410285847:3:1:5 GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16c8810, key = (nil), line = pub:u:1024:1:D2C2514414B7E8E6:1432752075:::u:::scESC:::::: GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16c8810, key = 0x16cd220, line = fpr:::::::::95C76C5EF83943DA2F322CF4D2C2514414B7E8E6: GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16c8810, key = 0x16cd220, line = uid:u::::1432752075::8ECF92C774CE2A15116BEB0B2038DE9D3CCA7A9E::testkey2 (testkey2) : GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16c8810, key = 0x16cd220, line = sub:u:1024:1:2E197B51ED8059EA:1432752075::::::e:::::: GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16c8810, key = 0x16cd220, line = fpr:::::::::47AE514B363C3E225FD474022E197B51ED8059EA: GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16c8810, key = 0x16cd220, line = sub:u:1024:1:7A26564274D6F5C6:1433074279::::::s:::::: GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16c8810, key = 0x16cd220, line = fpr:::::::::61F756F77290CBBCE30988567A26564274D6F5C6: GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16cd0a0, need to check GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16cd0a0, handler (0x16c9d50, 4) GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_remove_io_cb: call: data=0x16cd080, setting fd 0x4 (item=0x16cd0a0) done GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16cd1f0, need to check GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16cd1f0, handler (0x16c9d50, 6) GPGME 2015-06-04 18:57:09 <0x1905> gpgme:keylist_colon_handler: call: ctx=0x16c8810, key = 0x16cd220, line = (null) GPGME 2015-06-04 18:57:09 <0x1905> gpgme:gpg_io_event: call: gpg=0x16c9d50, event 0x7f6a59a9dad0, type 2, type_data 0x16cd220 GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_remove_io_cb: call: data=0x16cd1d0, setting fd 0x6 (item=0x16cd1f0) done GPGME 2015-06-04 18:57:09 <0x1905> gpgme:gpg_io_event: call: gpg=0x16c9d50, event 0x7f6a59a9dad0, type 1, type_data 0x7ffdf87154c0 GPGME 2015-06-04 18:57:09 <0x1905> gpgme_op_keylist_next: leave: key=0x16cd220 (95C76C5EF83943DA2F322CF4D2C2514414B7E8E6) GPGME 2015-06-04 18:57:09 <0x1905> gpgme_release: call: ctx=0x16c8810 GPGME 2015-06-04 18:57:09 <0x1905> gpgme_signers_clear: call: ctx=0x16ca550 GPGME 2015-06-04 18:57:09 <0x1905> gpgme_signers_add: enter: ctx=0x16ca550, key=0x16ca850 (95C76C5EF83943DA2F322CF4D2C2514414B7E8E6) GPGME 2015-06-04 18:57:09 <0x1905> gpgme_signers_add: leave GPGME 2015-06-04 18:57:09 <0x1905> gpgme_op_encrypt_sign: enter: ctx=0x16ca550, flags=0x1, plain=0x16caf80, cipher=0x16cbfd0 GPGME 2015-06-04 18:57:09 <0x1905> gpgme_op_encrypt_sign: check: ctx=0x16ca550, recipient[0] = 0x16cd220 (95C76C5EF83943DA2F322CF4D2C2514414B7E8E6) GPGME 2015-06-04 18:57:09 <0x1905> gpgme_sig_notation_get: call: ctx=0x16ca550, ctx->sig_notations=(nil) GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_add_io_cb: call: ctx=0x16ca550, fd 4, dir=1 -> tag=0x16ca070 GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_add_io_cb: call: ctx=0x16ca550, fd 8, dir=1 -> tag=0x16ca1c0 GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_add_io_cb: call: ctx=0x16ca550, fd 11, dir=0 -> tag=0x16ca210 GPGME 2015-06-04 18:57:09 <0x1905> gpgme:gpg_io_event: call: gpg=0x16c9d50, event 0x7f6a59a9dad0, type 0, type_data (nil) GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16ca230, need to check GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16ca230, handler (0x16caf80, 11) GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_data_outbound_handler: enter: dh=0x16caf80, fd=0xb GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_data_outbound_handler: leave GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16ca230, need to check GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16ca230, handler (0x16caf80, 11) GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_data_outbound_handler: enter: dh=0x16caf80, fd=0xb GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_remove_io_cb: call: data=0x16ca210, setting fd 0xb (item=0x16ca230) done GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_data_outbound_handler: leave GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16ca090, need to check GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16ca090, handler (0x16c9d50, 4) GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16ca090, need to check GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_run_io_cb: call: item=0x16ca090, handler (0x16c9d50, 4) GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_cancel_with_err: enter: ctx=0x16ca550, ctx_err=117440566, op_err=0 GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_remove_io_cb: call: data=0x16ca070, setting fd 0x4 (item=0x16ca090) done GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_remove_io_cb: call: data=0x16ca1c0, setting fd 0x8 (item=0x16ca1e0) done GPGME 2015-06-04 18:57:09 <0x1905> gpgme:gpg_io_event: call: gpg=0x16c9d50, event 0x7f6a59a9dad0, type 1, type_data 0x7ffdf87154c0 GPGME 2015-06-04 18:57:09 <0x1905> _gpgme_cancel_with_err: leave GPGME 2015-06-04 18:57:09 <0x1905> gpgme_op_encrypt_sign: error: Unusable secret key GPGME 2015-06-04 18:57:09 <0x1905> gpgme_release: call: ctx=0x16ca550 gpg2 key: -------- GPGME 2015-06-04 18:58:16 <0x1927> gpgme_debug: level=4 GPGME 2015-06-04 18:58:16 <0x1927> gpgme_check_version: call: 0=(nil), req_version=(null), VERSION=1.5.1 GPGME 2015-06-04 18:58:16 <0x1927> gpgme_check_version_internal: call: 0=(nil), req_version=(null), offset_sig_validity=60 GPGME 2015-06-04 18:58:16 <0x1927> gpgme_set_locale: enter: ctx=(nil), category=0, value=C GPGME 2015-06-04 18:58:16 <0x1927> gpgme_set_locale: leave GPGME 2015-06-04 18:58:16 <0x1927> gpgme_set_locale: enter: ctx=(nil), category=5, value=C GPGME 2015-06-04 18:58:16 <0x1927> gpgme_set_locale: leave GPGME 2015-06-04 18:58:16 <0x1927> gpgme-dinfo: gpgconf='/usr/bin/gpgconf' GPGME 2015-06-04 18:58:16 <0x1927> gpgme-dinfo: gpg='/usr/bin/gpg2' GPGME 2015-06-04 18:58:16 <0x1927> gpgme-dinfo: gpgsm='/usr/bin/gpgsm' GPGME 2015-06-04 18:58:16 <0x1927> gpgme-dinfo: homedir='/home/folkert/.gnupg' GPGME 2015-06-04 18:58:16 <0x1927> gpgme-dinfo: agent='/home/folkert/.gnupg/S.gpg-agent' GPGME 2015-06-04 18:58:16 <0x1927> gpgme-dinfo: uisrv='/home/folkert/.gnupg/S.uiserver' GPGME 2015-06-04 18:58:16 <0x1927> gpgme_new: enter: r_ctx=0x7fff5afd07a8 GPGME 2015-06-04 18:58:16 <0x1927> gpgme_new: leave: ctx=0x20c0810 GPGME 2015-06-04 18:58:16 <0x1927> gpgme_op_keylist_start: enter: ctx=0x20c0810, pattern=0BF38589, secret_only=1 GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_add_io_cb: call: ctx=0x20c0810, fd 4, dir=1 -> tag=0x20c26b0 GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_add_io_cb: call: ctx=0x20c0810, fd 6, dir=1 -> tag=0x20c2800 GPGME 2015-06-04 18:58:16 <0x1927> gpgme:gpg_io_event: call: gpg=0x20c0c10, event 0x7fd8b1a20ad0, type 0, type_data (nil) GPGME 2015-06-04 18:58:16 <0x1927> gpgme_op_keylist_start: leave GPGME 2015-06-04 18:58:16 <0x1927> gpgme_op_keylist_next: enter: ctx=0x20c0810 GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c2820, need to check GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c2820, handler (0x20c0c10, 6) GPGME 2015-06-04 18:58:16 <0x1927> gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = (nil), line = sec:u:2048:1:CC73A8A60BF38589:1433443717:::u:::scESC:::::: GPGME 2015-06-04 18:58:16 <0x1927> gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = 0x20c2850, line = fpr:::::::::20CD3FF80DA6C1E46CD9F135CC73A8A60BF38589: GPGME 2015-06-04 18:58:16 <0x1927> gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = 0x20c2850, line = uid:u::::1433443717::9963CFDE0C8920AD077B06A281992C4008E67E4F::testkey3 (testkey3) : GPGME 2015-06-04 18:58:16 <0x1927> gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = 0x20c2850, line = ssb:u:2048:1:22317805D48C1491:1433443717::::::e:::::: GPGME 2015-06-04 18:58:16 <0x1927> gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = 0x20c2850, line = fpr:::::::::FB6FFB7D8BEC710A745DE86C22317805D48C1491: GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c26d0, need to check GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c26d0, handler (0x20c0c10, 4) GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_remove_io_cb: call: data=0x20c26b0, setting fd 0x4 (item=0x20c26d0) done GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c2820, need to check GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c2820, handler (0x20c0c10, 6) GPGME 2015-06-04 18:58:16 <0x1927> gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = 0x20c2850, line = (null) GPGME 2015-06-04 18:58:16 <0x1927> gpgme:gpg_io_event: call: gpg=0x20c0c10, event 0x7fd8b1a20ad0, type 2, type_data 0x20c2850 GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_remove_io_cb: call: data=0x20c2800, setting fd 0x6 (item=0x20c2820) done GPGME 2015-06-04 18:58:16 <0x1927> gpgme:gpg_io_event: call: gpg=0x20c0c10, event 0x7fd8b1a20ad0, type 1, type_data 0x7fff5afd0700 GPGME 2015-06-04 18:58:16 <0x1927> gpgme_op_keylist_next: leave: key=0x20c2850 (20CD3FF80DA6C1E46CD9F135CC73A8A60BF38589) GPGME 2015-06-04 18:58:16 <0x1927> gpgme_release: call: ctx=0x20c0810 GPGME 2015-06-04 18:58:16 <0x1927> gpgme_new: enter: r_ctx=0x7fff5afd0818 GPGME 2015-06-04 18:58:16 <0x1927> gpgme_new: leave: ctx=0x20c2210 GPGME 2015-06-04 18:58:16 <0x1927> gpgme_op_keylist_start: enter: ctx=0x20c2210, pattern=4BE78BDCF3F5352CF624A6DF3AD6F8118300CC02, secret_only=0 GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_add_io_cb: call: ctx=0x20c2210, fd 4, dir=1 -> tag=0x20c1f50 GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_add_io_cb: call: ctx=0x20c2210, fd 6, dir=1 -> tag=0x20c1fa0 GPGME 2015-06-04 18:58:16 <0x1927> gpgme:gpg_io_event: call: gpg=0x20c0c10, event 0x7fd8b1a20ad0, type 0, type_data (nil) GPGME 2015-06-04 18:58:16 <0x1927> gpgme_op_keylist_start: leave GPGME 2015-06-04 18:58:16 <0x1927> gpgme_op_keylist_next: enter: ctx=0x20c2210 GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c1fc0, need to check GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c1fc0, handler (0x20c0c10, 6) GPGME 2015-06-04 18:58:16 <0x1927> gpgme:keylist_colon_handler: call: ctx=0x20c2210, key = (nil), line = tru::0:1433443869:2410285847:3:1:5 GPGME 2015-06-04 18:58:16 <0x1927> gpgme:keylist_colon_handler: call: ctx=0x20c2210, key = (nil), line = pub:-:1024:17:3AD6F8118300CC02:1039074767:::-:::scESC:::::: GPGME 2015-06-04 18:58:16 <0x1927> gpgme:keylist_colon_handler: call: ctx=0x20c2210, key = 0x20c2b70, line = fpr:::::::::4BE78BDCF3F5352CF624A6DF3AD6F8118300CC02: GPGME 2015-06-04 18:58:16 <0x1927> gpgme:keylist_colon_handler: call: ctx=0x20c2210, key = 0x20c2b70, line = uid:-::::1203999932::275AAD3E991F1962AD510CC96760907BE70FE668::Bla : GPGME 2015-06-04 18:58:16 <0x1927> gpgme:keylist_colon_handler: call: ctx=0x20c2210, key = 0x20c2b70, line = uid:-::::1203999938::59689891229F1817EF66BFC63D9D0BB2F45F5209::Bla : GPGME 2015-06-04 18:58:16 <0x1927> gpgme:keylist_colon_handler: call: ctx=0x20c2210, key = 0x20c2b70, line = uid:r::::::8A709552E7AB85B53DDAE18A48C0978E5EBF5547::Bla : GPGME 2015-06-04 18:58:16 <0x1927> gpgme:keylist_colon_handler: call: ctx=0x20c2210, key = 0x20c2b70, line = sub:-:2048:16:942E547C12A6B1C2:1039075030::::::e:::::: GPGME 2015-06-04 18:58:16 <0x1927> gpgme:keylist_colon_handler: call: ctx=0x20c2210, key = 0x20c2b70, line = fpr:::::::::E69EF5226BBF7EC14F1D7D96942E547C12A6B1C2: GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c1f70, need to check GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c1f70, handler (0x20c0c10, 4) GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_remove_io_cb: call: data=0x20c1f50, setting fd 0x4 (item=0x20c1f70) done GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c1fc0, need to check GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c1fc0, handler (0x20c0c10, 6) GPGME 2015-06-04 18:58:16 <0x1927> gpgme:keylist_colon_handler: call: ctx=0x20c2210, key = 0x20c2b70, line = (null) GPGME 2015-06-04 18:58:16 <0x1927> gpgme:gpg_io_event: call: gpg=0x20c0c10, event 0x7fd8b1a20ad0, type 2, type_data 0x20c2b70 GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_remove_io_cb: call: data=0x20c1fa0, setting fd 0x6 (item=0x20c1fc0) done GPGME 2015-06-04 18:58:16 <0x1927> gpgme:gpg_io_event: call: gpg=0x20c0c10, event 0x7fd8b1a20ad0, type 1, type_data 0x7fff5afd0760 GPGME 2015-06-04 18:58:16 <0x1927> gpgme_op_keylist_next: leave: key=0x20c2b70 (4BE78BDCF3F5352CF624A6DF3AD6F8118300CC02) GPGME 2015-06-04 18:58:16 <0x1927> gpgme_release: call: ctx=0x20c2210 GPGME 2015-06-04 18:58:16 <0x1927> gpgme_new: enter: r_ctx=0x7fff5afd07c8 GPGME 2015-06-04 18:58:16 <0x1927> gpgme_new: leave: ctx=0x20c2550 GPGME 2015-06-04 18:58:16 <0x1927> gpgme_set_passphrase_cb: call: ctx=0x20c2550, passphrase_cb=(nil)/(nil) GPGME 2015-06-04 18:58:16 <0x1927> gpgme_set_pinentry_mode: call: ctx=0x20c2550, pinentry_mode=4 GPGME 2015-06-04 18:58:16 <0x1927> gpgme_set_passphrase_cb: call: ctx=0x20c2550, passphrase_cb=0x403420/0x20c0058 GPGME 2015-06-04 18:58:16 <0x1927> gpgme_set_passphrase_cb: call: ctx=0x20c2550, passphrase_cb=0x403420/0x20c0058 GPGME 2015-06-04 18:58:16 <0x1927> gpgme_new: enter: r_ctx=0x7fff5afd0768 GPGME 2015-06-04 18:58:16 <0x1927> gpgme_new: leave: ctx=0x20c0810 GPGME 2015-06-04 18:58:16 <0x1927> gpgme_op_keylist_start: enter: ctx=0x20c0810, pattern=0BF38589, secret_only=0 GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_add_io_cb: call: ctx=0x20c0810, fd 4, dir=1 -> tag=0x20c4fd0 GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_add_io_cb: call: ctx=0x20c0810, fd 6, dir=1 -> tag=0x20c5120 GPGME 2015-06-04 18:58:16 <0x1927> gpgme:gpg_io_event: call: gpg=0x20c1d50, event 0x7fd8b1a20ad0, type 0, type_data (nil) GPGME 2015-06-04 18:58:16 <0x1927> gpgme_op_keylist_start: leave GPGME 2015-06-04 18:58:16 <0x1927> gpgme_op_keylist_next: enter: ctx=0x20c0810 GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c5140, need to check GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c5140, handler (0x20c1d50, 6) GPGME 2015-06-04 18:58:16 <0x1927> gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = (nil), line = tru::0:1433443869:2410285847:3:1:5 GPGME 2015-06-04 18:58:16 <0x1927> gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = (nil), line = pub:u:2048:1:CC73A8A60BF38589:1433443717:::u:::scESC:::::: GPGME 2015-06-04 18:58:16 <0x1927> gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = 0x20c5170, line = fpr:::::::::20CD3FF80DA6C1E46CD9F135CC73A8A60BF38589: GPGME 2015-06-04 18:58:16 <0x1927> gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = 0x20c5170, line = uid:u::::1433443717::9963CFDE0C8920AD077B06A281992C4008E67E4F::testkey3 (testkey3) : GPGME 2015-06-04 18:58:16 <0x1927> gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = 0x20c5170, line = sub:u:2048:1:22317805D48C1491:1433443717::::::e:::::: GPGME 2015-06-04 18:58:16 <0x1927> gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = 0x20c5170, line = fpr:::::::::FB6FFB7D8BEC710A745DE86C22317805D48C1491: GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c4ff0, need to check GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c4ff0, handler (0x20c1d50, 4) GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_remove_io_cb: call: data=0x20c4fd0, setting fd 0x4 (item=0x20c4ff0) done GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c5140, need to check GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c5140, handler (0x20c1d50, 6) GPGME 2015-06-04 18:58:16 <0x1927> gpgme:keylist_colon_handler: call: ctx=0x20c0810, key = 0x20c5170, line = (null) GPGME 2015-06-04 18:58:16 <0x1927> gpgme:gpg_io_event: call: gpg=0x20c1d50, event 0x7fd8b1a20ad0, type 2, type_data 0x20c5170 GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_remove_io_cb: call: data=0x20c5120, setting fd 0x6 (item=0x20c5140) done GPGME 2015-06-04 18:58:16 <0x1927> gpgme:gpg_io_event: call: gpg=0x20c1d50, event 0x7fd8b1a20ad0, type 1, type_data 0x7fff5afd06c0 GPGME 2015-06-04 18:58:16 <0x1927> gpgme_op_keylist_next: leave: key=0x20c5170 (20CD3FF80DA6C1E46CD9F135CC73A8A60BF38589) GPGME 2015-06-04 18:58:16 <0x1927> gpgme_release: call: ctx=0x20c0810 GPGME 2015-06-04 18:58:16 <0x1927> gpgme_signers_clear: call: ctx=0x20c2550 GPGME 2015-06-04 18:58:16 <0x1927> gpgme_signers_add: enter: ctx=0x20c2550, key=0x20c2850 (20CD3FF80DA6C1E46CD9F135CC73A8A60BF38589) GPGME 2015-06-04 18:58:16 <0x1927> gpgme_signers_add: leave GPGME 2015-06-04 18:58:16 <0x1927> gpgme_op_encrypt_sign: enter: ctx=0x20c2550, flags=0x1, plain=0x20c2ed0, cipher=0x20c3f20 GPGME 2015-06-04 18:58:16 <0x1927> gpgme_op_encrypt_sign: check: ctx=0x20c2550, recipient[0] = 0x20c5170 (20CD3FF80DA6C1E46CD9F135CC73A8A60BF38589) GPGME 2015-06-04 18:58:16 <0x1927> gpgme_sig_notation_get: call: ctx=0x20c2550, ctx->sig_notations=(nil) GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_add_io_cb: call: ctx=0x20c2550, fd 4, dir=1 -> tag=0x20c2070 GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_add_io_cb: call: ctx=0x20c2550, fd 8, dir=1 -> tag=0x20c21c0 GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_add_io_cb: call: ctx=0x20c2550, fd 11, dir=0 -> tag=0x20c2210 GPGME 2015-06-04 18:58:16 <0x1927> gpgme:gpg_io_event: call: gpg=0x20c1d50, event 0x7fd8b1a20ad0, type 0, type_data (nil) GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c2230, need to check GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c2230, handler (0x20c2ed0, 11) GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_data_outbound_handler: enter: dh=0x20c2ed0, fd=0xb GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_data_outbound_handler: leave GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c2230, need to check GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c2230, handler (0x20c2ed0, 11) GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_data_outbound_handler: enter: dh=0x20c2ed0, fd=0xb GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_remove_io_cb: call: data=0x20c2210, setting fd 0xb (item=0x20c2230) done GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_data_outbound_handler: leave GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c2090, need to check GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c2090, handler (0x20c1d50, 4) GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c2090, need to check GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_run_io_cb: call: item=0x20c2090, handler (0x20c1d50, 4) GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_cancel_with_err: enter: ctx=0x20c2550, ctx_err=117440566, op_err=0 GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_remove_io_cb: call: data=0x20c2070, setting fd 0x4 (item=0x20c2090) done GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_remove_io_cb: call: data=0x20c21c0, setting fd 0x8 (item=0x20c21e0) done GPGME 2015-06-04 18:58:16 <0x1927> gpgme:gpg_io_event: call: gpg=0x20c1d50, event 0x7fd8b1a20ad0, type 1, type_data 0x7fff5afd06c0 GPGME 2015-06-04 18:58:16 <0x1927> _gpgme_cancel_with_err: leave GPGME 2015-06-04 18:58:16 <0x1927> gpgme_op_encrypt_sign: error: Unusable secret key GPGME 2015-06-04 18:58:16 <0x1927> gpgme_release: call: ctx=0x20c2550 Folkert van Heusden From ueno at gnu.org Tue Jun 2 10:56:44 2015 From: ueno at gnu.org (Daiki Ueno) Date: Tue, 02 Jun 2015 17:56:44 +0900 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <874mms4tzc.wl-neal@walfield.org> (Neal H. Walfield's message of "Sun, 31 May 2015 18:00:55 +0200") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> Message-ID: Hello Neal, Thanks for the thorough review, responses are inlined below. By the way, on second thoughts, I ended up with a specialized protocol for this, to avoid unnecessary character escaping and encoding conversion (and also reconnecting to a socket every time). The protocol is actually a subset of the Pinentry Assuan protocol, and implemented in pinentry.el, which shall be included in Emacs, maybe under lisp/net/ or ELPA. I'm attaching the new patch and pinentry.el. To test, use "M-x pinentry-start" instead of "M-x server-start". "Neal H. Walfield" writes: >> +if test "$pinentry_emacs" = "maybe"; then >> + AC_MSG_CHECKING([if Unix domain socket is supported]) > > I think we should check for != "no" here. If pinentry_emacs is yes, > but we don't support unix domain sockets, then it would be better to > error out here than when compiling the code. Do you agree? Yes, exactly. Fixed. >> +#include > > As far as I can tell, this include is gratuitious. Removed. >> + if (strlen (tmpdir) + strlen (socket_name) + 10 + 2 >> + >= sizeof (emacs_server_address.sun_path)) [...] >> + sprintf (emacs_server_address.sun_path, "%s/emacs%lu/%s", >> + tmpdir, (unsigned long) uid, socket_name); > > I think the check above is wrong. It should be something like: > > if (strlen (tmpdir) + strlen("/emacs") + 10 + strlen("/") > + strlen (socket_name) + 1 > >= sizeof (emacs_server_address.sun_path)) Right, thanks for pointing that out. Fixed using the correct formula. >> + if (connect (s, (struct sockaddr *) &emacs_server_address, >> + strlen (emacs_server_address.sun_path) + 2) < 0) > > Why don't you just use 'sizeof (emacs_server_address)' here? I really > don't like the magic number 2 here. Fixed using SUN_LEN from GnuPG. >> + if (strprefix ("-print ", p)) > Does it make sense to emit a warning if there is a line with an > unrecognized prefix? As far as I can see, lines with unknown commands > are currently ignored. Yes, added warnings. >> + sprintf (command, "(" CALLBACK_NAME " \"%s\" %s)", >> + name, quoted_value); >> + if (quoted_value != nil) >> + free (quoted_value); > > Here's another instance where I'd strongly prefer something like > asprintf. Yes. Those allocation and copying are no longer necessary with the new protocol. >> + quoted_command = build_command (name, local_value); >> + if (local_value != value) >> + free (local_value); > > I think this comparison is useless. If value is not NULL, then we > call pinentry_utf8_to_local, which always allocates a new buffer. Good point. Likewise to the above, the extra allocation is not needed anymore. > Does emacs not support setting custom button labels? Yes, it could. However, for a password query, labels would be too verbose to be shown in the minibuffer. So, in pinentry.el, they are only used for a confirmation query. > If pe->prompt is NULL, then you should fallback to pe->default_prompt. Fixed. > If you have time, it would be nice to add support for the external > password manager checkbox. In the very least, please note the lack of > this support with an XXX comment in the source code. Sure, added a comment. >> + if (pe->repeat_passphrase) >> + pe->repeat_okay = 1; > > Why are you setting this if the user didn't actually enter the > password twice? I implemented the repeat feature in the new patch. >> +int >> +do_confirm (pinentry_t pe) [...] >> + set_value (pe, "SETPROMPT", pe->prompt); > > Again, please fallback to pe->default_prompt. Fixed. > Any reason, there is no support for custom button labels? Also, what > about support for the other button? If this is not yet possible, > please note it with an XXX comment. Fixed. >> -#if defined FALLBACK_CURSES || defined PINENTRY_CURSES || defined >> PINENTRY_GTK >> +#if defined FALLBACK_CURSES || defined INSIDE_EMACS || defined >> PINENTRY_CURSES || defined PINENTRY_GTK >> char * >> pinentry_utf8_to_local (const char *lc_ctype, const char *text) >> { > > I think we should check if PINENTRY_EMACS is defined, not INSIDE_EMACS > here. I reverted this change since the patch no longer uses pinentry_utf8_to_local. Regards, -- Daiki Ueno -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-inside-Emacs-mode-to-GUI-pinentry-programs.patch Type: text/x-patch Size: 33333 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pinentry.el URL: From neal at walfield.org Wed Jun 3 14:49:27 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 03 Jun 2015 14:49:27 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> Message-ID: <873829rm7c.wl-neal@walfield.org> Hi Daiki, I just took a quick look and it seems good. I'll have time to do a thorough review tomorrow (Thursday). :) Neal At Tue, 02 Jun 2015 17:56:44 +0900, Daiki Ueno wrote: > > [1 ] > Hello Neal, > > Thanks for the thorough review, responses are inlined below. > > By the way, on second thoughts, I ended up with a specialized protocol > for this, to avoid unnecessary character escaping and encoding > conversion (and also reconnecting to a socket every time). The protocol > is actually a subset of the Pinentry Assuan protocol, and implemented in > pinentry.el, which shall be included in Emacs, maybe under lisp/net/ or > ELPA. > > I'm attaching the new patch and pinentry.el. To test, use "M-x > pinentry-start" instead of "M-x server-start". > > "Neal H. Walfield" writes: > > >> +if test "$pinentry_emacs" = "maybe"; then > >> + AC_MSG_CHECKING([if Unix domain socket is supported]) > > > > I think we should check for != "no" here. If pinentry_emacs is yes, > > but we don't support unix domain sockets, then it would be better to > > error out here than when compiling the code. Do you agree? > > Yes, exactly. Fixed. > > >> +#include > > > > As far as I can tell, this include is gratuitious. > > Removed. > > >> + if (strlen (tmpdir) + strlen (socket_name) + 10 + 2 > >> + >= sizeof (emacs_server_address.sun_path)) > [...] > >> + sprintf (emacs_server_address.sun_path, "%s/emacs%lu/%s", > >> + tmpdir, (unsigned long) uid, socket_name); > > > > I think the check above is wrong. It should be something like: > > > > if (strlen (tmpdir) + strlen("/emacs") + 10 + strlen("/") > > + strlen (socket_name) + 1 > > >= sizeof (emacs_server_address.sun_path)) > > Right, thanks for pointing that out. Fixed using the correct formula. > > >> + if (connect (s, (struct sockaddr *) &emacs_server_address, > >> + strlen (emacs_server_address.sun_path) + 2) < 0) > > > > Why don't you just use 'sizeof (emacs_server_address)' here? I really > > don't like the magic number 2 here. > > Fixed using SUN_LEN from GnuPG. > > >> + if (strprefix ("-print ", p)) > > > Does it make sense to emit a warning if there is a line with an > > unrecognized prefix? As far as I can see, lines with unknown commands > > are currently ignored. > > Yes, added warnings. > > >> + sprintf (command, "(" CALLBACK_NAME " \"%s\" %s)", > >> + name, quoted_value); > >> + if (quoted_value != nil) > >> + free (quoted_value); > > > > Here's another instance where I'd strongly prefer something like > > asprintf. > > Yes. Those allocation and copying are no longer necessary with the new > protocol. > > >> + quoted_command = build_command (name, local_value); > >> + if (local_value != value) > >> + free (local_value); > > > > I think this comparison is useless. If value is not NULL, then we > > call pinentry_utf8_to_local, which always allocates a new buffer. > > Good point. Likewise to the above, the extra allocation is not needed > anymore. > > > Does emacs not support setting custom button labels? > > Yes, it could. However, for a password query, labels would be too > verbose to be shown in the minibuffer. So, in pinentry.el, they are > only used for a confirmation query. > > > If pe->prompt is NULL, then you should fallback to pe->default_prompt. > > Fixed. > > > If you have time, it would be nice to add support for the external > > password manager checkbox. In the very least, please note the lack of > > this support with an XXX comment in the source code. > > Sure, added a comment. > > >> + if (pe->repeat_passphrase) > >> + pe->repeat_okay = 1; > > > > Why are you setting this if the user didn't actually enter the > > password twice? > > I implemented the repeat feature in the new patch. > > >> +int > >> +do_confirm (pinentry_t pe) > [...] > >> + set_value (pe, "SETPROMPT", pe->prompt); > > > > Again, please fallback to pe->default_prompt. > > Fixed. > > > Any reason, there is no support for custom button labels? Also, what > > about support for the other button? If this is not yet possible, > > please note it with an XXX comment. > > Fixed. > > >> -#if defined FALLBACK_CURSES || defined PINENTRY_CURSES || defined > >> PINENTRY_GTK > >> +#if defined FALLBACK_CURSES || defined INSIDE_EMACS || defined > >> PINENTRY_CURSES || defined PINENTRY_GTK > >> char * > >> pinentry_utf8_to_local (const char *lc_ctype, const char *text) > >> { > > > > I think we should check if PINENTRY_EMACS is defined, not INSIDE_EMACS > > here. > > I reverted this change since the patch no longer uses > pinentry_utf8_to_local. > > Regards, > -- > Daiki Ueno > [2 0001-Add-inside-Emacs-mode-to-GUI-pinentry-programs.patch ] > From 14789d2bfa4fd7931a0191a1379d3fcd449e12aa Mon Sep 17 00:00:00 2001 > From: Daiki Ueno > Date: Wed, 27 May 2015 17:06:08 +0900 > Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs > > * configure.ac: Add --enable-pinentry-emacs and > --enable-inside-emacs option. > (BUILD_LIBPINENTRY_EMACS): New conditional. > (BUILD_PINENTRY_EMACS): New conditional. > (INSIDE_EMACS): New conditional. > * Makefile.am (pinentry_emacs): New. > (SUBDIRS): Add "emacs" subdir if PINENTRY_EMACS is set. > > * pinentry/pinentry-emacs.h: New file. > * pinentry/pinentry-emacs.c: New file. > * pinentry/Makefile.am: New file. > > * emacs/pinentry-emacs.c: New file. > * emacs/Makefile.am: New file. > > * qt4/Makefile.am (libemacs): New variable, set if the > INSIDE_EMACS conditional is true. > (pinentry_qt4_LDADD): Add $(libemacs). > * qt4/main.cpp (main): Set pinentry_cmd_handler if > the INSIDE_EMACS envvar is set and the socket is usable. > > * gnome3/Makefile.am (libemacs): New variable, set if the > INSIDE_EMACS conditional is true. > (LDADD): Add $(libemacs). > * gnome3/pinentry-gnome3.c (main): Set pinentry_cmd_handler if > the INSIDE_EMACS envvar is set and the socket is usable. > > * gtk+-2/Makefile.am (libemacs): New variable, set if the INSIDE_EMACS > conditional is true. > (LDADD): Add $(libemacs). > * gtk+-2/pinentry-gtk-2.c (main): Set pinentry_cmd_handler if > the INSIDE_EMACS envvar is set and the socket is usable. > --- > Makefile.am | 10 +- > configure.ac | 60 +++++ > emacs/Makefile.am | 29 +++ > emacs/pinentry-emacs.c | 47 ++++ > gnome3/Makefile.am | 8 +- > gnome3/pinentry-gnome3.c | 21 +- > gtk+-2/Makefile.am | 8 +- > gtk+-2/pinentry-gtk-2.c | 25 +- > pinentry/Makefile.am | 9 +- > pinentry/pinentry-emacs.c | 640 ++++++++++++++++++++++++++++++++++++++++++++++ > pinentry/pinentry-emacs.h | 41 +++ > qt4/Makefile.am | 9 +- > qt4/main.cpp | 93 ++++--- > 13 files changed, 941 insertions(+), 59 deletions(-) > create mode 100644 emacs/Makefile.am > create mode 100644 emacs/pinentry-emacs.c > create mode 100644 pinentry/pinentry-emacs.c > create mode 100644 pinentry/pinentry-emacs.h > > diff --git a/Makefile.am b/Makefile.am > index 177f37e..388464e 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -40,6 +40,12 @@ else > pinentry_tty = > endif > > +if BUILD_PINENTRY_EMACS > +pinentry_emacs = emacs > +else > +pinentry_emacs = > +endif > + > if BUILD_PINENTRY_GTK_2 > pinentry_gtk_2 = gtk+-2 > else > @@ -65,8 +71,8 @@ pinentry_w32 = > endif > > SUBDIRS = assuan secmem pinentry ${pinentry_curses} ${pinentry_tty} \ > - ${pinentry_gtk_2} ${pinentry_gnome_3} ${pinentry_qt4} \ > - ${pinentry_w32} doc > + ${pinentry_emacs} ${pinentry_gtk_2} ${pinentry_gnome_3} \ > + ${pinentry_qt4} ${pinentry_w32} doc > > > install-exec-local: > diff --git a/configure.ac b/configure.ac > index 9948d1f..abc248e 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -271,6 +271,63 @@ if test "$pinentry_curses" = "yes" \ > fi > fi > > +dnl > +dnl Check for emacs pinentry program. > +dnl > +AC_ARG_ENABLE(pinentry-emacs, > + AC_HELP_STRING([--enable-pinentry-emacs], [build emacs pinentry]), > + pinentry_emacs=$enableval, pinentry_emacs=maybe) > +AC_ARG_ENABLE(inside-emacs, > + AC_HELP_STRING([--enable-inside-emacs], [include emacs hack]), > + inside_emacs=$enableval, inside_emacs=maybe) > + > +if test "$pinentry_emacs" != "no"; then > + AC_MSG_CHECKING([if Unix domain socket is supported]) > + AC_TRY_COMPILE([ > +#include > +#include > +], > + [int s = socket (AF_UNIX, SOCK_STREAM, 0);], > + [_unixsock_works=yes], > + [_unixsock_works=no]) > + AC_MSG_RESULT($_unixsock_works) > + if test "$_unixsock_works" = "yes"; then > + pinentry_emacs=yes > + else > + if test "$pinentry_emacs" = "yes"; then > + AC_MSG_ERROR([[ > +*** > +*** Support for Unix domain sockets is required. > +***]]) > + fi > + pinentry_emacs=no > + fi > +fi > + > +if test "$inside_emacs" = "maybe"; then > + if test "$pinentry_emacs" = "yes"; then > + inside_emacs=yes > + else > + inside_emacs=no > + fi > +fi > + > +AM_CONDITIONAL(BUILD_LIBPINENTRY_EMACS, > + test "$pinentry_emacs" = "yes" -o "$inside_emacs" = "yes") > +AM_CONDITIONAL(BUILD_PINENTRY_EMACS, test "$pinentry_emacs" = "yes") > +AM_CONDITIONAL(INSIDE_EMACS, test "$inside_emacs" = "yes") > + > +if test "$pinentry_emacs" = "yes"; then > + AC_DEFINE(PINENTRY_EMACS, 1, > + [The Emacs version of Pinentry is to be build]) > +fi > + > +if test "$inside_emacs" = "yes"; then > + inside_emacs=yes > + AC_DEFINE(INSIDE_EMACS, 1, > + [The GUI pinentries should respect INSIDE_EMACS envvar.]) > +fi > + > > > dnl > @@ -512,6 +569,7 @@ secmem/Makefile > pinentry/Makefile > curses/Makefile > tty/Makefile > +emacs/Makefile > gtk+-2/Makefile > gnome3/Makefile > qt4/Makefile > @@ -531,12 +589,14 @@ AC_MSG_NOTICE([ > > Curses Pinentry ..: $pinentry_curses > TTY Pinentry .....: $pinentry_tty > + Emacs Pinentry ...: $pinentry_emacs > GTK+-2 Pinentry ..: $pinentry_gtk_2 > GNOME 3 Pinentry .: $pinentry_gnome_3 > Qt4 Pinentry .....: $pinentry_qt4 $pinentry_qt4_clip_msg > W32 Pinentry .....: $pinentry_w32 > > Fallback to Curses: $fallback_curses > + Inside-EMACS mode : $inside_emacs > > libsecret ........: $libsecret > > diff --git a/emacs/Makefile.am b/emacs/Makefile.am > new file mode 100644 > index 0000000..a0bfe6c > --- /dev/null > +++ b/emacs/Makefile.am > @@ -0,0 +1,29 @@ > +# Makefile.am - PIN entry emacs frontend. > +# Copyright (C) 2002, 2015 g10 Code GmbH > +# > +# This file is part of PINENTRY. > +# > +# PINENTRY is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; either version 2 of the License, or > +# (at your option) any later version. > +# > +# PINENTRY is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA > + > +## Process this file with automake to produce Makefile.in > + > +bin_PROGRAMS = pinentry-emacs > + > +AM_CPPFLAGS = $(COMMON_CFLAGS) $(NEMACS_INCLUDE) -I$(top_srcdir)/pinentry > +LDADD = ../pinentry/libpinentry.a ../pinentry/libpinentry-emacs.a \ > + ../assuan/libassuan.a ../secmem/libsecmem.a \ > + $(COMMON_LIBS) $(LIBCAP) $(LIBEMACS) $(LIBICONV) > + > +pinentry_emacs_SOURCES = pinentry-emacs.c > diff --git a/emacs/pinentry-emacs.c b/emacs/pinentry-emacs.c > new file mode 100644 > index 0000000..de4ca05 > --- /dev/null > +++ b/emacs/pinentry-emacs.c > @@ -0,0 +1,47 @@ > +/* pinentry-emacs.c - A secure emacs dialog for PIN entry, library version > + Copyright (C) 2015 Daiki Ueno > + > + This file is part of PINENTRY. > + > + PINENTRY is free software; you can redistribute it and/or modify it > + under the terms of the GNU General Public License as published by > + the Free Software Foundation; either version 2 of the License, or > + (at your option) any later version. > + > + PINENTRY is distributed in the hope that it will be useful, but > + WITHOUT ANY WARRANTY; without even the implied warranty of > + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + General Public License for more details. > + > + You should have received a copy of the GNU General Public License > + along with this program; if not, see . > +*/ > + > +#ifdef HAVE_CONFIG_H > +#include > +#endif > + > +#include > +#include > + > +#include "pinentry.h" > +#include "pinentry-emacs.h" > + > +pinentry_cmd_handler_t pinentry_cmd_handler = emacs_cmd_handler; > + > + > +int > +main (int argc, char *argv[]) > +{ > + pinentry_init ("pinentry-emacs"); > + > + if (!pinentry_emacs_init ()) > + return 1; > + > + pinentry_parse_opts (argc, argv); > + > + if (pinentry_loop ()) > + return 1; > + > + return 0; > +} > diff --git a/gnome3/Makefile.am b/gnome3/Makefile.am > index 46639de..c8767df 100644 > --- a/gnome3/Makefile.am > +++ b/gnome3/Makefile.am > @@ -29,10 +29,16 @@ ncurses_include = > libcurses = > endif > > +if INSIDE_EMACS > +libemacs = ../pinentry/libpinentry-emacs.a > +else > +libemacs = > +endif > + > AM_CPPFLAGS = $(COMMON_CFLAGS) $(GNOME3CFLAGS) \ > $(ncurses_include) -I$(top_srcdir)/assuan \ > -I$(top_srcdir)/secmem -I$(top_srcdir)/pinentry > LDADD = ../pinentry/libpinentry.a ../assuan/libassuan.a ../secmem/libsecmem.a \ > - $(COMMON_LIBS) $(LIBCAP) $(GNOME3LIBS) $(libcurses) > + $(COMMON_LIBS) $(LIBCAP) $(GNOME3LIBS) $(libcurses) $(libemacs) > > pinentry_gnome3_SOURCES = pinentry-gnome3.c > diff --git a/gnome3/pinentry-gnome3.c b/gnome3/pinentry-gnome3.c > index 74ec89c..113bde3 100644 > --- a/gnome3/pinentry-gnome3.c > +++ b/gnome3/pinentry-gnome3.c > @@ -37,6 +37,10 @@ > #include "pinentry-curses.h" > #endif > > +#ifdef INSIDE_EMACS > +#include "pinentry-emacs.h" > +#endif > + > > #define PGMNAME "pinentry-gnome3" > > @@ -253,14 +257,21 @@ main (int argc, char *argv[]) > { > pinentry_init (PGMNAME); > > -#ifdef FALLBACK_CURSES > - if (pinentry_have_display (argc, argv)) > - gtk_init (&argc, &argv); > +#ifdef INSIDE_EMACS > + if (pinentry_inside_emacs () && pinentry_emacs_init ()) > + pinentry_cmd_handler = emacs_cmd_handler; > else > - pinentry_cmd_handler = curses_cmd_handler; > +#endif > + { > +#ifdef FALLBACK_CURSES > + if (pinentry_have_display (argc, argv)) > + gtk_init (&argc, &argv); > + else > + pinentry_cmd_handler = curses_cmd_handler; > #else > - gtk_init (&argc, &argv); > + gtk_init (&argc, &argv); > #endif > + } > > pinentry_parse_opts (argc, argv); > > diff --git a/gtk+-2/Makefile.am b/gtk+-2/Makefile.am > index 7e37469..8e7717e 100644 > --- a/gtk+-2/Makefile.am > +++ b/gtk+-2/Makefile.am > @@ -29,10 +29,16 @@ ncurses_include = > libcurses = > endif > > +if INSIDE_EMACS > +libemacs = ../pinentry/libpinentry-emacs.a $(LIBEMACS) $(LIBICONV) > +else > +libemacs = > +endif > + > AM_CPPFLAGS = $(COMMON_CFLAGS) $(GTK2CFLAGS) $(ncurses_include) \ > -I$(top_srcdir)/secmem -I$(top_srcdir)/pinentry > LDADD = ../pinentry/libpinentry.a ../assuan/libassuan.a ../secmem/libsecmem.a \ > - $(COMMON_LIBS) $(LIBCAP) $(GTK2LIBS) $(libcurses) > + $(COMMON_LIBS) $(LIBCAP) $(GTK2LIBS) $(libcurses) $(libemacs) > > pinentry_gtk_2_SOURCES = pinentry-gtk-2.c \ > gtksecentry.c gtksecentry.h gseal-gtk-compat.h > diff --git a/gtk+-2/pinentry-gtk-2.c b/gtk+-2/pinentry-gtk-2.c > index 1a88e5a..7792046 100644 > --- a/gtk+-2/pinentry-gtk-2.c > +++ b/gtk+-2/pinentry-gtk-2.c > @@ -52,6 +52,10 @@ > #include "pinentry-curses.h" > #endif > > +#ifdef INSIDE_EMACS > +#include "pinentry-emacs.h" > +#endif > + > > #define PGMNAME "pinentry-gtk2" > > @@ -716,17 +720,24 @@ main (int argc, char *argv[]) > > pinentry_init (PGMNAME); > > -#ifdef FALLBACK_CURSES > - if (pinentry_have_display (argc, argv)) > +#ifdef INSIDE_EMACS > + if (pinentry_inside_emacs () && pinentry_emacs_init ()) > + pinentry_cmd_handler = emacs_cmd_handler; > + else > +#endif > { > - if (! gtk_init_check (&argc, &argv)) > +#ifdef FALLBACK_CURSES > + if (pinentry_have_display (argc, argv)) > + { > + if (! gtk_init_check (&argc, &argv)) > + pinentry_cmd_handler = curses_cmd_handler; > + } > + else > pinentry_cmd_handler = curses_cmd_handler; > - } > - else > - pinentry_cmd_handler = curses_cmd_handler; > #else > - gtk_init (&argc, &argv); > + gtk_init (&argc, &argv); > #endif > + } > > pinentry_parse_opts (argc, argv); > > diff --git a/pinentry/Makefile.am b/pinentry/Makefile.am > index 7fbbab6..e6e4ba6 100644 > --- a/pinentry/Makefile.am > +++ b/pinentry/Makefile.am > @@ -27,7 +27,13 @@ else > pinentry_curses = > endif > > -noinst_LIBRARIES = libpinentry.a $(pinentry_curses) > +if BUILD_LIBPINENTRY_EMACS > +pinentry_emacs = libpinentry-emacs.a > +else > +pinentry_emacs = > +endif > + > +noinst_LIBRARIES = libpinentry.a $(pinentry_curses) $(pinentry_emacs) > > LDADD = $(COMMON_LIBS) > AM_CPPFLAGS = $(COMMON_CFLAGS) -I$(top_srcdir)/assuan -I$(top_srcdir)/secmem > @@ -35,3 +41,4 @@ AM_CPPFLAGS = $(COMMON_CFLAGS) -I$(top_srcdir)/assuan -I$(top_srcdir)/secmem > libpinentry_a_SOURCES = pinentry.h pinentry.c argparse.c argparse.h \ > password-cache.h password-cache.c > libpinentry_curses_a_SOURCES = pinentry-curses.h pinentry-curses.c > +libpinentry_emacs_a_SOURCES = pinentry-emacs.h pinentry-emacs.c > diff --git a/pinentry/pinentry-emacs.c b/pinentry/pinentry-emacs.c > new file mode 100644 > index 0000000..280546d > --- /dev/null > +++ b/pinentry/pinentry-emacs.c > @@ -0,0 +1,640 @@ > +/* pinentry-emacs.c - A secure emacs dialog for PIN entry, library version > + Copyright (C) 2015 Daiki Ueno > + > + This file is part of PINENTRY. > + > + PINENTRY is free software; you can redistribute it and/or modify it > + under the terms of the GNU General Public License as published by > + the Free Software Foundation; either version 2 of the License, or > + (at your option) any later version. > + > + PINENTRY is distributed in the hope that it will be useful, but > + WITHOUT ANY WARRANTY; without even the implied warranty of > + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + General Public License for more details. > + > + You should have received a copy of the GNU General Public License > + along with this program; if not, see . > +*/ > + > +#ifdef HAVE_CONFIG_H > +#include > +#endif > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#ifdef HAVE_UTIME_H > +#include > +#endif /*HAVE_UTIME_H*/ > + > +#include "pinentry.h" > +#include "assuan.h" > +#include "memory.h" > +#include "secmem-util.h" > + > +/* The communication mechanism is similar to emacsclient, but there > + are a few differences: > + > + - To avoid unnecessary character escaping and encoding conversion, > + we use a subset of the Pinentry Assuan protocol, instead of the > + emacsclient protocol. > + > + - We only use a Unix domain socket, while emacsclient has an > + ability to use a TCP socket. The socket file is located at > + ${TMPDIR-/tmp}/emacs$UID/pinentry (i.e., under the same directory > + as the socket file used by emacsclient, so the same permission > + and file owner settings apply). > + > + - The server implementation can be found in pinentry.el, which is > + available in Emacs 25+ or from ELPA. */ > + > +#define LINELENGTH ASSUAN_LINELENGTH > +#define SEND_BUFFER_SIZE 4096 > +#define INITIAL_TIMEOUT 60 > + > +#define MIN(x, y) ((x) < (y) ? (x) : (y)) > + > +#ifndef SUN_LEN > +# define SUN_LEN(ptr) ((size_t) (((struct sockaddr_un *) 0)->sun_path) \ > + + strlen ((ptr)->sun_path)) > +#endif > + > +static int emacs_socket = -1; > +static char send_buffer[SEND_BUFFER_SIZE + 1]; > +static int send_buffer_length; /* Fill pointer for the send buffer. */ > + > +#ifndef HAVE_DOSISH_SYSTEM > +static int timed_out; > +#endif > + > +static int > +set_socket (const char *socket_name) > +{ > + struct sockaddr_un unaddr; > + struct stat statbuf; > + const char *tmpdir; > + char *tmpdir_storage = NULL; > + uid_t uid; > + > + unaddr.sun_family = AF_UNIX; > + > + /* The socket address contains a UID, but POSIX doesn't define the > + maximum of uid_t: > + http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html#tag_22_02_12_01 > + We only support 32-bit UIDs, which can be represented with 10 > + decimal digits. > + */ > + uid = getuid (); > + if (uid > 0x100000000) > + { > + fprintf (stderr, "UID is too large\n"); > + return 0; > + } > + > + tmpdir = getenv ("TMPDIR"); > + if (!tmpdir) > + { > +#ifdef _CS_DARWIN_USER_TEMP_DIR > + size_t n = confstr (_CS_DARWIN_USER_TEMP_DIR, NULL, (size_t) 0); > + if (n > 0) > + { > + tmpdir = tmpdir_storage = malloc (n); > + if (!tmpdir) > + { > + fprintf (stderr, "out of core\n"); > + return 0; > + } > + confstr (_CS_DARWIN_USER_TEMP_DIR, tmpdir_storage, n); > + } > + else > +#endif > + tmpdir = "/tmp"; > + } > + > + if (strlen (tmpdir) + strlen ("/emacs") + 10 + strlen ("/") > + + strlen (socket_name) + 1 >= sizeof (unaddr.sun_path)) > + { > + fprintf (stderr, "socket name is too long\n"); > + return 0; > + } > + sprintf (unaddr.sun_path, "%s/emacs%lu/%s", tmpdir, > + (unsigned long) uid, socket_name); > + free (tmpdir_storage); > + > + /* See if the socket exists, and if it's owned by us. */ > + if (stat (unaddr.sun_path, &statbuf) == -1) > + { > + perror ("stat"); > + return 0; > + } > + > + if (statbuf.st_uid != geteuid ()) > + { > + fprintf (stderr, "socket is not owned by the same user\n"); > + return 0; > + } > + > + emacs_socket = socket (AF_UNIX, SOCK_STREAM, 0); > + if (emacs_socket < 0) > + { > + perror ("socket"); > + return 0; > + } > + > + if (connect (emacs_socket, (struct sockaddr *) &unaddr, > + SUN_LEN (&unaddr)) < 0) > + { > + perror ("connect"); > + close (emacs_socket); > + return 0; > + } > + > + return 1; > +} > + > +/* Percent-escape control characters in DATA. Return a newly > + allocated string, or DATA itself if there is no need to escape any > + character. Store the length of the string to LENGTHP. */ > +static char * > +escape (const char *data, size_t *lengthp) > +{ > + char *buffer, *out_p; > + size_t length = *lengthp, buffer_length; > + size_t offset = 0; > + size_t count = 0; > + > + while (offset < length) > + { > + switch (data[offset]) > + { > + case '%': case '\n': case '\r': > + count++; > + break; > + default: > + break; > + } > + offset++; > + } > + > + if (count == 0) > + return (char *) data; > + > + buffer_length = length + count * 2; > + buffer = malloc (buffer_length); > + if (!buffer) > + return NULL; > + > + out_p = buffer; > + while (offset < length) > + { > + int c = data[offset]; > + switch (c) > + { > + case '%': case '\n': case '\r': > + sprintf (out_p, "%%%02X", c); > + out_p += 3; > + break; > + default: > + *out_p++ = c; > + break; > + } > + offset++; > + } > + > + *lengthp = buffer_length; > + return buffer; > +} > + > +/* The inverse of escape. Removes quoting in string STR by modifying > + the string in place. */ > +static char * > +unescape (char *data, size_t *lengthp) > +{ > + char *p = data, *q = data; > + > + while (*p) > + { > + if (*p == '%' && p[1] && p[2]) > + { > + p++; > + *q++ = xtoi_2 (p); > + p += 2; > + } > + else > + *q++ = *p++; > + } > + *q = 0; > + *lengthp = q - data; > + return data; > +} > + > +/* Let's send the data to Emacs when either > + - the data ends in "\n", or > + - the buffer is full (but this shouldn't happen) > + Otherwise, we just accumulate it. */ > +static int > +send_to_emacs (int s, const char *buffer, size_t length) > +{ > + int retval = 1; > + > + while (*buffer) > + { > + size_t part = MIN (length, SEND_BUFFER_SIZE - send_buffer_length); > + memcpy (&send_buffer[send_buffer_length], buffer, part); > + buffer += part; > + send_buffer_length += part; > + > + if (send_buffer_length == SEND_BUFFER_SIZE > + || (send_buffer_length > 0 > + && send_buffer[send_buffer_length-1] == '\n')) > + { > + int sent = send (s, send_buffer, send_buffer_length, 0); > + if (sent < 0) > + { > + fprintf (stderr, "failed to send %d bytes to socket: %s\n", > + send_buffer_length, strerror (errno)); > + retval = 0; > + break; > + } > + if (sent != send_buffer_length) > + memmove (send_buffer, &send_buffer[sent], > + send_buffer_length - sent); > + send_buffer_length -= sent; > + } > + > + length -= part; > + } > + > + return retval; > +} > + > +/* Read a server response. If the response contains any data, this > + function returns it as a string. If BUFFER is not NULL, the data > + will be stored there. Otherwise, it allocates memory. */ > +static char * > +read_from_emacs (int s, int timeout, char *buffer, size_t *lengthp, > + assuan_error_t *error) > +{ > + struct timeval tv; > + fd_set rfds; > + int retval; > + size_t offset = 0; > + int allocated = buffer == NULL; > + size_t allocated_capacity = 0; > + int got_response = 0; > + char read_buffer[BUFSIZ + 1]; > + size_t read_offset = 0; > + > + tv.tv_sec = timeout; > + tv.tv_usec = 0; > + > + FD_ZERO (&rfds); > + FD_SET (s, &rfds); > + retval = select (s + 1, &rfds, NULL, NULL, &tv); > + if (retval == -1) > + { > + perror ("select"); > + return 0; > + } > + else if (retval == 0) > + { > + timed_out = 1; > + return 0; > + } > + > + while (!got_response) > + { > + int rl = 0; > + char *p, *end_p; > + do > + { > + errno = 0; > + rl = recv (s, read_buffer + read_offset, > + sizeof (read_buffer) - 1 - read_offset, 0); > + } > + /* If we receive a signal (e.g. SIGWINCH, which we pass > + through to Emacs), on some OSes we get EINTR and must retry. */ > + while (rl < 0 && errno == EINTR); > + > + if (rl < 0) > + { > + perror ("recv"); > + *error = ASSUAN_General_Error; > + goto error; > + } > + if (rl == 0) > + break; > + > + read_offset += rl; > + read_buffer[read_offset] = '\0'; > + > + end_p = strchr (read_buffer, '\n'); > + > + /* If the buffer is filled without NL, throw the contents away. > + FIXME: We could return ASSUAN_Line_Too_Long or > + ASSUAN_Line_Not_Terminated here. */ > + if (!end_p && read_offset == sizeof (read_buffer) - 1) > + read_offset = 0; > + > + /* Loop over all NL-terminated messages. */ > + for (p = read_buffer; end_p; p = end_p + 1, end_p = strchr (p, '\n')) > + { > + *end_p = '\0'; > + if (!strncmp ("D ", p, 2)) > + { > + char *data; > + size_t data_length; > + > + data = p + 2; > + data_length = end_p - data; > + > + if (allocated && offset + data_length > allocated_capacity) > + { > + allocated_capacity = allocated_capacity * 2 + 10; > + buffer = realloc (buffer, allocated_capacity); > + if (!buffer) > + { > + *error = ASSUAN_Out_Of_Core; > + goto error; > + } > + } > + else if (!allocated && offset + data_length > *lengthp) > + { > + *error = ASSUAN_General_Error; > + goto error; > + } > + > + memcpy (&buffer[offset], data, data_length); > + offset += data_length; > + } > + else if (!strcmp ("OK", p) || !strncmp ("OK ", p, 3)) > + { > + *error = ASSUAN_No_Error; > + got_response = 1; > + break; > + } > + else if (!strncmp ("ERR ", p, 4)) > + { > + unsigned long code = strtoul (p + 4, NULL, 10); > + if (code == ULONG_MAX && errno == ERANGE) > + *error = ASSUAN_General_Error; > + else > + *error = code; > + got_response = 1; > + break; > + } > + else if (!strncmp ("# ", p, 2)) > + ; > + else > + fprintf (stderr, "invalid response: %s\n", p); > + } > + > + if (!got_response) > + { > + size_t length = &read_buffer[read_offset] - p; > + memmove (read_buffer, p, length); > + read_offset = length; > + } > + } > + > + if (*error == ASSUAN_No_Error) > + { > + *lengthp = offset; > + return buffer; > + } > + > + error: > + if (allocated) > + free (buffer); > + > + return NULL; > +} > + > +int > +set_label (pinentry_t pe, const char *name, const char *value) > +{ > + char buffer[16], *escaped; > + size_t length; > + assuan_error_t error; > + int retval; > + > + if (!send_to_emacs (emacs_socket, name, strlen (name)) > + || !send_to_emacs (emacs_socket, " ", 1)) > + return 0; > + > + length = strlen (value); > + escaped = escape (value, &length); > + if (!escaped) > + return 0; > + > + retval = send_to_emacs (emacs_socket, escaped, length) > + && send_to_emacs (emacs_socket, "\n", 1); > + > + if (escaped != value) > + free (escaped); > + if (!retval) > + return 0; > + > + length = sizeof (buffer); > + read_from_emacs (emacs_socket, pe->timeout, buffer, &length, &error); > + return error == ASSUAN_No_Error; > +} > + > +static void > +set_labels (pinentry_t pe) > +{ > + if (pe->title) > + set_label (pe, "SETTITLE", pe->title); > + if (pe->description) > + set_label (pe, "SETDESC", pe->description); > + if (pe->error) > + set_label (pe, "SETERROR", pe->error); > + if (pe->prompt) > + set_label (pe, "SETPROMPT", pe->prompt); > + else if (pe->default_prompt) > + set_label (pe, "SETPROMPT", pe->default_prompt); > + if (pe->repeat_passphrase) > + set_label (pe, "SETREPEAT", pe->repeat_passphrase); > + if (pe->repeat_error_string) > + set_label (pe, "SETREPEATERROR", pe->repeat_error_string); > + > + /* XXX: pe->quality_bar and pe->quality_bar_tt are not supported. */ > + > + /* Buttons. */ > + if (pe->ok) > + set_label (pe, "SETOK", pe->ok); > + else if (pe->default_ok) > + set_label (pe, "SETOK", pe->default_ok); > + if (pe->cancel) > + set_label (pe, "SETCANCEL", pe->cancel); > + else if (pe->default_ok) > + set_label (pe, "SETCANCEL", pe->default_cancel); > + if (pe->notok) > + set_label (pe, "SETNOTOK", pe->notok); > +} > + > +static int > +do_password (pinentry_t pe) > +{ > + char *escaped, *password; > + size_t length; > + assuan_error_t error; > + > + set_labels (pe); > + > + if (!send_to_emacs (emacs_socket, "GETPIN\n", 7)) > + return -1; > + > + escaped = read_from_emacs (emacs_socket, pe->timeout, NULL, &length, &error); > + if (error != ASSUAN_No_Error) > + { > + pe->specific_err = error; > + return -1; > + } > + /* No data sent from the server - maybe cancelled. */ > + if (!escaped) > + { > + pe->specific_err = ASSUAN_General_Error; > + return -1; > + } > + > + password = unescape (escaped, &length); > + pinentry_setbufferlen (pe, length); > + if (pe->pin) > + memcpy (pe->pin, password, length); > + > + if (pe->repeat_passphrase) > + pe->repeat_okay = 1; > + > + if (password != escaped) > + free (password); > + free (escaped); > + > + /* XXX: we don't support external password cache (yet). */ > + > + return 1; > +} > + > +static int > +do_confirm (pinentry_t pe) > +{ > + char buffer[16]; > + size_t length; > + assuan_error_t error; > + > + set_labels (pe); > + > + if (!send_to_emacs (emacs_socket, "CONFIRM\n", 8)) > + return 0; > + > + length = sizeof (buffer); > + read_from_emacs (emacs_socket, pe->timeout, buffer, &length, &error); > + if (error != ASSUAN_No_Error) > + { > + pe->specific_err = error; > + return 0; > + } > + > + return 1; > +} > + > +/* If a touch has been registered, touch that file. */ > +static void > +do_touch_file (pinentry_t pinentry) > +{ > +#ifdef HAVE_UTIME_H > + struct stat st; > + time_t tim; > + > + if (!pinentry->touch_file || !*pinentry->touch_file) > + return; > + > + if (stat (pinentry->touch_file, &st)) > + return; /* Oops. */ > + > + /* Make sure that we actually update the mtime. */ > + while ( (tim = time (NULL)) == st.st_mtime ) > + sleep (1); > + > + /* Update but ignore errors as we can't do anything in that case. > + Printing error messages may even clubber the display further. */ > + utime (pinentry->touch_file, NULL); > +#endif /*HAVE_UTIME_H*/ > +} > + > +#ifndef HAVE_DOSISH_SYSTEM > +static void > +catchsig (int sig) > +{ > + if (sig == SIGALRM) > + timed_out = 1; > +} > +#endif > + > +int > +emacs_cmd_handler (pinentry_t pe) > +{ > + int rc; > + > +#ifndef HAVE_DOSISH_SYSTEM > + timed_out = 0; > + > + if (pe->timeout) > + { > + struct sigaction sa; > + > + memset (&sa, 0, sizeof(sa)); > + sa.sa_handler = catchsig; > + sigaction (SIGALRM, &sa, NULL); > + alarm (pe->timeout); > + } > +#endif > + > + if (pe->pin) > + rc = do_password (pe); > + else > + rc = do_confirm (pe); > + > + do_touch_file (pe); > + return rc; > +} > + > +int > +pinentry_inside_emacs (void) > +{ > + const char *envvar; > + > + /* Check if INSIDE_EMACS envvar is set. */ > + envvar = getenv ("INSIDE_EMACS"); > + if (!envvar || !*envvar) > + return 0; > + > + /* FIXME: Additional checks for the value. */ > + return 1; > +} > + > +int > +pinentry_emacs_init (void) > +{ > + char buffer[256]; > + size_t length = sizeof (buffer); > + assuan_error_t error; > + > + /* Check if we can connect to the Emacs server socket. */ > + if (!set_socket ("pinentry")) > + return 0; > + > + /* Check if the server responds. */ > + read_from_emacs (emacs_socket, INITIAL_TIMEOUT, buffer, &length, &error); > + return error == ASSUAN_No_Error; > +} > diff --git a/pinentry/pinentry-emacs.h b/pinentry/pinentry-emacs.h > new file mode 100644 > index 0000000..732c0ac > --- /dev/null > +++ b/pinentry/pinentry-emacs.h > @@ -0,0 +1,41 @@ > +/* pinentry-emacs.c - A secure emacs dialog for PIN entry, library version > + Copyright (C) 2015 Daiki Ueno > + > + This file is part of PINENTRY. > + > + PINENTRY is free software; you can redistribute it and/or modify it > + under the terms of the GNU General Public License as published by > + the Free Software Foundation; either version 2 of the License, or > + (at your option) any later version. > + > + PINENTRY is distributed in the hope that it will be useful, but > + WITHOUT ANY WARRANTY; without even the implied warranty of > + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + General Public License for more details. > + > + You should have received a copy of the GNU General Public License > + along with this program; if not, see . > +*/ > + > +#ifndef PINENTRY_EMACS_H > +#define PINENTRY_EMACS_H > + > +#include "pinentry.h" > + > +#ifdef __cplusplus > +extern "C" { > +#endif > + > +/* Return true if INSIDE_EMACS is set. */ > +int pinentry_inside_emacs (void); > + > +/* Initialize the Emacs interface, return true if success. */ > +int pinentry_emacs_init (void); > + > +int emacs_cmd_handler (pinentry_t pinentry); > + > +#ifdef __cplusplus > +} > +#endif > + > +#endif /* PINENTRY_EMACS_H */ > diff --git a/qt4/Makefile.am b/qt4/Makefile.am > index 816aade..c2ee3c6 100644 > --- a/qt4/Makefile.am > +++ b/qt4/Makefile.am > @@ -33,6 +33,12 @@ ncurses_include = > libcurses = > endif > > +if INSIDE_EMACS > +libemacs = ../pinentry/libpinentry-emacs.a $(LIBEMACS) $(LIBICONV) > +else > +libemacs = > +endif > + > > AM_CPPFLAGS = $(COMMON_CFLAGS) \ > -I$(top_srcdir) -I$(top_srcdir)/assuan -I$(top_srcdir)/secmem \ > @@ -41,7 +47,8 @@ AM_CXXFLAGS = $(QT4_CORE_CFLAGS) $(QT4_GUI_CFLAGS) > pinentry_qt4_LDADD = \ > ../pinentry/libpinentry.a $(top_builddir)/assuan/libassuan.a \ > $(top_builddir)/secmem/libsecmem.a \ > - $(COMMON_LIBS) $(QT4_CORE_LIBS) $(QT4_GUI_LIBS) $(libcurses) $(LIBCAP) > + $(COMMON_LIBS) $(QT4_CORE_LIBS) $(QT4_GUI_LIBS) \ > + $(libcurses) $(libemacs) $(LIBCAP) > > BUILT_SOURCES = \ > pinentryconfirm.moc qsecurelineedit.moc pinentrydialog.moc > diff --git a/qt4/main.cpp b/qt4/main.cpp > index 37b6e7b..bb682b3 100644 > --- a/qt4/main.cpp > +++ b/qt4/main.cpp > @@ -50,6 +50,10 @@ > #include > #endif > > +#ifdef INSIDE_EMACS > +#include "pinentry-emacs.h" > +#endif > + > static QString escape_accel( const QString & s ) { > > QString result; > @@ -263,51 +267,58 @@ main (int argc, char *argv[]) > > std::auto_ptr app; > > -#ifdef FALLBACK_CURSES > - if (!pinentry_have_display (argc, argv)) > - pinentry_cmd_handler = curses_cmd_handler; > +#ifdef INSIDE_EMACS > + if (pinentry_inside_emacs () && pinentry_emacs_init ()) > + pinentry_cmd_handler = emacs_cmd_handler; > else > #endif > { > - /* Qt does only understand -display but not --display; thus we > - are fixing that here. The code is pretty simply and may get > - confused if an argument is called "--display". */ > - char **new_argv, *p; > - size_t n; > - int i, done; > - > - for (n=0,i=0; i < argc; i++) > - n += strlen (argv[i])+1; > - n++; > - new_argv = (char**)calloc (argc+1, sizeof *new_argv); > - if (new_argv) > - *new_argv = (char*)malloc (n); > - if (!new_argv || !*new_argv) > - { > - fprintf (stderr, "pinentry-qt4: can't fixup argument list: %s\n", > - strerror (errno)); > - exit (EXIT_FAILURE); > - > - } > - for (done=0,p=*new_argv,i=0; i < argc; i++) > - if (!done && !strcmp (argv[i], "--display")) > - { > - new_argv[i] = strcpy (p, argv[i]+1); > - p += strlen (argv[i]+1) + 1; > - done = 1; > - } > - else > - { > - new_argv[i] = strcpy (p, argv[i]); > - p += strlen (argv[i]) + 1; > - } > +#ifdef FALLBACK_CURSES > + if (!pinentry_have_display (argc, argv)) > + pinentry_cmd_handler = curses_cmd_handler; > + else > +#endif > + { > + /* Qt does only understand -display but not --display; thus we > + are fixing that here. The code is pretty simply and may get > + confused if an argument is called "--display". */ > + char **new_argv, *p; > + size_t n; > + int i, done; > + > + for (n=0,i=0; i < argc; i++) > + n += strlen (argv[i])+1; > + n++; > + new_argv = (char**)calloc (argc+1, sizeof *new_argv); > + if (new_argv) > + *new_argv = (char*)malloc (n); > + if (!new_argv || !*new_argv) > + { > + fprintf (stderr, "pinentry-qt4: can't fixup argument list: %s\n", > + strerror (errno)); > + exit (EXIT_FAILURE); > > - /* We use a modal dialog window, so we don't need the application > - window anymore. */ > - i = argc; > - app.reset (new QApplication (i, new_argv)); > - const QIcon icon( QLatin1String( ":/document-encrypt.png" ) ); > - app->setWindowIcon( icon ); > + } > + for (done=0,p=*new_argv,i=0; i < argc; i++) > + if (!done && !strcmp (argv[i], "--display")) > + { > + new_argv[i] = strcpy (p, argv[i]+1); > + p += strlen (argv[i]+1) + 1; > + done = 1; > + } > + else > + { > + new_argv[i] = strcpy (p, argv[i]); > + p += strlen (argv[i]) + 1; > + } > + > + /* We use a modal dialog window, so we don't need the application > + window anymore. */ > + i = argc; > + app.reset (new QApplication (i, new_argv)); > + const QIcon icon( QLatin1String( ":/document-encrypt.png" ) ); > + app->setWindowIcon( icon ); > + } > } > > > -- > 2.1.0 > > [3 pinentry.el ] > ;;; pinentry.el --- GnuPG Pinentry server implementation -*- lexical-binding: t -*- > > ;; Copyright (C) 2015 Free Software Foundation, Inc. > > ;; Author: Daiki Ueno > ;; Keywords: GnuPG > > ;; This file is part of GNU Emacs. > > ;; GNU Emacs is free software: you can redistribute it and/or modify > ;; it under the terms of the GNU General Public License as published by > ;; the Free Software Foundation, either version 3 of the License, or > ;; (at your option) any later version. > > ;; GNU Emacs is distributed in the hope that it will be useful, > ;; but WITHOUT ANY WARRANTY; without even the implied warranty of > ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > ;; GNU General Public License for more details. > > ;; You should have received a copy of the GNU General Public License > ;; along with GNU Emacs. If not, see . > > ;;; Code: > > (defvar pinentry--server-process nil) > (defvar pinentry--connection-process-list nil) > > (defvar pinentry--labels nil) > (put 'pinentry-read-point 'permanent-local t) > (defvar pinentry--read-point nil) > (put 'pinentry--read-point 'permanent-local t) > > ;; We use the same location as `server-socket-dir', when local sockets > ;; are supported. > (defvar pinentry--socket-dir > (format "%s/emacs%d" (or (getenv "TMPDIR") "/tmp") (user-uid)) > "The directory in which to place the server socket. > If local sockets are not supported, this is nil.") > > (defconst pinentry--set-label-commands > '("SETPROMPT" "SETTITLE" "SETDESC" > "SETREPEAT" "SETREPEATERROR" > "SETOK" "SETCANCEL" "SETNOTOK")) > > (defmacro pinentry--error-code (code) > (logior (lsh 5 24) code)) > (defconst pinentry--error-not-implemented > (cons (pinentry--error-code 69) "not implemented")) > (defconst pinentry--error-cancelled > (cons (pinentry--error-code 99) "cancelled")) > (defconst pinentry--error-not-confirmed > (cons (pinentry--error-code 114) "not confirmed")) > > (autoload 'server-ensure-safe-dir "server") > > ;;;###autoload > (defun pinentry-start () > "Start a Pinentry service." > (interactive) > (unless (featurep 'make-network-process '(:family local)) > (error "local sockets are not supported")) > (if (process-live-p pinentry--server-process) > (message "Pinentry service is already running") > (let* ((server-file (expand-file-name "pinentry" pinentry--socket-dir))) > (server-ensure-safe-dir pinentry--socket-dir) > ;; Delete the socket files made by previous server invocations. > (ignore-errors > (let (delete-by-moving-to-trash) > (delete-file server-file))) > (setq pinentry--server-process > (make-network-process > :name "pinentry" > :server t > :noquery t > :sentinel #'pinentry--process-sentinel > :filter #'pinentry--process-filter > :coding 'no-conversion > :family 'local > :service server-file)) > (process-put pinentry--server-process :server-file server-file)))) > > (defun pinentry-stop () > "Stop a Pinentry service." > (interactive) > (when (process-live-p pinentry--server-process) > (delete-process pinentry--server-process)) > (setq pinentry--server-process nil) > (dolist (process pinentry--connection-process-list) > (when (buffer-live-p (process-buffer process)) > (kill-buffer (process-buffer process)))) > (setq pinentry--connection-process-list nil)) > > (defun pinentry--labels-to-shortcuts (labels) > (mapcar (lambda (label) > (when label > (if (string-match "_\\([[:alnum:]]\\)" label) > (let* ((key (match-string 1 label)) > (c (downcase (aref key 0)))) > (setq label (replace-match > (propertize key 'face 'underline) > t t label)) > (cons c label)) > (cons (if (= (length label) 0) > ?? > (downcase (aref 0 label))) > label)))) > labels)) > > (defun pinentry--escape-string (string) > "Escape STRING in the Assuan percent escape." > (let ((length (length string)) > (index 0) > (count 0)) > (while (< index length) > (if (memq (aref string index) '(?\n ?\r ?%)) > (setq count (1+ count))) > (setq index (1+ index))) > (setq index 0) > (let ((result (make-string (+ length (* count 2)) ?\0)) > (result-index 0) > c) > (while (< index length) > (setq c (aref string index)) > (if (memq c '(?\n ?\r ?%)) > (let ((hex (format "%02X" c))) > (aset result result-index ?%) > (setq result-index (1+ result-index)) > (aset result result-index (aref hex 0)) > (setq result-index (1+ result-index)) > (aset result result-index (aref hex 1)) > (setq result-index (1+ result-index))) > (aset result result-index c) > (setq result-index (1+ result-index))) > (setq index (1+ index))) > result))) > > (defun pinentry--send-data (process escaped) > "Send a string ESCAPED to a process PROCESS. > ESCAPED will be split if it exceeds the line length limit of the > Assuan protocol." > (let ((length (length escaped)) > (index 0)) > (if (= length 0) > (process-send-string process "D \n") > (while (< index length) > ;; 997 = ASSUAN_LINELENGTH (= 1000) - strlen ("D \n") > (let* ((sub-length (min (- length index) 997)) > (sub (substring escaped index (+ index sub-length)))) > (unwind-protect > (progn > (process-send-string process "D ") > (process-send-string process sub) > (process-send-string process "\n")) > (clear-string sub)) > (setq index (+ index sub-length))))))) > > (defun pinentry--send-error (process error) > (process-send-string process (format "ERR %d %s\n" (car error) (cdr error)))) > > (defun pinentry--process-filter (process input) > (unless (buffer-live-p (process-buffer process)) > (let ((buffer (generate-new-buffer " *pinentry*"))) > (set-process-buffer process buffer) > (with-current-buffer buffer > (if (fboundp 'set-buffer-multibyte) > (set-buffer-multibyte nil)) > (make-local-variable 'pinentry--read-point) > (setq pinentry--read-point (point-min)) > (make-local-variable 'pinentry--labels)))) > (with-current-buffer (process-buffer process) > (save-excursion > (goto-char (point-max)) > (insert input) > (goto-char pinentry--read-point) > (beginning-of-line) > (while (looking-at ".*\n") ;the input line finished > (if (looking-at "\\([A-Z_]+\\) ?\\(.*\\)") > (let ((command (match-string 1)) > (string (match-string 2))) > (pcase command > ((and set (guard (member set pinentry--set-label-commands))) > (when (> (length string) 0) > (let* ((symbol (intern (downcase (substring set 3)))) > (entry (assq symbol pinentry--labels)) > (label (decode-coding-string string 'utf-8))) > (if entry > (setcdr entry label) > (push (cons symbol label) pinentry--labels)))) > (process-send-string process "OK\n")) > ("NOP" > (process-send-string process "OK\n")) > ("GETPIN" > (let ((prompt > (or (cdr (assq 'desc pinentry--labels)) > (cdr (assq 'prompt pinentry--labels)) > "")) > (confirm (not (null (assq 'repeat pinentry--labels)))) > entry) > (if (setq entry (assq 'error pinentry--labels)) > (setq prompt (concat "Error: " > (propertize > (copy-sequence (cdr entry)) > 'face 'error) > "\n" > prompt))) > (if (setq entry (assq 'title pinentry--labels)) > (setq prompt (format "[%s] %s" > (cdr entry) prompt))) > (if (string-match ":?[ \n]*\\'" prompt) > (setq prompt (concat > (substring > prompt 0 (match-beginning 0)) ": "))) > (let (passphrase escaped-passphrase encoded-passphrase) > (unwind-protect > (condition-case nil > (progn > (setq passphrase > (read-passwd prompt confirm)) > (setq escaped-passphrase > (pinentry--escape-string > passphrase)) > (setq encoded-passphrase (encode-coding-string > escaped-passphrase > 'utf-8)) > (pinentry--send-data > process encoded-passphrase) > (process-send-string process "OK\n")) > (error > (pinentry--send-error > process > pinentry--error-cancelled))) > (if passphrase > (clear-string passphrase)) > (if escaped-passphrase > (clear-string escaped-passphrase)) > (if encoded-passphrase > (clear-string encoded-passphrase)))) > (setq pinentry--labels nil))) > ("CONFIRM" > (let ((prompt > (or (cdr (assq 'desc pinentry--labels)) > "")) > (buttons > (pinentry--labels-to-shortcuts > (list (cdr (assq 'ok pinentry--labels)) > (cdr (assq 'notok pinentry--labels)) > (cdr (assq 'cancel pinentry--labels))))) > entry) > (if (setq entry (assq 'error pinentry--labels)) > (setq prompt (concat "Error: " > (propertize > (copy-sequence (cdr entry)) > 'face 'error) > "\n" > prompt))) > (if (setq entry (assq 'title pinentry--labels)) > (setq prompt (format "[%s] %s" > (cdr entry) prompt))) > (if (remq nil buttons) > (progn > (setq prompt > (concat prompt " (" > (mapconcat #'cdr (remq nil buttons) > ", ") > ") ")) > (condition-case nil > (let ((result (read-char prompt))) > (if (eq result (caar buttons)) > (process-send-string process "OK\n") > (if (eq result (car (nth 1 buttons))) > (pinentry--send-error > process > pinentry--error-not-confirmed) > (pinentry--send-error > process > pinentry--error-cancelled)))) > (error > (pinentry--send-error > process > pinentry--error-cancelled)))) > (if (string-match "[ \n]*\\'" prompt) > (setq prompt (concat > (substring > prompt 0 (match-beginning 0)) " "))) > (if (condition-case nil > (y-or-n-p prompt) > (quit)) > (process-send-string process "OK\n") > (pinentry--send-error > process > pinentry--error-not-confirmed))) > (setq pinentry--labels nil))) > (_ (pinentry--send-error > process > pinentry--error-not-implemented))) > (forward-line) > (setq pinentry--read-point (point)))))))) > > (defun pinentry--process-sentinel (process _status) > "The process sentinel for Emacs server connections." > ;; If this is a new client process, set the query-on-exit flag to nil > ;; for this process (it isn't inherited from the server process). > (when (and (eq (process-status process) 'open) > (process-query-on-exit-flag process)) > (push process pinentry--connection-process-list) > (set-process-query-on-exit-flag process nil) > (process-send-string process "OK Your orders please\n")) > ;; Kill the process buffer of the connection process. > (when (and (not (process-contact process :server)) > (eq (process-status process) 'closed)) > (when (buffer-live-p (process-buffer process)) > (kill-buffer (process-buffer process))) > (setq pinentry--connection-process-list > (delq process pinentry--connection-process-list))) > ;; Delete the associated connection file, if applicable. > ;; Although there's no 100% guarantee that the file is owned by the > ;; running Emacs instance, server-start uses server-running-p to check > ;; for possible servers before doing anything, so it *should* be ours. > (and (process-contact process :server) > (eq (process-status process) 'closed) > (ignore-errors > (delete-file (process-get process :server-file))))) > > (provide 'pinentry) > > ;;; pinentry.el ends here From dkg at fifthhorseman.net Thu Jun 4 20:23:31 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 04 Jun 2015 14:23:31 -0400 Subject: pinentry-gnome3 and gpg-agent 2.0.28 kbd accelerators not working In-Reply-To: <87y4jz1gzb.fsf@alice.fifthhorseman.net> References: <87bngv2x5t.fsf@alice.fifthhorseman.net> <87wpzjqs2l.wl-neal@walfield.org> <87y4jz1gzb.fsf@alice.fifthhorseman.net> Message-ID: <87sia71gf0.fsf@alice.fifthhorseman.net> On Thu 2015-06-04 14:11:20 -0400, Daniel Kahn Gillmor wrote: > On Thu 2015-06-04 13:52:34 -0400, Neal H. Walfield wrote: > >> I just tried something similar on my system and the accelerators are >> displayed and work fine. There is probably a bug in the gcr backend >> that you are using. I'm on Xfce and thus (AIUI) I get the Gtk+ back >> end. > > Thanks for the quick response, Neal. another twisty maze of > dependencies for me to track down :/ > > Can you send a screenshot of what your xfce screenshot looks like? I'll > try to reproduce it here too... Here's what i see under xfce4 on debian unstable: -------------- next part -------------- A non-text attachment was scrubbed... Name: pinentry-gnome3.screenshot.xfce4.small.jpg Type: image/jpeg Size: 30119 bytes Desc: pinentry-gnome3 showing (but not using) keyboard accelerators on XFCE4 URL: -------------- next part -------------- in this case, the accelerators work for Cancel and OK, but they don't work for "_Save in password manager". What's different about our setups that they work for you? --dkg PS i notice one other issue under xfce4 that doesn't happen in gnome3: in xfce4, the TAB key is treated as input to the password field, instead of switching input fields. shift-TAB, however, does work to cycle through the fields in reverse tab order. under GNOME, both TAB and shift-TAB work as expected. weirdness... From neal at walfield.org Thu Jun 4 22:43:22 2015 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 04 Jun 2015 22:43:22 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> Message-ID: <87r3prqk5x.wl-neal@walfield.org> Hi Daiki, My comments are inline. Thanks! :) Neal At Tue, 02 Jun 2015 17:56:44 +0900, Daiki Ueno wrote: > +AM_CONDITIONAL(BUILD_LIBPINENTRY_EMACS, > + test "$pinentry_emacs" = "yes" -o "$inside_emacs" = "yes") I'm a bit confused by this. I can unstand building the emacs pinentry without the inside emacs check, but doesn't inside_emacs imply pinentry_emacs? If so, we only need to check if "$pinentry_emacs" = "yes". Right? > diff --git a/pinentry/pinentry-emacs.c b/pinentry/pinentry-emacs.c > new file mode 100644 > index 0000000..280546d > --- /dev/null > +++ b/pinentry/pinentry-emacs.c > + if (strlen (tmpdir) + strlen ("/emacs") + 10 + strlen ("/") > + + strlen (socket_name) + 1 >= sizeof (unaddr.sun_path)) > + { > + fprintf (stderr, "socket name is too long\n"); > + return 0; > + } > + sprintf (unaddr.sun_path, "%s/emacs%lu/%s", tmpdir, > + (unsigned long) uid, socket_name); Technically, this is too conservative. 10 is the maximum length of the uid. If the user is 1000, then only 4 characters are needed. > +/* Percent-escape control characters in DATA. Return a newly > + allocated string, or DATA itself if there is no need to escape any > + character. Store the length of the string to LENGTHP. */ > +static char * > +escape (const char *data, size_t *lengthp) > +{ > + char *buffer, *out_p; > + size_t length = *lengthp, buffer_length; The comment is inaccurate. *LENGTHP needs to contain the length of DATA. It also doesn't return a string, but a character vector (it is not NUL terminated as far as I can tell). This is actually a problem for set_label (and perhaps elsewhere): it calls escape with the length of the string, not including the NUL character! Also, the return semantics are a bit too smart for my taste. It would be better to always allocate a new string. > +/* The inverse of escape. Removes quoting in string STR by modifying > + the string in place. */ > +static char * > +unescape (char *data, size_t *lengthp) > +{ The semantics doesn't match escape's semantics: *LENGTHP is not the length of the character vector. Instead, this function assumes that DATA is a NUL-terminated C string. This lack of symmetry is another reason to change escape. > +static int > +do_password (pinentry_t pe) > +{ > + char *escaped, *password; > + size_t length; > + assuan_error_t error; > + > + set_labels (pe); > + > + if (!send_to_emacs (emacs_socket, "GETPIN\n", 7)) > + return -1; > + > + escaped = read_from_emacs (emacs_socket, pe->timeout, NULL, &length, &error); It is a bit unfortunate that the password is initially read into insecure memory. Let's allocate, say, 1k of secure memory and use that. > + password = unescape (escaped, &length); > + pinentry_setbufferlen (pe, length); > + if (pe->pin) > + memcpy (pe->pin, password, length); You should NUL terminate the password. > +static int > +do_confirm (pinentry_t pe) > +{ > + char buffer[16]; > + size_t length; > + assuan_error_t error; > + > + set_labels (pe); > + > + if (!send_to_emacs (emacs_socket, "CONFIRM\n", 8)) > + return 0; > + > + length = sizeof (buffer); > + read_from_emacs (emacs_socket, pe->timeout, buffer, &length, &error); > + if (error != ASSUAN_No_Error) > + { > + pe->specific_err = error; > + return 0; > + } > + > + return 1; You don't handle the case when the user pressed cancelled (we need to set pe->cancelled) or the third button. It is important to get at least the former right. Are there any specific reasons that this is difficult? > +int > +pinentry_inside_emacs (void) > +{ > + const char *envvar; > + > + /* Check if INSIDE_EMACS envvar is set. */ > + envvar = getenv ("INSIDE_EMACS"); > + if (!envvar || !*envvar) > + return 0; > + > + /* FIXME: Additional checks for the value. */ > + return 1; > +} > + > +int > +pinentry_emacs_init (void) > +{ > + char buffer[256]; > + size_t length = sizeof (buffer); > + assuan_error_t error; > + > + /* Check if we can connect to the Emacs server socket. */ > + if (!set_socket ("pinentry")) > + return 0; > + > + /* Check if the server responds. */ > + read_from_emacs (emacs_socket, INITIAL_TIMEOUT, buffer, &length, &error); > + return error == ASSUAN_No_Error; > +} Why doesn't pinentry_inside_emacs directly call pinentry_emacs_init? It seems to me that the real test of whether we can use an emacs pin is there? Also, in your previous patch, you checked for the existence of a particular symbol. Why don't you do that anymore? I think it is reasonable that the INSIDE_EMACS is set, but the version of emacs doesn't have support for pinentry. Thanks, Neal From andreas.stieger at gmx.de Fri Jun 5 00:06:01 2015 From: andreas.stieger at gmx.de (Andreas Stieger) Date: Fri, 05 Jun 2015 00:06:01 +0200 Subject: pinentry-gnome3: (libgcrypt): Cannot allocate memory Message-ID: <5570CBC9.9080500@gmx.de> Hello, As I was packaging pinentry 0.9.3 with the new /usr/bin/pinentry-gnome3 I noticed the following: $ /usr/bin/pinentry-gnome3 OK Your orders please getpin couldn't lock 16384 bytes of memory (libgcrypt): Cannot allocate memory ERR 83886179 canceled strace: mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7efc75498000 mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7efc75494000 mlock(0x7efc75494000, 16384) = -1 ENOMEM (Cannot allocate memory) write(2, "couldn't lock 16384 bytes of mem"..., 72couldn't lock 16384 bytes of memory (libgcrypt): Cannot allocate memory This is on a system with a fairly standard limit: max locked memory (kbytes, -l) 64 Where would we start looking to debug and look for a possible solution? Do you think the gnome3 variant could receive a change to stay below a 64k lock limit? openSUSE tracks this in: https://bugzilla.opensuse.org/show_bug.cgi?id=933687 Andreas From dkg at fifthhorseman.net Fri Jun 5 01:46:13 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 04 Jun 2015 19:46:13 -0400 Subject: pinentry-gnome3: (libgcrypt): Cannot allocate memory In-Reply-To: <5570CBC9.9080500@gmx.de> References: <5570CBC9.9080500@gmx.de> Message-ID: <87382711h6.fsf@alice.fifthhorseman.net> Hi Andreas-- On Thu 2015-06-04 18:06:01 -0400, Andreas Stieger wrote: > As I was packaging pinentry 0.9.3 with the new /usr/bin/pinentry-gnome3 You don't say what platform you're packaging this for, but please note that pinentry-gnome3 is already available in debian unstable :) > $ /usr/bin/pinentry-gnome3 > OK Your orders please > getpin > couldn't lock 16384 bytes of memory (libgcrypt): Cannot allocate memory > ERR 83886179 canceled > > strace: > > mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) > = 0x7efc75498000 > mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, > 0) = 0x7efc75494000 > mlock(0x7efc75494000, 16384) = -1 ENOMEM (Cannot allocate memory) > write(2, "couldn't lock 16384 bytes of mem"..., 72couldn't lock 16384 > bytes of memory (libgcrypt): Cannot allocate memory > > This is on a system with a fairly standard limit: > max locked memory (kbytes, -l) 64 > > Where would we start looking to debug and look for a possible solution? > Do you think the gnome3 variant could receive a change to stay below a > 64k lock limit? I can't reproduce this on debian: 0 dkg at alice:~$ ulimit -a | grep locked max locked memory (kbytes, -l) 64 0 dkg at alice:~$ pinentry-gnome3 OK Your orders please getpin D abc123 OK 0 dkg at alice:~$ > openSUSE tracks this in: > https://bugzilla.opensuse.org/show_bug.cgi?id=933687 Sounds like this might be platform specific. What version of libgcrypt are you running? --dkg From dkg at fifthhorseman.net Fri Jun 5 03:39:21 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 04 Jun 2015 21:39:21 -0400 Subject: gnome keyring & gpg agent In-Reply-To: <877fsbvwhr.wl-neal@walfield.org> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> <877fsbvwhr.wl-neal@walfield.org> Message-ID: <87k2vjylva.fsf@alice.fifthhorseman.net> On Thu 2015-05-14 14:34:40 -0400, Neal H. Walfield wrote: > Is it possible to fix this issue in Debian Stable (e.g., in the next > point release)? This is a lot of change to push into a stable point release, so i'm not sure that it'll happen. The first step would be to make sure that it's all resolved in unstable, and then we can look into what parts are possible for stable. > So far, I've identified these requirements: > > - Adding a new pinentry-gnome3 package with the yet-to-be-released > pinentry with Gnome3 support. This is done in debian unstable, with pinentry 0.9.3. yay! > - An update to GPG with the relatively small change. I'm not sure exactly which change to gpg this is intended to be. do you have a suggestion? > - An update to Gnome-Keyring that disables it GPG Agent proxy. Maybe we need to offer them a patch. the goal here is just to disable gnome-keyring's gpg-agent proxy implementation by default, right? > - Make Gnome Keyring depend on pinentry-gnome3. I've opened https://bugs.debian.org/787786 for this. --dkg From neal at walfield.org Fri Jun 5 04:09:28 2015 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 05 Jun 2015 04:09:28 +0200 Subject: gnome keyring & gpg agent In-Reply-To: <87k2vjylva.fsf@alice.fifthhorseman.net> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> <877fsbvwhr.wl-neal@walfield.org> <87k2vjylva.fsf@alice.fifthhorseman.net> Message-ID: <87oakurjmv.wl-neal@walfield.org> Hi Daniel, At Thu, 04 Jun 2015 21:39:21 -0400, Daniel Kahn Gillmor wrote: > On Thu 2015-05-14 14:34:40 -0400, Neal H. Walfield wrote: > > Is it possible to fix this issue in Debian Stable (e.g., in the next > > point release)? > > This is a lot of change to push into a stable point release, so i'm not > sure that it'll happen. The first step would be to make sure that it's > all resolved in unstable, and then we can look into what parts are > possible for stable. Ok. > > So far, I've identified these requirements: > > > > - Adding a new pinentry-gnome3 package with the yet-to-be-released > > pinentry with Gnome3 support. > > This is done in debian unstable, with pinentry 0.9.3. yay! great :). > > - An update to GPG with the relatively small change. > > I'm not sure exactly which change to gpg this is intended to be. do you > have a suggestion? The main change in 2.0.28: dde8ddffd37c9ef96cae2e2b1317d1dee607fc0b (plus the minor fix in ef0741ac54c63b9b744de9dec86e82c530f9543a). commit dde8ddffd37c9ef96cae2e2b1317d1dee607fc0b Author: Neal H. Walfield Date: Tue May 19 13:53:43 2015 +0200 agent: Backport changes from 2.1 to support an external password manager. * agent/agent.h (agent_askpin): Add arguments keyinfo and cache_mode. Update callers. (agent_get_passphrase): Likewise. (agent_clear_passphrase): New function. (opt): Add field allow_external_cache. * agent/call-pinentry.c (start_pinentry): Send "OPTION allow-external-password-cache" to the pinentry. (PINENTRY_STATUS_PASSWORD_FROM_CACHE): New constant. (pinentry_status_cb): New function. (agent_askpin): Add arguments keyinfo and cache_mode. If KEYINFO and CACHE_MODE describe a cachable key, then send SETKEYINFO to the pinentry. Pass PINENTRY_STATUS_CB to the "GETPIN" invocation. If the passphrase was incorrect and PINENTRY_STATUS_PASSWORD_FROM_CACHE is set, decrement PININFO->FAILED_TRIES. (agent_get_passphrase): Add arguments keyinfo and cache_mode. If KEYINFO and CACHE_MODE describe a cachable key, then send SETKEYINFO to the pinentry. (agent_clear_passphrase): New function. * agent/call-pinentry.c (start_pinentry): Act upon new var, allow_external_cache. * agent/command.c (cmd_clear_passphrase): Call agent_clear_passphrase. * agent/gpg-agent.c (oNoAllowExternalCache): New. (opts): Add option --no-allow-external-cache. (parse_rereadable_options): Set this option. > > - An update to Gnome-Keyring that disables it GPG Agent proxy. > > Maybe we need to offer them a patch. the goal here is just to disable > gnome-keyring's gpg-agent proxy implementation by default, right? That's correct. It should be sufficient to configure gnome keyring with --disable-gpg-agent (but I haven't tested this). > > - Make Gnome Keyring depend on pinentry-gnome3. > > I've opened https://bugs.debian.org/787786 for this. In that report, you note: This is part of a larger project to reduce superfluous dependencies on headless servers that use GnuPG while improving the user experience for desktop users of GnuPG That's a worth effort, but it might be worth mentioning that it is also about fixing the gnome keyring hijack problem. Thanks for working on this! :) Neal From dkg at fifthhorseman.net Fri Jun 5 04:14:25 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 04 Jun 2015 22:14:25 -0400 Subject: gnome keyring & gpg agent In-Reply-To: <87oakurjmv.wl-neal@walfield.org> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> <877fsbvwhr.wl-neal@walfield.org> <87k2vjylva.fsf@alice.fifthhorseman.net> <87oakurjmv.wl-neal@walfield.org> Message-ID: <87a8wezyta.fsf@alice.fifthhorseman.net> On Thu 2015-06-04 22:09:28 -0400, Neal H. Walfield wrote: > The main change in 2.0.28: dde8ddffd37c9ef96cae2e2b1317d1dee607fc0b > (plus the minor fix in ef0741ac54c63b9b744de9dec86e82c530f9543a). Thanks, that's good to keep track of. >> > - An update to Gnome-Keyring that disables it GPG Agent proxy. >> >> Maybe we need to offer them a patch. the goal here is just to disable >> gnome-keyring's gpg-agent proxy implementation by default, right? > > That's correct. It should be sufficient to configure gnome keyring > with --disable-gpg-agent (but I haven't tested this). that would make it so that users who wanted to use gnome-keyring as the gpg-agent (e.g. those who don't have smartcards, don't use gpgsm, and who otherwise ignore the concerns Werner has raised about gnome-keyring's incomplete gpg-agent support) would be unable to do so. It's a more invasive change than just disabling the functionality as per runtime defaults. Then again, that might keep us from dealing with a lot of extra bug reports :) >> > - Make Gnome Keyring depend on pinentry-gnome3. >> >> I've opened https://bugs.debian.org/787786 for this. > > In that report, you note: > > This is part of a larger project to reduce superfluous dependencies > on headless servers that use GnuPG while improving the user > experience for desktop users of GnuPG > > That's a worth effort, but it might be worth mentioning that it is > also about fixing the gnome keyring hijack problem. The bug reports referenced in #787786 each point to the hijacking problem as well, but i welcome any followup at 787786 at bugs.debian.org that you think would be relevant there too. Thanks, --dkg From neal at walfield.org Fri Jun 5 04:30:21 2015 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 05 Jun 2015 04:30:21 +0200 Subject: gnome keyring & gpg agent In-Reply-To: <87a8wezyta.fsf@alice.fifthhorseman.net> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> <877fsbvwhr.wl-neal@walfield.org> <87k2vjylva.fsf@alice.fifthhorseman.net> <87oakurjmv.wl-neal@walfield.org> <87a8wezyta.fsf@alice.fifthhorseman.net> Message-ID: <87mw0erio2.wl-neal@walfield.org> At Thu, 04 Jun 2015 22:14:25 -0400, Daniel Kahn Gillmor wrote: > >> > - An update to Gnome-Keyring that disables it GPG Agent proxy. > >> > >> Maybe we need to offer them a patch. the goal here is just to disable > >> gnome-keyring's gpg-agent proxy implementation by default, right? > > > > That's correct. It should be sufficient to configure gnome keyring > > with --disable-gpg-agent (but I haven't tested this). > > that would make it so that users who wanted to use gnome-keyring as the > gpg-agent (e.g. those who don't have smartcards, don't use gpgsm, and > who otherwise ignore the concerns Werner has raised about > gnome-keyring's incomplete gpg-agent support) would be unable to do so. > > It's a more invasive change than just disabling the functionality as per > runtime defaults. > > Then again, that might keep us from dealing with a lot of extra bug > reports :) I spoke with Stef (the maintainer of GNOME Keyring, cc'ed) and he agrees that removing the proxy is the correct way forward. The only reason that the proxy exists is to cache passwords. pinentry-gnome3 does exactly that in a cleaner way. In other words: it makes the proxy completely redundant. A GSoC student is working on finishing the changes to GNOME Keyring and pinentry-gnome3 (e.g., extending GCR to deal with all of GnuPG's prompts). Nevertheless, the current pinentry version already more complete than the proxy. :) Neal From dkg at fifthhorseman.net Fri Jun 5 06:20:07 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 05 Jun 2015 00:20:07 -0400 Subject: gnome keyring & gpg agent In-Reply-To: <87mw0erio2.wl-neal@walfield.org> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> <877fsbvwhr.wl-neal@walfield.org> <87k2vjylva.fsf@alice.fifthhorseman.net> <87oakurjmv.wl-neal@walfield.org> <87a8wezyta.fsf@alice.fifthhorseman.net> <87mw0erio2.wl-neal@walfield.org> Message-ID: <87vbf2yefc.fsf@alice.fifthhorseman.net> Control: retitle 760102 gnome-keyring: please build with --disable-gpg-agent Control: block 760102 with 787786 On Thu 2015-06-04 22:30:21 -0400, Neal H. Walfield wrote: > At Thu, 04 Jun 2015 22:14:25 -0400, Daniel Kahn Gillmor wrote: >> >> > - An update to Gnome-Keyring that disables it GPG Agent proxy. >> >> >> >> Maybe we need to offer them a patch. the goal here is just to disable >> >> gnome-keyring's gpg-agent proxy implementation by default, right? >> > >> > That's correct. It should be sufficient to configure gnome keyring >> > with --disable-gpg-agent (but I haven't tested this). >> >> that would make it so that users who wanted to use gnome-keyring as the >> gpg-agent (e.g. those who don't have smartcards, don't use gpgsm, and >> who otherwise ignore the concerns Werner has raised about >> gnome-keyring's incomplete gpg-agent support) would be unable to do so. >> >> It's a more invasive change than just disabling the functionality as per >> runtime defaults. >> >> Then again, that might keep us from dealing with a lot of extra bug >> reports :) > > I spoke with Stef (the maintainer of GNOME Keyring, cc'ed) and he > agrees that removing the proxy is the correct way forward. > > The only reason that the proxy exists is to cache passwords. > pinentry-gnome3 does exactly that in a cleaner way. In other words: > it makes the proxy completely redundant. > > A GSoC student is working on finishing the changes to GNOME Keyring > and pinentry-gnome3 (e.g., extending GCR to deal with all of GnuPG's > prompts). Nevertheless, the current pinentry version already more > complete than the proxy. Great, this sounds like a good assessment. I'm forwarding this info to https://bugs.debian.org/760102, which is already asking for some resolution of this situation. If gnome-keyring can Depend: pinentry-gnome3 (#787786), it should be able to build with --disable-gpg-agent. Thanks for your work on this, all the coordination. Regards, --dkg From dkg at fifthhorseman.net Fri Jun 5 08:16:57 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 05 Jun 2015 02:16:57 -0400 Subject: Bug#760102: gnome keyring & gpg agent In-Reply-To: <55712734.1090206@debian.org> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> <877fsbvwhr.wl-neal@walfield.org> <87k2vjylva.fsf@alice.fifthhorseman.net> <87oakurjmv.wl-neal@walfield.org> <87a8wezyta.fsf@alice.fifthhorseman.net> <87mw0erio2.wl-neal@walfield.org> <87vbf2yefc.fsf@alice.fifthhorseman.net> <55712734.1090206@debian.org> Message-ID: <87r3pqy90m.fsf@alice.fifthhorseman.net> On Fri 2015-06-05 00:36:04 -0400, Michael Biebl wrote: > Am 05.06.2015 um 06:20 schrieb Daniel Kahn Gillmor: >> If gnome-keyring can Depend: pinentry-gnome3 (#787786), it should be >> able to build with --disable-gpg-agent. > > I just installed pinentry-gnome3 to give it a try, but apparently it > needs further configuration to be used by gnome-keyring. > Can you explain, how? You need to: * disable gnome-keyring's gpg-agent mechanism (either by rebuilding gnome-keyring with --disable-gpg-agent or by fiddling with /etc/xdg/autostart/gnome-keyring-gpg.desktop) , and * make sure the gnupg-agent package is installed, and that gpg-agent is running in your session (usually started by /etc/X11/Xsession.d/90gpg-agent for gpg-agent < 2.1, or automatically when needed for gpg2 and gpg-agent >= 2.1) Then any gpg or gpg2 process that wants to talk to the gpg-agent will find it. when gpg-agent wants a passphrase, it will invoke pinentry, which should now be provided by pinentry-gnome3. this uses gcr for prompting, and uses libsecret to (optionally) store passphrases with gnome-keyring. make sense? does this work for you? please let me know if you're having any trouble with it, i'm happy to help. --dkg From dkg at fifthhorseman.net Fri Jun 5 09:06:12 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 05 Jun 2015 03:06:12 -0400 Subject: Bug#760102: gnome keyring & gpg agent In-Reply-To: <5571443B.4080809@debian.org> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> <877fsbvwhr.wl-neal@walfield.org> <87k2vjylva.fsf@alice.fifthhorseman.net> <87oakurjmv.wl-neal@walfield.org> <87a8wezyta.fsf@alice.fifthhorseman.net> <87mw0erio2.wl-neal@walfield.org> <87vbf2yefc.fsf@alice.fifthhorseman.net> <55712734.1090206@debian.org> <87r3pqy90m.fsf@alice.fifthhorseman.net> <5571443B.4080809@debian.org> Message-ID: <87k2viy6qj.fsf@alice.fifthhorseman.net> On Fri 2015-06-05 02:39:55 -0400, Michael Biebl wrote: > That said, the package doesn't ship any translations apparently, and the > leading '_" in _Save, _OK and _Cancel look there is something broken > with i18n. The "_OK" and "_Cancel" work fine in gcr under xfce4, as noted here: http://thread.gmane.org/gmane.comp.encryption.gpg.devel/20133/focus=20139 ("_Save" is still broken on xfce4's gcr prompter, though). So I think the issue is with gcr on gnome3, not with pinentry. It looks to me like gcr_prompt_set_choice_label() doesn't support prefixed-underscore accelerator keys the way gcr_prompt_set_continue_label() and gcr_prompt_set_cancel_label() does on xfce4's gcr. Shall I open a bug in gcr about this? > I think before we consider switching to pinentry-gnome3, this should be > fixed and the package should provide a basic set of translations, at > least for the more popular languages. The translations of those strings actually ship in gpg-agent's source (gnupg2), which already has translations for most of the strings. The only new string in all of this is "Save in password manager", and gnupg has plausible translations for de at least there. (cs, da, jp, fr, nl, pl, ru, sv, uk, and zh_TW appear to have fuzzy-mapped "Save in password manager" to the "Cancel" string, which is probably a pretty bad outcome; i agree that part should be fixed) --dkg From Andreas.Stieger at gmx.de Fri Jun 5 09:47:04 2015 From: Andreas.Stieger at gmx.de (Andreas Stieger) Date: Fri, 5 Jun 2015 09:47:04 +0200 Subject: pinentry-gnome3: (libgcrypt): Cannot allocate memory In-Reply-To: <87382711h6.fsf@alice.fifthhorseman.net> References: <5570CBC9.9080500@gmx.de>, <87382711h6.fsf@alice.fifthhorseman.net> Message-ID: Hello, > > As I was packaging pinentry 0.9.3 with the new /usr/bin/pinentry-gnome3 > > You don't say what platform you're packaging this for, but please note > that pinentry-gnome3 is already available in debian unstable :) This is for SUSE/openSUSE. Keeping pinentry and all packages of the project current was never an issue, but obviously as binary vendors we would like to make sure this is working properly. > > $ /usr/bin/pinentry-gnome3 > > OK Your orders please > > getpin > > couldn't lock 16384 bytes of memory (libgcrypt): Cannot allocate memory > > ERR 83886179 canceled > > > > strace: > > > > mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) > > = 0x7efc75498000 > > mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, > > 0) = 0x7efc75494000 > > mlock(0x7efc75494000, 16384) = -1 ENOMEM (Cannot allocate memory) > > write(2, "couldn't lock 16384 bytes of mem"..., 72couldn't lock 16384 > > bytes of memory (libgcrypt): Cannot allocate memory > > > > This is on a system with a fairly standard limit: > > max locked memory (kbytes, -l) 64 > > > > Where would we start looking to debug and look for a possible solution? > > Do you think the gnome3 variant could receive a change to stay below a > > 64k lock limit? > > I can't reproduce this on debian: > > 0 dkg at alice:~$ ulimit -a | grep locked > max locked memory (kbytes, -l) 64 > 0 dkg at alice:~$ pinentry-gnome3 > OK Your orders please > getpin > D abc123 > OK > 0 dkg at alice:~$ > > > openSUSE tracks this in: > > https://bugzilla.opensuse.org/show_bug.cgi?id=933687 > > Sounds like this might be platform specific. What version of libgcrypt > are you running? This is occurring with libgcrypt 1.6.1 and 1.6.3, in this case on openSUSE 13.2. I have seen different behaviour in this area before. I will look into this some more, let's see if this can be debugged. If you know anything that would point me in the right direction that would be appreciated. Andreas From dkg at fifthhorseman.net Fri Jun 5 10:01:46 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 05 Jun 2015 04:01:46 -0400 Subject: Bug#760102: gnome keyring & gpg agent In-Reply-To: <55714AAA.1010100@michaelbiebl.de> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> <877fsbvwhr.wl-neal@walfield.org> <87k2vjylva.fsf@alice.fifthhorseman.net> <87oakurjmv.wl-neal@walfield.org> <87a8wezyta.fsf@alice.fifthhorseman.net> <87mw0erio2.wl-neal@walfield.org> <87vbf2yefc.fsf@alice.fifthhorseman.net> <55712734.1090206@debian.org> <87r3pqy90m.fsf@alice.fifthhorseman.net> <5571443B.4080809@debian.org> <55714AAA.1010100@michaelbiebl.de> Message-ID: <87eglqy45x.fsf@alice.fifthhorseman.net> [ dropping bug about gnome integration, Stef, and Neal from cc ] On Fri 2015-06-05 03:07:22 -0400, Michael Biebl wrote: > Am 05.06.2015 um 08:39 schrieb Michael Biebl: >> Am 05.06.2015 um 08:16 schrieb Daniel Kahn Gillmor: >>> make sense? does this work for you? please let me know if you're >>> having any trouble with it, i'm happy to help. >> >> Seems to work ok for unlocking the keys. Haven't tried the "Save in >> password manager" option yet, though. > > Daniel, on a related note, is it possible that gpg2 much slower then the > older gpg v1? It seems unlikely to me that this would be the case, but maybe it is. What version of gpg2 are you running? > It often happens here that Thunderbird (using enigmail) hangs for 30secs > and I have a gpg2 process at 100% CPU. I never saw that behaviour with > gpg v1. What version of thunderbird? what version of enigmail? When did you start to see this happen? --dkg From wk at gnupg.org Fri Jun 5 10:33:00 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 05 Jun 2015 10:33:00 +0200 Subject: Facing issue while installing GnuPG 2.0.27 on AIX 7.1 In-Reply-To: <0b421b1066e8482491ea4a06308d61b2@CO2PR42MB076.048d.mgd.msft.net> (manan navin mehta's message of "Thu, 4 Jun 2015 07:04:59 +0000") References: <0b421b1066e8482491ea4a06308d61b2@CO2PR42MB076.048d.mgd.msft.net> Message-ID: <87eglqftc3.fsf@vigenere.g10code.de> On Thu, 4 Jun 2015 09:04, manan.navin.mehta at accenture.com said: > Below are the OS level details: > > [cid:image006.png at 01D09EBE.3BD6EBA0] Sorry, I can't view the images as they are only available in the HTML rendered version. Please always transcript con5tents from screenshots so that it is possible to search for the content. Anyway, the attached config.log has all the details of your system. > But still we are facing Error as C compiler cannot create executables The configure run and the config.log show > configure:3875: checking whether the C compiler works > configure:3897: c99 -g conftest.c -lposix >&5 > ./configure[3899]: c99: not found Thus you don't have a compiler installed. You need to have a compiler and all related tools (the toolchain) to build software. > If you have 24X7 support help line number then kindly share the > details. This is a public mailing list. If you need commercial support please see http://gnupg.org/service.html . Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Jun 5 10:52:36 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 05 Jun 2015 10:52:36 +0200 Subject: Bug#760102: gnome keyring & gpg agent In-Reply-To: <87k2viy6qj.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 05 Jun 2015 03:06:12 -0400") References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> <877fsbvwhr.wl-neal@walfield.org> <87k2vjylva.fsf@alice.fifthhorseman.net> <87oakurjmv.wl-neal@walfield.org> <87a8wezyta.fsf@alice.fifthhorseman.net> <87mw0erio2.wl-neal@walfield.org> <87vbf2yefc.fsf@alice.fifthhorseman.net> <55712734.1090206@debian.org> <87r3pqy90m.fsf@alice.fifthhorseman.net> <5571443B.4080809@debian.org> <87k2viy6qj.fsf@alice.fifthhorseman.net> Message-ID: <87a8wefsff.fsf@vigenere.g10code.de> On Fri, 5 Jun 2015 09:06, dkg at fifthhorseman.net said: > (cs, da, jp, fr, nl, pl, ru, sv, uk, and zh_TW appear to have > fuzzy-mapped "Save in password manager" to the "Cancel" string, which is > probably a pretty bad outcome; i agree that part should be fixed) fuzzy marked entries are not used by gettest. Thus this is only a missing translation. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Jun 5 11:31:23 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 05 Jun 2015 11:31:23 +0200 Subject: Pinentry linking to libassuan? (was: Add inside-Emacs mode to GUI pinentry programs) In-Reply-To: <87r3prqk5x.wl-neal@walfield.org> (Neal H. Walfield's message of "Thu, 04 Jun 2015 22:43:22 +0200") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> Message-ID: <873826fqms.fsf_-_@vigenere.g10code.de> Hi, given that pinentry gets more and more complicated it does not anymore fulfill its original goal to be small enough to be easily audited. One of the main problem here has been the major changes to Gtk+ over the last decade. And now of Emacs socket code is added as well. Originally Pinentry should be mostly self-standing but today this is only true for the plain curses, tty and Windows versions. Most users however build one of the real GUI versions with all their large dependencies. The question is whether we should keep on using our much stripped down versions of libassuan and libgpg-error or switch over to use libassuan and libgpg-error directly. In fact, both libraries are required by GnuPG itself and also be any software using GPGME. Thus we can expect that such a change won't introduce any new platform problems. However, we should also link to Libgcrypt to make use of its secure memory code - if that is something we should keep on using. It would also be possible to do without and make sure that the passphrase is only stored at one place which we would manually clear as needed. Frankly, I think that the mlock-ed memory area is not useful anymore because it does not help against hibernation. To mitigate the swapping problem an encrypted swap partition is anyway much easier and safer. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ueno at gnu.org Fri Jun 5 12:28:44 2015 From: ueno at gnu.org (Daiki Ueno) Date: Fri, 05 Jun 2015 19:28:44 +0900 Subject: Pinentry linking to libassuan? In-Reply-To: <873826fqms.fsf_-_@vigenere.g10code.de> (Werner Koch's message of "Fri, 05 Jun 2015 11:31:23 +0200") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <873826fqms.fsf_-_@vigenere.g10code.de> Message-ID: <87lhfycuub.fsf-ueno@gnu.org> Werner Koch writes: > The question is whether we should keep on using our much stripped down > versions of libassuan and libgpg-error or switch over to use libassuan > and libgpg-error directly. In fact, both libraries are required by > GnuPG itself and also be any software using GPGME. Thus we can expect > that such a change won't introduce any new platform problems. I think using proper libassuan would make sense, for the Emacs Pinentry at least. Given the easiness of writing an Assuan server in Elisp (with `make-network-process'), what really needed is for Pinentry protocol messages to be directed to the socket which Emacs listens. If we can use assuan_socket_connect (not available in the stripped down version) for that, the Pinentry-side code could eliminate all the complex stuff, including escaping and buffering in pinentry/pinentry-emacs.c. (Thanks Neal for the review, will update the patch soon, in any case.) Regards, -- Daiki Ueno From neal at walfield.org Fri Jun 5 15:55:22 2015 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 05 Jun 2015 15:55:22 +0200 Subject: gnome keyring & gpg agent In-Reply-To: <5571A616.9020508@gnome.org> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> <877fsbvwhr.wl-neal@walfield.org> <87k2vjylva.fsf@alice.fifthhorseman.net> <87oakurjmv.wl-neal@walfield.org> <87a8wezyta.fsf@alice.fifthhorseman.net> <87mw0erio2.wl-neal@walfield.org> <87vbf2yefc.fsf@alice.fifthhorseman.net> <5571A616.9020508@gnome.org> Message-ID: <87k2viqmyd.wl-neal@walfield.org> Hi Stef, At Fri, 05 Jun 2015 15:37:26 +0200, Stef Walter wrote: > Confirming that I'll be ready to remove the code once the new pinentry > makes it into a release. Removing code always makes me smile :) A new pinentry with the code has already been released (0.9.3). :) Neal From dkg at fifthhorseman.net Fri Jun 5 16:01:03 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 05 Jun 2015 10:01:03 -0400 Subject: gnupg2: occasionally runs for 30 seconds at 100% CPU [was: Re: Bug#760102: gnome keyring & gpg agent] In-Reply-To: <55715ADA.8070300@debian.org> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> <877fsbvwhr.wl-neal@walfield.org> <87k2vjylva.fsf@alice.fifthhorseman.net> <87oakurjmv.wl-neal@walfield.org> <87a8wezyta.fsf@alice.fifthhorseman.net> <87mw0erio2.wl-neal@walfield.org> <87vbf2yefc.fsf@alice.fifthhorseman.net> <55712734.1090206@debian.org> <87r3pqy90m.fsf@alice.fifthhorseman.net> <5571443B.4080809@debian.org> <55714AAA.1010100@michaelbiebl.de> <87eglqy45x.fsf@alice.fifthhorseman.net> <55715ADA.8070300@debian.org> Message-ID: <87bnguxnj4.fsf@alice.fifthhorseman.net> Hi Michael-- On Fri 2015-06-05 04:16:26 -0400, Michael Biebl wrote: > Am 05.06.2015 um 10:01 schrieb Daniel Kahn Gillmor: >> On Fri 2015-06-05 03:07:22 -0400, Michael Biebl wrote: >>> Daniel, on a related note, is it possible that gpg2 much slower then the >>> older gpg v1? >> >> It seems unlikely to me that this would be the case, but maybe it is. >> What version of gpg2 are you running? > > 2.0.28-1 thanks, can you give me a sense of the size of your public keyring and the number of elements in it? gpg2 --list-keys --with-colons | cut -f1 -d: | sort | uniq -c gpg2 --list-secret-keys --with-colons | cut -f1 -d: | sort | uniq -c and can you tell me whether you have no-auto-check-trustdb in ~/.gnupg/gpg.conf ? >>> It often happens here that Thunderbird (using enigmail) hangs for 30secs >>> and I have a gpg2 process at 100% CPU. I never saw that behaviour with >>> gpg v1. >> >> What version of thunderbird? what version of enigmail? > > Thunderbird 31.7.0, Enigmail 1.8.2 Thanks. The next time this hang happens, can you use ps to figure out what the exact command line is that is running, and report it here? This might be an enigmail issue, so if we can find anything to improve there, that would be great. (i'm happy to forward the bug to enigmail upstream if we track it down) Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From loweel at gmx.de Fri Jun 5 16:39:33 2015 From: loweel at gmx.de (Low Eel) Date: Fri, 5 Jun 2015 16:39:33 +0200 Subject: Golang "OpenPGP" implementation... Message-ID: Hi All ? I hope to don't be OT , and I have a question about OpenPGP libraries. ? As you probably (?) know, Google launched their language, golang, and it ships with something they call "OpenPGP" libraries: ? https://godoc.org/golang.org/x/crypto/openpgp ? I know because I am going to write some server using GPG and I was looking for some library. Now the name "OpenPGP" Google is using seems promising, but. - Are that libraries a port/endorsed/written together with the gpg dev? - Does anyone knows if they are 100% compatible or a "google flavour"? thanks in advance, ? LowEel ? -- LowEel ? From neal at walfield.org Fri Jun 5 18:06:09 2015 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 05 Jun 2015 18:06:09 +0200 Subject: Use of composed characters and altgr utf-8 symbols on passwords. In-Reply-To: References: Message-ID: <87iob2qgwe.wl-neal@walfield.org> Hi Pedro, Reviewing the mailing list archive, I saw that your issue got no responses. I've open an issue on the bug tracker so that it is not lost [1]. If you have any additional information, please provide it. I wonder if the problem is an encoding issue. Are you using the same encoding on both computers? Thanks, :) Neal [1] https://bugs.gnupg.org/gnupg/issue1998 At Thu, 30 Apr 2015 16:37:21 +0100, Pedro Coelho wrote: > I have an issue that I've detected today and searched the entire > mailing list and did not find an answer. > I hope I'm not wasting anyone's time. > I use OpenSuSE 13.1 64bits as my main distribution on Linux. > I encrypt on that same computer some files and my passphrase always > used both composed characters as well as altgr symbols. > Meaning utf-8 characters. > > In this particular case I used symmetric encryption on a file, like > this: > > gpg -c --s2k-mode 3 --s2k-count 65011712 --s2k-cipher-algo AES256 - > -cert-digest-algo SHA512 file.txt > > All is ok to decrypt the file when I use OpenSuSE KDE desktop even on > other computers I have. > What I have noticed tho is a strange behavior that should be of some > concern. > When trying to decrypt the exact same file on Other distros I always > get the Bad Key message! > Once the Same file is encrypted with a passphrase with no composed > characters And No altgr characters everything is ok! the file is > decrypted with no problem. > I've done some testing and used Centos 6 CLI mode only, Centos 7 with > x, Ubuntu (several versions) , Kali Linux, Tails ... you name it. > > Worst. > On my computer I switched to a new session with LXDE as the desktop > and ... the result was the same! > The file I could decrypt in my KDE session I was not able to decrypt > on the same computer o on the LXDE session. > Same old bad key error. > > Of course this may be realted to the way those chars are "interpreted" > between different environments. Or could this be a gpg bug? > > Also I must alert you good folks that this is for me of Paramount > importance since increasing the character space of a passwrod is > Hugely important to increase the security. > It's also a big big hurdle if I can not have inter-environment > compatibility. > It really really is annoying ... and higly curtails a lot of the power > contained in gnupg .. > > Can anyone try to explain why this happening ? > > Best regards, > Pedro > > [2 ] > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From neal at walfield.org Fri Jun 5 18:46:19 2015 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 05 Jun 2015 18:46:19 +0200 Subject: gpg --check-trustdb returns data on stdout when --verbose --verbose is present? In-Reply-To: <87twvombpu.fsf@alice.fifthhorseman.net> References: <87twvombpu.fsf@alice.fifthhorseman.net> Message-ID: <87h9qmqf1g.wl-neal@walfield.org> Hi, Daniel, I noticed that this issue didn't get any responses. To prevent it from getting lost, I've open a new issue on the bug tracker: https://bugs.gnupg.org/gnupg/issue1999 Thanks, :) Neal At Thu, 07 May 2015 15:25:33 -0400, Daniel Kahn Gillmor wrote: > > gpg --check-trustdb normally sends no data to stdout, even if --verbose > is specfieid once. however, when i add --verbose --verbose it sends a > lot of data to stdout, in particular, lines like this: > > 0:F2AD85AC1E42B367:U:::f:::Werner Koch : > [...] > > I believe this also happens when the trustdb is automatically checked > (though i'm not sure how to force that to happen to test it better). > > sending additional data to stdout during an automatic check (or even > during --check-trustdb when it's not otherwise expected) seems > problematic for anyone using the tool programmatically. From jim at meyering.net Fri Jun 5 17:49:17 2015 From: jim at meyering.net (Jim Meyering) Date: Fri, 5 Jun 2015 16:49:17 +0100 Subject: [PATCH] configure.ac: improve check for clock_gettime library Message-ID: Hello, I noticed the clock_gettime-vs-librt problem with npth-1.2 on a CentOS6 system and fixed it, but then noticed that the first post-release patch also made a change on that front. I have rebased on top of that. I have attached an additional patch: -------------- next part -------------- A non-text attachment was scrubbed... Name: npth-configure-vs-clock_gettime.patch Type: application/octet-stream Size: 2508 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Jun 5 19:19:45 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 05 Jun 2015 13:19:45 -0400 Subject: Bug#760102: gnome keyring & gpg agent In-Reply-To: <5571D6AF.1040306@debian.org> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> <877fsbvwhr.wl-neal@walfield.org> <87k2vjylva.fsf@alice.fifthhorseman.net> <87oakurjmv.wl-neal@walfield.org> <87a8wezyta.fsf@alice.fifthhorseman.net> <87mw0erio2.wl-neal@walfield.org> <87vbf2yefc.fsf@alice.fifthhorseman.net> <5571A616.9020508@gnome.org> <87k2viqmyd.wl-neal@walfield.org> <5571D6AF.1040306@debian.org> Message-ID: <87twumvzri.fsf@alice.fifthhorseman.net> On Fri 2015-06-05 13:04:47 -0400, Michael Biebl wrote: > Just to be clear here: this new pinentry-gnome3 and gnupg-agent, do they > both work with either gnupg and gnupg2? Yes, they both work with either gnupg or gnupg2. > @Joss: related to that, I notice, that you added a versioned dependency > on gnupg (>= 1.4.7) to the seahorse package in 2008. > Is this still valid today? Or should we either drop that dependency or > replace it with something like Depends: gnupg2 | gnupg (>= 1.4.7) > > I have no strong preference which one we pick as default, as long as it > works properly. So I'd leave the judgement to those more familiar with > the advantages/disadvantags of gnupg vs gnupg2 seahorse links to libgpgme11, which itself depends on gnupg2 (this is the preferred backend for GnuPG upstream). Given that 1.4.7 is older than oldoldstable, you ought to be able to drop the explicit gnupg dependency entirely from seahorse, iiuc. --dkg From dkg at fifthhorseman.net Fri Jun 5 19:34:22 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 05 Jun 2015 13:34:22 -0400 Subject: gpg --check-trustdb returns data on stdout when --verbose --verbose is present? In-Reply-To: <87h9qmqf1g.wl-neal@walfield.org> References: <87twvombpu.fsf@alice.fifthhorseman.net> <87h9qmqf1g.wl-neal@walfield.org> Message-ID: <87r3pqvz35.fsf@alice.fifthhorseman.net> On Fri 2015-06-05 12:46:19 -0400, Neal H. Walfield wrote: > I noticed that this issue didn't get any responses. To prevent it > from getting lost, I've open a new issue on the bug tracker: > > https://bugs.gnupg.org/gnupg/issue1999 Thanks, Neal. I think it's fixed in 2.1.4 already. i've followed up on the ticket there with backported patches to STABLE-BRANCH-1-4 and STABLE-BRANCH-2-0, which end up being very straightforward git cherry-picks of b03a2647299a6c8764a2574590cbaccdff9e497d. Regards, --dkg From neal at walfield.org Fri Jun 5 19:56:20 2015 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 05 Jun 2015 19:56:20 +0200 Subject: gpg-agent features of loopback-pinentry mode, preset_passphrase In-Reply-To: <1432032302-353352.688746913.ft4JAiSDp000769@rs146.luxsci.com> References: <554C2094.20904@fsij.org> <874mnnlqxn.fsf@alice.fifthhorseman.net> <554C309F.5010706@fsij.org> <871tiegpoh.fsf@vigenere.g10code.de> <1432032302-353352.688746913.ft4JAiSDp000769@rs146.luxsci.com> Message-ID: <87fv66qbsr.wl-neal@walfield.org> At Tue, 19 May 2015 06:44:27 -0400, Ben Kibbey wrote: > > While looking at the code for --gen-key I noticed that gpg-agent isn't > used for getting the passphrase. Is it possible to do this? Or would > that make creating the public key impossible? I ask because --command-fd > isn't considered during --gen-key making pinentry-mode=loopback broken. > > I have patches for fixing --command-fd (bjk/passphrase-inquire branches > of gpgme and gnupg) but those still don't use gpg-agent during > --gen-key. Maybe there is a reason why --gen-key isn't supposed to work > while using pinentry-mode=loopback? Since you haven't gotten a response, I've create an issue in the bug tracker. https://bugs.gnupg.org/gnupg/issue2001 Thanks, :) Neal From andreas.stieger at gmx.de Fri Jun 5 19:20:56 2015 From: andreas.stieger at gmx.de (Andreas Stieger) Date: Fri, 05 Jun 2015 19:20:56 +0200 Subject: pinentry-gnome3: (libgcrypt): Cannot allocate memory In-Reply-To: <5570CBC9.9080500@gmx.de> References: <5570CBC9.9080500@gmx.de> Message-ID: <5571DA78.2090107@gmx.de> Hello, On 05/06/15 00:06, Andreas Stieger wrote: > As I was packaging pinentry 0.9.3 with the new /usr/bin/pinentry-gnome3 > I noticed the following: > > $ /usr/bin/pinentry-gnome3 > OK Your orders please > getpin > couldn't lock 16384 bytes of memory (libgcrypt): Cannot allocate memory > ERR 83886179 canceled > > strace: > > mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) > = 0x7efc75498000 > mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, > 0) = 0x7efc75494000 > mlock(0x7efc75494000, 16384) = -1 ENOMEM (Cannot allocate memory) > write(2, "couldn't lock 16384 bytes of mem"..., 72couldn't lock 16384 > bytes of memory (libgcrypt): Cannot allocate memory > > This is on a system with a fairly standard limit: > max locked memory (kbytes, -l) 64 > > Where would we start looking to debug and look for a possible solution? > Do you think the gnome3 variant could receive a change to stay below a > 64k lock limit? tl;dnr: DEFAULT_POOLSIZE was set to 64k, leaving no more for mlock in the -gnome3 UI with standard limits. Debugged this... When running pinentry-gnome3, mlock called twice, first via pinentry_init -> secmem_init $ gdb pinentry-gnome3 done. (gdb) catch syscall mlock Catchpoint 1 (syscall 'mlock' [149]) (gdb) run Starting program: /usr/bin/pinentry-gnome3 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Catchpoint 1 (call to syscall mlock), 0x00007ffff63a9307 in mlock () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff63a9307 in mlock () at /lib64/libc.so.6 #1 0x0000000000409d14 in secmem_init (n=65536, p=0x7ffff7fe7000) at secmem.c:167 #2 0x0000000000409d14 in secmem_init (n=65536) at secmem.c:246 #3 0x0000000000409d14 in secmem_init (n=65536, n at entry=1) at secmem.c:306 #4 0x00000000004052cf in pinentry_init (pgmname=pgmname at entry=0x40c2e7 "pinentry-gnome3") at pinentry.c:512 #5 0x0000000000403196 in main (argc=1, argv=0x7fffffffdce8) at pinentry-gnome3.c:254 (gdb) (gdb) c Continuing. Catchpoint 1 (returned from syscall mlock), 0x00007ffff63a9307 in mlock () from /lib64/libc.so.6 (gdb) c Continuing. [New Thread 0x7fffec027700 (LWP 8640)] OK Your orders please getpin [New Thread 0x7fffeb826700 (LWP 8641)] And then again with via the GUI in -gnome3. Catchpoint 1 (call to syscall mlock), 0x00007ffff63a9307 in mlock () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff63a9307 in mlock () at /lib64/libc.so.6 #1 0x00007ffff6b41865 in () at /usr/lib64/libgcr-base-3.so.1 #2 0x00007ffff5ff0f29 in () at /usr/lib64/libgcrypt.so.20 #3 0x00007ffff5ff22c3 in () at /usr/lib64/libgcrypt.so.20 #4 0x00007ffff608c71b in () at /usr/lib64/libgcrypt.so.20 #5 0x00007ffff608c8d7 in () at /usr/lib64/libgcrypt.so.20 #6 0x00007ffff6b3c0ca in () at /usr/lib64/libgcr-base-3.so.1 #7 0x00007ffff6b148b6 in () at /usr/lib64/libgcr-base-3.so.1 #8 0x00007ffff6b151f8 in gcr_secret_exchange_receive () at /usr/lib64/libgcr-base-3.so.1 #9 0x00007ffff6b186d9 in () at /usr/lib64/libgcr-base-3.so.1 #10 0x00007ffff5d3a7e1 in () at /usr/lib64/libgio-2.0.so.0 #11 0x00007ffff76768e5 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0 #12 0x00007ffff7676c48 in () at /usr/lib64/libglib-2.0.so.0 #13 0x00007ffff7676f0a in g_main_loop_run () at /usr/lib64/libglib-2.0.so.0 #14 0x00007ffff6b17315 in () at /usr/lib64/libgcr-base-3.so.1 #15 0x00007ffff5ccd2ba in g_initable_new_valist () at /usr/lib64/libgio-2.0.so.0 #16 0x00007ffff5ccd39c in g_initable_new () at /usr/lib64/libgio-2.0.so.0 #17 0x00007ffff6b191a1 in gcr_system_prompt_open_for_prompter () at /usr/lib64/libgcr-base-3.so.1 #18 0x00000000004033b2 in create_prompt (pe=pe at entry=0x611ae0 , confirm=confirm at entry=0) at pinentry-gnome3.c:80 #19 0x00000000004035f8 in gnome3_cmd_handler (pe=0x611ae0 ) at pinentry-gnome3.c:176 #20 0x0000000000404f78 in cmd_getpin (ctx=0x7ffff7fe7008, line=) at pinentry.c:1168 #21 0x0000000000408eea in process_request (linelen=, line=0x7ffff7fe7056 "", ctx=0x7ffff7fe7008) at assuan-handler.c:435 #22 0x0000000000408eea in process_request (ctx=0x7ffff7fe7008) at assuan-handler.c:458 #23 0x0000000000409470 in assuan_process (ctx=0x7ffff7fe7008) at assuan-handler.c:526 #24 0x000000000040579d in pinentry_loop2 (infd=infd at entry=0, outfd=outfd at entry=1) at pinentry.c:1426 #25 0x000000000040585c in pinentry_loop () at pinentry.c:1446 #26 0x00000000004031c4 in main (argc=1, argv=0x7fffffffdce8) at pinentry-gnome3.c:267 (gdb) Of course an initial mlock call of 64k will exhaust the lock limit, leaving none for the second. The 64k was due to a local change of DEFAULT_POOLSIZE to address a problem that has since vanished. Local problem. Andreas From neal at walfield.org Fri Jun 5 20:24:01 2015 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 05 Jun 2015 20:24:01 +0200 Subject: gnupg 2.1.4 fails to build with --disable-gpgsm In-Reply-To: <5554AC7A.5040101@ipsumj.de> References: <5554AC7A.5040101@ipsumj.de> Message-ID: <87eglqqaim.wl-neal@walfield.org> Hi, I just tried this on Debian Jessie with the latest version of git. The build completed without an error. If you are still getting this error, please provide some more details about your configuration. Thanks, :) Neal GnuPG v2.1.5-beta6 has been configured as follows: Revision: 3a93054 (14995) Platform: GNU/Linux (x86_64-unknown-linux-gnu) OpenPGP: yes S/MIME: no Agent: yes Smartcard: yes (without internal CCID driver) G13: yes Dirmngr: yes Gpgtar: no Protect tool: (default) LDAP wrapper: (default) Default agent: (default) Default pinentry: (default) Default scdaemon: (default) Default dirmngr: (default) Dirmngr auto start: yes Readline support: yes LDAP support: yes DNS SRV support: yes TLS support: gnutls At Thu, 14 May 2015 16:08:58 +0200, HW42 wrote: > > Hi, > > when I try to build gnupg 2.1.4 with --disable-gpgsm the build fails. > > $ ./configure --disable-gpgsm --disable-gpgtar > [ ... ] > GnuPG v2.1.4 has been configured as follows: > > Revision: a67ead6 (42622) > Platform: GNU/Linux (x86_64-unknown-linux-gnu) > > OpenPGP: yes > S/MIME: no > Agent: yes > Smartcard: yes (without internal CCID driver) > G13: yes > Dirmngr: yes > Gpgtar: no > > Protect tool: (default) > LDAP wrapper: (default) > Default agent: (default) > Default pinentry: (default) > Default scdaemon: (default) > Default dirmngr: (default) > > Dirmngr auto start: yes > Readline support: yes > LDAP support: yes > DNS SRV support: yes > TLS support: gnutls > > $ make > [ ... ] > mv -f .deps/getkey.Tpo .deps/getkey.Po > gcc -DHAVE_CONFIG_H -I. -I.. -I../common > -DLOCALEDIR=\"/usr/local/share/locale\" > -DGNUPG_BINDIR="\"/usr/local/bin\"" > -DGNUPG_LIBEXECDIR="\"/usr/local/libexec\"" > -DGNUPG_LIBDIR="\"/usr/local/lib/gnupg\"" > -DGNUPG_DATADIR="\"/usr/local/share/gnupg\"" > -DGNUPG_SYSCONFDIR="\"/usr/local/etc/gnupg\"" > -DGNUPG_LOCALSTATEDIR="\"/usr/local/var\"" > -I/tmp/b/libgcrypt-1.6.3/build/include > -I/tmp/b/libgpg-error-1.19/build/include > -I/tmp/b/libassuan-2.2.0/build/include > -I/tmp/b/libgpg-error-1.19/build/include > -I/tmp/b/libgpg-error-1.19/build/include -Wall -Wno-pointer-sign > -Wpointer-arith -MT keydb.o -MD -MP -MF .deps/keydb.Tpo -c -o keydb.o > keydb.c > In file included from keydb.c:37:0: > ../kbx/keybox.h:36:19: fatal error: ksba.h: No such file or directory > # include > ^ > compilation terminated. > Makefile:775: recipe for target 'keydb.o' failed > make[2]: *** [keydb.o] Error 1 > make[2]: Leaving directory '/tmp/b/gnupg-2.1.4/g10' > Makefile:576: recipe for target 'all-recursive' failed > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory '/tmp/b/gnupg-2.1.4' > Makefile:495: recipe for target 'all' failed > make: *** [all] Error 2 > $ export CFLAGS="$CFLAGS $(ksba-config --cflags)" # workaroud 1 > $ ./configure --disable-gpgsm --disable-gpgtar > [ ... ] > $ make > [ ... ] > make[2]: *** No rule to make target '../kbx/libkeybox.a', needed by > 'gpg2'. Stop. > make[2]: Leaving directory '/tmp/b/gnupg-2.1.4/g10' > Makefile:576: recipe for target 'all-recursive' failed > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory '/tmp/b/gnupg-2.1.4' > Makefile:495: recipe for target 'all' failed > make: *** [all] Error 2 > $ make kbx=kbx # workaround 2 > [ ... ] > $ # successful build > > Without the --disable-gpgtar there is another missing include error. > > HW42 > From wk at gnupg.org Fri Jun 5 20:52:12 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 05 Jun 2015 20:52:12 +0200 Subject: gnome keyring & gpg agent In-Reply-To: <87k2viqmyd.wl-neal@walfield.org> (Neal H. Walfield's message of "Fri, 05 Jun 2015 15:55:22 +0200") References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> <877fsbvwhr.wl-neal@walfield.org> <87k2vjylva.fsf@alice.fifthhorseman.net> <87oakurjmv.wl-neal@walfield.org> <87a8wezyta.fsf@alice.fifthhorseman.net> <87mw0erio2.wl-neal@walfield.org> <87vbf2yefc.fsf@alice.fifthhorseman.net> <5571A616.9020508@gnome.org> <87k2viqmyd.wl-neal@walfield.org> Message-ID: <877fridm3n.fsf@vigenere.g10code.de> On Fri, 5 Jun 2015 15:55, neal at walfield.org said: > A new pinentry with the code has already been released (0.9.3). but you better get 0.9.4. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Fri Jun 5 20:57:40 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 05 Jun 2015 14:57:40 -0400 Subject: Bug#760102: gnome keyring & gpg agent In-Reply-To: <5571DB96.1020007@debian.org> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> <877fsbvwhr.wl-neal@walfield.org> <87k2vjylva.fsf@alice.fifthhorseman.net> <87oakurjmv.wl-neal@walfield.org> <87a8wezyta.fsf@alice.fifthhorseman.net> <87mw0erio2.wl-neal@walfield.org> <87vbf2yefc.fsf@alice.fifthhorseman.net> <5571A616.9020508@gnome.org> <87k2viqmyd.wl-neal@walfield.org> <5571D6AF.1040306@debian.org> <87twumvzri.fsf@alice.fifthhorseman.net> <5571DB96.1020007@debian.org> Message-ID: <87lhfyvv8b.fsf@alice.fifthhorseman.net> Control: clone 760102 -1 Control: reassign -1 seahorse Control: tags -1 + patch Control: retitle -1 build seahorse compatible with gpg2 On Fri 2015-06-05 13:25:42 -0400, Michael Biebl wrote: > Am 05.06.2015 um 19:19 schrieb Daniel Kahn Gillmor: >> Given that 1.4.7 is older than oldoldstable, you ought to be able to >> drop the explicit gnupg dependency entirely from seahorse, iiuc. > > Well, assuming that seahorse does work properly with gnupg2. > That's basically my question. The seahorse source code seems to actually behave completely differently depending on whether it is built with modern versions of any branch (meaning: gpg >= 1.4.10, or gpg2 >= 2.0.12) versus older versions. (see pgp/seahorse-gpgme-key-op.h). :( This is not great engineering practice, because the version built against isn't guaranteed to match the version that's running. That said, even oldoldstable builds and runs "modern versions" by this metric. I just tested seahorse on a minimal-ish unstable gnome install, where i did "dpkg --force-depend --purge gnupg". Unfortunately, it looks like seahorse embeds the string "gpg" in it, so it's looking for /usr/bin/gpg. Running seahorse in this configuration produces lots of errors of this form: operation-Message: couldn't initialize gnupg properly: Invalid crypto engine The attached patch should resolve things for future versions of seahorse, though, both on build-time detection and on runtime flexibility. (the attached patch touches both ./configure.ac and ./configure -- since the package appears to be doing autoreconf, maybe the modifications to ./configure are unnecessary) The only failures i'm now running into with seahorse like this are failures due to gcr_importer hard-coding paths to gpg as well, so those are bugs i'll file separately.. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-avoid-deps-on-a-certain-version-of-gpg.patch Type: text/x-diff Size: 3968 bytes Desc: avoid dependencies on a certain version of gpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From hw42 at ipsumj.de Fri Jun 5 23:58:18 2015 From: hw42 at ipsumj.de (HW42) Date: Fri, 05 Jun 2015 23:58:18 +0200 Subject: gnupg 2.1.4 fails to build with --disable-gpgsm In-Reply-To: <87eglqqaim.wl-neal@walfield.org> References: <5554AC7A.5040101@ipsumj.de> <87eglqqaim.wl-neal@walfield.org> Message-ID: <55721B7A.3010409@ipsumj.de> Hi Neal, Werner already responded on 2015-05-15 that this will be fixed in 2.1.5 - but seems to forgot to CC the list. Thank you. HW42 Neal H. Walfield: > Hi, > > I just tried this on Debian Jessie with the latest version of git. > The build completed without an error. > > If you are still getting this error, please provide some more details > about your configuration. > > Thanks, > > :) Neal > > > GnuPG v2.1.5-beta6 has been configured as follows: > > Revision: 3a93054 (14995) > Platform: GNU/Linux (x86_64-unknown-linux-gnu) > > OpenPGP: yes > S/MIME: no > Agent: yes > Smartcard: yes (without internal CCID driver) > G13: yes > Dirmngr: yes > Gpgtar: no > > Protect tool: (default) > LDAP wrapper: (default) > Default agent: (default) > Default pinentry: (default) > Default scdaemon: (default) > Default dirmngr: (default) > > Dirmngr auto start: yes > Readline support: yes > LDAP support: yes > DNS SRV support: yes > TLS support: gnutls > > At Thu, 14 May 2015 16:08:58 +0200, > HW42 wrote: >> >> Hi, >> >> when I try to build gnupg 2.1.4 with --disable-gpgsm the build fails. >> >> $ ./configure --disable-gpgsm --disable-gpgtar >> [ ... ] >> GnuPG v2.1.4 has been configured as follows: >> >> Revision: a67ead6 (42622) >> Platform: GNU/Linux (x86_64-unknown-linux-gnu) >> >> OpenPGP: yes >> S/MIME: no >> Agent: yes >> Smartcard: yes (without internal CCID driver) >> G13: yes >> Dirmngr: yes >> Gpgtar: no >> >> Protect tool: (default) >> LDAP wrapper: (default) >> Default agent: (default) >> Default pinentry: (default) >> Default scdaemon: (default) >> Default dirmngr: (default) >> >> Dirmngr auto start: yes >> Readline support: yes >> LDAP support: yes >> DNS SRV support: yes >> TLS support: gnutls >> >> $ make >> [ ... ] >> mv -f .deps/getkey.Tpo .deps/getkey.Po >> gcc -DHAVE_CONFIG_H -I. -I.. -I../common >> -DLOCALEDIR=\"/usr/local/share/locale\" >> -DGNUPG_BINDIR="\"/usr/local/bin\"" >> -DGNUPG_LIBEXECDIR="\"/usr/local/libexec\"" >> -DGNUPG_LIBDIR="\"/usr/local/lib/gnupg\"" >> -DGNUPG_DATADIR="\"/usr/local/share/gnupg\"" >> -DGNUPG_SYSCONFDIR="\"/usr/local/etc/gnupg\"" >> -DGNUPG_LOCALSTATEDIR="\"/usr/local/var\"" >> -I/tmp/b/libgcrypt-1.6.3/build/include >> -I/tmp/b/libgpg-error-1.19/build/include >> -I/tmp/b/libassuan-2.2.0/build/include >> -I/tmp/b/libgpg-error-1.19/build/include >> -I/tmp/b/libgpg-error-1.19/build/include -Wall -Wno-pointer-sign >> -Wpointer-arith -MT keydb.o -MD -MP -MF .deps/keydb.Tpo -c -o keydb.o >> keydb.c >> In file included from keydb.c:37:0: >> ../kbx/keybox.h:36:19: fatal error: ksba.h: No such file or directory >> # include >> ^ >> compilation terminated. >> Makefile:775: recipe for target 'keydb.o' failed >> make[2]: *** [keydb.o] Error 1 >> make[2]: Leaving directory '/tmp/b/gnupg-2.1.4/g10' >> Makefile:576: recipe for target 'all-recursive' failed >> make[1]: *** [all-recursive] Error 1 >> make[1]: Leaving directory '/tmp/b/gnupg-2.1.4' >> Makefile:495: recipe for target 'all' failed >> make: *** [all] Error 2 >> $ export CFLAGS="$CFLAGS $(ksba-config --cflags)" # workaroud 1 >> $ ./configure --disable-gpgsm --disable-gpgtar >> [ ... ] >> $ make >> [ ... ] >> make[2]: *** No rule to make target '../kbx/libkeybox.a', needed by >> 'gpg2'. Stop. >> make[2]: Leaving directory '/tmp/b/gnupg-2.1.4/g10' >> Makefile:576: recipe for target 'all-recursive' failed >> make[1]: *** [all-recursive] Error 1 >> make[1]: Leaving directory '/tmp/b/gnupg-2.1.4' >> Makefile:495: recipe for target 'all' failed >> make: *** [all] Error 2 >> $ make kbx=kbx # workaround 2 >> [ ... ] >> $ # successful build >> >> Without the --disable-gpgtar there is another missing include error. >> >> HW42 >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Sat Jun 6 00:48:57 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 05 Jun 2015 18:48:57 -0400 Subject: Pinentry linking to libassuan? (was: Add inside-Emacs mode to GUI pinentry programs) In-Reply-To: <873826fqms.fsf_-_@vigenere.g10code.de> References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <873826fqms.fsf_-_@vigenere.g10code.de> Message-ID: <87r3ppvkiu.fsf@alice.fifthhorseman.net> Hi there-- On Fri 2015-06-05 05:31:23 -0400, Werner Koch wrote: > Originally Pinentry should be mostly self-standing but today this is > only true for the plain curses, tty and Windows versions. Most users > however build one of the real GUI versions with all their large > dependencies. For users of graphical environments, this seems likely to be the right choice. > The question is whether we should keep on using our much stripped down > versions of libassuan and libgpg-error or switch over to use libassuan > and libgpg-error directly. In fact, both libraries are required by > GnuPG itself and also be any software using GPGME. Thus we can expect > that such a change won't introduce any new platform problems. I'd be happy to switch to libassuan + gcrypt in those environments, since those libraries are likely already on the system (and pinentry is really usually expected to be invoked by gpg-agent, which itself depends on libassuan and gcrypt). That said, I'd like to try to minimize the number of dependencies for the non-graphical clients in normal circumstances. I've filed: https://bugs.debian.org/787883 to track doing that in debian. Is there a way to make a single build of the pinentry tree, but to only enable libsecret for gtk2, qt4, and gnome3 and leave it out for tty and curses? if not, i guess i can just ./configure twice and build different variants in the different configurations. > However, we should also link to Libgcrypt to make use of its secure > memory code - if that is something we should keep on using. It would > also be possible to do without and make sure that the passphrase is only > stored at one place which we would manually clear as needed. Frankly, I > think that the mlock-ed memory area is not useful anymore because it > does not help against hibernation. To mitigate the swapping problem an > encrypted swap partition is anyway much easier and safer. Doing away with mlocking entirely would certainly simplify the pinentry codebase. --dkg From neal at walfield.org Sat Jun 6 01:32:48 2015 From: neal at walfield.org (Neal H. Walfield) Date: Sat, 06 Jun 2015 01:32:48 +0200 Subject: Pinentry linking to libassuan? (was: Add inside-Emacs mode to GUI pinentry programs) In-Reply-To: <87r3ppvkiu.fsf@alice.fifthhorseman.net> References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <873826fqms.fsf_-_@vigenere.g10code.de> <87r3ppvkiu.fsf@alice.fifthhorseman.net> Message-ID: <87bngtrasf.wl-neal@walfield.org> At Fri, 05 Jun 2015 18:48:57 -0400, Daniel Kahn Gillmor wrote: > Is there a way to make a single build of > the pinentry tree, but to only enable libsecret for gtk2, qt4, and > gnome3 and leave it out for tty and curses? if not, i guess i can just > ./configure twice and build different variants in the different > configurations. Enabling libsecret on a per-pinentry basis is possible, but it would add a fair amount of complexity to the build system. If configuring twice is easy, then let's do that. Neal From neal at walfield.org Sat Jun 6 03:02:41 2015 From: neal at walfield.org (Neal H. Walfield) Date: Sat, 06 Jun 2015 03:02:41 +0200 Subject: [PATCH] dirmngr_ldap: support ldap secure connection(ldaps) In-Reply-To: <555C8BAF.1060202@digiflak.com> References: <555C8BAF.1060202@digiflak.com> Message-ID: <87a8wdr6mm.wl-neal@walfield.org> Hi, I'm having trouble applying this patch. It looks like the whitespace got mangled in transit. Can you please resend the patch or provide a tree that I can pull from? Thanks, Neal At Wed, 20 May 2015 16:27:11 +0300, Dmitry Falko wrote: > > Hello! > > I encountered a problem connecting to the LDAP server via TLS and > wrote a small patch, send it as is. > > * dirmngr.h (ldap_server_s): add schema field > * dirmngr_ldap.c (fetch_ldap): ldaps support > * ldap.c (make_url, start_cert_fetch_ldap): add schema > * ldapserver.c (ldapserver_parse_one): parse schema > * server.c (lookup_cert_by_pattern): additional log info > > dirmngr_ldap can retrieve certificates from LDAP server > by TLS(using ldaps protocol). Protocol can be set in > dirmngr_ldapserver.conf: > hostname:port:username:password:base_dn:schema > If not set use ldap.By default dirmngr_ldap use > /etc/ssl/CA(dirmngr_ldap.c CA_CERT_DEFAULT) CA certificate, > user can set DIRMNGR_LDAP_CACERT env variable to > override this value. > --- > dirmngr/dirmngr.h | 1 + > dirmngr/dirmngr_ldap.c | 61 > +++++++++++++++++++++++++++++++++++++++++++++----- > dirmngr/ldap.c | 24 +++++++++++++++----- > dirmngr/ldapserver.c | 5 +++++ > dirmngr/server.c | 3 ++- > 5 files changed, 81 insertions(+), 13 deletions(-) > > diff --git a/dirmngr/dirmngr.h b/dirmngr/dirmngr.h > index 4f037e7..3406494 100644 > --- a/dirmngr/dirmngr.h > +++ b/dirmngr/dirmngr.h > @@ -46,6 +46,7 @@ struct ldap_server_s > char *user; > char *pass; > char *base; > + char *schema; > }; > typedef struct ldap_server_s *ldap_server_t; > > diff --git a/dirmngr/dirmngr_ldap.c b/dirmngr/dirmngr_ldap.c > index 61a7e39..8bb739c 100644 > --- a/dirmngr/dirmngr_ldap.c > +++ b/dirmngr/dirmngr_ldap.c > @@ -46,6 +46,8 @@ > /* For OpenLDAP, to enable the API that we're using. */ > # define LDAP_DEPRECATED 1 > # include > + /* FIXME: use configure script to set this define */ > +# define CA_CERT_DEFAULT ("/etc/ssl/CA") > #endif > > @@ -571,9 +573,10 @@ fetch_ldap (my_opt_t myopt, const char *url, > const LDAPURLDesc *ludp) > LDAP *ld; > LDAPMessage *msg; > int rc = 0; > - char *host, *dn, *filter, *attrs[2], *attr; > + char *host, *dn, *filter, *attrs[2], *attr, *ca_cert, *ldap_url; > int port; > int ret; > + int err; > > host = myopt->host? myopt->host : ludp->lud_host; > port = myopt->port? myopt->port : ludp->lud_port; > @@ -583,6 +586,17 @@ fetch_ldap (my_opt_t myopt, const char *url, > const LDAPURLDesc *ludp) > attrs[1] = NULL; > attr = attrs[0]; > > + ca_cert = getenv("DIRMNGR_LDAP_CACERT"); > + if(!ca_cert) > + { > + if (myopt->verbose) > + { > + log_info("Using default CA certificate"); > + } > + > + ca_cert = CA_CERT_DEFAULT; > + } > + > if (!port) > port = (ludp->lud_scheme && !strcmp (ludp->lud_scheme, "ldaps"))? > 636:389; > > @@ -628,23 +642,58 @@ fetch_ldap (my_opt_t myopt, const char *url, > const LDAPURLDesc *ludp) > > set_timeout (myopt); > + > + ldap_url = alloca(4 + strlen(ludp->lud_scheme) > + + strlen(host) > + + 5); /* for port */ > + sprintf(ldap_url, "%s://%s:%d", ludp->lud_scheme, host, port); > + > npth_unprotect (); > - ld = my_ldap_init (host, port); > + err = ldap_initialize(&ld, ldap_url) ; > npth_protect (); > - if (!ld) > + if (err != LDAP_SUCCESS) > { > - log_error (_("LDAP init to '%s:%d' failed: %s\n"), > - host, port, strerror (errno)); > + log_error (_("LDAP init to '%s' failed: %s\n"), > + ldap_url, ldap_err2string (errno)); > return -1; > } > npth_unprotect (); > + > + if(!strcmp (ludp->lud_scheme, "ldaps")) > + { > + /* Additional options for tls connection */ > + /*FIXME: LDAP_OPT_X_TLS_NEVER or LDAP_OPT_X_TLS_HARD, add option*/ > + int req_cert = LDAP_OPT_X_TLS_NEVER; > + > + err = ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, > + ca_cert); > + npth_protect (); > + if(err != LDAP_SUCCESS) > + { > + log_error (_("setting ca-certificate failed: %s\n"), > + ldap_err2string (err)); > + return -1; > + } > + npth_unprotect (); > + err=ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, > + &req_cert); > + npth_protect (); > + if(err != LDAP_SUCCESS) > + { > + log_error (_("setting require certificate failed: %s\n"), > + ldap_err2string (err)); > + return -1; > + } > + npth_unprotect (); > + } > + > /* Fixme: Can we use MYOPT->user or is it shared with other theeads?. > */ > ret = my_ldap_simple_bind_s (ld, myopt->user, myopt->pass); > npth_protect (); > if (ret) > { > log_error (_("binding to '%s:%d' failed: %s\n"), > - host, port, strerror (errno)); > + host, port, ldap_err2string (errno)); > ldap_unbind (ld); > return -1; > } > diff --git a/dirmngr/ldap.c b/dirmngr/ldap.c > index e4c6aa2..d4e0730 100644 > --- a/dirmngr/ldap.c > +++ b/dirmngr/ldap.c > @@ -423,10 +423,10 @@ escape4url (const char *string) > need the host and port because this will be specified using the > override options. */ > static gpg_error_t > -make_url (char **url, const char *dn, const char *filter) > +make_url (char **url, const char *dn, const char *filter, const char > *schema) > { > gpg_error_t err; > - char *u_dn, *u_filter; > + char *u_dn, *u_filter, *u_schema; > char const attrs[] = (USERCERTIFICATE "," > /* USERSMIMECERTIFICATE "," */ > CACERTIFICATE "," > @@ -434,6 +434,10 @@ make_url (char **url, const char *dn, const char > *filter) > > *url = NULL; > > + u_schema = escape4url (schema); > + if(!u_schema) > + return gpg_error_from_errno (errno); > + > u_dn = escape4url (dn); > if (!u_dn) > return gpg_error_from_errno (errno); > @@ -445,7 +449,8 @@ make_url (char **url, const char *dn, const char > *filter) > xfree (u_dn); > return err; > } > - *url = malloc ( 8 + strlen (u_dn) > + *url = malloc ( 4 + strlen (schema) > + + strlen (u_dn) > + 1 + strlen (attrs) > + 5 + strlen (u_filter) + 1 ); > if (!*url) > @@ -456,12 +461,14 @@ make_url (char **url, const char *dn, const char > *filter) > return err; > } > > - stpcpy (stpcpy (stpcpy (stpcpy (stpcpy (stpcpy (*url, "ldap:///"), > + stpcpy (stpcpy (stpcpy (stpcpy (stpcpy (stpcpy (stpcpy(*url, > u_schema), > + ":///"), > u_dn), > "?"), > attrs), > "?sub?"), > u_filter); > + xfree (u_schema); > xfree (u_dn); > xfree (u_filter); > return 0; > @@ -525,6 +532,7 @@ start_cert_fetch_ldap (ctrl_t ctrl, > cert_fetch_context_t *context, > const char *user; > const char *pass; > const char *base; > + const char *schema; > const char *argv[50]; > int argc; > char portbuf[30], timeoutbuf[30]; > @@ -538,6 +546,7 @@ start_cert_fetch_ldap (ctrl_t ctrl, > cert_fetch_context_t *context, > user = server->user; > pass = server->pass; > base = server->base; > + schema = server->schema; > } > else /* Use a default server. */ > return gpg_error (GPG_ERR_NOT_IMPLEMENTED); > @@ -545,6 +554,9 @@ start_cert_fetch_ldap (ctrl_t ctrl, > cert_fetch_context_t *context, > if (!base) > base = ""; > > + if(!schema) > + schema = "ldap"; > + > argc = 0; > if (pass) /* Note: Must be the first item. */ > { > @@ -606,9 +618,9 @@ start_cert_fetch_ldap (ctrl_t ctrl, > cert_fetch_context_t *context, > return gpg_error (GPG_ERR_INV_USER_ID); > } > if ((sl->flags & 1)) > - err = make_url (&url, sl->d, "objectClass=*"); > + err = make_url (&url, sl->d, "objectClass=*", schema); > else > - err = make_url (&url, base, sl->d); > + err = make_url (&url, base, sl->d, schema); > free_strlist (sl); > if (err) > { > diff --git a/dirmngr/ldapserver.c b/dirmngr/ldapserver.c > index 16e13e2..87c8b47 100644 > --- a/dirmngr/ldapserver.c > +++ b/dirmngr/ldapserver.c > @@ -115,6 +115,11 @@ ldapserver_parse_one (char *line, > server->base = xstrdup (p); > break; > > + case 6: > + if (*p) > + server->schema = xstrdup (p); > + break; > + > default: > /* (We silently ignore extra fields.) */ > break; > diff --git a/dirmngr/server.c b/dirmngr/server.c > index 1b7e9e9..bcf83f9 100644 > --- a/dirmngr/server.c > +++ b/dirmngr/server.c > @@ -1259,7 +1259,8 @@ lookup_cert_by_pattern (assuan_context_t ctx, > char *line, > ldap_server_t ldapserver = ldapserver_iter.server; > > if (DBG_LOOKUP) > - log_debug ("cmd_lookup: trying %s:%d base=%s\n", > + log_debug ("cmd_lookup: trying %s://%s:%d base=%s\n", > + ldapserver->schema ? ldapserver->schema: "ldap", > ldapserver->host, ldapserver->port, > ldapserver->base?ldapserver->base : "[default]"); > > -- > 1.9.1 > > -- > Best Regards! > From gniibe at fsij.org Sat Jun 6 09:51:58 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sat, 06 Jun 2015 16:51:58 +0900 Subject: [PATCH] configure.ac: improve check for clock_gettime library In-Reply-To: References: Message-ID: <5572A69E.10703@fsij.org> On 06/06/2015 12:49 AM, Jim Meyering wrote: > I noticed the clock_gettime-vs-librt problem with npth-1.2 on a CentOS6 > system and fixed it, but then noticed that the first post-release patch also > made a change on that front. I have rebased on top of that. > > I have attached an additional patch: Thank you. Applied and pushed. -- From stef at thewalter.net Sun Jun 7 10:58:13 2015 From: stef at thewalter.net (Stef Walter) Date: Sun, 07 Jun 2015 10:58:13 +0200 Subject: Removing gpg-agent from gnome-keyring Message-ID: <557407A5.7010706@thewalter.net> So due to the fine work of Neal Walfield, we're just about ready to remove the gpg-agent from gnome-keyring. Gnupg 2.x has a very different model for key usage, and the GPG agent is an intimate part of GnuPG, not something that can be randomly reimplemented. Here's the bug to remove the gpg-agent and a patch: https://bugzilla.gnome.org/show_bug.cgi?id=750514 People should use the pinentry-gnome3 in 0.9.4 instead. We need to figure out how to make this the default for GNOME. Any ideas? Currently you have to put this in ~/.gnupg/gpg-agent.conf: pinentry-program /usr/bin/pinentry-gnome3 Neal, I noticed that the code to actually optionally save the passphrase via libsecret isn't yet hooked up. In particular the following function is never invoked (which would get the checkbox value from the gnome shell prompt): gcr_prompt_get_choice_chosen() There's also a bit of work here that's necessary before things show up correctly: https://bugzilla.gnome.org/show_bug.cgi?id=750465 Stef From neal at walfield.org Sun Jun 7 14:39:05 2015 From: neal at walfield.org (Neal H. Walfield) Date: Sun, 07 Jun 2015 14:39:05 +0200 Subject: Removing gpg-agent from gnome-keyring In-Reply-To: <557407A5.7010706@thewalter.net> References: <557407A5.7010706@thewalter.net> Message-ID: <87vbezpuae.wl-neal@walfield.org> At Sun, 07 Jun 2015 10:58:13 +0200, Stef Walter wrote: > Neal, I noticed that the code to actually optionally save the passphrase > via libsecret isn't yet hooked up. In particular the following function > is never invoked (which would get the checkbox value from the gnome > shell prompt): > > gcr_prompt_get_choice_chosen() That's embarrassing. It seems I forgot to check for that. Storing the passphrase definately works with pinentry-gtk, which is what I used for testing when developing the functionality. I've now fixed the gnome3 pinentry (and tested it) and I've pushed it as commit 444598586d0abf70d5a27d2aafcd6c14989621db. Thanks and sorry about the bug! :) Neal From gnupg-devel at spodhuis.org Mon Jun 8 02:49:37 2015 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Mon, 8 Jun 2015 00:49:37 +0000 Subject: Golang "OpenPGP" implementation... In-Reply-To: References: Message-ID: <20150608004937.GA15405@tower.spodhuis.org> On 2015-06-05 at 16:39 +0200, Low Eel wrote: > As you probably (?) know, Google launched their language, golang, and it ships > with something they call "OpenPGP" libraries: OpenPGP is the IETF name for the specification. The Internet Engineering Task Force defines the protocol. GnuPG is one implementation of the OpenPGP specification, and today is very probably the dominant implementation. > https://godoc.org/golang.org/x/crypto/openpgp > ? > I know because I am going to write some server using GPG and I was looking for > some library. Now the name "OpenPGP" Google is using seems promising, but. > > - Are that libraries a port/endorsed/written together with the gpg dev? > - Does anyone knows if they are 100% compatible or a "google flavour"? They are Google's implementation of the IETF standard. Compatibility is a complex issue but in general anything claiming "100% compatible" should be viewed with suspicion. Most products aren't even fully 100% compatible with themselves across versions; in good projects, such breakages then lead to additions to regression tests to try to avoid repeating such embarrassments. Casey Marshall wrote a PGP keyserver, Hockeypuck, designed to interop with SKS (the dominant PGP keyserver); Hockeypuck is written in Go and Casey tried to use the Google-provided x package, but ran into some limitations and forked off something which he could adapt to work for his use-case: https://github.com/hockeypuck/openpgp/tree/v1 (see also: https://hockeypuck.github.io/contributing.html ) I recommend evaluating both Google's package and Casey's, to see which is a better fit for your needs. Figure out why you choose one, and use the differences as inspiration so that you know when and how to fork yourself, to get closer to the level of compatibility which you need. Good luck! -Phil From ueno at gnu.org Mon Jun 8 06:05:01 2015 From: ueno at gnu.org (Daiki Ueno) Date: Mon, 08 Jun 2015 13:05:01 +0900 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> Message-ID: Hello Neal, Thanks for the prompt review. The new patch attached below should address the issues. "Neal H. Walfield" writes: > At Tue, 02 Jun 2015 17:56:44 +0900, > Daiki Ueno wrote: >> +AM_CONDITIONAL(BUILD_LIBPINENTRY_EMACS, >> + test "$pinentry_emacs" = "yes" -o "$inside_emacs" = "yes") > > I'm a bit confused by this. I can unstand building the emacs pinentry > without the inside emacs check, but doesn't inside_emacs imply > pinentry_emacs? If so, we only need to check if "$pinentry_emacs" = > "yes". Right? I think the check logic was rather wrong and the build settings of inside_emacs and pinentry_emacs should be orthogonal, i.e., GUI pinentries can be built with support for INSIDE_EMACS, but without building the pinentry-emacs program itself (and vice versa). It should be fixed now. >> + if (strlen (tmpdir) + strlen ("/emacs") + 10 + strlen ("/") >> + + strlen (socket_name) + 1 >= sizeof (unaddr.sun_path)) > > Technically, this is too conservative. 10 is the maximum length of > the uid. If the user is 1000, then only 4 characters are needed. It seems that I misunderstood your previous suggestion regarding asprintf. I added an extra allocation to relax the check. >> +/* Percent-escape control characters in DATA. Return a newly >> + allocated string, or DATA itself if there is no need to escape any >> + character. Store the length of the string to LENGTHP. */ >> +static char * >> +escape (const char *data, size_t *lengthp) >> +{ >> + char *buffer, *out_p; >> + size_t length = *lengthp, buffer_length; > > The comment is inaccurate. *LENGTHP needs to contain the length of > DATA. It also doesn't return a string, but a character vector (it is > not NUL terminated as far as I can tell). This is actually a problem > for set_label (and perhaps elsewhere): it calls escape with the length > of the string, not including the NUL character! Oops. > Also, the return semantics are a bit too smart for my taste. It would > be better to always allocate a new string. I see. Now all the string related functions (i.e., escape, unescape, send_to_emacs, and read_from_emacs) treat input/output NUL terminated. That significantly simplified the code, indeed. >> +static int >> +do_password (pinentry_t pe) >> +{ >> + char *escaped, *password; >> + size_t length; >> + assuan_error_t error; >> + >> + set_labels (pe); >> + >> + if (!send_to_emacs (emacs_socket, "GETPIN\n", 7)) >> + return -1; >> + >> + escaped = read_from_emacs (emacs_socket, pe->timeout, NULL, >> &length, &error); > > It is a bit unfortunate that the password is initially read into > insecure memory. Let's allocate, say, 1k of secure memory and use > that. Good idea, done. >> + password = unescape (escaped, &length); >> + pinentry_setbufferlen (pe, length); >> + if (pe->pin) >> + memcpy (pe->pin, password, length); > > You should NUL terminate the password. Done. >> +static int >> +do_confirm (pinentry_t pe) >> +{ > > You don't handle the case when the user pressed cancelled (we need to > set pe->cancelled) or the third button. It is important to get at > least the former right. Are there any specific reasons that this is > difficult? Thanks, I missed the field in the pinentry struct. Fixed. >> +int >> +pinentry_inside_emacs (void) >> +{ >> + const char *envvar; >> + >> + /* Check if INSIDE_EMACS envvar is set. */ >> + envvar = getenv ("INSIDE_EMACS"); >> + if (!envvar || !*envvar) >> + return 0; >> + >> + /* FIXME: Additional checks for the value. */ >> + return 1; >> +} >> + > Why doesn't pinentry_inside_emacs directly call pinentry_emacs_init? > It seems to me that the real test of whether we can use an emacs pin > is there? Good idea, done. >> + /* Check if the server responds. */ >> + read_from_emacs (emacs_socket, INITIAL_TIMEOUT, buffer, &length, &error); >> + return error == ASSUAN_No_Error; > > Also, in your previous patch, you checked for the existence of a > particular symbol. Why don't you do that anymore? I think it is > reasonable that the INSIDE_EMACS is set, but the version of emacs > doesn't have support for pinentry. Because the new patch no longer uses Elisp REPL, but the Assuan-like protocol. We could send "NOP" when connecting, but it is defined that an Assuan server should send an "OK" response on a new connection, and it is already checked here. Regards, -- Daiki Ueno -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-inside-Emacs-mode-to-GUI-pinentry-programs.patch Type: text/x-patch Size: 33674 bytes Desc: not available URL: From h.sand01 at gmail.com Mon Jun 8 12:53:01 2015 From: h.sand01 at gmail.com (Sand, Harrison) Date: Mon, 08 Jun 2015 12:53:01 +0200 Subject: OpenPGP Card version 3.0 Availability Message-ID: <5575740D.7070007@gmail.com> Hi All, I saw on g10code that the OpenPGP Card version 3.0 specification was released last week. (http://g10code.com/docs/openpgp-card-3.0.pdf) Are there any estimates to when this card will be publicly available? Thanks, Harrison From wk at gnupg.org Mon Jun 8 15:29:59 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 08 Jun 2015 15:29:59 +0200 Subject: [Announce] GPGME 1.5.5 released Message-ID: <87fv62ba5j.fsf@vigenere.g10code.de> Hello! We are pleased to announce version 1.5.5 of GPGME. GnuPG Made Easy (GPGME) is a C language library that allows to add support for cryptography to a program. It is designed to make access to public key crypto engines as included in GnuPG easier for applications. GPGME provides a high-level crypto API for encryption, decryption, signing, signature verification, and key management. * Noteworthy changes in version 1.5.5 - Fixed crash in key listings for user ids with a backslash. This bug was not exploitable except for a DoS (see commit 0d28a69). - Fixed regression for GPGSM use with GnuPG < 2.1. - Properly set signature summary for revoked OpenPGP keys. * Download You may download this library and its OpenPGP signature from: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.5.5.tar.bz2 (953k) ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.5.5.tar.bz2.sig The SHA-1 checksum is 88476d72cb099e179de4040760502886f7a54926 gpgme-1.5.5.tar.bz2 * Support Please send questions regarding the use of GPGME to the gnupg-devel mailing list: https://lists.gnupg.org/mailman/listinfo/gnupg-devel/ If you need commercial support, you may want to consult this listing: https://gnupg.org/service.html For the GnuPG team, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From neal at walfield.org Mon Jun 8 20:51:01 2015 From: neal at walfield.org (Neal H. Walfield) Date: Mon, 08 Jun 2015 20:51:01 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> Message-ID: <87lhfuowyy.wl-neal@walfield.org> Hi Daiki, It looks great. Just a couple of small comments. I think we almost there. Thanks! :) Neal At Mon, 08 Jun 2015 13:05:01 +0900, Daiki Ueno wrote: > +static int > +send_to_emacs (int s, const char *buffer) > +{ > + size_t length; > + int retval = 1; > + > + length = strlen (buffer); > + while (*buffer) > + { > + size_t part = MIN (length, SEND_BUFFER_SIZE - send_buffer_length); > + memcpy (&send_buffer[send_buffer_length], buffer, part); > + buffer += part; > + send_buffer_length += part; > + > + if (send_buffer_length == SEND_BUFFER_SIZE > + || (send_buffer_length > 0 > + && send_buffer[send_buffer_length-1] == '\n')) Should we check for embedded newlines and not just those at the end? That is, something like this: memchr (send_buffer, '\n', send_buffer_length) > +read_from_emacs (int s, int timeout, char *buffer, size_t capacity, > + assuan_error_t *error) I think this function assumes that responses are line buffered. That is, emacs will never send a single message consisting of "OK\nOK\n". Is that reasonable? > + if (allocated && offset + data_length + 1 > allocated_capacity) > + { > + allocated_capacity = allocated_capacity * 2 + 10; I think this is wrong. allocated_capacity has to be at least as large as offset + data_length + 1. If data_length is more than allocated_capacity + 10, then we overflow when we copy the data into buffer (this is easy when buffer is NULL). How about this? allocated_capacity = MAX (allocated_capacity * 2 + 10, offset + data_length + 1); > +int > +pinentry_inside_emacs (void) > +{ > + const char *envvar; > + > + /* Check if INSIDE_EMACS envvar is set. */ > + envvar = getenv ("INSIDE_EMACS"); > + if (!envvar || !*envvar) > + return 0; > + > + /* FIXME: Additional checks for the value. */ > + return pinentry_emacs_init (); > +} > + > +int > +pinentry_emacs_init (void) > +{ > + char buffer[256]; > + assuan_error_t error; > + > + /* Check if we can connect to the Emacs server socket. */ > + if (!set_socket ("pinentry")) > + return 0; > + > + /* Check if the server responds. */ > + read_from_emacs (emacs_socket, INITIAL_TIMEOUT, buffer, sizeof (buffer), > + &error); > + return error == ASSUAN_No_Error; > +} Since pinentry_inside_emacs calls pinentry_emacs_init should we make sure pinentry_emacs_init is only called once (perhaps by checking whether emacs_socket is -1)? Alternatively, if it has already been called, then we should release emacs_socket. From rfkrocktk at gmail.com Tue Jun 9 00:16:42 2015 From: rfkrocktk at gmail.com (Naftuli Tzvi Kay) Date: Mon, 8 Jun 2015 15:16:42 -0700 Subject: Feature request: handle multiple encryption subkeys on different smart cards intelligently Message-ID: Here's a little background on what I'm experiencing: https://security.stackexchange.com/questions/91054/multiple-encryption-subkeys-on-hardware-smart-cards/91068 Basically, I have two PGP identities: mine and my wife's. For each identity, we have multiple hardware smart cards storing 3 RSA certificates: one for encryption, one for signing, and one for authentication. It kind of looks like this: - Identitiy: me (master key, RSA signing key only) - Card: 1001 - Encryption Subkey A - Signing Subkey B - Authentication Subkey C - Card: 1002: - Encryption Subkey D - Signing Subkey E - Authentication Subkey F - Identity: wife (master key, RSA signing key only) - Card: 1003: - Encryption Subkey G - Signing Subkey H - Authentication Subkey I - Card: 1004: - Encryption Subkey J - Signing Subkey K - Authentication Subkey L Both my wife and I should have access to a given file X, therefore I encrypt it like this: gpg --encrypt --recipient me --encyrpt-to $ENC_SUBKEY_A! --encrypt-to $ENC_SUBKEY_D! \ --recipient wife --encrypt-to $ENC_SUBKEY_G! --encrypt-to $ENC_SUBKEY_J! This encrypts the file for myself and for my wife, and forces it to encrypt it for all of our subkeys. Decrypting this file, however, proves to be problematic. Since each identity has multiple encryption subkeys and all encryption subkeys live on smart cards, GPG seems to get confused by things and dosen't seem to execute certain commands in the right order. The process it seems to use is like this: 1. Check if $ENC_SUBKEY_A's secret key is present: it's not. 2. Complain about the card not being present: Please remove the current card and insert the one with serial number: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Hit return when ready or enter 'c' to cancel 3. Hit c until it gets to the right key and prompts for the smart card PIN. This can take a while, as I have 3 cards per identity. What it *should* do is this: 1. Examine the file and determine which keys can decrypt it. _If_ a smart card is present _and_ the smart card's secret key stub in secring.gpg can decrypt the file, immediately defer to using that card. 2. If no card is present or the file is --hidden-recipient, try decrypting with any present keys in the keyring whose smart card is present. 3. If there are no present keys, the present key can't decrypt the file, or the present key failed to decrypt the file, then start prompting to "insert the key known as ...". An explanation of my setup and why I did what I did is in order. I and my wife will be primarily using a single smart card each to access our data and boot our computers. Our encrypted key files will be encrypted for both of our identities and all of our smart cards. The reason for this is redundancy: if I lose access to my primary smart card, I'll be able to grab my backup smart card, revoke the keys of the first smart card, and decrypt the encrypted key file using the second smart card. As my wife will also need to boot the computer, she can use her primary smart card to decrypt the key file, falling back to her other one if the first one is compromised. My disk is encrypted using LUKS and a key file encrypted by GPG. This setup, though possibly confusing, gives me the best flexibility in terms of key compromise, as I can grab the backup hardware key and keep going. I can immediately issue a revocation for the keys on the first smart card, and begin reencyrpting all of my valuable data to exclude the compromised key. By keeping a reasonable amount of keys per identity and storing them in secure locations, I get all the benefits of strong encryption that GnuPG provides, the ability to recover in case of compromise, and the security of knowing my private keys only exist in hardware. Please see my inquiry on security.stackexchange and evaluate my setup and LUKS decrypt script, and you'll hopefully see what's going wrong and what could be improved in this regard. As far as I know, I can still accomplish what I want to by hacking my LUKS decryption script, but the process could be streamlined tremendously to one step for the user rather than up to 6 steps in my case (ie: hit c 5 times, then finally enter the PIN). In --batch mode, it just fails outright, which really shouldn't happen: it should see if it can decrypt with *any* present secret key (hardware or otherwise) and only then it should fail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Tue Jun 9 04:57:45 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 08 Jun 2015 22:57:45 -0400 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> Message-ID: <87616xsi52.fsf@alice.fifthhorseman.net> Hi Daiki-- thanks for your work on this. A couple questions/comments below... On Mon 2015-06-08 00:05:01 -0400, Daiki Ueno wrote: > --- a/gnome3/pinentry-gnome3.c > +++ b/gnome3/pinentry-gnome3.c [...] > @@ -253,14 +257,21 @@ main (int argc, char *argv[]) > { > pinentry_init (PGMNAME); > > -#ifdef FALLBACK_CURSES > - if (pinentry_have_display (argc, argv)) > - gtk_init (&argc, &argv); > +#ifdef INSIDE_EMACS > + if (pinentry_inside_emacs ()) > + pinentry_cmd_handler = emacs_cmd_handler; > else > - pinentry_cmd_handler = curses_cmd_handler; > +#endif > + { > +#ifdef FALLBACK_CURSES > + if (pinentry_have_display (argc, argv)) > + gtk_init (&argc, &argv); > + else > + pinentry_cmd_handler = curses_cmd_handler; > #else > - gtk_init (&argc, &argv); > + gtk_init (&argc, &argv); > #endif > + } > > pinentry_parse_opts (argc, argv); This worries me a bit. I use emacs regularly, and i often use emacs under X11. I'd generally rather that emacs *not* ever see or touch my passphrase or my secret key material, deferring instead to gpg-agent and graphical pinentry prompts to retain its ignorance. But i think the code you've outlined above makes it so that pinentry will be used automatically as long as it is detected as running within emacs. is that right? What can i do to ensure that this doesn't happen, if i want to rely on either pinentry-curses (without X11) or one of the graphical pinentries, while still invoking GnuPG from within emacs? > --- /dev/null > +++ b/pinentry/pinentry-emacs.c [...] > +int > +pinentry_inside_emacs (void) > +{ > + const char *envvar; > + > + /* Check if INSIDE_EMACS envvar is set. */ > + envvar = getenv ("INSIDE_EMACS"); > + if (!envvar || !*envvar) > + return 0; > + > + /* FIXME: Additional checks for the value. */ > + return pinentry_emacs_init (); > +} What does the FIXME above mean? What checks do you imagine going here? what problems could happen if the checks are not done? --dkg From ueno at gnu.org Tue Jun 9 05:40:36 2015 From: ueno at gnu.org (Daiki Ueno) Date: Tue, 09 Jun 2015 12:40:36 +0900 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87616xsi52.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 08 Jun 2015 22:57:45 -0400") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87616xsi52.fsf@alice.fifthhorseman.net> Message-ID: Hello Daniel, Thanks for the comment. Daniel Kahn Gillmor writes: > This worries me a bit. I use emacs regularly, and i often use emacs > under X11. I'd generally rather that emacs *not* ever see or touch my > passphrase or my secret key material, deferring instead to gpg-agent and > graphical pinentry prompts to retain its ignorance. That's a valid concern. Actually, I too am unlikely to use the Emacs pinentry regularly for security reasons, while users are really eager for the enter-passphrase-from-the-minibuffer feature. > But i think the code you've outlined above makes it so that pinentry > will be used automatically as long as it is detected as running within > emacs. is that right? Partly yes. To enable the Emacs pinentry, a user needs to call M-x pinentry-start manually. However, this might not be sufficient for GnuPG not to interact with Emacs. In that case, it might make sense to add an option to pinentry.conf, e.g., {no-,}allow-emacs-pinentry. I will try to add it in the new patch. >> + /* Check if INSIDE_EMACS envvar is set. */ >> + envvar = getenv ("INSIDE_EMACS"); >> + if (!envvar || !*envvar) >> + return 0; >> + >> + /* FIXME: Additional checks for the value. */ >> + return pinentry_emacs_init (); >> +} > > What does the FIXME above mean? What checks do you imagine going > here? > what problems could happen if the checks are not done? I was thinking of some version checks of Emacs, based on the value of INSIDE_EMACS, which normally in the form of "25.0.50.1,comint". However, now that the Emacs side code (pinentry.el) doesn't depend on particular version of Emacs, we can remove the comment. Regards, -- Daiki Ueno From dkg at fifthhorseman.net Tue Jun 9 05:54:27 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 08 Jun 2015 23:54:27 -0400 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87616xsi52.fsf@alice.fifthhorseman.net> Message-ID: <87r3plr0y4.fsf@alice.fifthhorseman.net> On Mon 2015-06-08 23:40:36 -0400, Daiki Ueno wrote: > That's a valid concern. Actually, I too am unlikely to use the Emacs > pinentry regularly for security reasons, while users are really eager > for the enter-passphrase-from-the-minibuffer feature. Which users are demanding this? In what contexts? How have the options and tradeoffs been presented to them? Understanding the goals and use cases for this potentially-risky feature seems like an important step, particularly if the folks developing it don't want to use it themselves. > To enable the Emacs pinentry, a user needs to call M-x pinentry-start > manually. However, this might not be sufficient for GnuPG not to > interact with Emacs. In that case, it might make sense to add an > option to pinentry.conf, e.g., {no-,}allow-emacs-pinentry. > > I will try to add it in the new patch. thanks, this is an interesting option. --dkg From yuuma.sato at gmail.com Tue Jun 9 05:31:28 2015 From: yuuma.sato at gmail.com (Watson Sato) Date: Tue, 9 Jun 2015 00:31:28 -0300 Subject: Default configuration of pinentry in gnome3 Message-ID: Hi, I'm Yuuma and I'm working on GNOME side of pinentry-gnome3 as a GSoC project. With pinentry-gnome3 implemented we are looking to set this pinentry program as default in gnome3. I know it' possible to configure the default pinentry through configuration in gpg-agent.conf file and it also can be passed as a parameter on execution. But what would be the way for GNOME to change default pinentry to pinentry-gnome3 when starting a session? Neal has mentioned that Debian uses update-alternatives to configure the default pinentry, would this approach be enough? Maybe reading a secondary config file where session managers can change stuff. Is there a better approach? -- Watson Yuuma Sato -------------- next part -------------- An HTML attachment was scrubbed... URL: From ueno at gnu.org Tue Jun 9 07:43:18 2015 From: ueno at gnu.org (Daiki Ueno) Date: Tue, 09 Jun 2015 14:43:18 +0900 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87r3plr0y4.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 08 Jun 2015 23:54:27 -0400") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87616xsi52.fsf@alice.fifthhorseman.net> <87r3plr0y4.fsf@alice.fifthhorseman.net> Message-ID: Daniel Kahn Gillmor writes: > On Mon 2015-06-08 23:40:36 -0400, Daiki Ueno wrote: >> That's a valid concern. Actually, I too am unlikely to use the Emacs >> pinentry regularly for security reasons, while users are really eager >> for the enter-passphrase-from-the-minibuffer feature. > > Which users are demanding this? In what contexts? How have the options > and tradeoffs been presented to them? I don't want to repeat the discussions here, sorry. If you are really interested, you can search on the Emacs bug tracker and the emacs-devel mailing list. > Understanding the goals and use cases for this potentially-risky > feature seems like an important step, particularly if the folks > developing it don't want to use it themselves. I merely meant that I generally prefer to do crypto operations outside of Emacs, as Emacs is inherently insecure (e.g., the read-passwd function could be replaced at run-time, by an external package). Nevertheless, the pinentry-emacs mechanism should be reasonably secure for the typical use-cases. >> option to pinentry.conf, e.g., {no-,}allow-emacs-pinentry. >> >> I will try to add it in the new patch. > > thanks, this is an interesting option. I'm now turning the option off by default. Regards, -- Daiki Ueno From andreas.stieger at gmx.de Tue Jun 9 08:44:12 2015 From: andreas.stieger at gmx.de (Andreas Stieger) Date: Tue, 09 Jun 2015 08:44:12 +0200 Subject: Default configuration of pinentry in gnome3 In-Reply-To: References: Message-ID: <55768B3C.2040709@gmx.de> Hello, On 09/06/15 05:31, Watson Sato wrote: > Hi, I'm Yuuma and I'm working on GNOME side of pinentry-gnome3 as a GSoC > project. > > With pinentry-gnome3 implemented we are looking to set this pinentry > program as default in gnome3. > > I know it' possible to configure the default pinentry through > configuration in gpg-agent.conf file and it also can be passed as a > parameter on execution. > > But what would be the way for GNOME to change default pinentry to > pinentry-gnome3 when starting a session? > > Neal has mentioned that Debian uses update-alternatives to configure the > default pinentry, would this approach be enough? > Maybe reading a secondary config file where session managers can change > stuff. > > Is there a better approach? You may be interested to know that SUSE/openSUSE and Fedora (et al) use a script wrapper in /usr/bin/pinentry that auto-detects the running graphical environment, desktop sesssion and installed pinentry binaries and calls the best available one. I found this to be superior to update-alternatives. https://build.opensuse.org/package/view_file/openSUSE:Factory/pinentry/pinentry?expand=1 http://pkgs.fedoraproject.org/cgit/pinentry.git/tree/pinentry-wrapper The openSUSE one has testamentary support for the newly added pinentry-gnome3, maybe you can suggest an environment variable for detecting a GNOME3 session reliably? Andreas From ueno at gnu.org Tue Jun 9 09:49:38 2015 From: ueno at gnu.org (Daiki Ueno) Date: Tue, 09 Jun 2015 16:49:38 +0900 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87lhfuowyy.wl-neal@walfield.org> (Neal H. Walfield's message of "Mon, 08 Jun 2015 20:51:01 +0200") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> Message-ID: Thanks for the review, I'm attaching a new patch. "Neal H. Walfield" writes: >> +static int >> +send_to_emacs (int s, const char *buffer) >> +{ [...] >> + if (send_buffer_length == SEND_BUFFER_SIZE >> + || (send_buffer_length > 0 >> + && send_buffer[send_buffer_length-1] == '\n')) > > Should we check for embedded newlines and not just those at the end? For our use-cases of send_to_emacs, we can assume that a newline character only appears at the end of buffer. The comment of send_to_emacs (copied from emacsclient.c) says: /* Let's send the data to Emacs when either - the data ends in "\n", or - the buffer is full (but this shouldn't happen) Otherwise, we just accumulate it. */ and a typical usage of the function: if (!send_to_emacs (emacs_socket, name) || !send_to_emacs (emacs_socket, " ")) return 0; escaped = escape (value); if (!escaped) return 0; retval = send_to_emacs (emacs_socket, escaped) && send_to_emacs (emacs_socket, "\n"); Here, a newline character will never be passed to send_to_emacs, until the last call of the function. Perhaps the comment should state that more clearly. >> +read_from_emacs (int s, int timeout, char *buffer, size_t capacity, >> + assuan_error_t *error) > > I think this function assumes that responses are line buffered. That > is, emacs will never send a single message consisting of "OK\nOK\n". > Is that reasonable? Yes, I think so. A send_to_emacs/read_from_emacs pair basically emulates assuan_transact, which expects at most one response code which completes a transaction (i.e., OK/ERR/END). >> + if (allocated && offset + data_length + 1 > allocated_capacity) >> + { >> + allocated_capacity = allocated_capacity * 2 + 10; > > I think this is wrong. allocated_capacity has to be at least as large > as offset + data_length + 1. If data_length is more than > allocated_capacity + 10, then we overflow when we copy the data into > buffer (this is easy when buffer is NULL). How about this? > > allocated_capacity = MAX (allocated_capacity * 2 + 10, > offset + data_length + 1); Oops, thanks for pointing that out. Fixed. > Since pinentry_inside_emacs calls pinentry_emacs_init should we make > sure pinentry_emacs_init is only called once (perhaps by checking > whether emacs_socket is -1)? Good point, but should we consider the case where pinentry_inside_emacs is called multiple times? Assuming not, I added an assertion in pinentry_emacs_init to prevent the socket being initialized twice, and renamed pinentry_inside_emacs to a clearer name denoting a side effect: pinentry_enable_emacs_cmd_handler. Also, I moved the call to the function right after pinentry_parse_opts, aiming for the option dependent behavior, which I wrote in the reply to Daniel: > GnuPG not to interact with Emacs. In that case, it might make sense to > add an option to pinentry.conf, e.g., {no-,}allow-emacs-pinentry. > > I will try to add it in the new patch. I postpone this for now, since it turned out that it requires a change in GnuPG. Regards, -- Daiki Ueno -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-inside-Emacs-mode-to-GUI-pinentry-programs.patch Type: text/x-patch Size: 30311 bytes Desc: not available URL: From wk at gnupg.org Tue Jun 9 09:55:40 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Jun 2015 09:55:40 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87r3plr0y4.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 08 Jun 2015 23:54:27 -0400") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87616xsi52.fsf@alice.fifthhorseman.net> <87r3plr0y4.fsf@alice.fifthhorseman.net> Message-ID: <87sia19uyr.fsf@vigenere.g10code.de> On Tue, 9 Jun 2015 05:54, dkg at fifthhorseman.net said: > Which users are demanding this? In what contexts? How have the options Well, it would make it easier to read encrypted mails by attaching to a remote Gnus session. I share your concerns that this is not a good idea security wise. OTOH, being able to attach to a remote Emacs session already allows you to take over the remote box. >> option to pinentry.conf, e.g., {no-,}allow-emacs-pinentry. >> >> I will try to add it in the new patch. > > thanks, this is an interesting option. Ack. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jun 9 10:05:46 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Jun 2015 10:05:46 +0200 Subject: Feature request: handle multiple encryption subkeys on different smart cards intelligently In-Reply-To: (Naftuli Tzvi Kay's message of "Mon, 8 Jun 2015 15:16:42 -0700") References: Message-ID: <87oakp9uhx.fsf@vigenere.g10code.de> On Tue, 9 Jun 2015 00:16, rfkrocktk at gmail.com said: > Decrypting this file, however, proves to be problematic. Since each > identity has multiple encryption subkeys and all encryption subkeys live on > smart cards, GPG seems to get confused by things and dosen't seem to > execute certain commands in the right order. See also: https://bugs.gnupg.org/gnupg/issue1955 Your suggestion makes a lot of sense. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jun 9 10:10:07 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Jun 2015 10:10:07 +0200 Subject: Default configuration of pinentry in gnome3 In-Reply-To: (Watson Sato's message of "Tue, 9 Jun 2015 00:31:28 -0300") References: Message-ID: <87k2vd9uao.fsf@vigenere.g10code.de> On Tue, 9 Jun 2015 05:31, yuuma.sato at gmail.com said: > Neal has mentioned that Debian uses update-alternatives to configure the > default pinentry, would this approach be enough? Yes. In fact gpg-agent looks for /usr/bin/pinentry which is supposed to be a link to one of the alternatives. The pinentry make install rule does exactly this. > Maybe reading a secondary config file where session managers can change > stuff. gpgconf allows to change a conf file at runtime. If you want to use a specific Pinentry per session, I would suggest to make use of this feature. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From yuuma.sato at gmail.com Tue Jun 9 13:19:59 2015 From: yuuma.sato at gmail.com (Watson Sato) Date: Tue, 9 Jun 2015 08:19:59 -0300 Subject: gnome-keyring Auto launched gpg-agent doesn't work with pinentry-gnome3 In-Reply-To: <557697D1.6080201@redhat.com> References: <557697D1.6080201@redhat.com> Message-ID: On Tue, Jun 9, 2015 at 4:37 AM, Stef Walter wrote: > > Yuuma, since you're working to help finish up this work, here's probably > another task you could work on patches for. > I'd like to help. But I couldn't reproduce the issue here. Surely I'm missing something. -- Watson Yuuma Sato -------------- next part -------------- An HTML attachment was scrubbed... URL: From neal at walfield.org Tue Jun 9 13:55:25 2015 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 09 Jun 2015 13:55:25 +0200 Subject: gnome keyring & gpg agent In-Reply-To: <877fsbvwhr.wl-neal@walfield.org> References: <87twvg8l4r.fsf@alice.fifthhorseman.net> <87bnhowa4x.wl-neal@walfield.org> <87twvfmnhx.fsf@vigenere.g10code.de> <87fv6z7032.fsf@alice.fifthhorseman.net> <877fsbvwhr.wl-neal@walfield.org> Message-ID: <87egllp042.wl-neal@walfield.org> At Thu, 14 May 2015 20:34:40 +0200, Neal H. Walfield wrote: > So far, I've identified these requirements: > > - Adding a new pinentry-gnome3 package with the yet-to-be-released > pinentry with Gnome3 support. > > - An update to GPG with the relatively small change. > > - An update to Gnome-Keyring that disables it GPG Agent proxy. Stef just removed GPG Agent from Gnome Keyring. https://bugzilla.gnome.org/show_bug.cgi?id=750514 Thanks, Stef! > - Make Gnome Keyring depend on pinentry-gnome3. :) Neal From ueno at gnu.org Tue Jun 9 14:12:43 2015 From: ueno at gnu.org (Daiki Ueno) Date: Tue, 09 Jun 2015 21:12:43 +0900 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: (Daiki Ueno's message of "Tue, 09 Jun 2015 16:49:38 +0900") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> Message-ID: <87oakpqdvo.fsf-ueno@gnu.org> Daiki Ueno writes: >> GnuPG not to interact with Emacs. In that case, it might make sense to >> add an option to pinentry.conf, e.g., {no-,}allow-emacs-pinentry. >> >> I will try to add it in the new patch. > > I postpone this for now, since it turned out that it requires a change > in GnuPG. Here is the follow-up patch which implements this. I'm also attaching a patch to GnuPG. Regards, -- Daiki Ueno -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-allow-emacs-prompt-Assuan-option.patch Type: text/x-diff Size: 4084 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-agent-Add-option-allow-emacs-pinentry.patch Type: text/x-diff Size: 3638 bytes Desc: not available URL: From gniibe at fsij.org Tue Jun 9 14:57:32 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 09 Jun 2015 21:57:32 +0900 Subject: Feature request: handle multiple encryption subkeys on different smart cards intelligently In-Reply-To: References: Message-ID: <5576E2BC.7070007@fsij.org> Hello, Thank you for detailed report. It helps me a lot to understand your situation. Let me explain current GnuPG implementation. Basically, current implementation processes OpenPGP packets one by one. On 06/09/2015 07:16 AM, Naftuli Tzvi Kay wrote: > The process it seems to use is like this: > > 1. Check if $ENC_SUBKEY_A's secret key is present: it's not. > 2. Complain about the card not being present: > Please remove the current card and insert the one with serial number: > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > Hit return when ready or enter 'c' to cancel > 3. Hit c until it gets to the right key and prompts for the smart > card PIN. This can take a while, as I have 3 cards per identity. Correct. Note that this behavior is not for smartcard only, it also applies to private keys on file system. > What it /should/ do is this: > > 1. Examine the file and determine which keys can decrypt it. _If_ a > smart card is present _and_ the smart card's secret key stub in > secring.gpg can decrypt the file, immediately defer to using that > card. > 2. If no card is present or the file is --hidden-recipient, try > decrypting with any present keys in the keyring whose smart card is > present. > 3. If there are no present keys, the present key can't decrypt the > file, or the present key failed to decrypt the file, then start > prompting to "insert the key known as ...". Yes, I agree. >From the implementation viewpoint, it will be something like: (1) gpg frontend parses all packets for ESK (Encrypted Session Key) sequence. (2) Then, talks to gpg-agent for available private keys to decide which private key to decrypt. (3) Asks gpg-agent to decrypt. -- From gniibe at fsij.org Tue Jun 9 15:25:52 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 09 Jun 2015 22:25:52 +0900 Subject: OpenPGP Card version 3.0 Availability In-Reply-To: <5575740D.7070007@gmail.com> References: <5575740D.7070007@gmail.com> Message-ID: <5576E960.4030606@fsij.org> On 06/08/2015 07:53 PM, Sand, Harrison wrote: > I saw on g10code that the OpenPGP Card version 3.0 specification was > released last week. (http://g10code.com/docs/openpgp-card-3.0.pdf) > > Are there any estimates to when this card will be publicly available? I don't have any information about the card 3.0. I mean, the product itself. But I know about GnuPG and Gnuk. GnuPG "modern" 2.1 will be ready for the OpenPGPcard specification version 3.0. The required code for ECC has already implemented in the repository. For other support, if needed, code will be added. Gnuk 1.1.5 is mostly compatible to the OpenPGPcard specification version 3.0 and users can use ECC with NIST P-256 curve now. I don't think people want to use NIST P-256 curve, though. Well, I am going to post Gnuk 1.1.5 release. -- From attila at stalphonsos.com Tue Jun 9 15:07:05 2015 From: attila at stalphonsos.com (attila) Date: Tue, 09 Jun 2015 08:07:05 -0500 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <874mms4tzc.wl-neal@walfield.org> References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> Message-ID: <87ioax2emz.fsf@tldr.l.stalphonsos.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 Hello gnupg-devel, Neal and Daiki, I've been following the discussion with some interest and only wish to make one slight comment: Neal H. Walfield writes: > Hi Daiki, > > [snip] >> + if (strlen (tmpdir) + strlen (socket_name) + 10 + 2 >> + >= sizeof (emacs_server_address.sun_path)) >> + { >> + fprintf (stderr, "socket name is too long\n"); >> + free (tmpdir_storage); >> + return 0; >> + } >> + >> + sprintf (emacs_server_address.sun_path, "%s/emacs%lu/%s", >> + tmpdir, (unsigned long) uid, socket_name); > > I think the check above is wrong. It should be something like: > > if (strlen (tmpdir) + strlen("/emacs") + 10 + strlen("/") > + strlen (socket_name) + 1 > >= sizeof (emacs_server_address.sun_path)) > > Or, less conservatively, we could replace 10 with the actual length of > the uid as a base-10 string. > > Perhaps the best approach is to use something like asprintf. (I say > like, because we can't use asprintf: it is not portable. But, recent > version of libgpg-error provide a replacement.) > I would humbly suggest an idiom based on snprintf(3): if (snprintf (emacs_server_address.sun_path, sizeof(emacs_server_address.sun_path), "%s/emacs%lu/%s", tmpdir, (unsigned long) uid, socket_name) >= sizeof(emacs_server_address.sun_path)) { fprintf (stderr, "socket name is too long\n"); free (tmpdir_storage); return 0; } This way you don't have to worry about checking the lengths of all the individual components of the path; you state how much space is available and snprintf(3) tells you if it was too much. snprintf(3) is now universally available and leads to shorter code whose intention is clearer. Before making this assertion I poked around a bit for some confirmation and found a couple encouraging things... on a NetBSD list related to Lua: ... which points at a blog post on MSDN re Microsoft support for (among other things) snprintf(3): So it seems previous objections to snprintf(3) based on portability (*cough* Microsoft *cough*) are perhaps no longer valid. It certainly appears to be supported everywhere else (C99 was a long time ago :-). It also appears that other groups of hackers are considering adopting use of snprintf(3) more universally for this reason, which is a good thing. The same idea applies for the rest of the sprintf calls here: replace the "check the length manually then call sprintf" idiom with "call snprintf and let it check the length". It is easier to audit code like this, if nothing else. >> [snip] Thanks for the work on GnuPG and pinentry... M-x lurk-mode RET Pax, -A - -- http://trac.haqistan.net | attila at stalphonsos.com | 0xE6CC1EDB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Processed by Mailcrypt 3.5.9 iQIcBAEBCQAGBQJVdupGAAoJEJZ30KbmzB7bEhUQAK6dG3sLBiLGOdUxQoL3s6V6 UbFEpneG6EqOSNzbzmpt37sS498CKltT+B6U3SpaJP2ty+mpQSW2xsRrmopLJK1w 9IGHHeHIjBGF55TtiI008ervV71kBHVpGnFZeDdoQF45/iUDwzXilipEJWI9n67x XasproNc1d/DnnOEQpG0zUAqcDN5EbIofrif6B9TyBuB+8GXdMezeiVUW4dURCAO IWV7KkSvB4tbQeL8rNelNdpUz9rjwvm8yYfWgztv2eMY7XrQ1l7oBAj4ObodB75t Vx2qv3U9Va0bW+LZPI1Ew2d7XLAKOJ8hU1Xr/7rLZ3qHlhfTJMFuoaULgMoI+PIb MTR3SSuM1TuTyseCNtoDG7909Gr8CF7xTx/MOz57jHqiiHhAHdMojp1JF+2hGVcP fVY3EHB+Qpp/e3SlTqa8/2QhrTabqngZ1qMYqyV7Rmo11J5sjb4yIh078e3DSH7z KueTSAezpBX0/LL0qPUzJIxEcXY3aSzTrOVAOTPWNAQ645FBP28njAP4qWA8m6OG 3CIK7c9C/KnvMr8GVHXbNQ5C+1U0j7quIWIuzPa8u7SdMGSM/agABg92AFDyUQJR 1mJ5mLlfJ3tVri1fTkE0u/Fatmo3IHNdEetqBrf0CQoZIU0P32E0tDsqnJ2YvPbJ ptzgyZldSupciatlfT/+ =E1qA -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Tue Jun 9 22:34:58 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 09 Jun 2015 16:34:58 -0400 Subject: Default configuration of pinentry in gnome3 In-Reply-To: References: Message-ID: <877frcr571.fsf@alice.fifthhorseman.net> On Mon 2015-06-08 23:31:28 -0400, Watson Sato wrote: > Neal has mentioned that Debian uses update-alternatives to configure the > default pinentry, would this approach be enough? fwiw (as one of the debian developers maintaining pinentry and the gnupg stack), i'm fine with using update-alternatives for this. By default pinentry-gnome3 if present will be a higher priority in pinentry-gtk2. so in debian, i think we could handle this by having the gnome-keyring package Depend: pinentry-gnome3, and leave it at that. Now you have three different responses to choose from, none of which require you to do anything in GNOME directly afaict :) * pinentry-wrapper (Andreas) * gpgconf (Werner) * /etc/alternatives (dkg) --dkg From rfkrocktk at gmail.com Tue Jun 9 21:26:56 2015 From: rfkrocktk at gmail.com (Naftuli Tzvi Kay) Date: Tue, 9 Jun 2015 12:26:56 -0700 Subject: Feature request: handle multiple encryption subkeys on different smart cards intelligently In-Reply-To: <5576E2BC.7070007@fsij.org> References: <5576E2BC.7070007@fsij.org> Message-ID: Thank goodness! I'm glad I was on to something here, moreso glad that I'm not hearing "it's not a bug, it's a feature?" as is unfortunately common to hear these days. I've yet to try using the --try-all-secrets in --batch mode, I'm not sure if that will help remedy the problem. Do note that I'm using GnuPG 1, as it's in an initramfs setting. Would that setting help remedy the problem in the interrim? I don't know what my options are in initramfs for using GnuPG without piping the password in with the cryptsetup askpass command; I assume that askpass does some magic to grab keyboard input that the gpg binary itself probably wouldn't be able to do. If I'm able to get gpg working interactively instead of reading the passphrase from STDIN, I can just endure having to press 'c' several times until everything is right in the world and it finds the right decryption key in hardware. Thanks, - Naftuli Tzvi On Tue, Jun 9, 2015 at 5:57 AM, NIIBE Yutaka wrote: > Hello, > > Thank you for detailed report. It helps me a lot to understand your > situation. > > Let me explain current GnuPG implementation. > > Basically, current implementation processes OpenPGP packets one by > one. > > On 06/09/2015 07:16 AM, Naftuli Tzvi Kay wrote: > > The process it seems to use is like this: > > > > 1. Check if $ENC_SUBKEY_A's secret key is present: it's not. > > 2. Complain about the card not being present: > > Please remove the current card and insert the one with serial number: > > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > > Hit return when ready or enter 'c' to cancel > > 3. Hit c until it gets to the right key and prompts for the smart > > card PIN. This can take a while, as I have 3 cards per identity. > > Correct. Note that this behavior is not for smartcard only, it also > applies to private keys on file system. > > > What it /should/ do is this: > > > > 1. Examine the file and determine which keys can decrypt it. _If_ a > > smart card is present _and_ the smart card's secret key stub in > > secring.gpg can decrypt the file, immediately defer to using that > > card. > > 2. If no card is present or the file is --hidden-recipient, try > > decrypting with any present keys in the keyring whose smart card is > > present. > > 3. If there are no present keys, the present key can't decrypt the > > file, or the present key failed to decrypt the file, then start > > prompting to "insert the key known as ...". > > Yes, I agree. > > From the implementation viewpoint, it will be something like: > > (1) gpg frontend parses all packets for ESK (Encrypted Session Key) > sequence. > > (2) Then, talks to gpg-agent for available private keys to decide > which private key to decrypt. > > (3) Asks gpg-agent to decrypt. > -- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neal at walfield.org Wed Jun 10 15:37:16 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 10 Jun 2015 15:37:16 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87oakpqdvo.fsf-ueno@gnu.org> References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87oakpqdvo.fsf-ueno@gnu.org> Message-ID: <87mw07ofar.wl-neal@walfield.org> Hi Daiki, At Tue, 09 Jun 2015 21:12:43 +0900, Daiki Ueno wrote: > Here is the follow-up patch which implements this. I'm also attaching a > patch to GnuPG. Thanks. I don't like this approach. In particular, I don't like adding new options / commands to the Assuan protocol. I think it is sufficient to have a command line option to the pinentry to do the emacs check. Then, users who want to use this would add the following to their gpg-agent.conf: pinentry-program /usr/bin/pinentry --enable-emacs (We could also add a new option called pinentry-program-options so that users can still use the system default.) Thoughts? Neal From wk at gnupg.org Wed Jun 10 16:58:29 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 10 Jun 2015 16:58:29 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87oakpqdvo.fsf-ueno@gnu.org> (Daiki Ueno's message of "Tue, 09 Jun 2015 21:12:43 +0900") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87oakpqdvo.fsf-ueno@gnu.org> Message-ID: <87eglj8vai.fsf@vigenere.g10code.de> On Tue, 9 Jun 2015 14:12, ueno at gnu.org said: > Here is the follow-up patch which implements this. I'm also attaching a I just pushed the GnuPG part of it so that it will go into the release I planned for today. I leave the Pinentry part to Neal. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Jun 10 17:22:12 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 10 Jun 2015 17:22:12 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87mw07ofar.wl-neal@walfield.org> (Neal H. Walfield's message of "Wed, 10 Jun 2015 15:37:16 +0200") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87oakpqdvo.fsf-ueno@gnu.org> <87mw07ofar.wl-neal@walfield.org> Message-ID: <87a8w78u6z.fsf@vigenere.g10code.de> On Wed, 10 Jun 2015 15:37, neal at walfield.org said: > pinentry-program /usr/bin/pinentry --enable-emacs > > (We could also add a new option called pinentry-program-options so > that users can still use the system default.) Both options are problematic for gpgconf because there is no support for this style of options. The --foo-options are already hard to handle by gpgconf but pinentry-program would require another dedicated feature in gpgconf. With Ueno's patch we have immediate support for Emacs in the configuration dialogs of GPA and Kleopatra (and hopefully others). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From yuuma.sato at gmail.com Thu Jun 11 05:02:43 2015 From: yuuma.sato at gmail.com (Watson Sato) Date: Thu, 11 Jun 2015 00:02:43 -0300 Subject: Default configuration of pinentry in gnome3 In-Reply-To: <877frcr571.fsf@alice.fifthhorseman.net> References: <877frcr571.fsf@alice.fifthhorseman.net> Message-ID: On Tue, Jun 9, 2015 at 5:34 PM, Daniel Kahn Gillmor wrote: > Now you have three different responses to choose from, none of which > require you to do anything in GNOME directly afaict :) > Thanks for the replies. So, as I understand, it is something to be setup by packagers or distributors... There are two separate things: First is to indicate that gnome-keyring goes well with pinentry-gnome3. That would be done by making one depend on the other? And second is to make gpg choose pinentry-gnome3 as default when running a GNOME session. I believe the pinentry-wrappers and alternatives to good approaches, if the user wishes to user another pinentry gpg-agent.conf should be used. Our concern is to ensure that when gnome-keyring is running along with gpg in a GNOME session gnome-keyring is able to cache gpg passphrases if opted to. Is there a mechanism for GNOME to recommend such setup up for packagers or distributors, maybe docs or something? (Does this question make sense? I don't know much about how packaging and shipping processes) -- Watson Yuuma Sato -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Thu Jun 11 08:06:11 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 11 Jun 2015 15:06:11 +0900 Subject: [PATCH] pinentry: Added generating missing file. In-Reply-To: <1408546196-28359-1-git-send-email-serge0x76@gmail.com> References: <1408546196-28359-1-git-send-email-serge0x76@gmail.com> Message-ID: <55792553.9020503@fsij.org> Hello, This is reply to your report on 2014-08-20. Thank you for your report. Sorry not responding earlier. On 08/20/2014 11:49 PM, Serge Voilokov wrote: > Fresh cloned pinentry/autogen.sh gives an error "required file './compile' not found". Perhaps, you've already known that it was fixed. It was fixed by the commits in September 2014. commit f21dcb8083905efef8e82e1bf91dd01457af81d1 Author: Werner Koch Date: Thu Sep 18 10:22:34 2014 +0200 Add missing build support files and move them to build-aux. commit 549479d69363ca1ef5e7c676517e2327b8baadea Author: Werner Koch Date: Thu Sep 18 10:21:19 2014 +0200 Use generic autogen.sh script. Pinentry is under active development these days. Please try new version, too. -- From casey.marshall at gmail.com Thu Jun 11 14:07:34 2015 From: casey.marshall at gmail.com (Casey Marshall) Date: Thu, 11 Jun 2015 07:07:34 -0500 Subject: Golang "OpenPGP" implementation... In-Reply-To: <20150608004937.GA15405@tower.spodhuis.org> References: <20150608004937.GA15405@tower.spodhuis.org> Message-ID: <55797A06.6070607@gmail.com> On 06/07/2015 07:49 PM, Phil Pennock wrote: > On 2015-06-05 at 16:39 +0200, Low Eel wrote: >> As you probably (?) know, Google launched their language, golang, and it ships >> with something they call "OpenPGP" libraries: > > OpenPGP is the IETF name for the specification. The Internet > Engineering Task Force defines the protocol. GnuPG is one > implementation of the OpenPGP specification, and today is very probably > the dominant implementation. > >> https://godoc.org/golang.org/x/crypto/openpgp >> >> I know because I am going to write some server using GPG and I was looking for >> some library. Now the name "OpenPGP" Google is using seems promising, but. >> >> - Are that libraries a port/endorsed/written together with the gpg dev? >> - Does anyone knows if they are 100% compatible or a "google flavour"? > > They are Google's implementation of the IETF standard. Compatibility is > a complex issue but in general anything claiming "100% compatible" > should be viewed with suspicion. Most products aren't even fully 100% > compatible with themselves across versions; in good projects, such > breakages then lead to additions to regression tests to try to avoid > repeating such embarrassments. > > Casey Marshall wrote a PGP keyserver, Hockeypuck, designed to interop > with SKS (the dominant PGP keyserver); Hockeypuck is written in Go and > Casey tried to use the Google-provided x package, but ran into some > limitations and forked off something which he could adapt to work for > his use-case: > > https://github.com/hockeypuck/openpgp/tree/v1 > > (see also: https://hockeypuck.github.io/contributing.html ) > To clarify -- and I should perhaps document this better on the hockeypuck site and project page -- github.com/hockeypuck/openpgp is not a fork of golang.org/x/openpgp. It's a wrapper around golang.org/x/crypto/packet, a low-level OpenPGP packet processing API, for the specific purpose of parsing key material to build a public keyserver -- which needs to deal with good, bad, ugly and as-of-yet unsupported key material. This is a much different concern from the high-level OpenPGP API in x/crypto, which is more about using OpenPGP for signing and encryption. > I recommend evaluating both Google's package and Casey's, to see which > is a better fit for your needs. Figure out why you choose one, and use > the differences as inspiration so that you know when and how to fork > yourself, to get closer to the level of compatibility which you need. > Use golang.org/x/crypto. github.com/hockeypuck/openpgp is really only useful if you're developing your own public keyserver, or have some other special-case need to process OpenPGP packets (perhaps for some WoT analysis, debugging OpenPGP implementations, etc.) > Good luck! > -Phil > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -- -Casey From wk at gnupg.org Thu Jun 11 16:00:49 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 11 Jun 2015 16:00:49 +0200 Subject: [Announce] GnuPG 2.1.5 released Message-ID: <874mme73am.fsf@vigenere.g10code.de> Hello! The GnuPG Project is pleased to announce the availability of a new release of GnuPG modern: Version 2.1.5. The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard which is commonly abbreviated as PGP. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. Since version 2 GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different branches of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features. This announcement is about this branch. - GnuPG "stable" (2.0) is the current stable version for general use. This is what most users are currently using. - GnuPG "classic" (1.4) is the old standalone version which is most suitable for older or embedded platforms. You may not install "modern" (2.1) and "stable" (2.0) at the same time. However, it is possible to install "classic" (1.4) along with any of the other versions. Noteworthy changes in version 2.1.5 =================================== * Support for an external passphrase cache. * Support for the forthcoming version 3 OpenPGP smartcard. * Manuals now show the actual used file names. * Prepared for improved integration with Emacs. * Code cleanups and minor bug fixes. A detailed description of the changes found in the 2.1 branch can be found at . This version fixes some bugs found after the release of 2.1.4. Please be aware that there are still known bugs which we are working on. Check the the bug tracker, https://wiki.gnupg.org, or the mailing list archives for known problems and workarounds. Getting the Software ==================== Please follow the instructions found at https://gnupg.org/download/ or read on: GnuPG 2.1.5 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. On ftp.gnupg.org you find these files: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.5.tar.bz2 (4791k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.5.tar.bz2.sig This is the GnuPG source code compressed using BZIP2 and its OpenPGP signature. ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.5_20150611.exe (2567k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.5_20150611.exe.sig This is an installer for Windows without graphical frontends except for a basic Pinentry tool. Please de-install an installed Gpg4win version before trying this installer. Note, that TLS access to keyservers is not yet available. The sources used to build the installer can be found in the same directory with an ".tar.xz" suffix. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.1.5.tar.bz2 you would use this command: gpg --verify gnupg-2.1.5.tar.bz2.sig gnupg-2.1.5.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See below for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.1.5.tar.bz2, you would run the command like this: sha1sum gnupg-2.1.5.tar.bz2 and check that the output matches the next line: 02bbe32e1ef3b06b3ae3c60c955fb767a1aa0f2f gnupg-2.1.5.tar.bz2 f705fb6ae7612428b33cc51e23e006cdbf958e5d gnupg-w32-2.1.5_20150611.exe 9ee6959be57c32bddeb2a855724a9080d1820079 gnupg-w32-2.1.5_20150611.tar.xz Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these files from a keyserver using this command gpg --keyserver hkp://keys.gnupg.net --recv-keys \ 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed using by a different key. Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Russian, and Ukrainian being almost completely translated (2071 different strings). Documentation ============= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete user manual of the system. Separate man pages are included as well but they have not all the details available as are the manual. It is also possible to read the complete manual online in HTML format at https://gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. You may also want to follow postings at https://gnupg.org/blob/. Support ======== Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . For commercial support requests we keep a list of known service companies at: https://gnupg.org/service.html If you are a developer and you may need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Maintenance and development of GnuPG is possible due to many individual and corporate donations; for a list of non-anonymous donors see . For the GnuPG hackers, Werner p.s. This is a announcement only mailing list. Please send replies only to the gnupg-users at gnupg.org mailing list. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From gniibe at fsij.org Fri Jun 12 09:05:56 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 12 Jun 2015 16:05:56 +0900 Subject: pinentry-curses can be forced to loop endlessly In-Reply-To: References: Message-ID: <557A84D4.9020607@fsij.org> Hello, Thank you for your report on 2014-08-25. On 08/25/2014 10:17 PM, Steffen Nurpmeso wrote: > the bug i report here was not present in v2.0.24 (i think, looking > at the ArchLinux package history [1]) but then came into existence > with v2.0.25 and is still present in the new package that uses > v2.0.26. > > [1] > > > I am still (see ArchLinux bug report [2]) too lazy to find > a different way to reproduce it, so this example assumes the > default ArchLinux mailx(1) (v14.7.2 or later) (or CRUX-Linux or > Void Linux packages; or download S-nail directly [3]): > > [2] Since it's still opened in the bug tracker, I'm writing to you. I think that this is the issue of pinentry program. I couldn't reproduce it in my environment of today, I checkd the pinentry commit log. I believe that the particular issue was handled by this commit. So, I think it was fixed already (in 0.9.0 or later). commit 3803fd15942f2f25108e400be6cd6faef791c8f7 Author: Stanislav Ochotnicky Date: Fri Feb 14 12:58:38 2014 +0100 Check if we are on tty before initializing curses. * pinentry/pinentry-curses.c (dialog_run): Check stant stdin and stout are connected to ttys. -- When we did not have a ttyname we just used stdin/out without checking if it's a proper TTY or a pipe. In some cases this can cause endless loop or escape seqeunces on the terminal. This commit changes behaviour so that if stdin/out is not tty and no ttyname is specified we error-out with errno set to ENOTTY Pinentry is under active development now. Please try newer version. -- From stef at thewalter.net Fri Jun 12 11:50:38 2015 From: stef at thewalter.net (Stef Walter) Date: Fri, 12 Jun 2015 11:50:38 +0200 Subject: Default configuration of pinentry in gnome3 In-Reply-To: References: <877frcr571.fsf@alice.fifthhorseman.net> Message-ID: <557AAB6E.1060301@thewalter.net> On 11.06.2015 05:02, Watson Sato wrote: > > On Tue, Jun 9, 2015 at 5:34 PM, Daniel Kahn Gillmor > > wrote: > > Now you have three different responses to choose from, none of which > require you to do anything in GNOME directly afaict :) > > > Thanks for the replies. > So, as I understand, it is something to be setup by packagers or > distributors... > > There are two separate things: > First is to indicate that gnome-keyring goes well with pinentry-gnome3. > That would be done by making one depend on the other? > And second is to make gpg choose pinentry-gnome3 as default when running > a GNOME session. I believe the pinentry-wrappers and alternatives to > good approaches, if the user wishes to user another pinentry > gpg-agent.conf should be used. > > Our concern is to ensure that when gnome-keyring is running along with > gpg in a GNOME session gnome-keyring is able to cache gpg passphrases if > opted to. > > Is there a mechanism for GNOME to recommend such setup up for packagers > or distributors, maybe docs or something? (Does this question make > sense? I don't know much about how packaging and shipping processes) I think the options that Daniel has outlined are sufficient. It's just up to us to go out to the various packagers and show them the options and have them decide how they want to proceed. Stef From neal at walfield.org Fri Jun 12 12:23:24 2015 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 12 Jun 2015 12:23:24 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> Message-ID: <87fv5xgr8j.wl-neal@walfield.org> Hi Daiki, Sorry for the delay in replying. I was traveling. At Tue, 09 Jun 2015 16:49:38 +0900, Daiki Ueno wrote: > Good point, but should we consider the case where pinentry_inside_emacs > is called multiple times? Assuming not, I added an assertion in > pinentry_emacs_init to prevent the socket being initialized twice, and > renamed pinentry_inside_emacs to a clearer name denoting a side effect: > pinentry_enable_emacs_cmd_handler. > > Also, I moved the call to the function right after pinentry_parse_opts, > aiming for the option dependent behavior, which I wrote in the reply to > Daniel: > > > GnuPG not to interact with Emacs. In that case, it might make sense to > > add an option to pinentry.conf, e.g., {no-,}allow-emacs-pinentry. > > > > I will try to add it in the new patch. > > I postpone this for now, since it turned out that it requires a change > in GnuPG. Is any change actually required on the pinentry side? If gpg-agent doesn't pass the INSIDE_EMACS environment variable through, then emacs support is automatically disabled. > +/* Enable pinentry command handler which interacts with Emacs, if > + INSIDE_EMACS envvar is set. This function should be called once, > + right before pinentry_loop call. */ > +void pinentry_enable_emacs_cmd_handler (void); I'm not convinced that this is the right construct. Why don't we just let pinentry_parse_opts do this. Also, why don't you modify the curses and tty frontends to support emacs? Thanks! :) Neal From ueno at gnu.org Fri Jun 12 13:15:25 2015 From: ueno at gnu.org (Daiki Ueno) Date: Fri, 12 Jun 2015 20:15:25 +0900 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87fv5xgr8j.wl-neal@walfield.org> (Neal H. Walfield's message of "Fri, 12 Jun 2015 12:23:24 +0200") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87fv5xgr8j.wl-neal@walfield.org> Message-ID: <87wpz96uuq.fsf-ueno@gnu.org> "Neal H. Walfield" writes: >> I postpone this for now, since it turned out that it requires a change >> in GnuPG. > > Is any change actually required on the pinentry side? If gpg-agent > doesn't pass the INSIDE_EMACS environment variable through, then emacs > support is automatically disabled. INSIDE_EMACS is a standardized variable, which is also set by shell-mode, eshell, tramp, etc., as well as epg.el and pinentry.el. With the patch, those major-modes will also benefit, while some users don't want to enable the feature automatically. So I think a separate option is inevitable here. >> +/* Enable pinentry command handler which interacts with Emacs, if >> + INSIDE_EMACS envvar is set. This function should be called once, >> + right before pinentry_loop call. */ >> +void pinentry_enable_emacs_cmd_handler (void); > > I'm not convinced that this is the right construct. Why don't we just > let pinentry_parse_opts do this. Good idea, but given that the option is supposed to be implemented as an Assuan option instead of a Pinentry option, I am not sure if the pinentry_parse_opts is the right place to do that. Perhaps we could integrate it into pinentry_loop? > Also, why don't you modify the curses and tty frontends to support > emacs? I just forgot that, since the implementation started based on the curses fallback. I will send a new patch soon. Regards, -- Daiki Ueno From neal at walfield.org Fri Jun 12 13:36:22 2015 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 12 Jun 2015 13:36:22 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87wpz96uuq.fsf-ueno@gnu.org> References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87fv5xgr8j.wl-neal@walfield.org> <87wpz96uuq.fsf-ueno@gnu.org> Message-ID: <87eglhgnux.wl-neal@walfield.org> At Fri, 12 Jun 2015 20:15:25 +0900, Daiki Ueno wrote: > > "Neal H. Walfield" writes: > > >> I postpone this for now, since it turned out that it requires a change > >> in GnuPG. > > > > Is any change actually required on the pinentry side? If gpg-agent > > doesn't pass the INSIDE_EMACS environment variable through, then emacs > > support is automatically disabled. > > INSIDE_EMACS is a standardized variable, which is also set by > shell-mode, eshell, tramp, etc., as well as epg.el and pinentry.el. > > With the patch, those major-modes will also benefit, while some users > don't want to enable the feature automatically. So I think a separate > option is inevitable here. I'm not sure what you mean. Let me be more specific. 1./ Your last patch adds a new option to gpg-agent: allow-emacs-pinentry. If this is not set, then the emacs pinentry shouldn't be used. 2./ gpg-agent controls what environment variables are passed to the pinentry. See agent/call-pinentry.c:atfork_cb. 3./ Your patch only uses the emacs pinentry if the INSIDE_EMACS environment variable is set. Thus, if allow-emacs-pinentry is not set (1) and we don't forward the INSIDE_EMACS environment variable (2), then pinentry won't try the emacs pinentry (3). Therefore, teaching pinentry about this option is not required. Does that make sense or do you have another use case in mind that I'm missing? Thanks, :) Neal From wk at gnupg.org Fri Jun 12 13:42:55 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 12 Jun 2015 13:42:55 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87fv5xgr8j.wl-neal@walfield.org> (Neal H. Walfield's message of "Fri, 12 Jun 2015 12:23:24 +0200") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87fv5xgr8j.wl-neal@walfield.org> Message-ID: <87bngl5f0g.fsf@vigenere.g10code.de> On Fri, 12 Jun 2015 12:23, neal at walfield.org said: > Is any change actually required on the pinentry side? If gpg-agent > doesn't pass the INSIDE_EMACS environment variable through, then emacs > support is automatically disabled. - I'd like to have this explicitly allowed. Technically suppressing INSIDE_EMACS is possible but it is a more code. It also goes nicely with the allow-external-cache option. - In case gpg-agent is started within Emacs, that envvar will be passed anyway. The special treatmeant of these envars affects is only fo gpg and gpgsm to override the envvars known by gpg-agent if they want different ones. The best examples here are the DISPLAY or LC_* envars which are often different than those use at the time gpg-agent was started. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Fri Jun 12 14:54:44 2015 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 12 Jun 2015 14:54:44 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87bngl5f0g.fsf@vigenere.g10code.de> References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87fv5xgr8j.wl-neal@walfield.org> <87bngl5f0g.fsf@vigenere.g10code.de> Message-ID: <87d211gk8b.wl-neal@walfield.org> At Fri, 12 Jun 2015 13:42:55 +0200, Werner Koch wrote: > On Fri, 12 Jun 2015 12:23, neal at walfield.org said: > > > Is any change actually required on the pinentry side? If gpg-agent > > doesn't pass the INSIDE_EMACS environment variable through, then emacs > > support is automatically disabled. > > - I'd like to have this explicitly allowed. Technically suppressing > INSIDE_EMACS is possible but it is a more code. It also goes nicely > with the allow-external-cache option. I disagree. I see INSIDE_EMACS as a policy decision at the gpg-agent level. Passing (or not passing) the INSIDE_EMACS variable is similar to an explicit delegation. But, I could see how one would argue that this is a pinentry policy. In that case, I think the configuration option should be in pinentry.conf and not gpg-agent.conf. > - In case gpg-agent is started within Emacs, that envvar will be passed > anyway. The special treatmeant of these envars affects is only fo gpg > and gpgsm to override the envvars known by gpg-agent if they want > different ones. The best examples here are the DISPLAY or LC_* envars > which are often different than those use at the time gpg-agent was > started. I understand better. I thought they were to sanitize the environment. Thanks, :) Neal From dkg at fifthhorseman.net Fri Jun 12 17:49:38 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 12 Jun 2015 11:49:38 -0400 Subject: gpgme 1.5.5 tests failing [was: Re: GPGME 1.5.5 released] In-Reply-To: <87fv62ba5j.fsf@vigenere.g10code.de> References: <87fv62ba5j.fsf@vigenere.g10code.de> Message-ID: <874mmdlyel.fsf@alice.fifthhorseman.net> On Mon 2015-06-08 09:29:59 -0400, Werner Koch wrote: > We are pleased to announce version 1.5.5 of GPGME. > > GnuPG Made Easy (GPGME) is a C language library that allows to add > support for cryptography to a program. It is designed to make access > to public key crypto engines as included in GnuPG easier for > applications. GPGME provides a high-level crypto API for encryption, > decryption, signing, signature verification, and key management. > > > * Noteworthy changes in version 1.5.5 > > - Fixed crash in key listings for user ids with a backslash. This bug > was not exploitable except for a DoS (see commit 0d28a69). > > - Fixed regression for GPGSM use with GnuPG < 2.1. > > - Properly set signature summary for revoked OpenPGP keys. I've built this for debian, and it works for me when building against GnuPG (and gpg-agent) 2.1.5. However, on a headless build daemon that i'm using which has gnupg (and gpg-agent) 2.0.28, the tests all fail: ------------ ... echo x > ./private-keys-v1.d/gpg-sample.stamp starting gpg-agent error starting gpg-agent PASS: initial.test t-encrypt.c:60: GPGME: Inappropriate ioctl for device FAIL: t-encrypt t-encrypt-sym.c:67: GPGME: Inappropriate ioctl for device FAIL: t-encrypt-sym t-encrypt-sign.c:116: GPGME: Inappropriate ioctl for device FAIL: t-encrypt-sign t-sign.c:124: GPGME: Inappropriate ioctl for device FAIL: t-sign t-signers.c:119: GPGME: Inappropriate ioctl for device FAIL: t-signers t-decrypt.c:65: GPGME: Inappropriate ioctl for device FAIL: t-decrypt t-verify.c:223: GPGME: Inappropriate ioctl for device FAIL: t-verify t-decrypt-verify.c:123: GPGME: Inappropriate ioctl for device FAIL: t-decrypt-verify t-sig-notation.c:149: GPGME: Inappropriate ioctl for device FAIL: t-sig-notation t-export.c:57: GPGME: Inappropriate ioctl for device FAIL: t-export t-import.c:229: GPGME: Inappropriate ioctl for device FAIL: t-import t-trustlist.c:50: GPGME: Inappropriate ioctl for device FAIL: t-trustlist t-edit.c:135: GPGME: Inappropriate ioctl for device FAIL: t-edit t-keylist.c:141: GPGME: Inappropriate ioctl for device FAIL: t-keylist t-keylist-sig.c:95: GPGME: Inappropriate ioctl for device FAIL: t-keylist-sig t-wait.c:59: GPGME: Inappropriate ioctl for device FAIL: t-wait t-encrypt-large.c:120: GPGME: Inappropriate ioctl for device FAIL: t-encrypt-large t-file-name.c:70: GPGME: Inappropriate ioctl for device FAIL: t-file-name PASS: t-gpgconf t-eventloop.c:201: GPGME: Inappropriate ioctl for device FAIL: t-eventloop t-thread1.c:124: GPGME: Inappropriate ioctl for device FAIL: t-thread1 gpg-agent not running PASS: final.test ====================================== 20 of 23 tests failed Please report to http://bugs.gnupg.org ====================================== ------------ Any suggestions of what to look for in debugging this? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From neal at walfield.org Fri Jun 12 20:48:46 2015 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 12 Jun 2015 20:48:46 +0200 Subject: pinentry loopback mode & password repeat Message-ID: <878ubohiep.wl-neal@walfield.org> Hi Ben, In issue #1976 (https://bugs.gnupg.org/gnupg/issue1976), Daiki reports that GnuPG 2.1 asks for the passphrase twice when encrypting in symmetric mode. I came up with a simple patch to always disable repeat mode when doing symmetric encryption. My question is directed to you, since you requested the pinentry loopback mode. Will this change break any behavior in your software? Does anyone else see any problem with unconditional disabling repeat mode for all symmetric operations independent of the pinentry mode? Thanks, :) Neal From wk at gnupg.org Fri Jun 12 20:58:05 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 12 Jun 2015 20:58:05 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87d211gk8b.wl-neal@walfield.org> (Neal H. Walfield's message of "Fri, 12 Jun 2015 14:54:44 +0200") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87fv5xgr8j.wl-neal@walfield.org> <87bngl5f0g.fsf@vigenere.g10code.de> <87d211gk8b.wl-neal@walfield.org> Message-ID: <87y4jo4uv6.fsf@vigenere.g10code.de> On Fri, 12 Jun 2015 14:54, neal at walfield.org said: > this is a pinentry policy. In that case, I think the configuration > option should be in pinentry.conf and not gpg-agent.conf. Hmmm, pinentry.conf - tehre is no such thing. Pinentry started out as a very small program to avoid all kind of complexity but over the years it grew a lot. For the user perspective it is a part of gpg-agent and in fact it works closely together with gpg-agent (cf. quality bar). Thus adding another conf file or another tab in gpgconf based option dialogs would make even harder for the user to see where to find a certain option. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Jun 12 21:01:45 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 12 Jun 2015 21:01:45 +0200 Subject: gpgme 1.5.5 tests failing In-Reply-To: <874mmdlyel.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 12 Jun 2015 11:49:38 -0400") References: <87fv62ba5j.fsf@vigenere.g10code.de> <874mmdlyel.fsf@alice.fifthhorseman.net> Message-ID: <87twuc4up2.fsf@vigenere.g10code.de> On Fri, 12 Jun 2015 17:49, dkg at fifthhorseman.net said: > I've built this for debian, and it works for me when building against > GnuPG (and gpg-agent) 2.1.5. However, on a headless build daemon that > i'm using which has gnupg (and gpg-agent) 2.0.28, the tests all fail: Actually I tested it agains 2.0.28 but under X. > t-encrypt.c:60: GPGME: Inappropriate ioctl for device That is: err = gpgme_get_key (ctx, "A0FF4590BB6122EDEF6E3C542D727CC768697734", &key[0], 0); fail_if_err (err); Any other special configuration of gpg or gpg-agent? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Fri Jun 12 21:09:49 2015 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 12 Jun 2015 21:09:49 +0200 Subject: pinentry loopback mode & password repeat In-Reply-To: <878ubohiep.wl-neal@walfield.org> References: <878ubohiep.wl-neal@walfield.org> Message-ID: <877fr8hhfm.wl-neal@walfield.org> Hi, At Fri, 12 Jun 2015 20:48:46 +0200, Neal H. Walfield wrote: > In issue #1976 (https://bugs.gnupg.org/gnupg/issue1976), Daiki reports > that GnuPG 2.1 asks for the passphrase twice when encrypting in > symmetric mode. I came up with a simple patch to always disable > repeat mode when doing symmetric encryption. After discussing some more with Werner, it seems I misunderstood: we shouldn't unconditionally disable repeat mode for symmetric encryption operations, but unconditionally disable repeat mode when in pinentry loopback mode. Neal From dkg at fifthhorseman.net Fri Jun 12 21:21:43 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 12 Jun 2015 15:21:43 -0400 Subject: gpgme 1.5.5 tests failing In-Reply-To: <87twuc4up2.fsf@vigenere.g10code.de> References: <87fv62ba5j.fsf@vigenere.g10code.de> <874mmdlyel.fsf@alice.fifthhorseman.net> <87twuc4up2.fsf@vigenere.g10code.de> Message-ID: <87oakklol4.fsf@alice.fifthhorseman.net> On Fri 2015-06-12 15:01:45 -0400, Werner Koch wrote: > On Fri, 12 Jun 2015 17:49, dkg at fifthhorseman.net said: > >> I've built this for debian, and it works for me when building against >> GnuPG (and gpg-agent) 2.1.5. However, on a headless build daemon that >> i'm using which has gnupg (and gpg-agent) 2.0.28, the tests all fail: > > Actually I tested it agains 2.0.28 but under X. I have also tested it against 2.0.28 on another system and don't see these errors there. I'm *only* seeing the errors on the headless build system. >> t-encrypt.c:60: GPGME: Inappropriate ioctl for device > > That is: > > err = gpgme_get_key (ctx, "A0FF4590BB6122EDEF6E3C542D727CC768697734", > &key[0], 0); > fail_if_err (err); > > Any other special configuration of gpg or gpg-agent? Not that i'm aware of. The headless build system where these errors show up is using cowbuilder inside a chroot. This means no pseudo-terminal is directly attached to the build/test process -- i don't know whether that's relevant. i'm stumped by this right now :/ --dkg From ueno at gnu.org Fri Jun 12 21:43:41 2015 From: ueno at gnu.org (Daiki Ueno) Date: Sat, 13 Jun 2015 04:43:41 +0900 Subject: gpgme 1.5.5 tests failing In-Reply-To: <87oakklol4.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 12 Jun 2015 15:21:43 -0400") References: <87fv62ba5j.fsf@vigenere.g10code.de> <874mmdlyel.fsf@alice.fifthhorseman.net> <87twuc4up2.fsf@vigenere.g10code.de> <87oakklol4.fsf@alice.fifthhorseman.net> Message-ID: <87pp507lwp.fsf-ueno-ueno@gnu.org> Daniel Kahn Gillmor writes: >>> t-encrypt.c:60: GPGME: Inappropriate ioctl for device >> >> That is: >> >> err = gpgme_get_key (ctx, "A0FF4590BB6122EDEF6E3C542D727CC768697734", >> &key[0], 0); >> fail_if_err (err); >> >> Any other special configuration of gpg or gpg-agent? > > Not that i'm aware of. The headless build system where these errors > show up is using cowbuilder inside a chroot. This means no > pseudo-terminal is directly attached to the build/test process -- i > don't know whether that's relevant. i'm stumped by this right now :/ The error looks similar to the one I got for ruby-gpgme, when running on Heroku: https://gist.github.com/vovayartsev/a466aa82320b84f32b13 (the original issue: https://github.com/ueno/ruby-gpgme/issues/26) where it seems to be failing in ttyname_r usage in GPGME. I have not tried it by myself, but ArchLinux people tweak the mount option of /dev/pts to work around this: https://lists.archlinux.org/pipermail/arch-projects/2011-October/001953.html https://lists.archlinux.org/pipermail/arch-projects/2011-October/001994.html Regards, -- Daiki Ueno From dkg at fifthhorseman.net Fri Jun 12 23:19:18 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 12 Jun 2015 17:19:18 -0400 Subject: gpgme 1.5.5 tests failing In-Reply-To: <87pp507lwp.fsf-ueno-ueno@gnu.org> References: <87fv62ba5j.fsf@vigenere.g10code.de> <874mmdlyel.fsf@alice.fifthhorseman.net> <87twuc4up2.fsf@vigenere.g10code.de> <87oakklol4.fsf@alice.fifthhorseman.net> <87pp507lwp.fsf-ueno-ueno@gnu.org> Message-ID: <878ubolj55.fsf@alice.fifthhorseman.net> On Fri 2015-06-12 15:43:41 -0400, Daiki Ueno wrote: > Daniel Kahn Gillmor writes: > >>>> t-encrypt.c:60: GPGME: Inappropriate ioctl for device >>> >>> That is: >>> >>> err = gpgme_get_key (ctx, "A0FF4590BB6122EDEF6E3C542D727CC768697734", >>> &key[0], 0); >>> fail_if_err (err); >>> >>> Any other special configuration of gpg or gpg-agent? >> >> Not that i'm aware of. The headless build system where these errors >> show up is using cowbuilder inside a chroot. This means no >> pseudo-terminal is directly attached to the build/test process -- i >> don't know whether that's relevant. i'm stumped by this right now :/ > > The error looks similar to the one I got for ruby-gpgme, when running > on Heroku: > https://gist.github.com/vovayartsev/a466aa82320b84f32b13 > (the original issue: https://github.com/ueno/ruby-gpgme/issues/26) > where it seems to be failing in ttyname_r usage in GPGME. > > I have not tried it by myself, but ArchLinux people tweak the mount > option of /dev/pts to work around this: > https://lists.archlinux.org/pipermail/arch-projects/2011-October/001953.html > https://lists.archlinux.org/pipermail/arch-projects/2011-October/001994.html Wow, thanks for finding this! it does look relevant. I'll poke around in cowbuilder and pbuilder to see if there's a /dev/pts issue i can sort out there. But... should gpgme require the existence or proper configuration of /dev/pts in some particular mode to be able to work? It seems to me that a system without /dev/pts at all should still be able to use gpgme, right? --dkg From wk at gnupg.org Sat Jun 13 09:27:51 2015 From: wk at gnupg.org (Werner Koch) Date: Sat, 13 Jun 2015 09:27:51 +0200 Subject: gpgme 1.5.5 tests failing In-Reply-To: <878ubolj55.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 12 Jun 2015 17:19:18 -0400") References: <87fv62ba5j.fsf@vigenere.g10code.de> <874mmdlyel.fsf@alice.fifthhorseman.net> <87twuc4up2.fsf@vigenere.g10code.de> <87oakklol4.fsf@alice.fifthhorseman.net> <87pp507lwp.fsf-ueno-ueno@gnu.org> <878ubolj55.fsf@alice.fifthhorseman.net> Message-ID: <87h9qc3w5k.fsf@vigenere.g10code.de> On Fri, 12 Jun 2015 23:19, dkg at fifthhorseman.net said: > But... should gpgme require the existence or proper configuration of > /dev/pts in some particular mode to be able to work? It seems to me > that a system without /dev/pts at all should still be able to use gpgme, Right. As long as stderr and stdout are not connceted to a tty there should be no problem. Maybe due to setlocale ? Running one of the test programs with GPGME=9: should show the cause. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sat Jun 13 09:31:41 2015 From: wk at gnupg.org (Werner Koch) Date: Sat, 13 Jun 2015 09:31:41 +0200 Subject: pinentry loopback mode & password repeat In-Reply-To: <877fr8hhfm.wl-neal@walfield.org> (Neal H. Walfield's message of "Fri, 12 Jun 2015 21:09:49 +0200") References: <878ubohiep.wl-neal@walfield.org> <877fr8hhfm.wl-neal@walfield.org> Message-ID: <87d2103vz6.fsf@vigenere.g10code.de> On Fri, 12 Jun 2015 21:09, neal at walfield.org said: > operations, but unconditionally disable repeat mode when in pinentry > loopback mode. The repeated passphrase entry is a pure UI topic and thus it is useless when there is no user interface involved at the layer. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ueno at gnu.org Sun Jun 14 03:24:04 2015 From: ueno at gnu.org (Daiki Ueno) Date: Sun, 14 Jun 2015 10:24:04 +0900 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87wpz96uuq.fsf-ueno@gnu.org> (Daiki Ueno's message of "Fri, 12 Jun 2015 20:15:25 +0900") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87fv5xgr8j.wl-neal@walfield.org> <87wpz96uuq.fsf-ueno@gnu.org> Message-ID: <871thfrsjv.fsf-ueno@gnu.org> Daiki Ueno writes: > Perhaps we could integrate it into pinentry_loop? > >> Also, why don't you modify the curses and tty frontends to support >> emacs? > > I just forgot that, since the implementation started based on the curses > fallback. I will send a new patch soon. Here is a new patch, modified along these lines. Changes from the previous version are: - pinentry_enable_emacs_cmd_handler is now called from option_handler, and all hooks in gnome3/gtk+-2/qt4 are removed - the allow-emacs-prompt Assuan option patch is squashed into this - the UID value check is now replaced with simple cast to uint32_t, using configure time check "Neal H. Walfield" writes: > Thus, if allow-emacs-pinentry is not set (1) and we don't forward the > INSIDE_EMACS environment variable (2), then pinentry won't try the > emacs pinentry (3). > > Therefore, teaching pinentry about this option is not required. > > Does that make sense or do you have another use case in mind that I'm > missing? As Werner already pointed, (2) is not always the case with the current code. However, perhaps the above scenario might be actually possible by explicitly unsetenv'ing INSIDE_EMACS in gpg-agent, when allow-emacs-pinentry is not set in gpg-agent.conf (like we do for DISPLAY, when keep-display is not set). Regards, -- Daiki Ueno -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-inside-Emacs-mode-to-GUI-pinentry-programs.patch Type: text/x-diff Size: 28347 bytes Desc: not available URL: From neal at walfield.org Sun Jun 14 12:19:08 2015 From: neal at walfield.org (Neal H. Walfield) Date: Sun, 14 Jun 2015 12:19:08 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <871thfrsjv.fsf-ueno@gnu.org> References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87fv5xgr8j.wl-neal@walfield.org> <87wpz96uuq.fsf-ueno@gnu.org> <871thfrsjv.fsf-ueno@gnu.org> Message-ID: <871theh9sz.wl-neal@walfield.org> At Sun, 14 Jun 2015 10:24:04 +0900, Daiki Ueno wrote: > - the UID value check is now replaced with simple cast to uint32_t, > using configure time check Is this really safe? Before you caught the error, now we silently take the value mod 2^32. > > Thus, if allow-emacs-pinentry is not set (1) and we don't forward the > > INSIDE_EMACS environment variable (2), then pinentry won't try the > > emacs pinentry (3). > > > > Therefore, teaching pinentry about this option is not required. > > > > Does that make sense or do you have another use case in mind that I'm > > missing? > > As Werner already pointed, (2) is not always the case with the current > code. > > However, perhaps the above scenario might be actually possible by > explicitly unsetenv'ing INSIDE_EMACS in gpg-agent, when > allow-emacs-pinentry is not set in gpg-agent.conf (like we do for > DISPLAY, when keep-display is not set). I seem to remember Werner suggesting that this would require a large change, but if it is easy, I would welcome this approach. > diff --git a/emacs/pinentry-emacs.c b/emacs/pinentry-emacs.c > new file mode 100644 > index 0000000..de4ca05 > --- /dev/null > +++ b/emacs/pinentry-emacs.c ... > pinentry_cmd_handler_t fallback_cmd_handler; Is there any reason this isn't marked static? > +static int > +initial_emacs_cmd_handler (pinentry_t pe) > +{ > + if (pe->allow_emacs_prompt && emacs_socket < 0) > + pinentry_emacs_init (); > + > + /* If we have successfully connected to Emacs, substitute > + pinentry_cmd_handler to emacs_cmd_handler. Otherwise, set it > + back to fallback_cmd_handler. */ > + if (emacs_socket < 0) > + pinentry_cmd_handler = fallback_cmd_handler; > + else > + pinentry_cmd_handler = emacs_cmd_handler; > + > + return (* pinentry_cmd_handler) (pe); > +} ... > +int > +pinentry_emacs_init (void) > +{ > + char buffer[256]; > + assuan_error_t error; > + > + assert (emacs_socket < 0); > + > + /* Check if we can connect to the Emacs server socket. */ > + if (!set_socket ("pinentry")) > + return 0; > + > + /* Check if the server responds. */ > + read_from_emacs (emacs_socket, INITIAL_TIMEOUT, buffer, sizeof (buffer), > + &error); > + return error == ASSUAN_No_Error; > +} If set_socket is successful, but read_from_emacs fails, then emacs_socket will be valid (>= 0) and the test in initial_emacs_cmd_handler will fail. I think initial_emacs_cmd_handler either needs to test the return result of pinentry_emacs_init or pinentry_emacs_init needs to deinit the socket if emacs doesn't have pinentry support. > diff --git a/pinentry/pinentry.c b/pinentry/pinentry.c > index 6f7a62c..9619696 100644 > --- a/pinentry/pinentry.c > +++ b/pinentry/pinentry.c > @@ -855,6 +861,13 @@ option_handler (ASSUAN_CONTEXT ctx, const char *key, const char *value) > pinentry.allow_external_password_cache = 1; > pinentry.tried_password_cache = 0; > } > + else if (!strcmp (key, "allow-emacs-prompt") && !*value) > + { > + pinentry.allow_emacs_prompt = 1; > +#ifdef INSIDE_EMACS > + pinentry_enable_emacs_cmd_handler (); > +#endif > + } > else > return ASSUAN_Invalid_Option; > return 0; pinentry_enable_emacs_cmd_handler can be called multiple times, but this function isn't designed for this. void pinentry_enable_emacs_cmd_handler (void) { const char *envvar; /* Check if INSIDE_EMACS envvar is set. */ envvar = getenv ("INSIDE_EMACS"); if (!envvar || !*envvar) return; /* Substitute pinentry_cmd_handler to initial_emacs_cmd_handler. */ fallback_cmd_handler = pinentry_cmd_handler; pinentry_cmd_handler = initial_emacs_cmd_handler; } On the second call, fallback_cmd_handler is set to initial_emacs_cmd_handler, which is not what we want. Consider: $ INSIDE_EMACS=1 curses/pinentry-curses OK Your orders please option allow-emacs-prompt OK getpin stat: No such file or directory D 123 OK $ INSIDE_EMACS=1 curses/pinentry-curses OK Your orders please option allow-emacs-prompt OK option allow-emacs-prompt OK getpin stat: No such file or directory stat: No such file or directory stat: No such file or directory ... Also, since pinentry_enable_emacs_cmd_handler is only called from the option handler, I don't think we need the field allow_emacs_prompt in the pinentry structure. Thanks! :) Neal From wk at gnupg.org Sun Jun 14 14:52:55 2015 From: wk at gnupg.org (Werner Koch) Date: Sun, 14 Jun 2015 14:52:55 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <871theh9sz.wl-neal@walfield.org> (Neal H. Walfield's message of "Sun, 14 Jun 2015 12:19:08 +0200") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87fv5xgr8j.wl-neal@walfield.org> <87wpz96uuq.fsf-ueno@gnu.org> <871thfrsjv.fsf-ueno@gnu.org> <871theh9sz.wl-neal@walfield.org> Message-ID: <87381u4fko.fsf@vigenere.g10code.de> On Sun, 14 Jun 2015 12:19, neal at walfield.org said: >> explicitly unsetenv'ing INSIDE_EMACS in gpg-agent, when >> allow-emacs-pinentry is not set in gpg-agent.conf (like we do for >> DISPLAY, when keep-display is not set). > > I seem to remember Werner suggesting that this would require a large > change, but if it is easy, I would welcome this approach. Actually we do this for DISPLAY on gpg-agent startup anyway thus I think we could do that for INSIDE_EMACS too. On gpg-agent startup and in atfork_cb. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Sun Jun 14 15:35:14 2015 From: neal at walfield.org (Neal H. Walfield) Date: Sun, 14 Jun 2015 15:35:14 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87381u4fko.fsf@vigenere.g10code.de> References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87fv5xgr8j.wl-neal@walfield.org> <87wpz96uuq.fsf-ueno@gnu.org> <871thfrsjv.fsf-ueno@gnu.org> <871theh9sz.wl-neal@walfield.org> <87381u4fko.fsf@vigenere.g10code.de> Message-ID: <87zj42fm5p.wl-neal@walfield.org> At Sun, 14 Jun 2015 14:52:55 +0200, Werner Koch wrote: > > On Sun, 14 Jun 2015 12:19, neal at walfield.org said: > > >> explicitly unsetenv'ing INSIDE_EMACS in gpg-agent, when > >> allow-emacs-pinentry is not set in gpg-agent.conf (like we do for > >> DISPLAY, when keep-display is not set). > > > > I seem to remember Werner suggesting that this would require a large > > change, but if it is easy, I would welcome this approach. > > Actually we do this for DISPLAY on gpg-agent startup anyway thus I think > we could do that for INSIDE_EMACS too. On gpg-agent startup and in > atfork_cb. Now that I think about this some more: isn't it required that we ignore the setting of INSIDE_EMACS for gpg-agent? We want to use whatever value was in gpg's environment. First, we don't want the pinentry to appear in an emacs that the user is not using. Second, if the user restarts emacs, the new value needs to be propagated somehow. Or am I confused and emacs always start its own gpg-agent? Thanks, :) Neal From wk at gnupg.org Sun Jun 14 19:11:35 2015 From: wk at gnupg.org (Werner Koch) Date: Sun, 14 Jun 2015 19:11:35 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87zj42fm5p.wl-neal@walfield.org> (Neal H. Walfield's message of "Sun, 14 Jun 2015 15:35:14 +0200") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87fv5xgr8j.wl-neal@walfield.org> <87wpz96uuq.fsf-ueno@gnu.org> <871thfrsjv.fsf-ueno@gnu.org> <871theh9sz.wl-neal@walfield.org> <87381u4fko.fsf@vigenere.g10code.de> <87zj42fm5p.wl-neal@walfield.org> Message-ID: <87wpz62p14.fsf@vigenere.g10code.de> On Sun, 14 Jun 2015 15:35, neal at walfield.org said: > Now that I think about this some more: isn't it required that we > ignore the setting of INSIDE_EMACS for gpg-agent? We want to use If we consider INSIDE_EMACS to have a simlar effect like DISPLAY we should do this. But be prepared that soon someone will ask for a --keep-inside-emacs option to make it really similar on how we handle DISPLAY. > Or am I confused and emacs always start its own gpg-agent? No, it does not. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Sun Jun 14 19:27:37 2015 From: neal at walfield.org (Neal H. Walfield) Date: Sun, 14 Jun 2015 19:27:37 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87wpz62p14.fsf@vigenere.g10code.de> References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87fv5xgr8j.wl-neal@walfield.org> <87wpz96uuq.fsf-ueno@gnu.org> <871thfrsjv.fsf-ueno@gnu.org> <871theh9sz.wl-neal@walfield.org> <87381u4fko.fsf@vigenere.g10code.de> <87zj42fm5p.wl-neal@walfield.org> <87wpz62p14.fsf@vigenere.g10code.de> Message-ID: <87y4jmfbee.wl-neal@walfield.org> At Sun, 14 Jun 2015 19:11:35 +0200, Werner Koch wrote: > On Sun, 14 Jun 2015 15:35, neal at walfield.org said: > > > Now that I think about this some more: isn't it required that we > > ignore the setting of INSIDE_EMACS for gpg-agent? We want to use > > If we consider INSIDE_EMACS to have a simlar effect like DISPLAY we > should do this. But be prepared that soon someone will ask for a > --keep-inside-emacs option to make it really similar on how we handle > DISPLAY. In what situation does that make sense? Don't we always want to use the DISPLAY of the gpg process and not the gpg-agent? I think the same holds for INSIDE_EMACS. Thanks, ) Neal From ueno at gnu.org Mon Jun 15 03:55:13 2015 From: ueno at gnu.org (Daiki Ueno) Date: Mon, 15 Jun 2015 10:55:13 +0900 Subject: 2.1.5; documentation build failure Message-ID: I noticed a minor build failure when building gnupg from git: $ git clean -xdff $ ./autogen.sh $ ./configure --sysconfdir=/etc --enable-maintainer-mode $ make ... gnupg.texi:4: @include: could not find defs.inc gnupg.texi:29: warning: undefined flag: VERSION I guess defs.inc should be properly marked as prerequisites, or the file should be renamed back to version.texi? (info "(automake) Texinfo") mentions: If the ?.texi? file ?@include?s ?version.texi?, then that file will be automatically generated. Regards, -- Daiki Ueno From gniibe at fsij.org Mon Jun 15 04:58:54 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 15 Jun 2015 11:58:54 +0900 Subject: pinentry-curses can be forced to loop endlessly In-Reply-To: <20150613141659.gPhW11fuvJQm%sdaoden@yandex.com> References: <557A84D4.9020607@fsij.org> <20150613141659.gPhW11fuvJQm%sdaoden@yandex.com> Message-ID: <557E3F6E.6000101@fsij.org> On 06/13/2015 11:16 PM, Steffen Nurpmeso wrote: > $ echo bla|MAILRC=/tmp/.rc mailx -n -dvv -s sub du at auch > LOAD 80 bytes > user = steffen, homedir = /home/steffen > gpg: encrypted with 4096-bit RSA key, ID A1862748, created 2014-07-08 > "Steffen Nurpmeso " > gpg: public key decryption failed: Operation cancelled > gpg: decryption failed: No secret key > *agent-shell-lookup* execution failure (`gpg -d /tmp/.pass.gpg') > "/home/steffen/dead.letter" 1/4 > ... message not sent. OK. It fails correctly when it tries to invoke pinentry-curses. The particular issue of endless pinentry was fixed. > But note that screen handling is still completely messy from the > pinentry side of the road, here just two snippets of what i see: I understand your problem. I think that this is another issue (than endless pinentry). I think that users would not like to use pinentry-curses in the scenario you provided (from S-nail), because S-nail and pinentry-curses interfere single terminal screen. > Btw.: does pinentry-gtk2/-qt4/.. also stop working when not > running on a terminal? I believe those work well, as well as pinentry-tty. I think that users would like to use pinentry-tty or pinentry-gnome3/-qt4 when gpg is invoked from a program which uses terminal. Please try pinentry-tty, it's there since pinentry 0.8.4. -- From ueno at gnu.org Mon Jun 15 05:15:51 2015 From: ueno at gnu.org (Daiki Ueno) Date: Mon, 15 Jun 2015 12:15:51 +0900 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87y4jmfbee.wl-neal@walfield.org> (Neal H. Walfield's message of "Sun, 14 Jun 2015 19:27:37 +0200") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87fv5xgr8j.wl-neal@walfield.org> <87wpz96uuq.fsf-ueno@gnu.org> <871thfrsjv.fsf-ueno@gnu.org> <871theh9sz.wl-neal@walfield.org> <87381u4fko.fsf@vigenere.g10code.de> <87zj42fm5p.wl-neal@walfield.org> <87wpz62p14.fsf@vigenere.g10code.de> <87y4jmfbee.wl-neal@walfield.org> Message-ID: "Neal H. Walfield" writes: > At Sun, 14 Jun 2015 19:11:35 +0200, > Werner Koch wrote: >> On Sun, 14 Jun 2015 15:35, neal at walfield.org said: >> >> > Now that I think about this some more: isn't it required that we >> > ignore the setting of INSIDE_EMACS for gpg-agent? We want to use >> >> If we consider INSIDE_EMACS to have a simlar effect like DISPLAY we >> should do this. But be prepared that soon someone will ask for a >> --keep-inside-emacs option to make it really similar on how we handle >> DISPLAY. > > In what situation does that make sense? Don't we always want to use > the DISPLAY of the gpg process and not the gpg-agent? I think the > same holds for INSIDE_EMACS. For INSIDE_EMACS, it would make more sense to clear the variable on gpg-agent startup. Otherwise, the initial value will remain in effect during the session: $ pkill gpg-agent $ INSIDE_EMACS=1 gpg2 --symmetric -o /dev/null < /dev/null ... prompted through Emacs ... $ unset INSIDE_EMACS $ gpg2 --symmetric -o /dev/null < /dev/null ... prompted through Emacs, though we expect GUI pinentry ... This is because gpg-agent is launched on the first call of gpg2 with INSIDE_EMACS is set, while on the second call, gpg-agent is not told that INSIDE_EMACS is no longer set, i.e., no "OPTION putenv=..." line is sent to gpg-agent when the envvar is not set. I'd suggest to clear INSIDE_EMACS unconditionally on gpg-agent startup (a trivial patch attached). Regards, -- Daiki Ueno -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-agent-Unset-INSIDE_EMACS-on-gpg-agent-startup.patch Type: text/x-patch Size: 1076 bytes Desc: not available URL: From gniibe at fsij.org Mon Jun 15 07:48:11 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 15 Jun 2015 14:48:11 +0900 Subject: trustdb race fix patch backported to 1.4 and 2.0 Message-ID: <557E671B.8050708@fsij.org> For the issue 1675 (which is reported to 1.4): https://bugs.gnupg.org/gnupg/issue1675 The fix was already included in 2.1. I backported it and pushed for 1.4 and 2.0, today. It was tested by make && make check. Also, tested by the minimized scenario with GDB. -- From neal at walfield.org Sat Jun 13 22:02:38 2015 From: neal at walfield.org (Neal H. Walfield) Date: Sat, 13 Jun 2015 22:02:38 +0200 Subject: Pinentry linking to libassuan? (was: Add inside-Emacs mode to GUI pinentry programs) In-Reply-To: <873826fqms.fsf_-_@vigenere.g10code.de> References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <873826fqms.fsf_-_@vigenere.g10code.de> Message-ID: <87381vgyw1.wl-neal@walfield.org> Hi, At Fri, 05 Jun 2015 11:31:23 +0200, Werner Koch wrote: > given that pinentry gets more and more complicated it does not anymore > fulfill its original goal to be small enough to be easily audited. One > of the main problem here has been the major changes to Gtk+ over the > last decade. And now of Emacs socket code is added as well. > > Originally Pinentry should be mostly self-standing but today this is > only true for the plain curses, tty and Windows versions. Most users > however build one of the real GUI versions with all their large > dependencies. > > The question is whether we should keep on using our much stripped down > versions of libassuan and libgpg-error or switch over to use libassuan > and libgpg-error directly. In fact, both libraries are required by > GnuPG itself and also be any software using GPGME. Thus we can expect > that such a change won't introduce any new platform problems. The attached patch does exactly this. Let me know if you have any objections to applying it. :) Neal From 524818b7d344c470a5072a43e977524554f1a249 Mon Sep 17 00:00:00 2001 From: "Neal H. Walfield" Date: Sat, 13 Jun 2015 21:43:33 +0200 Subject: [PATCH] Remove internal mini-libassuan implementation and link to libassuan. * assuan/ChangeLog-old: Remove file. * assuan/Makefile.am: Remove file. * assuan/README.1st: Remove file. * assuan/assuan-buffer.c: Remove file. * assuan/assuan-defs.h: Remove file. * assuan/assuan-handler.c: Remove file. * assuan/assuan-listen.c: Remove file. * assuan/assuan-pipe-server.c: Remove file. * assuan/assuan-util.c: Remove file. * assuan/assuan.h: Remove file. * assuan/mkerrors: Remove file. * configure.ac: Check for libgpg-error and libassuan. (COMMON_CFLAGS): Add $GPG_ERROR_CFLAGS and $LIBASSUAN_CFLAGS. (COMMAND_LIBS): Add $GPG_ERROR_LIBS and $LIBASSUAN_LIBS. (GPG_ERR_ENABLE_GETTEXT_MACROS): Define this macro. (GPG_ERR_ENABLE_ERRNO_MACROS): Likewise. (GNUPG_LIBASSUAN_VERSION): Likewise. (AC_CONFIG_FILES): Don't generate assuan/Makefile. * Makefile.am (SUBDIRS): Remove assuan. * curses/Makefile.am (LDADD): Remove ../assuan/libassuan.a. * gnome3/Makefile.am (AM_CPPFLAGS): Remove -I$(top_srcdir)/assuan. (LDADD): Remove ../assuan/libassuan.a. * gtk+-2/Makefile.am (LDADD): Remove ../assuan/libassuan.a. * pinentry/Makefile.am: Remove -I$(top_srcdir)/assuan. * qt4/Makefile.am (AM_CPPFLAGS): Remove -I$(top_srcdir)/assuan. (pinentry_qt4_LDADD): Remove $(top_builddir)/assuan/libassuan.a. * tty/Makefile.am (LDADD): Remove ../assuan/libassuan.a. * gnome3/pinentry-gnome3.c: Include , not "assuan.h". Replace ASSUAN_General_Error with gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ASS_GENERAL), etc. * pinentry/pinentry-curses.c: Likewise. * pinentry/pinentry.c: Likewise. (pinentry_assuan_reset_handler): Change return type to gpg_error_t. Change type of argument CTX from ASSUAN_CONTEXT to assuan_context_t. Return 0. (pinentry_inq_quality): Change variable CTX's type from ASSUAN_CONTEXT to assuan_context_t. (assuan_malloc_hooks): New variable. (pinentry_init): Call gpgrt_check_version. Change use of assuan_set_malloc_hooks to match libassuan's semantics. (option_handler): Return a gpg_error_t, not an int. Replace use of ASSUAN_Out_Of_Core with gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM), etc. (cmd_setdesc): Return a gpg_error_t, not an int. Change argument CTX's type from ASSUAN_CONTEXT to assuan_context_t. Replace use of ASSUAN_Out_Of_Core with gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM), etc. (cmd_setprompt): Likewise. (cmd_setkeyinfo): Likewise. (cmd_setrepeat): Likewise. (cmd_setrepeaterror): Likewise. (cmd_seterror): Likewise. (cmd_setok): Likewise. (cmd_setnotok): Likewise. (cmd_setcancel): Likewise. (cmd_settimeout): Likewise. (cmd_settitle): Likewise. (cmd_setqualitybar): Likewise. (cmd_setqualitybar_tt): Likewise. (cmd_getpin): Likewise. (cmd_confirm): Likewise. (cmd_message): Likewise. (cmd_getinfo): Likewise. (cmd_clear_passphrase): Likewise. (register_commands): Likewise. Change use of assuan_register_command to match libassuan's semantics. (pinentry_loop2): Change variable RC's type from int to gpg_error_t. Change variable CTX's type from ASSUAN_CONTEXT to assuan_context_t. Use assuan_new to initialize CTX. Change use of assuan_init_pipe_server to match libassuan's semantics. Replace use of assuan_strerror with gpg_strerror. Call assuan_release instead of assuan_deinit_server. Conflicts: Makefile.am gnome3/Makefile.am gtk+-2/Makefile.am qt4/Makefile.am --- Makefile.am | 2 +- assuan/ChangeLog-old | 254 ----------------- assuan/Makefile.am | 43 --- assuan/README.1st | 1 - assuan/assuan-buffer.c | 474 ------------------------------- assuan/assuan-defs.h | 139 --------- assuan/assuan-handler.c | 672 -------------------------------------------- assuan/assuan-listen.c | 132 --------- assuan/assuan-pipe-server.c | 127 --------- assuan/assuan-util.c | 196 ------------- assuan/assuan.h | 202 ------------- assuan/mkerrors | 71 ----- configure.ac | 77 ++++- curses/Makefile.am | 3 +- gnome3/Makefile.am | 5 +- gnome3/pinentry-gnome3.c | 8 +- gtk+-2/Makefile.am | 2 +- pinentry/Makefile.am | 2 +- pinentry/pinentry-curses.c | 27 +- pinentry/pinentry.c | 234 ++++++++------- qt4/Makefile.am | 5 +- tty/Makefile.am | 3 +- 22 files changed, 231 insertions(+), 2448 deletions(-) delete mode 100644 assuan/ChangeLog-old delete mode 100644 assuan/Makefile.am delete mode 100644 assuan/README.1st delete mode 100644 assuan/assuan-buffer.c delete mode 100644 assuan/assuan-defs.h delete mode 100644 assuan/assuan-handler.c delete mode 100644 assuan/assuan-listen.c delete mode 100644 assuan/assuan-pipe-server.c delete mode 100644 assuan/assuan-util.c delete mode 100644 assuan/assuan.h delete mode 100755 assuan/mkerrors diff --git a/Makefile.am b/Makefile.am index 177f37e..71f8541 100644 --- a/Makefile.am +++ b/Makefile.am @@ -64,7 +64,7 @@ else pinentry_w32 = endif -SUBDIRS = assuan secmem pinentry ${pinentry_curses} ${pinentry_tty} \ +SUBDIRS = secmem pinentry ${pinentry_curses} ${pinentry_tty} \ ${pinentry_gtk_2} ${pinentry_gnome_3} ${pinentry_qt4} \ ${pinentry_w32} doc diff --git a/assuan/ChangeLog-old b/assuan/ChangeLog-old deleted file mode 100644 index 077831d..0000000 --- a/assuan/ChangeLog-old +++ /dev/null @@ -1,254 +0,0 @@ -2012-08-08 Werner Koch - - NB: ChangeLog files are no longer manually maintained. Starting - on August 8, 2012 we put change information only in the GIT commit - log, and generate a top-level ChangeLog file from logs at "make - dist". See doc/HACKING for details. - -2008-02-14 Werner Koch - - * assuan.h (ASSUAN_Parameter_Error): Add new alias. - -2008-01-10 Marcus Brinkmann - - * assuan-handler.c (dispatch_command): Use Syntax_Error instead of - Invalid_Command. - * assuan.h (assuan_error_t): Change all error codes to gpg-error - codes. - -2004-12-22 Werner Koch - - * assuan.h (assuan_error_t, assuan_context_t): New aliases. - * assuan-buffer.c (readline): Renamed EOF to ISEOF to avoid - compiler warnings. - -2004-04-20 Werner Koch - - * mkerrors: Add missing last LF. - -2004-01-30 Werner Koch - - * assuan-inquire.c, assuan-connect.c, assuan-client.c - * assuan-socket-server.c, assuan-pipe-connect.c - * assuan-socket-connect.c: Removed. - * assuan-handler.c (assuan_get_data_fp): Removed. - -2003-12-23 Werner Koch - - * Makefile.am (EXTRA_DIST): Added Manifest. - * Manifest: Added. - -2003-12-22 Werner Koch - - * assuan.h (ASSUAN_Locale_Problem): Added. - -2002-04-04 Werner Koch - - * assuan-buffer.c (my_log_prefix): New. Use it for all i/o debug - output. - -2002-03-06 Werner Koch - - * assuan-client.c (_assuan_read_from_server): Detect END. - (assuan_transact): Pass it to the data callback. - -2002-02-27 Werner Koch - - * assuan-client.c (assuan_transact): Add 2 more arguments to - support status lines. Passing NULL yields the old behaviour. - - * assuan-handler.c (process_request): Flush data lines send - without using the data fp. - -2002-02-14 Werner Koch - - * assuan-inquire.c (assuan_inquire): Check for a cancel command - and return ASSUAN_Canceled. Allow for non-data inquiry. - - * assuan.h: Add a few token specific error codes. - -2002-02-13 Werner Koch - - * assuan-defs.h (assuan_context_s): New var CLIENT_PID. - * assuan-pipe-server.c (_assuan_new_context): set default value. - * assuan-socket-server.c (accept_connection): get the actual pid. - -2002-02-12 Werner Koch - - * assuan-buffer.c (writen,readline) [USE_GNU_PT]: Use pth_read/write. - * assuan-socket-server.c (accept_connection) [USE_GNU_PTH]: Ditto. - -2002-02-01 Marcus Brinkmann - - * Makefile.am (MOSTLYCLEANFILES): New variable. - -2002-01-23 Werner Koch - - * assuan-socket-connect.c (LOGERRORX): and removed typo. - -2002-01-22 Marcus Brinkmann - - * assuan-socket-connect.c (LOGERRORX): Reverse arguments to fputs. - -2002-01-21 Werner Koch - - * assuan-connect.c: Move all except assuan_get_pid to... - * assuan-pipe-connect.c: this. - (assuan_pipe_disconnect): Removed. - (do_finish, do_deinit): New - (assuan_pipe_connect): and set them into the context. - * assuan-socket-connect.c: New. - - * assuan-util.c (_assuan_log_sanitized_string): New. - - * assuan-pipe-server.c (assuan_init_pipe_server): Factored most - code out to ... - (_assuan_new_context): new func. - (_assuan_release_context): New - * assuan-connect.c (assuan_pipe_connect): Use the new functions. - -2002-01-20 Werner Koch - - * assuan.h: Added Invalid Option error code. - - * assuan-handler.c (std_handler_option): New. - (std_cmd_tbl): Add OPTION as standard command. - (assuan_register_option_handler): New. - (dispatch_command): Use case insensitive matching as a fallback. - (my_strcasecmp): New. - -2002-01-19 Werner Koch - - * assuan-buffer.c (_assuan_read_line): Add output logging. - (assuan_write_line): Ditto. - (_assuan_cookie_write_data): Ditto. - (_assuan_cookie_write_flush): Ditto. - * assuan-util.c (_assuan_log_print_buffer): New. - (assuan_set_log_stream): New. - (assuan_begin_confidential): New. - (assuan_end_confidential): New. - - * assuan-defs.h: Add a few handler variables. - * assuan-pipe-server.c (assuan_deinit_pipe_server): Removed. - (deinit_pipe_server): New. - (assuan_deinit_server): New. Changed all callers to use this. - * assuan-listen.c (assuan_accept): Use the accept handler. - * assuan-handler.c (process_request): Use the close Handler. - * assuan-socket-server.c: New. - -2002-01-14 Werner Koch - - * assuan-client.c (_assuan_read_from_server): Skip spaces after - the keyword. - -2002-01-03 Werner Koch - - * assuan-handler.c (assuan_set_okay_line): New. - (process_request): And use it here. - -2002-01-02 Werner Koch - - * assuan-inquire.c (init_membuf,put_membuf,get_membuf): Apply a - hidden 0 behind the buffer so that the buffer can be used as a - string in certain contexts. - -2001-12-14 Marcus Brinkmann - - * assuan-connect.c (assuan_pipe_connect): New argument - FD_CHILD_LIST. Don't close those fds. - * assuan.h: Likewise for prototype. - -2001-12-14 Werner Koch - - * assuan-listen.c (assuan_close_input_fd): New. - (assuan_close_output_fd): New. - * assuan-handler.c (std_handler_reset): Always close them after a - reset command. - (std_handler_bye): Likewise. - -2001-12-14 Marcus Brinkmann - - * assuan-buffer.c (_assuan_read_line): New variable ATTICLEN, use - it to save the length of the attic line. - Rediddle the code a bit to make it more clear what happens. - -2001-12-14 Marcus Brinkmann - - * assuan-defs.h (LINELENGTH): Define as ASSUAN_LINELENGTH. - assuan.h: Define ASSUAN_LINELENGTH. - -2001-12-13 Marcus Brinkmann - - * assuan-buffer.c (assuan_read_line): Fix order of execution to - get correct return values. - -2001-12-13 Werner Koch - - * assuan-handler.c (assuan_get_active_fds): Fixed silly bug, - pretty obvious that nobody ever tested this function. - -2001-12-12 Werner Koch - - * assuan-connect.c (assuan_pipe_connect): Implemented the inital - handshake. - * assuan-client.c (read_from_server): Renamed to - (_assuan_read_from_server): this and made external. - - * assuan-listen.c (assuan_set_hello_line): New. - (assuan_accept): Use a custom hello line is available. - - * assuan-buffer.c (assuan_read_line): New. - (assuan_pending_line): New. - (_assuan_write_line): Renamed to .. - (assuan_write_line): this, made public and changed all callers. - -2001-12-04 Werner Koch - - * assuan-connect.c (assuan_pipe_connect): Add more error reporting. - * assuan-client.c: New. - - * assuan-inquire.c: New. - * assuan-handler.c (process_request): Check for nested invocations. - -2001-11-27 Werner Koch - - * assuan-handler.c (assuan_register_input_notify): New. - (assuan_register_output_notify): New. - -2001-11-26 Werner Koch - - * assuan.h: Added more status codes. - -2001-11-25 Werner Koch - - * assuan-handler.c (assuan_register_bye_notify) - (assuan_register_reset_notify) - (assuan_register_cancel_notify): New and call them from the - standard handlers. - (assuan_process): Moved bulk of function to .. - (process_request): .. new. - (assuan_process_next): One shot version of above. - (assuan_get_active_fds): New. - -2001-11-24 Werner Koch - - * assuan-connect.c (assuan_get_pid): New. - - * assuan-buffer.c (_assuan_read_line): Deal with reads of more - than a line. - * assuan-defs.h: Add space in the context for this. - - - ************************************************************ - * Please note that this is a stripped down Assuan version. * - ************************************************************ - - Copyright 2001, 2002, 2004 Free Software Foundation, Inc. - - This file is free software; as a special exception the author gives - unlimited permission to copy and/or distribute it, with or without - modifications, as long as this notice is preserved. - - This file is distributed in the hope that it will be useful, but - WITHOUT ANY WARRANTY, to the extent permitted by law; without even the - implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. diff --git a/assuan/Makefile.am b/assuan/Makefile.am deleted file mode 100644 index 2553f3e..0000000 --- a/assuan/Makefile.am +++ /dev/null @@ -1,43 +0,0 @@ -# Assuan Makefile for test purposes -# Copyright (C) 2001 Free Software Foundation, Inc. -# -# This file is part of GnuPG. -# -# GnuPG is free software; you can redistribute it and/or modify -# it under the terms of the GNU General Public License as published by -# the Free Software Foundation; either version 2 of the License, or -# (at your option) any later version. -# -# GnuPG is distributed in the hope that it will be useful, -# but WITHOUT ANY WARRANTY; without even the implied warranty of -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -# GNU General Public License for more details. -# -# You should have received a copy of the GNU General Public License -# along with this program; if not, write to the Free Software -# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA - -## Process this file with automake to produce Makefile.in - -EXTRA_DIST = mkerrors ChangeLog-old -AM_CPPFLAGS = -I.. -I$(top_srcdir)/include -BUILT_SOURCES = assuan-errors.c -MOSTLYCLEANFILES = assuan-errors.c - -noinst_LIBRARIES = libassuan.a - - -#libassuan_a_LDFLAGS = -libassuan_a_SOURCES = \ - assuan.h \ - assuan-defs.h \ - assuan-util.c \ - assuan-errors.c \ - assuan-buffer.c \ - assuan-handler.c \ - assuan-listen.c \ - assuan-pipe-server.c - - -assuan-errors.c : assuan.h - $(srcdir)/mkerrors < $(srcdir)/assuan.h > assuan-errors.c diff --git a/assuan/README.1st b/assuan/README.1st deleted file mode 100644 index bb52959..0000000 --- a/assuan/README.1st +++ /dev/null @@ -1 +0,0 @@ -Please don't modify it here but in the copy which comes with GnuPG. \ No newline at end of file diff --git a/assuan/assuan-buffer.c b/assuan/assuan-buffer.c deleted file mode 100644 index 363d6cf..0000000 --- a/assuan/assuan-buffer.c +++ /dev/null @@ -1,474 +0,0 @@ -/* assuan-buffer.c - read and send data - * Copyright (C) 2001 Free Software Foundation, Inc. - * - * This file is part of GnuPG. - * - * GnuPG is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * GnuPG is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA - */ - -#include -#include -#include -#include -#ifndef HAVE_W32CE_SYSTEM -# include -#endif -#include -#include -#ifdef USE_GNU_PTH -# include -#endif -#ifdef HAVE_W32CE_SYSTEM -# include -#endif - -#include "assuan-defs.h" - -#ifdef HAVE_JNLIB_LOGGING -#include "../jnlib/logging.h" -#endif - -#ifdef HAVE_W32CE_SYSTEM -const char * -strerror (int e) -{ - return "error"; -} -static int errno; -#endif - - -static const char * -my_log_prefix (void) -{ -#ifdef HAVE_JNLIB_LOGGING - return log_get_prefix (NULL); -#else - return ""; -#endif -} - - -static int -writen ( int fd, const char *buffer, size_t length ) -{ - while (length) - { - int nwritten; -#ifdef HAVE_W32CE_SYSTEM - do - { - if (!WriteFile ((HANDLE)fd, buffer, length, &nwritten, NULL)) - nwritten = -1; - } - while (nwritten == -1 && GetLastError () == ERROR_PIPE_NOT_CONNECTED); -#elif defined(USE_GNU_PTH) - nwritten = pth_write (fd, buffer, length); -#else - nwritten = write (fd, buffer, length); -#endif - if (nwritten < 0) - { -#ifndef HAVE_W32CE_SYSTEM - if (errno == EINTR) - continue; -#endif - return -1; /* write error */ - } - length -= nwritten; - buffer += nwritten; - } - return 0; /* okay */ -} - -/* read an entire line */ -static int -readline (int fd, char *buf, size_t buflen, int *r_nread, int *iseof) -{ - size_t nleft = buflen; char *p; - - *iseof = 0; - *r_nread = 0; - while (nleft > 0) - { - int n; -#ifdef HAVE_W32CE_SYSTEM - do - { - if (!ReadFile ((HANDLE)fd, buf, nleft, &n, NULL)) - n = -1; - } - while (n == -1 && GetLastError () == ERROR_PIPE_NOT_CONNECTED); -#elif defined(USE_GNU_PTH) - n = pth_read (fd, buf, nleft); -#else - n = read (fd, buf, nleft); -#endif - if (n < 0) - { -#ifndef HAVE_W32CE_SYSTEM - if (errno == EINTR) - continue; -#endif - return -1; /* read error */ - } - else if (!n) - { - *iseof = 1; - break; /* allow incomplete lines */ - } - p = buf; - nleft -= n; - buf += n; - *r_nread += n; - - for (; n && *p != '\n'; n--, p++) - ; - if (n) - break; /* at least one full line available - that's enough for now */ - } - - return 0; -} - - -int -_assuan_read_line (ASSUAN_CONTEXT ctx) -{ - char *line = ctx->inbound.line; - int n, nread, atticlen; - int rc; - - if (ctx->inbound.eof) - return -1; - - atticlen = ctx->inbound.attic.linelen; - if (atticlen) - { - memcpy (line, ctx->inbound.attic.line, atticlen); - ctx->inbound.attic.linelen = 0; - for (n=0; n < atticlen && line[n] != '\n'; n++) - ; - if (n < atticlen) - { - rc = 0; /* found another line in the attic */ - nread = atticlen; - atticlen = 0; - } - else - { /* read the rest */ - assert (atticlen < LINELENGTH); - rc = readline (ctx->inbound.fd, line + atticlen, - LINELENGTH - atticlen, &nread, &ctx->inbound.eof); - } - } - else - rc = readline (ctx->inbound.fd, line, LINELENGTH, - &nread, &ctx->inbound.eof); - if (rc) - { - if (ctx->log_fp) - fprintf (ctx->log_fp, "%s[%p] <- [Error: %s]\n", - my_log_prefix (), ctx, strerror (errno)); - return ASSUAN_Read_Error; - } - if (!nread) - { - assert (ctx->inbound.eof); - if (ctx->log_fp) - fprintf (ctx->log_fp, "%s[%p] <- [EOF]\n", my_log_prefix (),ctx); - return -1; - } - - ctx->inbound.attic.pending = 0; - nread += atticlen; - for (n=0; n < nread; n++) - { - if (line[n] == '\n') - { - if (n+1 < nread) - { - char *s, *d; - int i; - - n++; - /* we have to copy the rest because the handlers are - allowed to modify the passed buffer */ - for (d=ctx->inbound.attic.line, s=line+n, i=nread-n; i; i--) - { - if (*s=='\n') - ctx->inbound.attic.pending = 1; - *d++ = *s++; - } - ctx->inbound.attic.linelen = nread-n; - n--; - } - if (n && line[n-1] == '\r') - n--; - line[n] = 0; - ctx->inbound.linelen = n; - if (ctx->log_fp) - { - fprintf (ctx->log_fp, "%s[%p] <- ", my_log_prefix (), ctx); - if (ctx->confidential) - fputs ("[Confidential data not shown]", ctx->log_fp); - else - _assuan_log_print_buffer (ctx->log_fp, - ctx->inbound.line, - ctx->inbound.linelen); - putc ('\n', ctx->log_fp); - } - return 0; - } - } - - if (ctx->log_fp) - fprintf (ctx->log_fp, "%s[%p] <- [Invalid line]\n", my_log_prefix (), ctx); - *line = 0; - ctx->inbound.linelen = 0; - return ctx->inbound.eof? ASSUAN_Line_Not_Terminated : ASSUAN_Line_Too_Long; -} - - -/* Read the next line from the client or server and return a pointer - to a buffer with holding that line. linelen returns the length of - the line. This buffer is valid until another read operation is - done on this buffer. The caller is allowed to modify this buffer. - He should only use the buffer if the function returns without an - error. - - Returns: 0 on success or an assuan error code - See also: assuan_pending_line(). -*/ -AssuanError -assuan_read_line (ASSUAN_CONTEXT ctx, char **line, size_t *linelen) -{ - AssuanError err; - - if (!ctx) - return ASSUAN_Invalid_Value; - - err = _assuan_read_line (ctx); - *line = ctx->inbound.line; - *linelen = ctx->inbound.linelen; - return err; -} - - -/* Return true when a full line is pending for a read, without the need - for actual IO */ -int -assuan_pending_line (ASSUAN_CONTEXT ctx) -{ - return ctx && ctx->inbound.attic.pending; -} - - -AssuanError -assuan_write_line (ASSUAN_CONTEXT ctx, const char *line ) -{ - int rc; - - if (!ctx) - return ASSUAN_Invalid_Value; - - /* fixme: we should do some kind of line buffering */ - if (ctx->log_fp) - { - fprintf (ctx->log_fp, "%s[%p] -> ", my_log_prefix (), ctx); - if (ctx->confidential) - fputs ("[Confidential data not shown]", ctx->log_fp); - else - _assuan_log_print_buffer (ctx->log_fp, - line, strlen (line)); - putc ('\n', ctx->log_fp); - } - - rc = writen (ctx->outbound.fd, line, strlen(line)); - if (rc) - rc = ASSUAN_Write_Error; - if (!rc) - { - rc = writen (ctx->outbound.fd, "\n", 1); - if (rc) - rc = ASSUAN_Write_Error; - } - - return rc; -} - - - -/* Write out the data in buffer as datalines with line wrapping and - percent escaping. This fucntion is used for GNU's custom streams */ -int -_assuan_cookie_write_data (void *cookie, const char *buffer, size_t size) -{ - ASSUAN_CONTEXT ctx = cookie; - char *line; - size_t linelen; - - if (ctx->outbound.data.error) - return 0; - - line = ctx->outbound.data.line; - linelen = ctx->outbound.data.linelen; - line += linelen; - while (size) - { - /* insert data line header */ - if (!linelen) - { - *line++ = 'D'; - *line++ = ' '; - linelen += 2; - } - - /* copy data, keep some space for the CRLF and to escape one character */ - while (size && linelen < LINELENGTH-2-2) - { - if (*buffer == '%' || *buffer == '\r' || *buffer == '\n') - { - sprintf (line, "%%%02X", *(unsigned char*)buffer); - line += 3; - linelen += 3; - buffer++; - } - else - { - *line++ = *buffer++; - linelen++; - } - size--; - } - - if (linelen >= LINELENGTH-2-2) - { - if (ctx->log_fp) - { - fprintf (ctx->log_fp, "%s[%p] -> ", my_log_prefix (), ctx); - if (ctx->confidential) - fputs ("[Confidential data not shown]", ctx->log_fp); - else - _assuan_log_print_buffer (ctx->log_fp, - ctx->outbound.data.line, - linelen); - putc ('\n', ctx->log_fp); - } - *line++ = '\n'; - linelen++; - if (writen (ctx->outbound.fd, ctx->outbound.data.line, linelen)) - { - ctx->outbound.data.error = ASSUAN_Write_Error; - return 0; - } - line = ctx->outbound.data.line; - linelen = 0; - } - } - - ctx->outbound.data.linelen = linelen; - return 0; -} - - -/* Write out any buffered data - This fucntion is used for GNU's custom streams */ -int -_assuan_cookie_write_flush (void *cookie) -{ - ASSUAN_CONTEXT ctx = cookie; - char *line; - size_t linelen; - - if (ctx->outbound.data.error) - return 0; - - line = ctx->outbound.data.line; - linelen = ctx->outbound.data.linelen; - line += linelen; - if (linelen) - { - if (ctx->log_fp) - { - fprintf (ctx->log_fp, "%s[%p] -> ", my_log_prefix (), ctx); - if (ctx->confidential) - fputs ("[Confidential data not shown]", ctx->log_fp); - else - _assuan_log_print_buffer (ctx->log_fp, - ctx->outbound.data.line, - linelen); - putc ('\n', ctx->log_fp); - } - *line++ = '\n'; - linelen++; - if (writen (ctx->outbound.fd, ctx->outbound.data.line, linelen)) - { - ctx->outbound.data.error = ASSUAN_Write_Error; - return 0; - } - ctx->outbound.data.linelen = 0; - } - return 0; -} - - -/** - * assuan_send_data: - * @ctx: An assuan context - * @buffer: Data to send or NULL to flush - * @length: length of the data to send/ - * - * This function may be used by the server or the client to send data - * lines. The data will be escaped as required by the Assuan protocol - * and may get buffered until a line is full. To force sending the - * data out @buffer may be passed as NULL (in which case @length must - * also be 0); however when used by a client this flush operation does - * also send the terminating "END" command to terminate the reponse on - * a INQUIRE response. However, when assuan_transact() is used, this - * function takes care of sending END itself. - * - * Return value: 0 on success or an error code - **/ - -AssuanError -assuan_send_data (ASSUAN_CONTEXT ctx, const void *buffer, size_t length) -{ - if (!ctx) - return ASSUAN_Invalid_Value; - if (!buffer && length) - return ASSUAN_Invalid_Value; - - if (!buffer) - { /* flush what we have */ - _assuan_cookie_write_flush (ctx); - if (ctx->outbound.data.error) - return ctx->outbound.data.error; - if (!ctx->is_server) - return assuan_write_line (ctx, "END"); - } - else - { - _assuan_cookie_write_data (ctx, buffer, length); - if (ctx->outbound.data.error) - return ctx->outbound.data.error; - } - - return 0; -} - - - - diff --git a/assuan/assuan-defs.h b/assuan/assuan-defs.h deleted file mode 100644 index 6c502bf..0000000 --- a/assuan/assuan-defs.h +++ /dev/null @@ -1,139 +0,0 @@ -/* assuan-defs.c - Internal definitions to Assuan - * Copyright (C) 2001 Free Software Foundation, Inc. - * - * This file is part of GnuPG. - * - * GnuPG is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * GnuPG is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA - */ - -#ifndef ASSUAN_DEFS_H -#define ASSUAN_DEFS_H - -#include -#include "assuan.h" - -#define LINELENGTH ASSUAN_LINELENGTH - -struct cmdtbl_s { - const char *name; - int cmd_id; - int (*handler)(ASSUAN_CONTEXT, char *line); -}; - -struct assuan_context_s { - AssuanError err_no; - const char *err_str; - int os_errno; /* last system error number used with certain error codes*/ - - int confidential; - int is_server; /* set if this is context belongs to a server */ - int in_inquire; - char *hello_line; - char *okay_line; /* see assan_set_okay_line() */ - - void *user_pointer; /* for assuan_[gs]et_pointer () */ - - FILE *log_fp; - - struct { - int fd; - int eof; - char line[LINELENGTH]; - int linelen; /* w/o CR, LF - might not be the same as - strlen(line) due to embedded nuls. However a nul - is always written at this pos */ - struct { - char line[LINELENGTH]; - int linelen ; - int pending; /* i.e. at least one line is available in the attic */ - } attic; - } inbound; - - struct { - int fd; - struct { - FILE *fp; - char line[LINELENGTH]; - int linelen; - int error; - } data; - } outbound; - - int pipe_mode; /* We are in pipe mode, i.e. we can handle just one - connection and must terminate then */ - pid_t pid; /* In pipe mode, the pid of the child server process. - In socket mode, the pid of the server */ - int listen_fd; /* The fd we are listening on (used by socket servers) */ - - pid_t client_pid; /* for a socket server the PID of the client or -1 - if not available */ - - void (*deinit_handler)(ASSUAN_CONTEXT); - int (*accept_handler)(ASSUAN_CONTEXT); - int (*finish_handler)(ASSUAN_CONTEXT); - - struct cmdtbl_s *cmdtbl; - size_t cmdtbl_used; /* used entries */ - size_t cmdtbl_size; /* allocated size of table */ - - void (*bye_notify_fnc)(ASSUAN_CONTEXT); - void (*reset_notify_fnc)(ASSUAN_CONTEXT); - void (*cancel_notify_fnc)(ASSUAN_CONTEXT); - int (*option_handler_fnc)(ASSUAN_CONTEXT,const char*, const char*); - void (*input_notify_fnc)(ASSUAN_CONTEXT, const char *); - void (*output_notify_fnc)(ASSUAN_CONTEXT, const char *); - - int input_fd; /* set by INPUT command */ - int output_fd; /* set by OUTPUT command */ - -}; - - -/*-- assuan-pipe-server.c --*/ -int _assuan_new_context (ASSUAN_CONTEXT *r_ctx); -void _assuan_release_context (ASSUAN_CONTEXT ctx); - - -/*-- assuan-handler.c --*/ -int _assuan_register_std_commands (ASSUAN_CONTEXT ctx); - -/*-- assuan-buffer.c --*/ -int _assuan_read_line (ASSUAN_CONTEXT ctx); -int _assuan_cookie_write_data (void *cookie, const char *buffer, size_t size); -int _assuan_cookie_write_flush (void *cookie); - -/*-- assuan-client.c --*/ -AssuanError _assuan_read_from_server (ASSUAN_CONTEXT ctx, int *okay, int *off); - - -/*-- assuan-util.c --*/ -void *_assuan_malloc (size_t n); -void *_assuan_calloc (size_t n, size_t m); -void *_assuan_realloc (void *p, size_t n); -void _assuan_free (void *p); - -#define xtrymalloc(a) _assuan_malloc ((a)) -#define xtrycalloc(a,b) _assuan_calloc ((a),(b)) -#define xtryrealloc(a,b) _assuan_realloc((a),(b)) -#define xfree(a) _assuan_free ((a)) - -#define set_error(c,e,t) assuan_set_error ((c), ASSUAN_ ## e, (t)) - -void _assuan_log_print_buffer (FILE *fp, const void *buffer, size_t length); -void _assuan_log_sanitized_string (const char *string); - - -#endif /*ASSUAN_DEFS_H*/ - diff --git a/assuan/assuan-handler.c b/assuan/assuan-handler.c deleted file mode 100644 index aadad21..0000000 --- a/assuan/assuan-handler.c +++ /dev/null @@ -1,672 +0,0 @@ -/* assuan-handler.c - dispatch commands - * Copyright (C) 2001 Free Software Foundation, Inc. - * - * This file is part of GnuPG. - * - * GnuPG is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * GnuPG is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA - */ - -#include -#include -#include -#include - -#include "assuan-defs.h" - -#define spacep(p) (*(p) == ' ' || *(p) == '\t') -#define digitp(a) ((a) >= '0' && (a) <= '9') - - -static int -dummy_handler (ASSUAN_CONTEXT ctx, char *line) -{ - (void)line; - return set_error (ctx, Server_Fault, "no handler registered"); -} - - -static int -std_handler_nop (ASSUAN_CONTEXT ctx, char *line) -{ - (void)ctx; - (void)line; - return 0; /* okay */ -} - -static int -std_handler_cancel (ASSUAN_CONTEXT ctx, char *line) -{ - (void)line; - if (ctx->cancel_notify_fnc) - ctx->cancel_notify_fnc (ctx); - return set_error (ctx, Not_Implemented, NULL); -} - -static int -std_handler_option (ASSUAN_CONTEXT ctx, char *line) -{ - char *key, *value, *p; - - for (key=line; spacep (key); key++) - ; - if (!*key) - return set_error (ctx, Syntax_Error, "argument required"); - if (*key == '=') - return set_error (ctx, Syntax_Error, "no option name given"); - for (value=key; *value && !spacep (value) && *value != '='; value++) - ; - if (*value) - { - if (spacep (value)) - *value++ = 0; /* terminate key */ - for (; spacep (value); value++) - ; - if (*value == '=') - { - *value++ = 0; /* terminate key */ - for (; spacep (value); value++) - ; - if (!*value) - return set_error (ctx, Syntax_Error, "option argument expected"); - } - if (*value) - { - for (p = value + strlen(value) - 1; p > value && spacep (p); p--) - ; - if (p > value) - *++p = 0; /* strip trailing spaces */ - } - } - - if (*key == '-' && key[1] == '-' && key[2]) - key += 2; /* the double dashes are optional */ - if (*key == '-') - return set_error (ctx, Syntax_Error, - "option should not begin with one dash"); - - if (ctx->option_handler_fnc) - return ctx->option_handler_fnc (ctx, key, value); - return 0; -} - -static int -std_handler_bye (ASSUAN_CONTEXT ctx, char *line) -{ - (void)line; - if (ctx->bye_notify_fnc) - ctx->bye_notify_fnc (ctx); - assuan_close_input_fd (ctx); - assuan_close_output_fd (ctx); - return -1; /* pretty simple :-) */ -} - -static int -std_handler_auth (ASSUAN_CONTEXT ctx, char *line) -{ - (void)line; - return set_error (ctx, Not_Implemented, NULL); -} - -static int -std_handler_reset (ASSUAN_CONTEXT ctx, char *line) -{ - (void)line; - if (ctx->reset_notify_fnc) - ctx->reset_notify_fnc (ctx); - assuan_close_input_fd (ctx); - assuan_close_output_fd (ctx); - return 0; -} - -static int -std_handler_end (ASSUAN_CONTEXT ctx, char *line) -{ - (void)line; - return set_error (ctx, Not_Implemented, NULL); -} - -static int -parse_cmd_input_output (ASSUAN_CONTEXT ctx, char *line, int *rfd) -{ - char *endp; - - if (strncmp (line, "FD=", 3)) - return set_error (ctx, Syntax_Error, "FD= expected"); - line += 3; - if (!digitp (*line)) - return set_error (ctx, Syntax_Error, "number required"); - *rfd = strtoul (line, &endp, 10); - /* remove that argument so that a notify handler won't see it */ - memset (line, ' ', endp? (endp-line):strlen(line)); - - if (*rfd == ctx->inbound.fd) - return set_error (ctx, Parameter_Conflict, "fd same as inbound fd"); - if (*rfd == ctx->outbound.fd) - return set_error (ctx, Parameter_Conflict, "fd same as outbound fd"); - return 0; -} - -/* Format is INPUT FD= */ -static int -std_handler_input (ASSUAN_CONTEXT ctx, char *line) -{ - int rc, fd; - - rc = parse_cmd_input_output (ctx, line, &fd); - if (rc) - return rc; - ctx->input_fd = fd; - if (ctx->input_notify_fnc) - ctx->input_notify_fnc (ctx, line); - return 0; -} - -/* Format is OUTPUT FD= */ -static int -std_handler_output (ASSUAN_CONTEXT ctx, char *line) -{ - int rc, fd; - - rc = parse_cmd_input_output (ctx, line, &fd); - if (rc) - return rc; - ctx->output_fd = fd; - if (ctx->output_notify_fnc) - ctx->output_notify_fnc (ctx, line); - return 0; -} - - - - - -/* This is a table with the standard commands and handler for them. - The table is used to initialize a new context and assuciate strings - and handlers with cmd_ids */ -static struct { - const char *name; - int cmd_id; - int (*handler)(ASSUAN_CONTEXT, char *line); - int always; /* always initialize this command */ -} std_cmd_table[] = { - { "NOP", ASSUAN_CMD_NOP, std_handler_nop, 1 }, - { "CANCEL", ASSUAN_CMD_CANCEL, std_handler_cancel, 1 }, - { "OPTION", ASSUAN_CMD_OPTION, std_handler_option, 1 }, - { "BYE", ASSUAN_CMD_BYE, std_handler_bye, 1 }, - { "AUTH", ASSUAN_CMD_AUTH, std_handler_auth, 1 }, - { "RESET", ASSUAN_CMD_RESET, std_handler_reset, 1 }, - { "END", ASSUAN_CMD_END, std_handler_end, 1 }, - - { "INPUT", ASSUAN_CMD_INPUT, std_handler_input }, - { "OUTPUT", ASSUAN_CMD_OUTPUT, std_handler_output }, - { "OPTION", ASSUAN_CMD_OPTION, std_handler_option, 1 }, - { NULL } -}; - - -/** - * assuan_register_command: - * @ctx: the server context - * @cmd_id: An ID value for the command - * @cmd_name: A string with the command name - * @handler: The handler function to be called - * - * Register a handler to be used for a given command. - * - * The @cmd_name must be %NULL or an empty string for all @cmd_ids - * below %ASSUAN_CMD_USER because predefined values are used. - * - * Return value: - **/ -int -assuan_register_command (ASSUAN_CONTEXT ctx, - int cmd_id, const char *cmd_name, - int (*handler)(ASSUAN_CONTEXT, char *)) -{ - int i; - - if (cmd_name && !*cmd_name) - cmd_name = NULL; - - if (cmd_id < ASSUAN_CMD_USER) - { - if (cmd_name) - return ASSUAN_Invalid_Value; /* must be NULL for these values*/ - - for (i=0; std_cmd_table[i].name; i++) - { - if (std_cmd_table[i].cmd_id == cmd_id) - { - cmd_name = std_cmd_table[i].name; - if (!handler) - handler = std_cmd_table[i].handler; - break; - } - } - if (!std_cmd_table[i].name) - return ASSUAN_Invalid_Value; /* not a pre-registered one */ - } - - if (!handler) - handler = dummy_handler; - - if (!cmd_name) - return ASSUAN_Invalid_Value; - -/* fprintf (stderr, "DBG-assuan: registering %d as `%s'\n", cmd_id, cmd_name); */ - - if (!ctx->cmdtbl) - { - ctx->cmdtbl_size = 50; - ctx->cmdtbl = xtrycalloc ( ctx->cmdtbl_size, sizeof *ctx->cmdtbl); - if (!ctx->cmdtbl) - return ASSUAN_Out_Of_Core; - ctx->cmdtbl_used = 0; - } - else if (ctx->cmdtbl_used >= ctx->cmdtbl_size) - { - struct cmdtbl_s *x; - - x = xtryrealloc ( ctx->cmdtbl, (ctx->cmdtbl_size+10) * sizeof *x); - if (!x) - return ASSUAN_Out_Of_Core; - ctx->cmdtbl = x; - ctx->cmdtbl_size += 50; - } - - ctx->cmdtbl[ctx->cmdtbl_used].name = cmd_name; - ctx->cmdtbl[ctx->cmdtbl_used].cmd_id = cmd_id; - ctx->cmdtbl[ctx->cmdtbl_used].handler = handler; - ctx->cmdtbl_used++; - return 0; -} - -int -assuan_register_bye_notify (ASSUAN_CONTEXT ctx, void (*fnc)(ASSUAN_CONTEXT)) -{ - if (!ctx) - return ASSUAN_Invalid_Value; - ctx->bye_notify_fnc = fnc; - return 0; -} - -int -assuan_register_reset_notify (ASSUAN_CONTEXT ctx, void (*fnc)(ASSUAN_CONTEXT)) -{ - if (!ctx) - return ASSUAN_Invalid_Value; - ctx->reset_notify_fnc = fnc; - return 0; -} - -int -assuan_register_cancel_notify (ASSUAN_CONTEXT ctx, void (*fnc)(ASSUAN_CONTEXT)) -{ - if (!ctx) - return ASSUAN_Invalid_Value; - ctx->cancel_notify_fnc = fnc; - return 0; -} - -int -assuan_register_option_handler (ASSUAN_CONTEXT ctx, - int (*fnc)(ASSUAN_CONTEXT, - const char*, const char*)) -{ - if (!ctx) - return ASSUAN_Invalid_Value; - ctx->option_handler_fnc = fnc; - return 0; -} - -int -assuan_register_input_notify (ASSUAN_CONTEXT ctx, - void (*fnc)(ASSUAN_CONTEXT, const char *)) -{ - if (!ctx) - return ASSUAN_Invalid_Value; - ctx->input_notify_fnc = fnc; - return 0; -} - -int -assuan_register_output_notify (ASSUAN_CONTEXT ctx, - void (*fnc)(ASSUAN_CONTEXT, const char *)) -{ - if (!ctx) - return ASSUAN_Invalid_Value; - ctx->output_notify_fnc = fnc; - return 0; -} - - -/* Helper to register the standards commands */ -int -_assuan_register_std_commands (ASSUAN_CONTEXT ctx) -{ - int i, rc; - - for (i=0; std_cmd_table[i].name; i++) - { - if (std_cmd_table[i].always) - { - rc = assuan_register_command (ctx, std_cmd_table[i].cmd_id, - NULL, NULL); - if (rc) - return rc; - } - } - return 0; -} - - - -/* Process the special data lines. The "D " has already been removed - from the line. As all handlers this function may modify the line. */ -static int -handle_data_line (ASSUAN_CONTEXT ctx, char *line, int linelen) -{ - (void)line; - (void)linelen; - return set_error (ctx, Not_Implemented, NULL); -} - -/* like ascii_strcasecmp but assume that B is already uppercase */ -static int -my_strcasecmp (const char *a, const char *b) -{ - if (a == b) - return 0; - - for (; *a && *b; a++, b++) - { - if (((*a >= 'a' && *a <= 'z')? (*a&~0x20):*a) != *b) - break; - } - return *a == *b? 0 : (((*a >= 'a' && *a <= 'z')? (*a&~0x20):*a) - *b); -} - -/* Parse the line, break out the command, find it in the command - table, remove leading and white spaces from the arguments, all the - handler with the argument line and return the error */ -static int -dispatch_command (ASSUAN_CONTEXT ctx, char *line, int linelen) -{ - char *p; - const char *s; - int shift, i; - - if (*line == 'D' && line[1] == ' ') /* divert to special handler */ - return handle_data_line (ctx, line+2, linelen-2); - - for (p=line; *p && *p != ' ' && *p != '\t'; p++) - ; - if (p==line) - return set_error (ctx, Syntax_Error, "leading white-space"); - if (*p) - { /* Skip over leading WS after the keyword */ - *p++ = 0; - while ( *p == ' ' || *p == '\t') - p++; - } - shift = p - line; - - for (i=0; (s=ctx->cmdtbl[i].name); i++) - { - if (!strcmp (line, s)) - break; - } - if (!s) - { /* and try case insensitive */ - for (i=0; (s=ctx->cmdtbl[i].name); i++) - { - if (!my_strcasecmp (line, s)) - break; - } - } - if (!s) - return set_error (ctx, Unknown_Command, NULL); - line += shift; - linelen -= shift; - -/* fprintf (stderr, "DBG-assuan: processing %s `%s'\n", s, line); */ - return ctx->cmdtbl[i].handler (ctx, line); -} - - - - -static int -process_request (ASSUAN_CONTEXT ctx) -{ - int rc; - - if (ctx->in_inquire) - return ASSUAN_Nested_Commands; - - rc = _assuan_read_line (ctx); - if (rc) - return rc; - if (*ctx->inbound.line == '#' || !ctx->inbound.linelen) - return 0; /* comment line - ignore */ - - ctx->outbound.data.error = 0; - ctx->outbound.data.linelen = 0; - /* dispatch command and return reply */ - rc = dispatch_command (ctx, ctx->inbound.line, ctx->inbound.linelen); - /* check from data write errors */ - if (ctx->outbound.data.fp) - { /* Flush the data lines */ - fclose (ctx->outbound.data.fp); - ctx->outbound.data.fp = NULL; - if (!rc && ctx->outbound.data.error) - rc = ctx->outbound.data.error; - } - else /* flush any data send w/o using the data fp */ - { - assuan_send_data (ctx, NULL, 0); - if (!rc && ctx->outbound.data.error) - rc = ctx->outbound.data.error; - } - /* Error handling */ - if (!rc) - { - rc = assuan_write_line (ctx, ctx->okay_line? ctx->okay_line : "OK"); - } - else if (rc == -1) - { /* No error checking because the peer may have already disconnect */ - assuan_write_line (ctx, "OK closing connection"); - ctx->finish_handler (ctx); - } - else - { - char errline[256]; - - if (rc < 100) - sprintf (errline, "ERR %d server fault (%.50s)", - ASSUAN_Server_Fault, assuan_strerror (rc)); - else - { - const char *text = ctx->err_no == rc? ctx->err_str:NULL; - - sprintf (errline, "ERR %d %.50s%s%.100s", - rc, assuan_strerror (rc), text? " - ":"", text?text:""); - } - rc = assuan_write_line (ctx, errline); - } - - ctx->confidential = 0; - if (ctx->okay_line) - { - xfree (ctx->okay_line); - ctx->okay_line = NULL; - } - return rc; -} - -/** - * assuan_process: - * @ctx: assuan context - * - * This fucntion is used to handle the assuan protocol after a - * connection has been established using assuan_accept(). This is the - * main protocol handler. - * - * Return value: 0 on success or an error code if the assuan operation - * failed. Note, that no error is returned for operational errors. - **/ -int -assuan_process (ASSUAN_CONTEXT ctx) -{ - int rc; - - do { - rc = process_request (ctx); - } while (!rc); - - if (rc == -1) - rc = 0; - - return rc; -} - - -/** - * assuan_process_next: - * @ctx: Assuan context - * - * Same as assuan_process() but the user has to provide the outer - * loop. He should loop as long as the return code is zero and stop - * otherwise; -1 is regular end. - * - * See also: assuan_get_active_fds() - * Return value: -1 for end of server, 0 on success or an error code - **/ -int -assuan_process_next (ASSUAN_CONTEXT ctx) -{ - return process_request (ctx); -} - - -/** - * assuan_get_active_fds: - * @ctx: Assuan context - * @what: 0 for read fds, 1 for write fds - * @fdarray: Caller supplied array to store the FDs - * @fdarraysize: size of that array - * - * Return all active filedescriptors for the given context. This - * function can be used to select on the fds and call - * assuan_process_next() if there is an active one. The first fd in - * the array is the one used for the command connection. - * - * Note, that write FDs are not yet supported. - * - * Return value: number of FDs active and put into @fdarray or -1 on - * error which is most likely a too small fdarray. - **/ -int -assuan_get_active_fds (ASSUAN_CONTEXT ctx, int what, - int *fdarray, int fdarraysize) -{ - int n = 0; - - if (!ctx || fdarraysize < 2 || what < 0 || what > 1) - return -1; - - if (!what) - { - if (ctx->inbound.fd != -1) - fdarray[n++] = ctx->inbound.fd; - } - else - { - if (ctx->outbound.fd != -1) - fdarray[n++] = ctx->outbound.fd; - if (ctx->outbound.data.fp) - fdarray[n++] = fileno (ctx->outbound.data.fp); - } - - return n; -} - - -/* Set the text used for the next OK reponse. This string is - automatically reset to NULL after the next command. */ -AssuanError -assuan_set_okay_line (ASSUAN_CONTEXT ctx, const char *line) -{ - if (!ctx) - return ASSUAN_Invalid_Value; - if (!line) - { - xfree (ctx->okay_line); - ctx->okay_line = NULL; - } - else - { - /* FIXME: we need to use gcry_is_secure() to test whether - we should allocate the entire line in secure memory */ - char *buf = xtrymalloc (3+strlen(line)+1); - if (!buf) - return ASSUAN_Out_Of_Core; - strcpy (buf, "OK "); - strcpy (buf+3, line); - xfree (ctx->okay_line); - ctx->okay_line = buf; - } - return 0; -} - - - -void -assuan_write_status (ASSUAN_CONTEXT ctx, const char *keyword, const char *text) -{ - char buffer[256]; - char *helpbuf; - size_t n; - - if ( !ctx || !keyword) - return; - if (!text) - text = ""; - - n = 2 + strlen (keyword) + 1 + strlen (text) + 1; - if (n < sizeof (buffer)) - { - strcpy (buffer, "S "); - strcat (buffer, keyword); - if (*text) - { - strcat (buffer, " "); - strcat (buffer, text); - } - assuan_write_line (ctx, buffer); - } - else if ( (helpbuf = xtrymalloc (n)) ) - { - strcpy (helpbuf, "S "); - strcat (helpbuf, keyword); - if (*text) - { - strcat (helpbuf, " "); - strcat (helpbuf, text); - } - assuan_write_line (ctx, helpbuf); - xfree (helpbuf); - } -} diff --git a/assuan/assuan-listen.c b/assuan/assuan-listen.c deleted file mode 100644 index db63ad2..0000000 --- a/assuan/assuan-listen.c +++ /dev/null @@ -1,132 +0,0 @@ -/* assuan-listen.c - Wait for a connection (server) - * Copyright (C) 2001 Free Software Foundation, Inc. - * - * This file is part of GnuPG. - * - * GnuPG is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * GnuPG is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA - */ - -#include -#include -#include -#include -#include - -#include "assuan-defs.h" - -AssuanError -assuan_set_hello_line (ASSUAN_CONTEXT ctx, const char *line) -{ - if (!ctx) - return ASSUAN_Invalid_Value; - if (!line) - { - xfree (ctx->hello_line); - ctx->hello_line = NULL; - } - else - { - char *buf = xtrymalloc (3+strlen(line)+1); - if (!buf) - return ASSUAN_Out_Of_Core; - strcpy (buf, "OK "); - strcpy (buf+3, line); - xfree (ctx->hello_line); - ctx->hello_line = buf; - } - return 0; -} - - -/** - * assuan_accept: - * @ctx: context - * - * Cancel any existing connectiion and wait for a connection from a - * client. The initial handshake is performed which may include an - * initial authentication or encryption negotiation. - * - * Return value: 0 on success or an error if the connection could for - * some reason not be established. - **/ -AssuanError -assuan_accept (ASSUAN_CONTEXT ctx) -{ - int rc; - - if (!ctx) - return ASSUAN_Invalid_Value; - - if (ctx->pipe_mode > 1) - return -1; /* second invocation for pipemode -> terminate */ - ctx->finish_handler (ctx); - - rc = ctx->accept_handler (ctx); - if (rc) - return rc; - - /* send the hello */ - rc = assuan_write_line (ctx, ctx->hello_line? ctx->hello_line - : "OK Your orders please"); - if (rc) - return rc; - - if (ctx->pipe_mode) - ctx->pipe_mode = 2; - - return 0; -} - - - -int -assuan_get_input_fd (ASSUAN_CONTEXT ctx) -{ - return ctx? ctx->input_fd : -1; -} - - -int -assuan_get_output_fd (ASSUAN_CONTEXT ctx) -{ - return ctx? ctx->output_fd : -1; -} - - -/* Close the fd descriptor set by the command INPUT FD=n. We handle - this fd inside assuan so that we can do some initial checks */ -AssuanError -assuan_close_input_fd (ASSUAN_CONTEXT ctx) -{ - if (!ctx || ctx->input_fd == -1) - return ASSUAN_Invalid_Value; - close (ctx->input_fd); - ctx->input_fd = -1; - return 0; -} - -/* Close the fd descriptor set by the command OUTPUT FD=n. We handle - this fd inside assuan so that we can do some initial checks */ -AssuanError -assuan_close_output_fd (ASSUAN_CONTEXT ctx) -{ - if (!ctx || ctx->output_fd == -1) - return ASSUAN_Invalid_Value; - - close (ctx->output_fd); - ctx->output_fd = -1; - return 0; -} - diff --git a/assuan/assuan-pipe-server.c b/assuan/assuan-pipe-server.c deleted file mode 100644 index c0d464f..0000000 --- a/assuan/assuan-pipe-server.c +++ /dev/null @@ -1,127 +0,0 @@ -/* assuan-pipe-server.c - Assuan server working over a pipe - * Copyright (C) 2001 Free Software Foundation, Inc. - * - * This file is part of GnuPG. - * - * GnuPG is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * GnuPG is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA - */ - -#include -#include -#include - -#include "assuan-defs.h" - -static void -deinit_pipe_server (ASSUAN_CONTEXT ctx) -{ - (void)ctx; - /* nothing to do for this simple server */ -} - -static int -accept_connection (ASSUAN_CONTEXT ctx) -{ - (void)ctx; - /* This is a NOP for a pipe server */ - return 0; -} - -static int -finish_connection (ASSUAN_CONTEXT ctx) -{ - (void)ctx; - /* This is a NOP for a pipe server */ - return 0; -} - - -/* Create a new context. Note that the handlers are set up for a pipe - server/client - this way we don't need extra dummy functions */ -int -_assuan_new_context (ASSUAN_CONTEXT *r_ctx) -{ - ASSUAN_CONTEXT ctx; - int rc; - - *r_ctx = NULL; - ctx = xtrycalloc (1, sizeof *ctx); - if (!ctx) - return ASSUAN_Out_Of_Core; - ctx->input_fd = -1; - ctx->output_fd = -1; - - ctx->inbound.fd = -1; - ctx->outbound.fd = -1; - - ctx->listen_fd = -1; - ctx->client_pid = (pid_t)-1; - /* use the pipe server handler as a default */ - ctx->deinit_handler = deinit_pipe_server; - ctx->accept_handler = accept_connection; - ctx->finish_handler = finish_connection; - - rc = _assuan_register_std_commands (ctx); - if (rc) - xfree (ctx); - else - *r_ctx = ctx; - return rc; -} - - - -int -assuan_init_pipe_server (ASSUAN_CONTEXT *r_ctx, int filedes[2]) -{ - int rc; - - rc = _assuan_new_context (r_ctx); - if (!rc) - { - ASSUAN_CONTEXT ctx = *r_ctx; - - ctx->is_server = 1; - ctx->inbound.fd = filedes[0]; - ctx->outbound.fd = filedes[1]; - ctx->pipe_mode = 1; - } - return rc; -} - - -void -_assuan_release_context (ASSUAN_CONTEXT ctx) -{ - if (ctx) - { - xfree (ctx->hello_line); - xfree (ctx->okay_line); - xfree (ctx); - } -} - -void -assuan_deinit_server (ASSUAN_CONTEXT ctx) -{ - if (ctx) - { - /* We use this function pointer to avoid linking other server - when not needed but still allow for a generic deinit function */ - ctx->deinit_handler (ctx); - ctx->deinit_handler = NULL; - _assuan_release_context (ctx); - } -} diff --git a/assuan/assuan-util.c b/assuan/assuan-util.c deleted file mode 100644 index c2c899f..0000000 --- a/assuan/assuan-util.c +++ /dev/null @@ -1,196 +0,0 @@ -/* assuan-util.c - Utility functions for Assuan - * Copyright (C) 2001 Free Software Foundation, Inc. - * - * This file is part of GnuPG. - * - * GnuPG is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * GnuPG is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA - */ - -#include -#include -#include -#include - -#include "assuan-defs.h" - -#ifdef HAVE_JNLIB_LOGGING -#include "../jnlib/logging.h" -#endif - - -static void *(*alloc_func)(size_t n) = malloc; -static void *(*realloc_func)(void *p, size_t n) = realloc; -static void (*free_func)(void*) = free; - - - -void -assuan_set_malloc_hooks ( void *(*new_alloc_func)(size_t n), - void *(*new_realloc_func)(void *p, size_t n), - void (*new_free_func)(void*) ) -{ - alloc_func = new_alloc_func; - realloc_func = new_realloc_func; - free_func = new_free_func; -} - -void * -_assuan_malloc (size_t n) -{ - return alloc_func (n); -} - -void * -_assuan_realloc (void *a, size_t n) -{ - return realloc_func (a, n); -} - -void * -_assuan_calloc (size_t n, size_t m) -{ - void *p = _assuan_malloc (n*m); - if (p) - memset (p, 0, n* m); - return p; -} - -void -_assuan_free (void *p) -{ - if (p) - free_func (p); -} - - - -/* Store the error in the context so that the error sending function - can take out a descriptive text. Inside the assuan code, use the - macro set_error instead of this function. */ -int -assuan_set_error (ASSUAN_CONTEXT ctx, int err, const char *text) -{ - ctx->err_no = err; - ctx->err_str = text; - return err; -} - -void -assuan_set_pointer (ASSUAN_CONTEXT ctx, void *pointer) -{ - if (ctx) - ctx->user_pointer = pointer; -} - -void * -assuan_get_pointer (ASSUAN_CONTEXT ctx) -{ - return ctx? ctx->user_pointer : NULL; -} - - -void -assuan_set_log_stream (ASSUAN_CONTEXT ctx, FILE *fp) -{ - if (ctx) - { - if (ctx->log_fp) - fflush (ctx->log_fp); - ctx->log_fp = fp; - } -} - - -void -assuan_begin_confidential (ASSUAN_CONTEXT ctx) -{ - if (ctx) - { - ctx->confidential = 1; - } -} - -void -assuan_end_confidential (ASSUAN_CONTEXT ctx) -{ - if (ctx) - { - ctx->confidential = 0; - } -} - -void -_assuan_log_print_buffer (FILE *fp, const void *buffer, size_t length) -{ - const unsigned char *s; - int n; - - for (n=length,s=buffer; n; n--, s++) - { - if (*s < ' ' || (*s >= 0x7f && *s <= 0xa0)) - break; - } - s = buffer; - if (!n && *s != '[') - fwrite (buffer, length, 1, fp); - else - { - putc ('[', fp); - for (n=0; n < length; n++, s++) - fprintf (fp, " %02x", *s); - putc (' ', fp); - putc (']', fp); - } -} - - -/* print a user supplied string after filtering out potential bad - characters*/ -void -_assuan_log_sanitized_string (const char *string) -{ - const unsigned char *s = (const unsigned char*)string; -#ifdef HAVE_JNLIB_LOGGING - FILE *fp = log_get_stream (); -#else - FILE *fp = stderr; -#endif - - for (; *s; s++) - { - if (*s < 0x20 || (*s >= 0x7f && *s <= 0xa0)) - { - putc ('\\', fp); - if (*s == '\n') - putc ('n', fp); - else if (*s == '\r') - putc ('r', fp); - else if (*s == '\f') - putc ('f', fp); - else if (*s == '\v') - putc ('v', fp); - else if (*s == '\b') - putc ('b', fp); - else if (!*s) - putc ('0', fp); - else - fprintf (fp, "x%02x", *s ); - } - else - putc (*s, fp); - } -} - - diff --git a/assuan/assuan.h b/assuan/assuan.h deleted file mode 100644 index 7087d7b..0000000 --- a/assuan/assuan.h +++ /dev/null @@ -1,202 +0,0 @@ -/* assuan.c - Definitions for the Assuna protocol - * Copyright (C) 2001, 2002 Free Software Foundation, Inc. - * - * This file is part of GnuPG. - * - * GnuPG is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * GnuPG is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA - */ - -#ifndef ASSUAN_H -#define ASSUAN_H - -#include -#include - -#ifdef __cplusplus -extern "C" { -#if 0 - } -#endif -#endif - -/* 5 is pinentry. */ -#define ASSUAN_ERROR(code) ((5 << 24) | code) - -typedef enum { - ASSUAN_No_Error = 0, - ASSUAN_General_Error = ASSUAN_ERROR (257), - ASSUAN_Out_Of_Core = ASSUAN_ERROR (86 | (1 << 15)), - ASSUAN_Invalid_Value = ASSUAN_ERROR (261), - ASSUAN_Timeout = ASSUAN_ERROR (62), - ASSUAN_Read_Error = ASSUAN_ERROR (270), /* Not 100%, but sufficient here. */ - ASSUAN_Write_Error = ASSUAN_ERROR (271), /* Not 100%, but sufficient here. */ - ASSUAN_Problem_Starting_Server = ASSUAN_ERROR (269), - ASSUAN_Not_A_Server = ASSUAN_ERROR (267), - ASSUAN_Not_A_Client = ASSUAN_ERROR (268), - ASSUAN_Nested_Commands = ASSUAN_ERROR (264), - ASSUAN_Invalid_Response = ASSUAN_ERROR (260), - ASSUAN_No_Data_Callback = ASSUAN_ERROR (265), - ASSUAN_No_Inquire_Callback = ASSUAN_ERROR (266), - ASSUAN_Connect_Failed = ASSUAN_ERROR (259), - ASSUAN_Accept_Failed = ASSUAN_ERROR (258), - - /* error codes above 99 are meant as status codes */ - ASSUAN_Not_Implemented = ASSUAN_ERROR (69), - ASSUAN_Server_Fault = ASSUAN_ERROR (80), - ASSUAN_Unknown_Command = ASSUAN_ERROR (275), - ASSUAN_Syntax_Error = ASSUAN_ERROR (276), - ASSUAN_Parameter_Conflict = ASSUAN_ERROR (280), - ASSUAN_Line_Too_Long = ASSUAN_ERROR (263), - ASSUAN_Line_Not_Terminated = ASSUAN_ERROR (262), - ASSUAN_Canceled = ASSUAN_ERROR (99), - ASSUAN_Invalid_Option = ASSUAN_ERROR (174), /* GPG_ERR_UNKNOWN_OPTION */ - ASSUAN_Locale_Problem = ASSUAN_ERROR (166), - ASSUAN_Not_Confirmed = ASSUAN_ERROR (114), - ASSUAN_Too_Short = ASSUAN_ERROR (66), - ASSUAN_ENOENT = ASSUAN_ERROR (81 | (1 << 15)), - ASSUAN_ENOTTY = ASSUAN_ERROR (102 | (1 << 15)), - -} assuan_error_t; - -#define ASSUAN_Parameter_Error ASSUAN_Parameter_Conflict - - -typedef assuan_error_t AssuanError; /* Deprecated. */ - -/* This is a list of pre-registered ASSUAN commands */ -typedef enum { - ASSUAN_CMD_NOP = 0, - ASSUAN_CMD_CANCEL, /* cancel the current request */ - ASSUAN_CMD_BYE, - ASSUAN_CMD_AUTH, - ASSUAN_CMD_RESET, - ASSUAN_CMD_OPTION, - ASSUAN_CMD_DATA, - ASSUAN_CMD_END, - ASSUAN_CMD_INPUT, - ASSUAN_CMD_OUTPUT, - - ASSUAN_CMD_USER = 256 /* Other commands should be used with this offset*/ -} AssuanCommand; - -#define ASSUAN_LINELENGTH 1002 /* 1000 + [CR,]LF */ - -struct assuan_context_s; -typedef struct assuan_context_s *assuan_context_t; -typedef struct assuan_context_s *ASSUAN_CONTEXT; /* Deprecated. */ - -/*-- assuan-handler.c --*/ -int assuan_register_command (ASSUAN_CONTEXT ctx, - int cmd_id, const char *cmd_string, - int (*handler)(ASSUAN_CONTEXT, char *)); -int assuan_register_bye_notify (ASSUAN_CONTEXT ctx, - void (*fnc)(ASSUAN_CONTEXT)); -int assuan_register_reset_notify (ASSUAN_CONTEXT ctx, - void (*fnc)(ASSUAN_CONTEXT)); -int assuan_register_cancel_notify (ASSUAN_CONTEXT ctx, - void (*fnc)(ASSUAN_CONTEXT)); -int assuan_register_input_notify (ASSUAN_CONTEXT ctx, - void (*fnc)(ASSUAN_CONTEXT, const char *)); -int assuan_register_output_notify (ASSUAN_CONTEXT ctx, - void (*fnc)(ASSUAN_CONTEXT, const char *)); - -int assuan_register_option_handler (ASSUAN_CONTEXT ctx, - int (*fnc)(ASSUAN_CONTEXT, - const char*, const char*)); - -int assuan_process (ASSUAN_CONTEXT ctx); -int assuan_process_next (ASSUAN_CONTEXT ctx); -int assuan_get_active_fds (ASSUAN_CONTEXT ctx, int what, - int *fdarray, int fdarraysize); - - -AssuanError assuan_set_okay_line (ASSUAN_CONTEXT ctx, const char *line); -void assuan_write_status (ASSUAN_CONTEXT ctx, - const char *keyword, const char *text); - - -/*-- assuan-listen.c --*/ -AssuanError assuan_set_hello_line (ASSUAN_CONTEXT ctx, const char *line); -AssuanError assuan_accept (ASSUAN_CONTEXT ctx); -int assuan_get_input_fd (ASSUAN_CONTEXT ctx); -int assuan_get_output_fd (ASSUAN_CONTEXT ctx); -AssuanError assuan_close_input_fd (ASSUAN_CONTEXT ctx); -AssuanError assuan_close_output_fd (ASSUAN_CONTEXT ctx); - - -/*-- assuan-pipe-server.c --*/ -int assuan_init_pipe_server (ASSUAN_CONTEXT *r_ctx, int filedes[2]); -void assuan_deinit_server (ASSUAN_CONTEXT ctx); - -/*-- assuan-socket-server.c --*/ -int assuan_init_socket_server (ASSUAN_CONTEXT *r_ctx, int listen_fd); - - -/*-- assuan-pipe-connect.c --*/ -AssuanError assuan_pipe_connect (ASSUAN_CONTEXT *ctx, const char *name, - char *const argv[], int *fd_child_list); -/*-- assuan-socket-connect.c --*/ -AssuanError assuan_socket_connect (ASSUAN_CONTEXT *ctx, const char *name, - pid_t server_pid); - -/*-- assuan-connect.c --*/ -void assuan_disconnect (ASSUAN_CONTEXT ctx); -pid_t assuan_get_pid (ASSUAN_CONTEXT ctx); - -/*-- assuan-client.c --*/ -AssuanError -assuan_transact (ASSUAN_CONTEXT ctx, - const char *command, - AssuanError (*data_cb)(void *, const void *, size_t), - void *data_cb_arg, - AssuanError (*inquire_cb)(void*, const char *), - void *inquire_cb_arg, - AssuanError (*status_cb)(void*, const char *), - void *status_cb_arg); - - -/*-- assuan-inquire.c --*/ -AssuanError assuan_inquire (ASSUAN_CONTEXT ctx, const char *keyword, - char **r_buffer, size_t *r_length, size_t maxlen); - -/*-- assuan-buffer.c --*/ -AssuanError assuan_read_line (ASSUAN_CONTEXT ctx, - char **line, size_t *linelen); -int assuan_pending_line (ASSUAN_CONTEXT ctx); -AssuanError assuan_write_line (ASSUAN_CONTEXT ctx, const char *line ); -AssuanError assuan_send_data (ASSUAN_CONTEXT ctx, - const void *buffer, size_t length); - - -/*-- assuan-util.c --*/ -void assuan_set_malloc_hooks ( void *(*new_alloc_func)(size_t n), - void *(*new_realloc_func)(void *p, size_t n), - void (*new_free_func)(void*) ); -void assuan_set_log_stream (ASSUAN_CONTEXT ctx, FILE *fp); -int assuan_set_error (ASSUAN_CONTEXT ctx, int err, const char *text); -void assuan_set_pointer (ASSUAN_CONTEXT ctx, void *pointer); -void *assuan_get_pointer (ASSUAN_CONTEXT ctx); - -void assuan_begin_confidential (ASSUAN_CONTEXT ctx); -void assuan_end_confidential (ASSUAN_CONTEXT ctx); - -/*-- assuan-errors.c (built) --*/ -const char *assuan_strerror (AssuanError err); - - -#ifdef __cplusplus -} -#endif -#endif /*ASSUAN_H*/ diff --git a/assuan/mkerrors b/assuan/mkerrors deleted file mode 100755 index 91902bf..0000000 --- a/assuan/mkerrors +++ /dev/null @@ -1,71 +0,0 @@ -#!/bin/sh -# mkerrors - Extract error strings from assuan.h -# and create C source for assuan_strerror -# Copyright (C) 2001 Free Software Foundation, Inc. -# -# This file is part of GnuPG. -# -# GnuPG is free software; you can redistribute it and/or modify -# it under the terms of the GNU General Public License as published by -# the Free Software Foundation; either version 2 of the License, or -# (at your option) any later version. -# -# GnuPG is distributed in the hope that it will be useful, -# but WITHOUT ANY WARRANTY; without even the implied warranty of -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -# GNU General Public License for more details. -# -# You should have received a copy of the GNU General Public License -# along with this program; if not, write to the Free Software -# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA - -cat < -#include "assuan.h" - -/** - * assuan_strerror: - * @err: Error code - * - * This function returns a textual representaion of the given - * errorcode. If this is an unknown value, a string with the value - * is returned (Beware: it is hold in a static buffer). - * - * Return value: String with the error description. - **/ -const char * -assuan_strerror (AssuanError err) -{ - const char *s; - static char buf[25]; - - switch (err) - { -EOF - -awk ' -/ASSUAN_No_Error/ { okay=1 } -!okay {next} -/}/ { exit 0 } -/ASSUAN_[A-Za-z_]*/ { print_code($1) } - - -function print_code( s ) -{ -printf " case %s: s=\"", s ; -gsub(/_/, " ", s ); -printf "%s\"; break;\n", tolower(substr(s,8)); -} -' - -cat < None required because we use a stripped down version of libassuan. +# +# libassuan is used for IPC +# +NEED_LIBASSUAN_API=2 +NEED_LIBASSUAN_VERSION=2.1.0 +have_libassuan=no +AM_PATH_LIBASSUAN("$NEED_LIBASSUAN_API:$NEED_LIBASSUAN_VERSION", + have_libassuan=yes,have_libassuan=no) +if test "$have_libassuan" = "yes"; then + AC_DEFINE_UNQUOTED(GNUPG_LIBASSUAN_VERSION, "$libassuan_version", + [version of the libassuan library]) +fi + +COMMON_CFLAGS="$LIBASSUAN_CFLAGS $COMMON_CFLAGS" +COMMON_LIBS="$LIBASSUAN_LIBS $COMMON_LIBS" dnl Checks for libsecmem. @@ -442,8 +476,8 @@ if test "$libsecret" = "yes"; then AC_DEFINE(HAVE_LIBSECRET, 1, [The pinentries should optionally cache the passphrase using libsecret.]) - COMMON_CFLAGS="$COMMON_CFLAGS $LIBSECRET_CFLAGS" - COMMON_LIBS="$COMMON_LIBS $LIBSECRET_LIBS" + COMMON_CFLAGS="$LIBSECRET_CFLAGS $COMMON_CFLAGS" + COMMON_LIBS="$LIBSECRET_LIBS $COMMON_LIBS" fi dnl @@ -561,9 +595,44 @@ else fi AC_SUBST(PINENTRY_DEFAULT) +# +# Print errors here so that they are visible all +# together and the user can acquire them all together. +# +die=no +if test "$have_gpg_error" = "no"; then + die=yes + AC_MSG_NOTICE([[ +*** +*** You need libgpg-error to build this program. +** This library is for example available at +*** ftp://ftp.gnupg.org/gcrypt/libgpg-error +*** (at least version $NEED_GPG_ERROR_VERSION is required.) +***]]) +fi + +if test "$have_libassuan" = "no"; then + die=yes + AC_MSG_NOTICE([[ +*** +*** You need libassuan to build this program. +*** This library is for example available at +*** ftp://ftp.gnupg.org/gcrypt/libassuan/ +*** (at least version $NEED_LIBASSUAN_VERSION (API $NEED_LIBASSUAN_API) is required). +***]]) +fi + +if test "$die" = "yes"; then + AC_MSG_ERROR([[ +*** +*** Required libraries not found. Please consult the above messages +*** and install them before running configure again. +***]]) +fi + + AC_CONFIG_FILES([ -assuan/Makefile secmem/Makefile pinentry/Makefile curses/Makefile diff --git a/curses/Makefile.am b/curses/Makefile.am index 4d764c7..915f8a8 100644 --- a/curses/Makefile.am +++ b/curses/Makefile.am @@ -23,7 +23,6 @@ bin_PROGRAMS = pinentry-curses AM_CPPFLAGS = $(COMMON_CFLAGS) $(NCURSES_INCLUDE) -I$(top_srcdir)/pinentry LDADD = ../pinentry/libpinentry.a ../pinentry/libpinentry-curses.a \ - ../assuan/libassuan.a ../secmem/libsecmem.a \ - $(COMMON_LIBS) $(LIBCAP) $(LIBCURSES) $(LIBICONV) + ../secmem/libsecmem.a $(COMMON_LIBS) $(LIBCAP) $(LIBCURSES) $(LIBICONV) pinentry_curses_SOURCES = pinentry-curses.c diff --git a/gnome3/Makefile.am b/gnome3/Makefile.am index 46639de..71c0732 100644 --- a/gnome3/Makefile.am +++ b/gnome3/Makefile.am @@ -30,9 +30,8 @@ libcurses = endif AM_CPPFLAGS = $(COMMON_CFLAGS) $(GNOME3CFLAGS) \ - $(ncurses_include) -I$(top_srcdir)/assuan \ - -I$(top_srcdir)/secmem -I$(top_srcdir)/pinentry -LDADD = ../pinentry/libpinentry.a ../assuan/libassuan.a ../secmem/libsecmem.a \ + $(ncurses_include) -I$(top_srcdir)/secmem -I$(top_srcdir)/pinentry +LDADD = ../pinentry/libpinentry.a ../secmem/libsecmem.a \ $(COMMON_LIBS) $(LIBCAP) $(GNOME3LIBS) $(libcurses) pinentry_gnome3_SOURCES = pinentry-gnome3.c diff --git a/gnome3/pinentry-gnome3.c b/gnome3/pinentry-gnome3.c index 0fea8f0..73d5f6d 100644 --- a/gnome3/pinentry-gnome3.c +++ b/gnome3/pinentry-gnome3.c @@ -27,7 +27,7 @@ #include -#include "assuan.h" +#include #include "memory.h" @@ -189,7 +189,8 @@ gnome3_cmd_handler (pinentry_t pe) if (error) /* Error. */ { - pe->specific_err = ASSUAN_General_Error; + pe->specific_err = + gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ASS_GENERAL); g_error_free (error); ret = -1; } @@ -231,7 +232,8 @@ gnome3_cmd_handler (pinentry_t pe) reply = gcr_prompt_confirm_run (prompt, NULL, &error); if (error) { - pe->specific_err = ASSUAN_General_Error; + pe->specific_err = + gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ASS_GENERAL); ret = 0; } else if (reply == GCR_PROMPT_REPLY_CONTINUE diff --git a/gtk+-2/Makefile.am b/gtk+-2/Makefile.am index 7e37469..88f245e 100644 --- a/gtk+-2/Makefile.am +++ b/gtk+-2/Makefile.am @@ -31,7 +31,7 @@ endif AM_CPPFLAGS = $(COMMON_CFLAGS) $(GTK2CFLAGS) $(ncurses_include) \ -I$(top_srcdir)/secmem -I$(top_srcdir)/pinentry -LDADD = ../pinentry/libpinentry.a ../assuan/libassuan.a ../secmem/libsecmem.a \ +LDADD = ../pinentry/libpinentry.a ../secmem/libsecmem.a \ $(COMMON_LIBS) $(LIBCAP) $(GTK2LIBS) $(libcurses) pinentry_gtk_2_SOURCES = pinentry-gtk-2.c \ diff --git a/pinentry/Makefile.am b/pinentry/Makefile.am index 7fbbab6..d24581b 100644 --- a/pinentry/Makefile.am +++ b/pinentry/Makefile.am @@ -30,7 +30,7 @@ endif noinst_LIBRARIES = libpinentry.a $(pinentry_curses) LDADD = $(COMMON_LIBS) -AM_CPPFLAGS = $(COMMON_CFLAGS) -I$(top_srcdir)/assuan -I$(top_srcdir)/secmem +AM_CPPFLAGS = $(COMMON_CFLAGS) -I$(top_srcdir)/secmem libpinentry_a_SOURCES = pinentry.h pinentry.c argparse.c argparse.h \ password-cache.h password-cache.c diff --git a/pinentry/pinentry-curses.c b/pinentry/pinentry-curses.c index d25ab2e..f130817 100644 --- a/pinentry/pinentry-curses.c +++ b/pinentry/pinentry-curses.c @@ -50,8 +50,9 @@ #include #endif /*HAVE_WCHAR_H*/ +#include + #include "pinentry.h" -#include "assuan.h" /* FIXME: We should allow configuration of these button labels and in any case use the default_ok, default_cancel values if available. @@ -250,7 +251,8 @@ dialog_create (pinentry_t pinentry, dialog_t dialog) if (!what) \ { \ err = 1; \ - pinentry->specific_err = ASSUAN_Locale_Problem; \ + pinentry->specific_err = \ + gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_LOCALE_PROBLEM); \ goto out; \ } \ } \ @@ -282,7 +284,8 @@ dialog_create (pinentry_t pinentry, dialog_t dialog) if (!new) \ { \ err = 1; \ - pinentry->specific_err = ASSUAN_Out_Of_Core; \ + pinentry->specific_err = \ + gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM); \ goto out; \ } \ \ @@ -307,7 +310,8 @@ dialog_create (pinentry_t pinentry, dialog_t dialog) if (!dialog->which) \ { \ err = 1; \ - pinentry->specific_err = ASSUAN_Locale_Problem; \ + pinentry->specific_err = \ + gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_LOCALE_PROBLEM); \ goto out; \ } \ } \ @@ -373,7 +377,8 @@ dialog_create (pinentry_t pinentry, dialog_t dialog) if (y > size_y) { err = 1; - pinentry->specific_err = ASSUAN_Too_Short; + pinentry->specific_err = + gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ASS_LINE_TOO_LONG); goto out; } @@ -428,7 +433,8 @@ dialog_create (pinentry_t pinentry, dialog_t dialog) if (x > size_x) { err = 1; - pinentry->specific_err = ASSUAN_Too_Short; + pinentry->specific_err = + gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ASS_LINE_TOO_LONG); goto out; } @@ -833,7 +839,8 @@ dialog_run (pinentry_t pinentry, const char *tty_name, const char *tty_type) ttyfi = fopen (tty_name, "r"); if (!ttyfi) { - pinentry->specific_err = ASSUAN_ENOENT; + pinentry->specific_err = + gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOENT); return -1; } ttyfo = fopen (tty_name, "w"); @@ -842,7 +849,8 @@ dialog_run (pinentry_t pinentry, const char *tty_name, const char *tty_type) int err = errno; fclose (ttyfi); errno = err; - pinentry->specific_err = ASSUAN_ENOENT; + pinentry->specific_err = + gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOENT); return -1; } screen = newterm (tty_type, ttyfo, ttyfi); @@ -855,7 +863,8 @@ dialog_run (pinentry_t pinentry, const char *tty_name, const char *tty_type) if (!(isatty(fileno(stdin)) && isatty(fileno(stdout)))) { errno = ENOTTY; - pinentry->specific_err = ASSUAN_ENOTTY; + pinentry->specific_err = + gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOTTY); return -1; } init_screen = 1; diff --git a/pinentry/pinentry.c b/pinentry/pinentry.c index 6f7a62c..c440d08 100644 --- a/pinentry/pinentry.c +++ b/pinentry/pinentry.c @@ -43,7 +43,8 @@ #include #endif -#include "assuan.h" +#include + #include "memory.h" #include "secmem-util.h" #include "argparse.h" @@ -165,11 +166,15 @@ pinentry_reset (int use_defaults) } } -static void -pinentry_assuan_reset_handler (ASSUAN_CONTEXT ctx) +static gpg_error_t +pinentry_assuan_reset_handler (assuan_context_t ctx, char *line) { (void)ctx; + (void)line; + pinentry_reset (0); + + return 0; } @@ -356,7 +361,7 @@ copy_and_escape (char *buffer, const void *text, size_t textlen) int pinentry_inq_quality (pinentry_t pin, const char *passphrase, size_t length) { - ASSUAN_CONTEXT ctx = pin->ctx_assuan; + assuan_context_t ctx = pin->ctx_assuan; const char prefix[] = "INQUIRE QUALITY "; char *command; char *line; @@ -500,6 +505,10 @@ pinentry_setbuffer_use (pinentry_t pin, char *passphrase, int len) pin->pin_len = len; } +static struct assuan_malloc_hooks assuan_malloc_hooks = { + secmem_malloc, secmem_realloc, secmem_free +}; + /* Initialize the secure memory subsystem, drop privileges and return. Must be called early. */ void @@ -510,6 +519,8 @@ pinentry_init (const char *pgmname) abort (); strcpy (this_pgmname, pgmname); + gpgrt_check_version (NULL); + /* Initialize secure memory. 1 is too small, so the default size will be used. */ secmem_init (1); @@ -521,7 +532,7 @@ pinentry_init (const char *pgmname) /* FIXME: Could not register at-exit function, bail out. */ } - assuan_set_malloc_hooks (secmem_malloc, secmem_realloc, secmem_free); + assuan_set_malloc_hooks (&assuan_malloc_hooks); } /* Simple test to check whether DISPLAY is set or the option --display @@ -755,8 +766,8 @@ pinentry_parse_opts (int argc, char *argv[]) } -static int -option_handler (ASSUAN_CONTEXT ctx, const char *key, const char *value) +static gpg_error_t +option_handler (assuan_context_t ctx, const char *key, const char *value) { (void)ctx; @@ -779,7 +790,7 @@ option_handler (ASSUAN_CONTEXT ctx, const char *key, const char *value) free (pinentry.display); pinentry.display = strdup (value); if (!pinentry.display) - return ASSUAN_Out_Of_Core; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM); } else if (!strcmp (key, "ttyname")) { @@ -787,7 +798,7 @@ option_handler (ASSUAN_CONTEXT ctx, const char *key, const char *value) free (pinentry.ttyname); pinentry.ttyname = strdup (value); if (!pinentry.ttyname) - return ASSUAN_Out_Of_Core; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM); } else if (!strcmp (key, "ttytype")) { @@ -795,7 +806,7 @@ option_handler (ASSUAN_CONTEXT ctx, const char *key, const char *value) free (pinentry.ttytype); pinentry.ttytype = strdup (value); if (!pinentry.ttytype) - return ASSUAN_Out_Of_Core; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM); } else if (!strcmp (key, "lc-ctype")) { @@ -803,7 +814,7 @@ option_handler (ASSUAN_CONTEXT ctx, const char *key, const char *value) free (pinentry.lc_ctype); pinentry.lc_ctype = strdup (value); if (!pinentry.lc_ctype) - return ASSUAN_Out_Of_Core; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM); } else if (!strcmp (key, "lc-messages")) { @@ -811,7 +822,7 @@ option_handler (ASSUAN_CONTEXT ctx, const char *key, const char *value) free (pinentry.lc_messages); pinentry.lc_messages = strdup (value); if (!pinentry.lc_messages) - return ASSUAN_Out_Of_Core; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM); } else if (!strcmp (key, "parent-wid")) { @@ -824,31 +835,31 @@ option_handler (ASSUAN_CONTEXT ctx, const char *key, const char *value) free (pinentry.touch_file); pinentry.touch_file = strdup (value); if (!pinentry.touch_file) - return ASSUAN_Out_Of_Core; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM); } else if (!strcmp (key, "default-ok")) { pinentry.default_ok = strdup (value); if (!pinentry.default_ok) - return ASSUAN_Out_Of_Core; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM); } else if (!strcmp (key, "default-cancel")) { pinentry.default_cancel = strdup (value); if (!pinentry.default_cancel) - return ASSUAN_Out_Of_Core; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM); } else if (!strcmp (key, "default-prompt")) { pinentry.default_prompt = strdup (value); if (!pinentry.default_prompt) - return ASSUAN_Out_Of_Core; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM); } else if (!strcmp (key, "default-pwmngr")) { pinentry.default_pwmngr = strdup (value); if (!pinentry.default_pwmngr) - return ASSUAN_Out_Of_Core; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM); } else if (!strcmp (key, "allow-external-password-cache") && !*value) { @@ -856,7 +867,7 @@ option_handler (ASSUAN_CONTEXT ctx, const char *key, const char *value) pinentry.tried_password_cache = 0; } else - return ASSUAN_Invalid_Option; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_UNKNOWN_OPTION); return 0; } @@ -881,8 +892,8 @@ strcpy_escaped (char *d, const char *s) } -static int -cmd_setdesc (ASSUAN_CONTEXT ctx, char *line) +static gpg_error_t +cmd_setdesc (assuan_context_t ctx, char *line) { char *newd; @@ -890,7 +901,7 @@ cmd_setdesc (ASSUAN_CONTEXT ctx, char *line) newd = malloc (strlen (line) + 1); if (!newd) - return ASSUAN_Out_Of_Core; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM); strcpy_escaped (newd, line); if (pinentry.description) @@ -900,8 +911,8 @@ cmd_setdesc (ASSUAN_CONTEXT ctx, char *line) } -static int -cmd_setprompt (ASSUAN_CONTEXT ctx, char *line) +static gpg_error_t +cmd_setprompt (assuan_context_t ctx, char *line) { char *newp; @@ -909,7 +920,7 @@ cmd_setprompt (ASSUAN_CONTEXT ctx, char *line) newp = malloc (strlen (line) + 1); if (!newp) - return ASSUAN_Out_Of_Core; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM); strcpy_escaped (newp, line); if (pinentry.prompt) @@ -923,8 +934,8 @@ cmd_setprompt (ASSUAN_CONTEXT ctx, char *line) to identify a key for caching strategies of its own. The empty string and --clear mean that the key does not have a stable identifier. */ -static int -cmd_setkeyinfo (ASSUAN_CONTEXT ctx, char *line) +static gpg_error_t +cmd_setkeyinfo (assuan_context_t ctx, char *line) { (void)ctx; @@ -940,8 +951,8 @@ cmd_setkeyinfo (ASSUAN_CONTEXT ctx, char *line) } -static int -cmd_setrepeat (ASSUAN_CONTEXT ctx, char *line) +static gpg_error_t +cmd_setrepeat (assuan_context_t ctx, char *line) { char *p; @@ -949,7 +960,7 @@ cmd_setrepeat (ASSUAN_CONTEXT ctx, char *line) p = malloc (strlen (line) + 1); if (!p) - return ASSUAN_Out_Of_Core; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM); strcpy_escaped (p, line); free (pinentry.repeat_passphrase); @@ -958,8 +969,8 @@ cmd_setrepeat (ASSUAN_CONTEXT ctx, char *line) } -static int -cmd_setrepeaterror (ASSUAN_CONTEXT ctx, char *line) +static gpg_error_t +cmd_setrepeaterror (assuan_context_t ctx, char *line) { char *p; @@ -967,7 +978,7 @@ cmd_setrepeaterror (ASSUAN_CONTEXT ctx, char *line) p = malloc (strlen (line) + 1); if (!p) - return ASSUAN_Out_Of_Core; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM); strcpy_escaped (p, line); free (pinentry.repeat_error_string); @@ -976,8 +987,8 @@ cmd_setrepeaterror (ASSUAN_CONTEXT ctx, char *line) } -static int -cmd_seterror (ASSUAN_CONTEXT ctx, char *line) +static gpg_error_t +cmd_seterror (assuan_context_t ctx, char *line) { char *newe; @@ -985,7 +996,7 @@ cmd_seterror (ASSUAN_CONTEXT ctx, char *line) newe = malloc (strlen (line) + 1); if (!newe) - return ASSUAN_Out_Of_Core; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM); strcpy_escaped (newe, line); if (pinentry.error) @@ -995,8 +1006,8 @@ cmd_seterror (ASSUAN_CONTEXT ctx, char *line) } -static int -cmd_setok (ASSUAN_CONTEXT ctx, char *line) +static gpg_error_t +cmd_setok (assuan_context_t ctx, char *line) { char *newo; @@ -1004,7 +1015,7 @@ cmd_setok (ASSUAN_CONTEXT ctx, char *line) newo = malloc (strlen (line) + 1); if (!newo) - return ASSUAN_Out_Of_Core; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM); strcpy_escaped (newo, line); if (pinentry.ok) @@ -1014,8 +1025,8 @@ cmd_setok (ASSUAN_CONTEXT ctx, char *line) } -static int -cmd_setnotok (ASSUAN_CONTEXT ctx, char *line) +static gpg_error_t +cmd_setnotok (assuan_context_t ctx, char *line) { char *newo; @@ -1023,7 +1034,7 @@ cmd_setnotok (ASSUAN_CONTEXT ctx, char *line) newo = malloc (strlen (line) + 1); if (!newo) - return ASSUAN_Out_Of_Core; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM); strcpy_escaped (newo, line); if (pinentry.notok) @@ -1033,8 +1044,8 @@ cmd_setnotok (ASSUAN_CONTEXT ctx, char *line) } -static int -cmd_setcancel (ASSUAN_CONTEXT ctx, char *line) +static gpg_error_t +cmd_setcancel (assuan_context_t ctx, char *line) { char *newc; @@ -1042,7 +1053,7 @@ cmd_setcancel (ASSUAN_CONTEXT ctx, char *line) newc = malloc (strlen (line) + 1); if (!newc) - return ASSUAN_Out_Of_Core; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM); strcpy_escaped (newc, line); if (pinentry.cancel) @@ -1052,8 +1063,8 @@ cmd_setcancel (ASSUAN_CONTEXT ctx, char *line) } -static int -cmd_settimeout (ASSUAN_CONTEXT ctx, char *line) +static gpg_error_t +cmd_settimeout (assuan_context_t ctx, char *line) { (void)ctx; @@ -1063,8 +1074,8 @@ cmd_settimeout (ASSUAN_CONTEXT ctx, char *line) return 0; } -static int -cmd_settitle (ASSUAN_CONTEXT ctx, char *line) +static gpg_error_t +cmd_settitle (assuan_context_t ctx, char *line) { char *newt; @@ -1072,7 +1083,7 @@ cmd_settitle (ASSUAN_CONTEXT ctx, char *line) newt = malloc (strlen (line) + 1); if (!newt) - return ASSUAN_Out_Of_Core; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM); strcpy_escaped (newt, line); if (pinentry.title) @@ -1081,8 +1092,8 @@ cmd_settitle (ASSUAN_CONTEXT ctx, char *line) return 0; } -static int -cmd_setqualitybar (ASSUAN_CONTEXT ctx, char *line) +static gpg_error_t +cmd_setqualitybar (assuan_context_t ctx, char *line) { char *newval; @@ -1093,7 +1104,7 @@ cmd_setqualitybar (ASSUAN_CONTEXT ctx, char *line) newval = malloc (strlen (line) + 1); if (!newval) - return ASSUAN_Out_Of_Core; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM); strcpy_escaped (newval, line); if (pinentry.quality_bar) @@ -1103,8 +1114,8 @@ cmd_setqualitybar (ASSUAN_CONTEXT ctx, char *line) } /* Set the tooltip to be used for a quality bar. */ -static int -cmd_setqualitybar_tt (ASSUAN_CONTEXT ctx, char *line) +static gpg_error_t +cmd_setqualitybar_tt (assuan_context_t ctx, char *line) { char *newval; @@ -1114,7 +1125,7 @@ cmd_setqualitybar_tt (ASSUAN_CONTEXT ctx, char *line) { newval = malloc (strlen (line) + 1); if (!newval) - return ASSUAN_Out_Of_Core; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM); strcpy_escaped (newval, line); } @@ -1127,8 +1138,8 @@ cmd_setqualitybar_tt (ASSUAN_CONTEXT ctx, char *line) } -static int -cmd_getpin (ASSUAN_CONTEXT ctx, char *line) +static gpg_error_t +cmd_getpin (assuan_context_t ctx, char *line) { int result; int set_prompt = 0; @@ -1138,7 +1149,7 @@ cmd_getpin (ASSUAN_CONTEXT ctx, char *line) pinentry_setbuffer_init (&pinentry); if (!pinentry.pin) - return ASSUAN_Out_Of_Core; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ENOMEM); /* Try reading from the password cache. */ if (/* If repeat passphrase is set, then we don't want to read from @@ -1224,7 +1235,9 @@ cmd_getpin (ASSUAN_CONTEXT ctx, char *line) pinentry_setbuffer_clear (&pinentry); if (pinentry.specific_err) return pinentry.specific_err; - return pinentry.locale_err? ASSUAN_Locale_Problem: ASSUAN_Canceled; + return (pinentry.locale_err + ? gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_LOCALE_PROBLEM) + : gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_CANCELED)); } out: @@ -1259,8 +1272,8 @@ cmd_getpin (ASSUAN_CONTEXT ctx, char *line) update pinentry or to have the caller test for the message command. New applications which are free to require an updated pinentry should use MESSAGE instead. */ -static int -cmd_confirm (ASSUAN_CONTEXT ctx, char *line) +static gpg_error_t +cmd_confirm (assuan_context_t ctx, char *line) { int result; @@ -1288,19 +1301,19 @@ cmd_confirm (ASSUAN_CONTEXT ctx, char *line) return pinentry.specific_err; if (pinentry.locale_err) - return ASSUAN_Locale_Problem; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_LOCALE_PROBLEM); if (pinentry.one_button) return 0; if (pinentry.canceled) - return ASSUAN_Canceled; - return ASSUAN_Not_Confirmed; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_CANCELED); + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_NOT_CONFIRMED); } -static int -cmd_message (ASSUAN_CONTEXT ctx, char *line) +static gpg_error_t +cmd_message (assuan_context_t ctx, char *line) { (void)line; @@ -1315,7 +1328,7 @@ cmd_message (ASSUAN_CONTEXT ctx, char *line) version - Return the version of the program. pid - Return the process id of the server. */ -static int +static gpg_error_t cmd_getinfo (assuan_context_t ctx, char *line) { int rc; @@ -1333,7 +1346,7 @@ cmd_getinfo (assuan_context_t ctx, char *line) rc = assuan_send_data (ctx, numbuf, strlen (numbuf)); } else - rc = ASSUAN_Parameter_Error; + rc = gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ASS_PARAMETER); return rc; } @@ -1342,13 +1355,13 @@ cmd_getinfo (assuan_context_t ctx, char *line) Clear the cache passphrase associated with the key identified by cacheid. */ -static int -cmd_clear_passphrase (ASSUAN_CONTEXT ctx, char *line) +static gpg_error_t +cmd_clear_passphrase (assuan_context_t ctx, char *line) { (void)ctx; if (! line) - return ASSUAN_Invalid_Value; + return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ASS_INV_VALUE); /* Remove leading and trailing white space. */ while (*line == ' ') @@ -1359,50 +1372,47 @@ cmd_clear_passphrase (ASSUAN_CONTEXT ctx, char *line) switch (password_cache_clear (line)) { case 1: return 0; - case 0: return ASSUAN_Invalid_Value; - default: return ASSUAN_General_Error; + case 0: return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ASS_INV_VALUE); + default: return gpg_err_make (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_ASS_GENERAL); } } /* Tell the assuan library about our commands. */ -static int -register_commands (ASSUAN_CONTEXT ctx) +static gpg_error_t +register_commands (assuan_context_t ctx) { static struct { const char *name; - int cmd_id; - int (*handler) (ASSUAN_CONTEXT, char *line); + gpg_error_t (*handler) (assuan_context_t, char *line); } table[] = { - { "SETDESC", 0, cmd_setdesc }, - { "SETPROMPT", 0, cmd_setprompt }, - { "SETKEYINFO", 0, cmd_setkeyinfo }, - { "SETREPEAT", 0, cmd_setrepeat }, - { "SETREPEATERROR",0, cmd_setrepeaterror }, - { "SETERROR", 0, cmd_seterror }, - { "SETOK", 0, cmd_setok }, - { "SETNOTOK", 0, cmd_setnotok }, - { "SETCANCEL", 0, cmd_setcancel }, - { "GETPIN", 0, cmd_getpin }, - { "CONFIRM", 0, cmd_confirm }, - { "MESSAGE", 0, cmd_message }, - { "SETQUALITYBAR", 0, cmd_setqualitybar }, - { "SETQUALITYBAR_TT", 0, cmd_setqualitybar_tt }, - { "GETINFO", 0, cmd_getinfo }, - { "SETTITLE", 0, cmd_settitle }, - { "SETTIMEOUT", 0, cmd_settimeout }, - { "CLEARPASSPHRASE", 0, cmd_clear_passphrase }, + { "SETDESC", cmd_setdesc }, + { "SETPROMPT", cmd_setprompt }, + { "SETKEYINFO", cmd_setkeyinfo }, + { "SETREPEAT", cmd_setrepeat }, + { "SETREPEATERROR", cmd_setrepeaterror }, + { "SETERROR", cmd_seterror }, + { "SETOK", cmd_setok }, + { "SETNOTOK", cmd_setnotok }, + { "SETCANCEL", cmd_setcancel }, + { "GETPIN", cmd_getpin }, + { "CONFIRM", cmd_confirm }, + { "MESSAGE", cmd_message }, + { "SETQUALITYBAR", cmd_setqualitybar }, + { "SETQUALITYBAR_TT", cmd_setqualitybar_tt }, + { "GETINFO", cmd_getinfo }, + { "SETTITLE", cmd_settitle }, + { "SETTIMEOUT", cmd_settimeout }, + { "CLEARPASSPHRASE", cmd_clear_passphrase }, { NULL } }; - int i, j, rc; + int i, j; + gpg_error_t rc; for (i = j = 0; table[i].name; i++) { - rc = assuan_register_command (ctx, - table[i].cmd_id ? table[i].cmd_id - : (ASSUAN_CMD_USER + j++), - table[i].name, table[i].handler); + rc = assuan_register_command (ctx, table[i].name, table[i].handler, NULL); if (rc) return rc; } @@ -1413,9 +1423,9 @@ register_commands (ASSUAN_CONTEXT ctx) int pinentry_loop2 (int infd, int outfd) { - int rc; + gpg_error_t rc; int filedes[2]; - ASSUAN_CONTEXT ctx; + assuan_context_t ctx; /* Extra check to make sure we have dropped privs. */ #ifndef HAVE_DOSISH_SYSTEM @@ -1423,23 +1433,31 @@ pinentry_loop2 (int infd, int outfd) abort (); #endif + rc = assuan_new (&ctx); + if (rc) + { + fprintf (stderr, "server context creation failed: %s\n", + gpg_strerror(rc)); + return -1; + } + /* For now we use a simple pipe based server so that we can work from scripts. We will later add options to run as a daemon and wait for requests on a Unix domain socket. */ filedes[0] = infd; filedes[1] = outfd; - rc = assuan_init_pipe_server (&ctx, filedes); + rc = assuan_init_pipe_server (ctx, filedes); if (rc) { fprintf (stderr, "%s: failed to initialize the server: %s\n", - this_pgmname, assuan_strerror(rc)); + this_pgmname, gpg_strerror (rc)); return -1; } rc = register_commands (ctx); if (rc) { fprintf (stderr, "%s: failed to the register commands with Assuan: %s\n", - this_pgmname, assuan_strerror(rc)); + this_pgmname, gpg_strerror (rc)); return -1; } @@ -1457,7 +1475,7 @@ pinentry_loop2 (int infd, int outfd) else if (rc) { fprintf (stderr, "%s: Assuan accept problem: %s\n", - this_pgmname, assuan_strerror (rc)); + this_pgmname, gpg_strerror (rc)); break; } @@ -1465,12 +1483,12 @@ pinentry_loop2 (int infd, int outfd) if (rc) { fprintf (stderr, "%s: Assuan processing failed: %s\n", - this_pgmname, assuan_strerror (rc)); + this_pgmname, gpg_strerror (rc)); continue; } } - assuan_deinit_server (ctx); + assuan_release (ctx); return 0; } diff --git a/qt4/Makefile.am b/qt4/Makefile.am index 816aade..e2014e3 100644 --- a/qt4/Makefile.am +++ b/qt4/Makefile.am @@ -35,12 +35,11 @@ endif AM_CPPFLAGS = $(COMMON_CFLAGS) \ - -I$(top_srcdir) -I$(top_srcdir)/assuan -I$(top_srcdir)/secmem \ + -I$(top_srcdir) -I$(top_srcdir)/secmem \ $(ncurses_include) -I$(top_srcdir)/pinentry AM_CXXFLAGS = $(QT4_CORE_CFLAGS) $(QT4_GUI_CFLAGS) pinentry_qt4_LDADD = \ - ../pinentry/libpinentry.a $(top_builddir)/assuan/libassuan.a \ - $(top_builddir)/secmem/libsecmem.a \ + ../pinentry/libpinentry.a $(top_builddir)/secmem/libsecmem.a \ $(COMMON_LIBS) $(QT4_CORE_LIBS) $(QT4_GUI_LIBS) $(libcurses) $(LIBCAP) BUILT_SOURCES = \ diff --git a/tty/Makefile.am b/tty/Makefile.am index ca6406f..e232473 100644 --- a/tty/Makefile.am +++ b/tty/Makefile.am @@ -21,8 +21,7 @@ bin_PROGRAMS = pinentry-tty AM_CPPFLAGS = $(COMMON_CFLAGS) -I$(top_srcdir)/secmem -I$(top_srcdir)/pinentry -LDADD = ../pinentry/libpinentry.a \ - ../assuan/libassuan.a ../secmem/libsecmem.a \ +LDADD = ../pinentry/libpinentry.a ../secmem/libsecmem.a \ $(COMMON_LIBS) $(LIBCAP) $(LIBICONV) pinentry_tty_SOURCES = pinentry-tty.c -- 2.1.4 From wk at gnupg.org Mon Jun 15 11:06:35 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 15 Jun 2015 11:06:35 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: (Daiki Ueno's message of "Mon, 15 Jun 2015 12:15:51 +0900") References: <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87fv5xgr8j.wl-neal@walfield.org> <87wpz96uuq.fsf-ueno@gnu.org> <871thfrsjv.fsf-ueno@gnu.org> <871theh9sz.wl-neal@walfield.org> <87381u4fko.fsf@vigenere.g10code.de> <87zj42fm5p.wl-neal@walfield.org> <87wpz62p14.fsf@vigenere.g10code.de> <87y4jmfbee.wl-neal@walfield.org> Message-ID: <87r3pd2vdw.fsf@vigenere.g10code.de> On Mon, 15 Jun 2015 05:15, ueno at gnu.org said: > + /* Remove the INSIDE_EMACS variable so that a pinentry does not > + always try to interact with Emacs. */ > +#ifndef HAVE_W32_SYSTEM > + gnupg_unsetenv ("INSIDE_EMACS"); > +#endif I think we can do this on all platforms. The ifdef W32 is used for DISPLAY because tehre is no X Server there. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jun 15 11:09:09 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 15 Jun 2015 11:09:09 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87y4jmfbee.wl-neal@walfield.org> (Neal H. Walfield's message of "Sun, 14 Jun 2015 19:27:37 +0200") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87fv5xgr8j.wl-neal@walfield.org> <87wpz96uuq.fsf-ueno@gnu.org> <871thfrsjv.fsf-ueno@gnu.org> <871theh9sz.wl-neal@walfield.org> <87381u4fko.fsf@vigenere.g10code.de> <87zj42fm5p.wl-neal@walfield.org> <87wpz62p14.fsf@vigenere.g10code.de> <87y4jmfbee.wl-neal@walfield.org> Message-ID: <87mw012v9l.fsf@vigenere.g10code.de> On Sun, 14 Jun 2015 19:27, neal at walfield.org said: >> should do this. But be prepared that soon someone will ask for a >> --keep-inside-emacs option to make it really similar on how we handle >> DISPLAY. > > In what situation does that make sense? Don't we always want to use > the DISPLAY of the gpg process and not the gpg-agent? I think the Some people like to stick it to a certain display (or screen(1)). This is the reason for the --keep-display option of gpg-agent. I don't think that this makes sense for Emacs, but thatr's just me ;-) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jun 15 11:19:09 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 15 Jun 2015 11:19:09 +0200 Subject: Pinentry linking to libassuan? In-Reply-To: <87381vgyw1.wl-neal@walfield.org> (Neal H. Walfield's message of "Sat, 13 Jun 2015 22:02:38 +0200") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <873826fqms.fsf_-_@vigenere.g10code.de> <87381vgyw1.wl-neal@walfield.org> Message-ID: <87ioap2usy.fsf@vigenere.g10code.de> On Sat, 13 Jun 2015 22:02, neal at walfield.org said: > (option_handler): Return a gpg_error_t, not an int. Replace use of > ASSUAN_Out_Of_Core with gpg_err_make (GPG_ERR_SOURCE_PINENTRY, > GPG_ERR_ENOMEM), etc. Note that you can use #ifdef GPG_ERR_SOURCE_DEFAULT # error GPG_ERR_SOURCE_DEFAULT already defined #endif #define GPG_ERR_SOURCE_DEFAULT GPG_ERR_SOURCE_PINENTRY before you include gpg-error.h or even easier into configure's AH_BOTTOM() so that it shows up in config.h. After a system call you may also want to use gpg_error_from_syserror () instead of a fixed error code. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jun 15 11:31:35 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 15 Jun 2015 11:31:35 +0200 Subject: 2.1.5; documentation build failure In-Reply-To: (Daiki Ueno's message of "Mon, 15 Jun 2015 10:55:13 +0900") References: Message-ID: <87egld2u88.fsf@vigenere.g10code.de> On Mon, 15 Jun 2015 03:55, ueno at gnu.org said: > gnupg.texi:4: @include: could not find defs.inc > gnupg.texi:29: warning: undefined flag: VERSION defs.inc is build by these rules: --8<---------------cut here---------------start------------->8--- mkdefsinc: mkdefsinc.c Makefile ../config.h $(CC_FOR_BUILD) -I. -I.. -I$(srcdir) $(AM_CPPFLAGS) \ -o $@ $(srcdir)/mkdefsinc.c defsincdate: $(gnupg_TEXINFOS) : >defsincdate ; \ if test -d $(top_srcdir)/.git; then \ (cd $(srcdir) && git log -1 --format='%ct' \ -- $(gnupg_TEXINFOS) 2>/dev/null) >>defsincdate; \ fi defs.inc : defsincdate Makefile mkdefsinc incd="`test -f defsincdate || echo '$(srcdir)/'`defsincdate"; \ ./mkdefsinc -C $(srcdir) --date "`cat $$incd 2>/dev/null`" \ $(gnupg_TEXINFOS) >$@ --8<---------------cut here---------------end--------------->8--- which says that it should take the date from git if this is a git checkout or on a distributed tarball take it from a file tracking that date. VERSION is read by mkdefsinc from config.h. > I guess defs.inc should be properly marked as prerequisites, or the file > should be renamed back to version.texi? version.texi does not work with git because git does not preseve the modification time. Thus the git log thing above. You log output is too short to see what is going wrong. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Mon Jun 15 14:59:28 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 15 Jun 2015 21:59:28 +0900 Subject: pinentry-curses can be forced to loop endlessly In-Reply-To: <20150615105436.UPh8N9FBWq_F%sdaoden@yandex.com> References: <557A84D4.9020607@fsij.org> <20150613141659.gPhW11fuvJQm%sdaoden@yandex.com> <557E3F6E.6000101@fsij.org> <20150615105436.UPh8N9FBWq_F%sdaoden@yandex.com> Message-ID: <557ECC30.8060400@fsij.org> On 06/15/2015 07:54 PM, Steffen Nurpmeso wrote: > Well no, that is, maybe, but i liked pinentry-curses pretty much, > it was (working well but then it) just (that it) entered an > endless loop when i interrupted it once i've tested > *agent-shell-lookup* implementation. In my opinion it should > instead have handled the interrupt (cleanup and whatever), then > reraise the signal or exit error (or whatever). Since I'm not sure if I understand your report correctly, please let me rephrase your problem. ================ When a program (in your case mail user agent) kicks the chain of: (1) gpg --invoke--> gpg-agent --invoke--> pinentry-curses and a user tries to interrupt, it goes well. On the other hand, when gpg-agent is there already, it goes: (2) gpg --connect-> gpg-agent -invoke-> pinentry-curses Then, a user tries to interrupt, it goes wrong somehow. In the original report, the problem was: pinentry-curses's going endless loop. Now, pinentry-curses doesn't work well as you expected. --- (*) ================ Is this description correct? I don't understand well about the part of (*). Do you mean that the screen is wrong? I think that the cause of the difference between (1) and (2) might be the controlling terminal of a process. Let me investigate. -- From ueno at gnu.org Mon Jun 15 14:47:13 2015 From: ueno at gnu.org (Daiki Ueno) Date: Mon, 15 Jun 2015 21:47:13 +0900 Subject: 2.1.5; documentation build failure In-Reply-To: <87egld2u88.fsf@vigenere.g10code.de> (Werner Koch's message of "Mon, 15 Jun 2015 11:31:35 +0200") References: <87egld2u88.fsf@vigenere.g10code.de> Message-ID: <87a8w1m94e.fsf-ueno@gnu.org> Werner Koch writes: > On Mon, 15 Jun 2015 03:55, ueno at gnu.org said: > >> gnupg.texi:4: @include: could not find defs.inc >> gnupg.texi:29: warning: undefined flag: VERSION > > defs.inc is build by these rules: [...] > which says that it should take the date from git if this is a git > checkout or on a distributed tarball take it from a file tracking that > date. VERSION is read by mkdefsinc from config.h. Yes, if I run "make defs.inc" in the doc directory, it works fine. However, if I run "make all", it doesn't even build mkdefsinc nor defsincdate. Apparently, there is no dependency from *.info to defs.inc. I'm attaching a log of 'cd doc && make'. If you need more detailed output (e.g make -d), let me know. I'm using Automake 1.14.1. >> I guess defs.inc should be properly marked as prerequisites, or the file >> should be renamed back to version.texi? > > version.texi does not work with git because git does not preseve the > modification time. Thus the git log thing above. If I replace defs.inc with version.texi in gnupg.texi, Automake emits the following rules to Makefile.in: $(srcdir)/gnupg.info: gnupg.texi $(srcdir)/version.texi $(gnupg_TEXINFOS) gnupg.dvi: gnupg.texi $(srcdir)/version.texi $(gnupg_TEXINFOS) gnupg.pdf: gnupg.texi $(srcdir)/version.texi $(gnupg_TEXINFOS) gnupg.html: gnupg.texi $(srcdir)/version.texi $(gnupg_TEXINFOS) So, I think, if you rename the file, you need to manually add the dependencies, or maybe add defs.inc to BUILT_SOURCES, which should be built before other rules (it works fine here). Regards, -- Daiki Ueno -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: log.txt URL: From wk at gnupg.org Mon Jun 15 16:23:55 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 15 Jun 2015 16:23:55 +0200 Subject: 2.1.5; documentation build failure In-Reply-To: <87a8w1m94e.fsf-ueno@gnu.org> (Daiki Ueno's message of "Mon, 15 Jun 2015 21:47:13 +0900") References: <87egld2u88.fsf@vigenere.g10code.de> <87a8w1m94e.fsf-ueno@gnu.org> Message-ID: <87381t2gp0.fsf@vigenere.g10code.de> On Mon, 15 Jun 2015 14:47, ueno at gnu.org said: > the dependencies, or maybe add defs.inc to BUILT_SOURCES, which should > be built before other rules (it works fine here). Adding extra dependencies to info files is unfortunately not supported. See the long comment in the automake source about building info files in the build dir. Because I do not want to override the default {info,html,pdf} rules I have added defs.inc to BUILT_SOURCES which should do the trick. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Tue Jun 16 04:43:11 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 16 Jun 2015 11:43:11 +0900 Subject: pinentry-curses can be forced to loop endlessly In-Reply-To: <20150615142321.6yt1Z-ih1UEV%sdaoden@yandex.com> References: <557A84D4.9020607@fsij.org> <20150613141659.gPhW11fuvJQm%sdaoden@yandex.com> <557E3F6E.6000101@fsij.org> <20150615105436.UPh8N9FBWq_F%sdaoden@yandex.com> <557ECC30.8060400@fsij.org> <20150615142321.6yt1Z-ih1UEV%sdaoden@yandex.com> Message-ID: <557F8D3F.5030400@fsij.org> Thank you for your patience. I think that I finally understand the problem. On 06/15/2015 11:23 PM, Steffen Nurpmeso wrote: > Oh it was fine (was it even coloured?) except that it entered this > endless loop when i tested the interruption case. The problem is: Typing control-C, you expect killing pinentry along with gpg, but pinentry is still there. With old version of pinentry, it looped endlessly. With new version, although it doesn't loop endlessly, the process of pinentry remains. Configure gpg-agent with pinentry-curses, minimum test case is: $ gpg --sign some.txt [Type Control-C, when you see curses dialog] The pinentry process won't be killed by Control-C. (This is internal of gpg) Expected behavior is when gpg cancels its operation, it should notify gpg-agent so that gpg-agent can cancel pinentry. I created: https://bugs.gnupg.org/gnupg/issue2011 -- From neal at walfield.org Tue Jun 16 12:13:12 2015 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 16 Jun 2015 12:13:12 +0200 Subject: Pinentry linking to libassuan? In-Reply-To: <87ioap2usy.fsf@vigenere.g10code.de> References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <873826fqms.fsf_-_@vigenere.g10code.de> <87381vgyw1.wl-neal@walfield.org> <87ioap2usy.fsf@vigenere.g10code.de> Message-ID: <874mm80xmv.wl-neal@walfield.org> Hi, At Mon, 15 Jun 2015 11:19:09 +0200, Werner Koch wrote: > > On Sat, 13 Jun 2015 22:02, neal at walfield.org said: > > > (option_handler): Return a gpg_error_t, not an int. Replace use of > > ASSUAN_Out_Of_Core with gpg_err_make (GPG_ERR_SOURCE_PINENTRY, > > GPG_ERR_ENOMEM), etc. > > Note that you can use > > #ifdef GPG_ERR_SOURCE_DEFAULT > # error GPG_ERR_SOURCE_DEFAULT already defined > #endif > #define GPG_ERR_SOURCE_DEFAULT GPG_ERR_SOURCE_PINENTRY > > before you include gpg-error.h or even easier into configure's > AH_BOTTOM() so that it shows up in config.h. > > After a system call you may also want to use gpg_error_from_syserror () > instead of a fixed error code. Thanks for the feedback. I've done this and pushed this patched. :) Neal From neal at walfield.org Tue Jun 16 13:04:40 2015 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 16 Jun 2015 13:04:40 +0200 Subject: Pinentry: secure memory In-Reply-To: <873826fqms.fsf_-_@vigenere.g10code.de> References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <873826fqms.fsf_-_@vigenere.g10code.de> Message-ID: <87381r29tj.wl-neal@walfield.org> Hi, At Fri, 05 Jun 2015 11:31:23 +0200, Werner Koch wrote: > given that pinentry gets more and more complicated it does not anymore > fulfill its original goal to be small enough to be easily audited. One > of the main problem here has been the major changes to Gtk+ over the > last decade. And now of Emacs socket code is added as well. > > Originally Pinentry should be mostly self-standing but today this is > only true for the plain curses, tty and Windows versions. Most users > however build one of the real GUI versions with all their large > dependencies. > > The question is whether we should keep on using our much stripped down > versions of libassuan and libgpg-error or switch over to use libassuan > and libgpg-error directly. In fact, both libraries are required by > GnuPG itself and also be any software using GPGME. Thus we can expect > that such a change won't introduce any new platform problems. > > However, we should also link to Libgcrypt to make use of its secure > memory code - if that is something we should keep on using. It would > also be possible to do without and make sure that the passphrase is only > stored at one place which we would manually clear as needed. Frankly, I > think that the mlock-ed memory area is not useful anymore because it > does not help against hibernation. To mitigate the swapping problem an > encrypted swap partition is anyway much easier and safer. This raises another question: do the secure widgets actually increase security? Recall our threat model is someone reading the password from swap. Here are two things to consider: 1./ Even pinentry-tty uses buffered I/O to read in the password. Since libc doesn't mlock the buffers, the password can potentially end up in unlock memory. The password also flies through the X server and functions processing it may end up storing parts of the password on the stack. Ensuring that the password is only held in mlocked memory is a pipe dream. 2./ The secure widgets are based on very old code, which we forked from, e.g., Gtk+2. It is possible that bugs have been fixed. In the very least it has caused some accessibility issues. Unfortunately, we don't have time to continuously merge in changes. Using the stock widgets would be easy. What do others thinK? Should we use use the stock widgets or do the secure entry widgets actually increase security? Thanks, :) Neal From neal at walfield.org Tue Jun 16 13:10:30 2015 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 16 Jun 2015 13:10:30 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87mw012v9l.fsf@vigenere.g10code.de> References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87fv5xgr8j.wl-neal@walfield.org> <87wpz96uuq.fsf-ueno@gnu.org> <871thfrsjv.fsf-ueno@gnu.org> <871theh9sz.wl-neal@walfield.org> <87381u4fko.fsf@vigenere.g10code.de> <87zj42fm5p.wl-neal@walfield.org> <87wpz62p14.fsf@vigenere.g10code.de> <87y4jmfbee.wl-neal@walfield.org> <87mw012v9l.fsf@vigenere.g10code.de> Message-ID: <871thb29jt.wl-neal@walfield.org> At Mon, 15 Jun 2015 11:09:09 +0200, Werner Koch wrote: > On Sun, 14 Jun 2015 19:27, neal at walfield.org said: > > >> should do this. But be prepared that soon someone will ask for a > >> --keep-inside-emacs option to make it really similar on how we handle > >> DISPLAY. > > > > In what situation does that make sense? Don't we always want to use > > the DISPLAY of the gpg process and not the gpg-agent? I think the > > Some people like to stick it to a certain display (or screen(1)). This > is the reason for the --keep-display option of gpg-agent. In the screen case, it would be nice if pinentry-curses / pinentry-tty could emit a bell when a prompt is shown. I've opened https://bugs.gnupg.org/gnupg/issue2013 for this idea. :) Neal From neal at walfield.org Tue Jun 16 13:15:04 2015 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 16 Jun 2015 13:15:04 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87fv5xgr8j.wl-neal@walfield.org> <87wpz96uuq.fsf-ueno@gnu.org> <871thfrsjv.fsf-ueno@gnu.org> <871theh9sz.wl-neal@walfield.org> <87381u4fko.fsf@vigenere.g10code.de> <87zj42fm5p.wl-neal@walfield.org> <87wpz62p14.fsf@vigenere.g10code.de> <87y4jmfbee.wl-neal@walfield.org> Message-ID: <87zj3zzyyv.wl-neal@walfield.org> At Mon, 15 Jun 2015 12:15:51 +0900, Daiki Ueno wrote: > > From 3a4e67b768f232b31843e1a2e1441ae78cebbc18 Mon Sep 17 00:00:00 2001 > From: Daiki Ueno > Date: Mon, 15 Jun 2015 12:04:01 +0900 > Subject: [PATCH] agent: Unset INSIDE_EMACS on gpg-agent startup > > * agent/gpg-agent.c (main): Unset INSIDE_EMACS envvar. > > -- > > The variable is set only temporarily when gpg is called from Emacs, > keeping it during the session makes no sense. > > Signed-off-by: Daiki Ueno > --- > agent/gpg-agent.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c > index e721d8a..9430bb1 100644 > --- a/agent/gpg-agent.c > +++ b/agent/gpg-agent.c > @@ -1172,6 +1172,12 @@ main (int argc, char **argv ) > gnupg_unsetenv ("DISPLAY"); > #endif > > + /* Remove the INSIDE_EMACS variable so that a pinentry does not > + always try to interact with Emacs. */ > +#ifndef HAVE_W32_SYSTEM > + gnupg_unsetenv ("INSIDE_EMACS"); > +#endif > + This clears it when gpg-agent is in regular server mode. What about pipe server mode? Thanks, :) Neal From neal at walfield.org Tue Jun 16 16:09:39 2015 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 16 Jun 2015 16:09:39 +0200 Subject: pinentry loopback mode & password repeat In-Reply-To: <877fr8hhfm.wl-neal@walfield.org> References: <878ubohiep.wl-neal@walfield.org> <877fr8hhfm.wl-neal@walfield.org> Message-ID: <87wpz3zqvw.wl-neal@walfield.org> Hi, At Fri, 12 Jun 2015 21:09:49 +0200, Neal H. Walfield wrote: > At Fri, 12 Jun 2015 20:48:46 +0200, > Neal H. Walfield wrote: > > In issue #1976 (https://bugs.gnupg.org/gnupg/issue1976), Daiki reports > > that GnuPG 2.1 asks for the passphrase twice when encrypting in > > symmetric mode. I came up with a simple patch to always disable > > repeat mode when doing symmetric encryption. > > After discussing some more with Werner, it seems I misunderstood: we > shouldn't unconditionally disable repeat mode for symmetric encryption > operations, but unconditionally disable repeat mode when in pinentry > loopback mode. I've now pushed a patch that implements this behavior (only ever ask for a passphrase once if we are in pinentry loopback mode). This closes issue #1976. If this is a problem, please let me know soon so we can revert it. Thanks, :) Neal From neal at walfield.org Tue Jun 16 16:41:52 2015 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 16 Jun 2015 16:41:52 +0200 Subject: pinentry offers to save symmetric passwords in libsecret Message-ID: <87vbenzpe7.wl-neal@walfield.org> Hi, I've create issue #2014 about this, but I'd like to get wider feedback to figure out the right policy. Currently, pinentry offers to save passwords in an external cache (using libsecret) for both private keys and symmetric encryption keys. At the implementation level, this is because symmetric keys have a valid cache id (thus gpg-agent calls SETKEYINFO on a pinentry). A major issue with this, according to Werner, is that unlike public key crypto, people are using symmetric encryption because they don't want to leave any traces on the disk about the encryption. (Note: saving passwords in an external password manager is defined to be opt-in so security conscious users are unlikely to save the password.) What should we do? Should we allow users to save the passphrases for symmetric encryption keys or limit the external password manager to passphrases for public keys? In gpg 2.0, this is not easy to fix: both symmetric keys and public keys are marked cache mode CACHE_MODE_USER. In 2.1, public keys are marked CACHE_MODE_NORMAL. As such, in 2.1, we could not call SETKEYINFO for keys with CACHE_MODE_USER thereby preventing the pinentry from offer the option. Thanks, :) Neal From dkg at fifthhorseman.net Tue Jun 16 17:58:39 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 16 Jun 2015 11:58:39 -0400 Subject: pinentry offers to save symmetric passwords in libsecret In-Reply-To: <87vbenzpe7.wl-neal@walfield.org> References: <87vbenzpe7.wl-neal@walfield.org> Message-ID: <87oakfhcgg.fsf@alice.fifthhorseman.net> On Tue 2015-06-16 10:41:52 -0400, Neal H. Walfield wrote: > Currently, pinentry offers to save passwords in an external cache > (using libsecret) for both private keys and symmetric encryption keys. > At the implementation level, this is because symmetric keys have a > valid cache id (thus gpg-agent calls SETKEYINFO on a pinentry). I'm not even sure what it means to save a symmetric passphrase to the password manager, without saving an adequately sensible contextual string along with it. Let's say i encrypt two files symmetrically using different passwords. Upon decryption, what is there to distinguish the two? how would the password manager offer the user a choice between which symmetric key to use in this context? Maybe what i'm missing is how the "cache_id" is selected for the symmetric passphrase, both at creation time and at re-use time. can you summarize that? I dug around in the code a bit but didn't sort out how it's being done. --dkg From wk at gnupg.org Tue Jun 16 18:21:30 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 16 Jun 2015 18:21:30 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87zj3zzyyv.wl-neal@walfield.org> (Neal H. Walfield's message of "Tue, 16 Jun 2015 13:15:04 +0200") References: <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87fv5xgr8j.wl-neal@walfield.org> <87wpz96uuq.fsf-ueno@gnu.org> <871thfrsjv.fsf-ueno@gnu.org> <871theh9sz.wl-neal@walfield.org> <87381u4fko.fsf@vigenere.g10code.de> <87zj42fm5p.wl-neal@walfield.org> <87wpz62p14.fsf@vigenere.g10code.de> <87y4jmfbee.wl-neal@walfield.org> <87zj3zzyyv.wl-neal@walfield.org> Message-ID: <87fv5r1v5h.fsf@vigenere.g10code.de> On Tue, 16 Jun 2015 13:15, neal at walfield.org said: > This clears it when gpg-agent is in regular server mode. What about > pipe server mode? --server is not really useful anymore. I can't even remember when I used it the last time for debugging. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ueno at gnu.org Wed Jun 17 03:32:22 2015 From: ueno at gnu.org (Daiki Ueno) Date: Wed, 17 Jun 2015 10:32:22 +0900 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <871theh9sz.wl-neal@walfield.org> (Neal H. Walfield's message of "Sun, 14 Jun 2015 12:19:08 +0200") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87fv5xgr8j.wl-neal@walfield.org> <87wpz96uuq.fsf-ueno@gnu.org> <871thfrsjv.fsf-ueno@gnu.org> <871theh9sz.wl-neal@walfield.org> Message-ID: Hello Neal, Thanks for the review, and sorry for late response. I was a bit occupied with other tasks. "Neal H. Walfield" writes: > At Sun, 14 Jun 2015 10:24:04 +0900, > Daiki Ueno wrote: >> - the UID value check is now replaced with simple cast to uint32_t, >> using configure time check > > Is this really safe? Before you caught the error, now we silently > take the value mod 2^32. Right, I added a check: uid == (uint32_t) uid. The intention of the above change was to suppress a compiler warning saying that a check like uid <= ULONG_MAX always evaluates to true. >> However, perhaps the above scenario might be actually possible by >> explicitly unsetenv'ing INSIDE_EMACS in gpg-agent, when >> allow-emacs-pinentry is not set in gpg-agent.conf (like we do for >> DISPLAY, when keep-display is not set). > > I seem to remember Werner suggesting that this would require a large > change, but if it is easy, I would welcome this approach. I leave this as is for now. I think we could remove the Assuan option later if restricting the envvar is sufficient for our purpose. >> pinentry_cmd_handler_t fallback_cmd_handler; > > Is there any reason this isn't marked static? Sure, fixed. > If set_socket is successful, but read_from_emacs fails, then > emacs_socket will be valid (>= 0) and the test in > initial_emacs_cmd_handler will fail. I think > initial_emacs_cmd_handler either needs to test the return result of > pinentry_emacs_init or pinentry_emacs_init needs to deinit the socket > if emacs doesn't have pinentry support. I took the latter approach and added a code to deinit emacs_socket in other appropriate places as well. > pinentry_enable_emacs_cmd_handler can be called multiple times, but > this function isn't designed for this. > > void > pinentry_enable_emacs_cmd_handler (void) > { > const char *envvar; Good point. I added a check if pinentry_cmd_handler is already set to initial_emacs_cmd_handler or emacs_cmd_handler. > Also, since pinentry_enable_emacs_cmd_handler is only called from the > option handler, I don't think we need the field allow_emacs_prompt in > the pinentry structure. Yes, removed the field. Other changes from the previous version are: - Removed allocation code from read_from_emacs and simplified the interface - Fixed minor errors detected by clang-analyzer Regards, -- Daiki Ueno -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-inside-Emacs-mode-to-GUI-pinentry-programs.patch Type: text/x-patch Size: 27367 bytes Desc: not available URL: From ueno at gnu.org Wed Jun 17 08:59:22 2015 From: ueno at gnu.org (Daiki Ueno) Date: Wed, 17 Jun 2015 15:59:22 +0900 Subject: pinentry offers to save symmetric passwords in libsecret In-Reply-To: <87vbenzpe7.wl-neal@walfield.org> (Neal H. Walfield's message of "Tue, 16 Jun 2015 16:41:52 +0200") References: <87vbenzpe7.wl-neal@walfield.org> Message-ID: Daniel Kahn Gillmor writes: > Maybe what i'm missing is how the "cache_id" is selected for the > symmetric passphrase, both at creation time and at re-use time. can you > summarize that? I dug around in the code a bit but didn't sort out how > it's being done. If I remember correctly (and the logic hasn't changed), it is a randomly chosen 8-octet salt value: http://tools.ietf.org/html/rfc4880#section-3.7.1.2 "Neal H. Walfield" writes: > A major issue with this, according to Werner, is that unlike public > key crypto, people are using symmetric encryption because they don't > want to leave any traces on the disk about the encryption. > > What should we do? Should we allow users to save the passphrases for > symmetric encryption keys or limit the external password manager to > passphrases for public keys? IMHO, the latter sounds better, unless the user frequently opens certain files which are symmetrically encrypted (e.g., ~/.authinfo.gpg used by Gnus, which saves IMAP passwords, etc. in that file); in that case, an additional information (a filename, etc) should be associated with the passphrase within the password manager. Also, a minor problem is that, if a user removes or re-encrypts a file, the old salt value will persists in the password manager. Regards, -- Daiki Ueno From wk at gnupg.org Wed Jun 17 09:10:49 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Jun 2015 09:10:49 +0200 Subject: pinentry offers to save symmetric passwords in libsecret In-Reply-To: <87oakfhcgg.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 16 Jun 2015 11:58:39 -0400") References: <87vbenzpe7.wl-neal@walfield.org> <87oakfhcgg.fsf@alice.fifthhorseman.net> Message-ID: <87wpz2zu6e.fsf@vigenere.g10code.de> On Tue, 16 Jun 2015 17:58, dkg at fifthhorseman.net said: > Maybe what i'm missing is how the "cache_id" is selected for the > symmetric passphrase, both at creation time and at re-use time. can you > summarize that? I dug around in the code a bit but didn't sort out how The S2K salt is used as cache id. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Wed Jun 17 12:25:15 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 17 Jun 2015 12:25:15 +0200 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87fv5xgr8j.wl-neal@walfield.org> <87wpz96uuq.fsf-ueno@gnu.org> <871thfrsjv.fsf-ueno@gnu.org> <871theh9sz.wl-neal@walfield.org> Message-ID: <87pp4uzl6c.wl-neal@walfield.org> At Wed, 17 Jun 2015 10:32:22 +0900, Daiki Ueno wrote: > Thanks for the review, and sorry for late response. I was a bit > occupied with other tasks. No problem! I hope you didn't have the impression that I was rushing you. I've committed your patch with a few small changes. If you have any issues with them, please let me know. The changes are: I changed comment recognition. I think any line that starts with a '#' and not just those that start with "# " should be recognized as comments. If INSIDE_EMACS is not defined, then I changed the option handler to return GPG_ERR_NOT_SUPPORTED. Finally, I forward ported the patch to the tip. Thanks for working on this! :) Neal From ueno at gnu.org Thu Jun 18 03:51:25 2015 From: ueno at gnu.org (Daiki Ueno) Date: Thu, 18 Jun 2015 10:51:25 +0900 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87pp4uzl6c.wl-neal@walfield.org> (Neal H. Walfield's message of "Wed, 17 Jun 2015 12:25:15 +0200") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87fv5xgr8j.wl-neal@walfield.org> <87wpz96uuq.fsf-ueno@gnu.org> <871thfrsjv.fsf-ueno@gnu.org> <871theh9sz.wl-neal@walfield.org> <87pp4uzl6c.wl-neal@walfield.org> Message-ID: "Neal H. Walfield" writes: > I've committed your patch with a few small changes. If you have any > issues with them, please let me know. The changes are: Thanks, those changes look good to me. I've also added pinentry.el to Emacs git master and ELPA, so it can be easily tested with: M-x package-install pinentry M-x pinentry-start Regards, -- Daiki Ueno From gniibe at fsij.org Thu Jun 18 10:42:36 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 18 Jun 2015 17:42:36 +0900 Subject: Gnuk 1.1.5 Message-ID: <5582847C.5080503@fsij.org> Two weeks ago, Gnuk 1.1.5 was out. Please note that the repository at gitorious.org is gone and I put repositories at alioth.debian.org. I didn't have time to post this announcement, since I was busy writing a story. I wish you enjoy this story: More Entropy, Please: http://www.gniibe.org/memo/development/gnuk/rng/more-entropy-please.html My plan is using this story as a kind of spin for selling NeuG device. ==================== This is another experimental release of version 1.1.x series. Gnuk Documentation is also updated: http://www.fsij.org/doc-gnuk/ Here are highlights. * upgrade_by_passwd.py is not so noisy any more. Since it's getting stable, no debug output any more. * Maple mini support. Although its random number generation is not tested, Maple mini support is added. * Windows interoperability fix. 1.1.x (0 to 4) didn't work with Windows because of INTERRUPT transfer. It's fixed and it works now. * OpenPGPcard specification v3.0 compatibility. OpenPGPcard specification v3.0 now include NIST curves (and other curves) and ECDSA and ECDH operations are defined. Gnuk follows this specification. Links: Gnuk Users Mailing List at alioth.debian.org: https://lists.alioth.debian.org/mailman/listinfo/gnuk-users Gnuk Project and its repositories: https://anonscm.debian.org/cgit/gnuk/ FST-01 Gnuk Handbook (in Japanese): http://no-passwd.net/fst-01-gnuk-handbook/ FST-01 introduction: http://www.seeedstudio.com/wiki/index.php?title=FST-01 -- From pedro.msac at gmail.com Fri Jun 19 14:55:41 2015 From: pedro.msac at gmail.com (Pedro Coelho) Date: Fri, 19 Jun 2015 13:55:41 +0100 Subject: Issue 1998 Extended and Composed Characters on password. Message-ID: Hi , Sorry to come up again with the same issue. I posted some weeks ago an issue about gpg that I have detected while working with gpg on Multiple/Cross systems. This was passed to the bug tracking system as issue 1998. I do not seem to be able to reply/follow-up on the bugtrack system so I hope to contribute in here for the same issue. I have tested to encrypt a file with a password that as several types of characters, ascii, extended and composed. As stated in the previous email listed below: https://bugs.gnupg.org/gnupg/issue1998 I was able to narrow down the problem to Composed Characters on the password. That is if one uses extended characters like the ones resulting from using or + and try to decrypt the file on a different OS/Computer, obviously the same keyboard layout must be present. If the characters showing up on the CLI are the same as the ones used on the password ... no problem for gpg to work correctly. I made some tests passing the same file to Multiple Distros installed and reached the conclusion that extended character support is not always reliable to say the least ... but it can work. For instance on Centos7 minimal with the exact same keyboard layout the characters shown on display are not the same as in my default OpenSuSE 13.2 or Ubuntu. But once they are found gpg can decrypt the file. That is an issue not of gpg but rather of the available mappings an Locales on those particular systems. One as to simply be advised for those issues in case of using gpg in multiple environments. But problems do not stop there. I have narrow down the problem of the decrypt bad key error to the Composed Character. If one uses composed characters problems keep showing up. I used on the Same PC two sessions: One normal OpenSuSE KDE environment, the other LXDE environment. I noticed that on the LXDE session when using extended altgr/altgr+shift chars I was able to decrypt my file. The problem came about when dealing with Composed characters ... those where a Symbol and a regular Character are composed. Those who write in English most likelly never used such characters ... like ? or ?. (don't even know if they even display correctly on your email reader ... ) Those are a problem since in different systems Even with the same Locale keyboard layout and Locale the use of a single composed chars can be "misinterpreted". On pinentry I've also seen for example when trying to enter a composed character the box showed a double entry ...two chars (asteriscs) instead of one ... So this may indeed be a OS/Locale problem rather then a gpg problem ... Regards, Pedro -------------- next part -------------- An HTML attachment was scrubbed... URL: From bre at pagekite.net Fri Jun 19 17:27:46 2015 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Fri, 19 Jun 2015 15:27:46 -0000 Subject: Memory Hole discussion / OpenPGP e-mail header protection Message-ID: <20150619135603-5988-65181-mailpile@slinky> Hello GnuPG-devel! Greetings from the Digital Citizenship and Surveillance Society conference in Cardiff! I am here with Meskio from Leap and Varac from Pixelated - they wanted to talk Memory Hole, so I did my best to summarize for them what was discussed at the summit last April. I've also recently had conversations about this with the folks at Lavaboom (Kernal is cc'ed). So there is plenty of interest! As I recall the plan last April was to continue the discussion here on this mailing list, but as far as I can tell that never really happened... until now. :-) Below is the rough summary I wrote up for Meskio and Varac, of my current understanding of the rough consensus that was reached in April. Please correct me if I got anything wrong! Sorry if this is really dense, I'm happy to clarify any points which are unclear. Links: - DKG's talk/slides: https://www.ietf.org/proceedings/92/slides/slides-92-appsawg-0.pdf - Mailpile 50% implementation: https://github.com/mailpile/Mailpile/blob/master/mailpile/contrib/experiments/experiments.py Idea summary: The goal is to extend the protection afforded by PGP/MIME to a subset of the message headers, in particular the Subject line. 1. MOVE or COPY headers from the RFC2822 header into a MIME part of type text/rfc822-headers 1.1. Moving can provide confidentiality, when a message is encrypted 1.2. Copying provides integrity, as a subset of the headers is signed 2. Protect the moved/copied header-part with a signature and/or encryption as appropriate (PGP/MIME) 3. Visibility of the moved/copied headers can be controlled using the Content-Disposition MIME attribute; this is useful for backwards compatibility. Refinements discussed at GnuPG summit: 1. The spec should be clear on how to structure mail (so where the attachment goes, how many) 2. For ENCRYPTED mail: 1. When headers are MOVED from the normal header (for privacy), SOME should be made visible to users with older MUAs 2. Since only some headers are made visible, this implies two text/rfc822-headers parts: 1. One visible part, in-line at top of message, 2. A second attachment, containing non-critical headers 3. Any given header should only be present in one of the two parts; unambiguous rules desirable. Visible headers override invisible? 3. For SIGNED (not encrypted) mail: 1. All headers are visible; never MOVE headers 2. No backwards compatibility concerns - so only one attachment with secure headers 4. The text/rfc822-headers part, when an attachment, should be given a user-friendly name 5. How to present this in the user interface? Which headers are "secure" or "insecure" 6. Which headers should be protected by default? Which headers are only copied, which are moved? 7. Compatibility concerns: 1. What breaks if we obscure the To / From / Cc / Reply-To / Errors-To / ... 2. What breaks if we obscure the References: and In-Reply-To: headers? 3. What breaks if we obscure the Message-ID? Next steps: 1. Try implementing it, exchanging mail 2. Write up the spec, host the on modernpgp site? 3. Standardize? I've made progress on 1, but I have nobody to exchange mail with... any volunteers? Cheers, - Bjarni -- Sent using Mailpile, Free Software from www.mailpile.is -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP Digital Signature URL: From gniibe at fsij.org Mon Jun 22 07:41:16 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 22 Jun 2015 14:41:16 +0900 Subject: scd: Fix Cherry ST-2000 support for pinpad input. Message-ID: <55879FFC.9080609@fsij.org> Hello, I applied and push a patch to fix an issue of pinpad input support for Cherry ST-2000. I saw two issues (2003 and 2004) in the BTS and a report in gnupg-users. I believe that in-stock CCID driver works fine with this patch. I'm not sure if the change is enough for PC/SC service on Windows. For GNU/Linux, I recommend in-stock CCID driver. -- From gniibe at fsij.org Tue Jun 23 03:24:48 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 23 Jun 2015 10:24:48 +0900 Subject: scd: pinpad workaround for PC/SC implementations. (was: scd: Fix Cherry ST-2000 support for pinpad input.) In-Reply-To: <55879FFC.9080609@fsij.org> References: <55879FFC.9080609@fsij.org> Message-ID: <5588B560.90203@fsij.org> On 06/22/2015 02:41 PM, NIIBE Yutaka wrote: > I believe that in-stock CCID driver works fine with this patch. I'm > not sure if the change is enough for PC/SC service on Windows. > > For GNU/Linux, I recommend in-stock CCID driver. Examining the source code of libccid and testing with it 1.4.18 and 1.4.19, I realized that we need following workaround now. I don't know if this is related to the behavior on Windows, but, this fixes the case of mine with Gemalto USB GemPCPinpad SmartCard Reader. Tested and worked fine. I'm going to push this fix. scd: pinpad workaround for PC/SC implementations. * scd/adpu.c (pcsc_pinpad_verify, pcsc_pinpad_modify): Bigger buffer for TPDU card reader. -- GnuPG-bug-id: 2003, 2004 This is needed for PC/SC on Debian Jessie. Note that it's not only for Cherry ST-2000, but also, for any TPDU card readers. diff --git a/scd/apdu.c b/scd/apdu.c index 82b2e1f..e8797cd 100644 --- a/scd/apdu.c +++ b/scd/apdu.c @@ -2290,8 +2290,16 @@ pcsc_pinpad_verify (int slot, int class, int ins, int p0, int p1, int sw; unsigned char *pin_verify; int len = PIN_VERIFY_STRUCTURE_SIZE + pininfo->fixedlen; - unsigned char result[2]; - pcsc_dword_t resultlen = 2; + /* + * The result buffer is only expected to have two-byte result on + * return. However, some implementation uses this buffer for lower + * layer too and it assumes that there is enough space for lower + * layer communication. Such an implementation fails for TPDU + * readers with "insufficient buffer", as it needs header and + * trailer. Six is the number for header + result + trailer (TPDU). + */ + unsigned char result[6]; + pcsc_dword_t resultlen = 6; int no_lc; if (!reader_table[slot].atrlen @@ -2365,8 +2373,8 @@ pcsc_pinpad_modify (int slot, int class, int ins, int p0, int p1, int sw; unsigned char *pin_modify; int len = PIN_MODIFY_STRUCTURE_SIZE + 2 * pininfo->fixedlen; - unsigned char result[2]; - pcsc_dword_t resultlen = 2; + unsigned char result[6]; /* See the comment at pinpad_verify. */ + pcsc_dword_t resultlen = 6; int no_lc; if (!reader_table[slot].atrlen -- From bernhard at intevation.de Tue Jun 23 16:26:50 2015 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 23 Jun 2015 16:26:50 +0200 Subject: Issue 1998 Extended and Composed Characters on password. In-Reply-To: References: Message-ID: <201506231626.51292.bernhard@intevation.de> Hi Pedro, On Friday 19 June 2015 at 14:55:41, Pedro Coelho wrote: > This was passed to the bug tracking system as issue 1998. > I do not seem to be able to reply/follow-up on the bugtrack system so I > hope to contribute in here for the same issue. in oder to be able to followup on the tracker, you need to have a tracker id and you must have been creating the issue in question or being upgraded to regular user. What is your tracker it? I've added your post to the issue. Best, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Tue Jun 23 16:37:18 2015 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 23 Jun 2015 16:37:18 +0200 Subject: GPGME pyme branch ready to merge with master In-Reply-To: <5557A7F2.5090002@adversary.org> References: <5557A7F2.5090002@adversary.org> Message-ID: <201506231637.24354.bernhard@intevation.de> Hi Ben, On Saturday 16 May 2015 at 22:26:26, Ben McGinnes wrote: > ????????As the subject indicates, the pyme branch in the GPGME repo is > ready to be merged with master. thanks for caring for the python3 bindings! Can you add the python3 version to https://wiki.gnupg.org/APIs so we can keep the overview there? Thanks. Bernhard ps.: just use your bugs.gnupg.org credentials to log in. -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From ben at adversary.org Tue Jun 23 17:20:33 2015 From: ben at adversary.org (Ben McGinnes) Date: Wed, 24 Jun 2015 01:20:33 +1000 Subject: GPGME pyme branch ready to merge with master In-Reply-To: <201506231637.24354.bernhard@intevation.de> References: <5557A7F2.5090002@adversary.org> <201506231637.24354.bernhard@intevation.de> Message-ID: <55897941.1070207@adversary.org> On 24/06/2015 12:37 am, Bernhard Reiter wrote: > Hi Ben, > > On Saturday 16 May 2015 at 22:26:26, Ben McGinnes wrote: >> As the subject indicates, the pyme branch in the GPGME repo is >> ready to be merged with master. > > thanks for caring for the python3 bindings! > Can you add the python3 version to https://wiki.gnupg.org/APIs > so we can keep the overview there? Sure. Also, it reminds me I've a little tweaking of it left after all. I've also given more thought to its eventual replacement after GPGME gets its overhaul and I think I'm leaning more towards CFFI than Cython to replace SWIG. I do love the idea of Cython, but that's not a good enough reason to select it for the job. CFFI, however, gives some significant benefits. Not least of which being: only needing to write Python code, native support for JIT interpreters (i.e. PyPy) and most performance tests indicate it's the most resource efficient of its kind. It's also the C framework of choice for certain other crypto modules (e.g. pyca/cryptography.py, PyCrypto and others others). It might make some of those things play together much more readily. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Tue Jun 23 16:21:54 2015 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 23 Jun 2015 16:21:54 +0200 Subject: trustdb calculation very slow (gpg2.0 vs gpg1) Message-ID: <201506231622.00041.bernhard@intevation.de> Hi on a Debian GNU/Linux Jessie system I have a defect that the trust calculation of a cert is taking a lot of time. Almost 2 minutes with 100%cpu. This used to be different with early gnupg2 versions I've used and it is different to gpg (1), where it were 20 seconds. No report found, thus seem to depend on my trustdb. Any ideas on how to create a good report/debug? Details: How to recreate: gpg2 --delete-key 52D717F3 time LANG=C gpg2 -v --recv-keys 52D717F3 real 1m57.144s user 1m46.560s sys 0m9.296s # as compared to gpg verison 1 gpg2 --delete-key 52D717F3 time LANG=C gpg --recv-keys 52D717F3 real 0m19.840s user 0m18.192s sys 0m0.900s ii gnupg 1.4.18-7 i386 GNU privacy guard - a free PGP re ii gnupg2 2.0.26-6 i386 GNU privacy guard - a free PGP re With 2.0.25-99intevation2 on Wheezy I did not notice the issue, but of course, my trustdb changed over time. Thanks in advance, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From Alexander.Strobel at giepa.de Tue Jun 23 17:27:29 2015 From: Alexander.Strobel at giepa.de (Alexander Strobel) Date: Tue, 23 Jun 2015 17:27:29 +0200 Subject: Memory Hole discussion / OpenPGP e-mail header protection In-Reply-To: <20150619135603-5988-65181-mailpile@slinky> References: <20150619135603-5988-65181-mailpile@slinky> Message-ID: <55897AE1.6000205@giepa.de> Hello Bjarne (and everyone else on the list) > I've made progress on 1, but I have nobody to exchange mail with... > any volunteers? We would be happy to exchange test emails with you and everyone else. Therefore we created a new email address openpgp.test at gpg4o.com and a corresponding OpenPGP key (Long Key-ID: 0x9B058941 74DEBFA4, uploaded to pool.sks-keyservers.net). This address is also suitable for other compability related tests. Please pay attention that this address is observed by humans only and there will be no automated processing of incoming emails. So answering incoming emails may take a while, but we try our best to answer it in time. One question regarding the specs: Did you talk about a version field? I think it might be easier to distinguish between emails from different implementation stages. I think this would also be helpful for debugging purposes after the initial release 1.0 . Regards Alex Strobel (gpg4o Team) From meskio at sindominio.net Tue Jun 23 20:16:48 2015 From: meskio at sindominio.net (Ruben Pollan) Date: Tue, 23 Jun 2015 20:16:48 +0200 Subject: Memory Hole discussion / OpenPGP e-mail header protection In-Reply-To: <55897AE1.6000205@giepa.de> References: <20150619135603-5988-65181-mailpile@slinky> <55897AE1.6000205@giepa.de> Message-ID: <20150623181648.10259.38722@KingMob> Quoting Alexander Strobel (2015-06-23 17:27:29) > One question regarding the specs: Did you talk about a version field? I > think it might be easier to distinguish between emails from different > implementation stages. I think this would also be helpful for debugging > purposes after the initial release 1.0 . You are right, it might be a good idea. We could add a 'Memory-Hole' header with the version, and this might be the place to add more info if needed in the future. This could be placed at the text/rfc822-headers attachment. -- Ruben Pollan | http://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: http://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: signature URL: From bre at pagekite.net Tue Jun 23 21:48:48 2015 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Tue, 23 Jun 2015 19:48:48 -0000 Subject: Memory Hole discussion / OpenPGP e-mail header protection In-Reply-To: <20150623181648.10259.38722@KingMob> References: <20150623181648.10259.38722@KingMob> Message-ID: <20150623185357-26635-45568-mailpile@slinky> Hello! Thanks Alexander for offering to receive test mail! Kernal of lavaboom has as well, I'll probably send my first round of tests tomorrow. Ruben Pollan wrote: > Quoting Alexander Strobel (2015-06-23 17:27:29) > > One question regarding the specs: Did you talk about a version field? I > > think it might be easier to distinguish between emails from different > > implementation stages. I think this would also be helpful for debugging > > purposes after the initial release 1.0 . > > You are right, it might be a good idea. We could add a 'Memory-Hole' header with > the version, and this might be the place to add more info if needed in the > future. This could be placed at the text/rfc822-headers attachment. Thanks for bringing this up! Leaving aside for a moment whether it's a version header or something else, this does remind me of something from the discussions in April that I forgot in my rehash: - There needs to be a way to differentiate Memory-Hole parts from other parts that just happen to be of MIME-type text/rfc822-headers. That marker may include a version identifier as well, but the important thing is we need a marker of some sort. It can't really be part of the text/rfc822-headers payload as you suggest, because that both has performance implications (you need to parse the part BEFORE you can know what it is) and would make the spec no longer content-agnostic; in particular we wouldn't be able to discuss the spec itself over e-mail without breaking things. Ideally the marker needs to be *inside* the encrypted or signed envelope. Having spent a little time browsing RFC2045, I think the Content-Type header of the memory-hole part might be the right place for this. Something like: Content-Type: text/rfc822-headers; charset=us-ascii; memoryhole=v1 AFAICT this fulfills the criteria of being legal according to the relevant RFCs, not user-configurable (so we're not preventing any legitimate use) and within the signed or encrypted envelope. I don't yet know whether this is easy or hard for folks to implement. Thoughts? - Bjarni -- Sent using Mailpile, Free Software from www.mailpile.is -------------- next part -------------- A non-text attachment was scrubbed... Name: Encryption key for Bjarni Runar Einarsson.asc Type: application/pgp-keys Size: 18318 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP Digital Signature URL: From pvoigt at uos.de Tue Jun 23 23:35:14 2015 From: pvoigt at uos.de (Dr. Peter Voigt) Date: Tue, 23 Jun 2015 23:35:14 +0200 Subject: trustdb calculation very slow (gpg2.0 vs gpg1) In-Reply-To: <201506231622.00041.bernhard@intevation.de> References: <201506231622.00041.bernhard@intevation.de> Message-ID: <20150623233514.6214f429@kirk.drpetervoigt.private> On Tue, 23 Jun 2015 16:21:54 +0200 Bernhard Reiter wrote: > Hi > on a Debian GNU/Linux Jessie system I have a defect that > the trust calculation of a cert is taking a lot of time. > Almost 2 minutes with 100%cpu. > This used to be different with early gnupg2 versions I've used > and it is different to gpg (1), where it were 20 seconds. > > No report found, thus seem to depend on my trustdb. > Any ideas on how to create a good report/debug? > > Details: > How to recreate: > gpg2 --delete-key 52D717F3 > time LANG=C gpg2 -v --recv-keys 52D717F3 > real 1m57.144s > user 1m46.560s > sys 0m9.296s > > # as compared to gpg verison 1 > gpg2 --delete-key 52D717F3 > time LANG=C gpg --recv-keys 52D717F3 > real 0m19.840s > user 0m18.192s > sys 0m0.900s > > ii gnupg 1.4.18-7 i386 GNU privacy guard - a > free PGP re ii gnupg2 2.0.26-6 i386 GNU privacy > guard - a free PGP re > > With 2.0.25-99intevation2 on Wheezy I did not notice the issue, > but of course, my trustdb changed over time. > > Thanks in advance, > Bernhard > Bernhard, I am just having a fully configured VirtualBox VM of Jessie with Gnome 3 available, but I am not having this problem: % time LANG=C gpg2 -v --recv-keys 52D717F3 ... LANG=C gpg2 -v --recv-keys 52D717F3 0.11s user 0.06s system 7% cpu 2.304 total % dpkg -l gnupg2 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=============================================================================================================== ii gnupg2 2.0.26-6 amd64 GNU privacy guard - a free PGP replacement (new v2.x) Regards, Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From wk at gnupg.org Wed Jun 24 09:02:34 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 24 Jun 2015 09:02:34 +0200 Subject: trustdb calculation very slow (gpg2.0 vs gpg1) In-Reply-To: <201506231622.00041.bernhard@intevation.de> (Bernhard Reiter's message of "Tue, 23 Jun 2015 16:21:54 +0200") References: <201506231622.00041.bernhard@intevation.de> Message-ID: <87oak5si5x.fsf@vigenere.g10code.de> On Tue, 23 Jun 2015 16:21, bernhard at intevation.de said: > on a Debian GNU/Linux Jessie system I have a defect that > the trust calculation of a cert is taking a lot of time. > Almost 2 minutes with 100%cpu. This has also been reported as https://bugs.gnupg.org/gnupg/issue2019 Please see there for followups. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Wed Jun 24 09:10:48 2015 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 24 Jun 2015 09:10:48 +0200 Subject: wiki / Re: GPGME pyme branch ready to merge with master In-Reply-To: <55897941.1070207@adversary.org> References: <5557A7F2.5090002@adversary.org> <201506231637.24354.bernhard@intevation.de> <55897941.1070207@adversary.org> Message-ID: <201506240910.54156.bernhard@intevation.de> On Tuesday 23 June 2015 at 17:20:33, Ben McGinnes wrote: > > thanks for caring for the python3 bindings! > > Can you add the python3 version to https://wiki.gnupg.org/APIs > > so we can keep the overview there? > > Sure. Also, it reminds me I've a little tweaking of it left after all. Thanks! > I've also given more thought to its eventual replacement after GPGME > gets its overhaul Just as a hint: If you want, you can always use wiki.gnupg.org as a scratch book for design ideas or anything else. Personally I believe that results of longer thoughts are more accessible when saved in the wiki, because it allows to have a concise documented and a history, while the email list tends more to be a stream of discussion where you need to participate to get the context, so old emails are less well understood than a concise wiki page. Best, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed Jun 24 09:17:35 2015 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 24 Jun 2015 09:17:35 +0200 Subject: trustdb calculation very slow (gpg2.0 vs gpg1) In-Reply-To: <20150623233514.6214f429@kirk.drpetervoigt.private> References: <201506231622.00041.bernhard@intevation.de> <20150623233514.6214f429@kirk.drpetervoigt.private> Message-ID: <201506240917.36681.bernhard@intevation.de> Peter, On Tuesday 23 June 2015 at 23:35:14, Dr. Peter Voigt wrote: > I am just having a fully configured VirtualBox VM of Jessie with Gnome > 3 available, but I am not having this problem: thanks for trying to reproduce! As your result is showing as well: It probably depends on my .gnupg data like the contents of my trustdb, private keys and settings. Of course I cannot just make this available, so I am grateful for hints to find out more about the issue. I could try to export, delete and reimport the trustdb, but because gpg 1.4 works on it a lot better I assume that it is not a simple structural problem of my trustdb. (Which I hope both gpg versions would detect.) So I am not sure, if this is a good step to take. Best, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed Jun 24 09:41:02 2015 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 24 Jun 2015 09:41:02 +0200 Subject: trustdb calculation very slow (gpg2.0 vs gpg1) In-Reply-To: <87oak5si5x.fsf@vigenere.g10code.de> References: <201506231622.00041.bernhard@intevation.de> <87oak5si5x.fsf@vigenere.g10code.de> Message-ID: <201506240941.07806.bernhard@intevation.de> On Wednesday 24 June 2015 at 09:02:34, Werner Koch wrote: > This has also been reported as > ? https://bugs.gnupg.org/gnupg/issue2019 > Please see there for followups. Thanks, somehow I did not find this issue in my search. I've added my addition info to it. -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From imrehg at gmail.com Wed Jun 24 11:52:56 2015 From: imrehg at gmail.com (Gergely Imreh) Date: Wed, 24 Jun 2015 09:52:56 +0000 Subject: [PATCH] curses: remove hard-wired ncursesw include path Message-ID: <1435139568-1565-1-git-send-email-imrehg@gmail.com> * pinentry/pinentry-curses.c: pkg-config finds the correct include paths so should not hard-wire the path for the ncursesw header file. --- Tested it with Buildroot, where the pinentry build fails due to the fixed ncursesw header. See for example autobuilder results at http://autobuild.buildroot.org/results/252/2528c7dfdc1ff9f0e6030ecfc22ff3acd26808e2/ --- pinentry/pinentry-curses.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/pinentry/pinentry-curses.c b/pinentry/pinentry-curses.c index 784c770..659fa47 100644 --- a/pinentry/pinentry-curses.c +++ b/pinentry/pinentry-curses.c @@ -22,11 +22,7 @@ #include #endif #include -#ifdef HAVE_NCURSESW -#include -#else #include -#endif #include #include #include -- 1.9.1 From patrick at enigmail.net Wed Jun 24 13:06:59 2015 From: patrick at enigmail.net (Patrick Brunschwig) Date: Wed, 24 Jun 2015 13:06:59 +0200 Subject: Memory Hole discussion / OpenPGP e-mail header protection In-Reply-To: <20150619135603-5988-65181-mailpile@slinky> References: <20150619135603-5988-65181-mailpile@slinky> Message-ID: <558A8F53.3060200@enigmail.net> On 19.06.15 17:27, Bjarni Runar Einarsson wrote: > Refinements discussed at GnuPG summit: > > 1. The spec should be clear on how to structure mail (so where the > attachment goes, how many) > 2. For ENCRYPTED mail: > 1. When headers are MOVED from the normal header (for privacy), SOME should be made visible to users with older MUAs > 2. Since only some headers are made visible, this implies two text/rfc822-headers parts: > 1. One visible part, in-line at top of message, > 2. A second attachment, containing non-critical headers > 3. Any given header should only be present in one of the two parts; unambiguous rules desirable. Visible headers override invisible? > 3. For SIGNED (not encrypted) mail: > 1. All headers are visible; never MOVE headers > 2. No backwards compatibility concerns - so only one attachment with secure headers > 4. The text/rfc822-headers part, when an attachment, should be given a > user-friendly name > 5. How to present this in the user interface? Which headers are "secure" > or "insecure" > 6. Which headers should be protected by default? Which headers are only > copied, which are moved? > 7. Compatibility concerns: > 1. What breaks if we obscure the To / From / Cc / Reply-To / Errors-To / ... > 2. What breaks if we obscure the References: and In-Reply-To: headers? > 3. What breaks if we obscure the Message-ID? > > > Next steps: > > 1. Try implementing it, exchanging mail > 2. Write up the spec, host the on modernpgp site? > 3. Standardize? > > > I've made progress on 1, but I have nobody to exchange mail with... any > volunteers? I'm currently working on this in Enigmail. I have a 70% implementation for reading the RFC822-headers part; once I'll have completed with this, I'll work on creating such messages. I'll be very happy to have another mail client to try to exchange mails. I expect to finish this in the next 3 weeks. I'll report back when I'm ready for testing. -Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From neal at walfield.org Wed Jun 24 14:31:19 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 24 Jun 2015 14:31:19 +0200 Subject: [PATCH] curses: remove hard-wired ncursesw include path In-Reply-To: <1435139568-1565-1-git-send-email-imrehg@gmail.com> References: <1435139568-1565-1-git-send-email-imrehg@gmail.com> Message-ID: <87mvzpz3s8.wl-neal@walfield.org> Hi, At Wed, 24 Jun 2015 09:52:56 +0000, Gergely Imreh wrote: > > * pinentry/pinentry-curses.c: pkg-config finds the correct include > paths so should not hard-wire the path for the ncursesw header file. Thanks! I've applied and pushed this. :) Neal From wk at gnupg.org Wed Jun 24 15:26:53 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 24 Jun 2015 15:26:53 +0200 Subject: Memory Hole discussion / OpenPGP e-mail header protection In-Reply-To: <20150619135603-5988-65181-mailpile@slinky> (Bjarni Runar Einarsson's message of "Fri, 19 Jun 2015 15:27:46 -0000") References: <20150619135603-5988-65181-mailpile@slinky> Message-ID: <87a8vps0de.fsf@vigenere.g10code.de> On Fri, 19 Jun 2015 17:27, bre at pagekite.net said: > 7. Compatibility concerns: > 1. What breaks if we obscure the To / From / Cc / Reply-To / Errors-To / ... Spam filter and general procmail rules. When running procomail (or whatever you guys use these days) on the client there will be a need for unattended decryption. This raises the same security concerns as those with Enigmail's auto decryption. > 2. What breaks if we obscure the References: and In-Reply-To: headers? Threaded display (unless auto decrypted) > 3. What breaks if we obscure the Message-ID? I don't see a problem here. The Message-id is only used locally and there should be no problem to use the replacement Message-ID. In fact there is no need for an encrypted Message-ID. If a MUA requires an authenticated Message-ID it may also use a hash of the signature instead. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bre at pagekite.net Thu Jun 25 18:12:33 2015 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Thu, 25 Jun 2015 16:12:33 -0000 Subject: Memory Hole discussion / OpenPGP e-mail header protection In-Reply-To: <558AB874.5060301@rundquadrat.at> References: <558AB874.5060301@rundquadrat.at> Message-ID: <20150625155353-31430-65983-mailpile@slinky> OK, I sent out a pair of test messages, on encrypted, one signed. For a version/part-marker, I added an attribute to the Content-Type, like so: memoryhole="v1," This allows for versioning and also binds the part to the message it applies to, which was one of the questions raised in April. I suspect we'll want to rename from "memoryhole" to something less cool but more descriptive sooner rather than later; "pgp-mime-headers" comes to mind? - Bjarni -- Sent using Mailpile, Free Software from www.mailpile.is -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP Digital Signature URL: From ben at adversary.org Thu Jun 25 18:41:55 2015 From: ben at adversary.org (Ben McGinnes) Date: Fri, 26 Jun 2015 02:41:55 +1000 Subject: wiki / Re: GPGME pyme branch ready to merge with master In-Reply-To: <201506240910.54156.bernhard@intevation.de> References: <5557A7F2.5090002@adversary.org> <201506231637.24354.bernhard@intevation.de> <55897941.1070207@adversary.org> <201506240910.54156.bernhard@intevation.de> Message-ID: <558C2F53.3080008@adversary.org> On 24/06/2015 5:10 pm, Bernhard Reiter wrote: > On Tuesday 23 June 2015 at 17:20:33, Ben McGinnes wrote: >>> thanks for caring for the python3 bindings! >>> Can you add the python3 version to https://wiki.gnupg.org/APIs >>> so we can keep the overview there? >> >> Sure. Also, it reminds me I've a little tweaking of it left after all. > > Thanks! It was added a day or two ago. >> I've also given more thought to its eventual replacement after GPGME >> gets its overhaul > > Just as a hint: > If you want, you can always use wiki.gnupg.org as a scratch book > for design ideas or anything else. Yeah, wikis are good for both that and for collaboration when a thing reaches the point where that stops being a distraction and starts being useful. Before that point I'm often fond of anything with no reliance on browsers and actually a quiet corner of a docs directory of a branch of a repo often works wonders there. It even, if necessary, tracks the evolution of any ideas had along the way. > Personally I believe that results of longer thoughts are more > accessible when saved in the wiki, because it allows to have a > concise documented and a history, while the email list tends more to > be a stream of discussion where you need to participate to get the > context, so old emails are less well understood than a concise wiki > page. Yeah, I've found similar results with text (mainly markdown or reST) within a repo because it puts me in the frame of mind to write documentation, even if that's more just feeling out the scope of a thing. So that's what I've started with for the future thing and I'll bring it to the wiki when I've got a clearer idea of what I'm bringing. Plus I can write even when my DSL connection is being a bit dodgy and not worry about losing anything. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Fri Jun 26 08:23:45 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 26 Jun 2015 15:23:45 +0900 Subject: [PATCH] scd: Support button flag and AES key data for OpenPGPcard v3.0. Message-ID: <558CEFF1.3060005@fsij.org> Hello, I'm adding OpenPGPcard v3.0. The process is basically on demand. In this month, since I was asked about the features of symmetric decryption and button, I add those two. No, it's not ready yet (I mean, not fully implemented). This is only a part of the feature. We need to consider about how symmetric decryption will be asked from gpg-agent to scdaemon. I'm going to push this change to the repository. * scd/app-openpgp.c (do_getattr, show_caps, app_select_openpgp): Support button and symmetric decryption. (do_setattr): Support setting AESKEY. diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 0e751e0..467389d 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -1,6 +1,6 @@ /* app-openpgp.c - The OpenPGP card application. * Copyright (C) 2003, 2004, 2005, 2007, 2008, - * 2009, 2013, 2014 Free Software Foundation, Inc. + * 2009, 2013, 2014, 2015 Free Software Foundation, Inc. * * This file is part of GnuPG. * @@ -114,6 +114,9 @@ static struct { { 0x0103, 0, 0, 0, 0, 0, 0, 0, "Private DO 3"}, { 0x0104, 0, 0, 0, 0, 0, 0, 0, "Private DO 4"}, { 0x7F21, 1, 0, 1, 0, 0, 0, 1, "Cardholder certificate"}, + /* V3.0 */ + { 0x7F74, 0, 0, 1, 0, 0, 0, 0, "General Feature Management"}, + { 0x00D5, 0, 0, 1, 0, 0, 0, 0, "AES key data"}, { 0 } }; @@ -195,13 +198,15 @@ struct app_local_s { struct { unsigned int is_v2:1; /* This is a v2.0 compatible card. */ + unsigned int sm_supported:1; /* Secure Messaging is supported. */ unsigned int get_challenge:1; unsigned int key_import:1; unsigned int change_force_chv:1; unsigned int private_dos:1; unsigned int algo_attr_change:1; /* Algorithm attributes changeable. */ - unsigned int sm_supported:1; /* Secure Messaging is supported. */ - unsigned int sm_aes128:1; /* Use AES-128 for SM. */ + unsigned int has_decrypt:1; /* Support symmetric decryption. */ + unsigned int has_button:1; + unsigned int sm_algo:2; /* Symmetric crypto algo for SM. */ unsigned int max_certlen_3:16; unsigned int max_get_challenge:16; /* Maximum size for get_challenge. */ unsigned int max_cmd_data:16; /* Maximum data size for a command. */ @@ -1057,7 +1062,8 @@ do_getattr (app_t app, ctrl_t ctrl, const char *name) char tmp[110]; snprintf (tmp, sizeof tmp, - "gc=%d ki=%d fc=%d pd=%d mcl3=%u aac=%d sm=%d si=%u", + "gc=%d ki=%d fc=%d pd=%d mcl3=%u aac=%d " + "sm=%d si=%u dec=%d bt=%d", app->app_local->extcap.get_challenge, app->app_local->extcap.key_import, app->app_local->extcap.change_force_chv, @@ -1065,9 +1071,12 @@ do_getattr (app_t app, ctrl_t ctrl, const char *name) app->app_local->extcap.max_certlen_3, app->app_local->extcap.algo_attr_change, (app->app_local->extcap.sm_supported - ? (app->app_local->extcap.sm_aes128? 7 : 2) + ? (app->app_local->extcap.sm_algo == 0? 2 : + (app->app_local->extcap.sm_algo == 1? 7 : 9)) : 0), - app->app_local->status_indicator); + app->app_local->status_indicator, + app->app_local->extcap.has_decrypt, + app->app_local->extcap.has_button); send_status_info (ctrl, table[idx].name, tmp, strlen (tmp), NULL, 0); return 0; } @@ -2119,6 +2128,7 @@ do_setattr (app_t app, const char *name, { "SM-KEY-ENC", 0x00D1, 3, 0, 1 }, { "SM-KEY-MAC", 0x00D2, 3, 0, 1 }, { "KEY-ATTR", 0, 0, 3, 1 }, + { "AESKEY", 0x00D5, 3, 0, 1 }, { NULL, 0 } }; int exmode; @@ -4302,13 +4312,16 @@ show_caps (struct app_local_s *s) log_info ("Algo-Attr-Change: %s\n", s->extcap.algo_attr_change? "yes":"no"); log_info ("SM-Support .....: %s", s->extcap.sm_supported? "yes":"no"); if (s->extcap.sm_supported) - log_printf (" (%s)", s->extcap.sm_aes128? "AES-128":"3DES"); + log_printf (" (%s)", s->extcap.sm_algo==2? "3DES": + (s->extcap.sm_algo==2? "AES-128" : "AES-256")); log_info ("Max-Cert3-Len ..: %u\n", s->extcap.max_certlen_3); log_info ("Max-Cmd-Data ...: %u\n", s->extcap.max_cmd_data); log_info ("Max-Rsp-Data ...: %u\n", s->extcap.max_rsp_data); log_info ("Cmd-Chaining ...: %s\n", s->cardcap.cmd_chaining?"yes":"no"); log_info ("Ext-Lc-Le ......: %s\n", s->cardcap.ext_lc_le?"yes":"no"); log_info ("Status Indicator: %02X\n", s->status_indicator); + log_info ("Symmetric crypto: %s\n", s->extcap.has_decrypt? "yes":"no"); + log_info ("Button..........: %s\n", s->extcap.has_button? "yes":"no"); log_info ("GnuPG-No-Sync ..: %s\n", s->flags.no_sync? "yes":"no"); log_info ("GnuPG-Def-PW2 ..: %s\n", s->flags.def_chv2? "yes":"no"); @@ -4568,11 +4581,12 @@ app_select_openpgp (app_t app) app->app_local->extcap.change_force_chv = !!(*buffer & 0x10); app->app_local->extcap.private_dos = !!(*buffer & 0x08); app->app_local->extcap.algo_attr_change = !!(*buffer & 0x04); + app->app_local->extcap.has_decrypt = !!(*buffer & 0x02); } if (buflen >= 10) { /* Available with v2 cards. */ - app->app_local->extcap.sm_aes128 = (buffer[1] == 1); + app->app_local->extcap.sm_algo = buffer[1]; app->app_local->extcap.max_get_challenge = (buffer[2] << 8 | buffer[3]); app->app_local->extcap.max_certlen_3 = (buffer[4] << 8 | buffer[5]); @@ -4586,6 +4600,12 @@ app_select_openpgp (app_t app) if (app->card_version <= 0x0100 && manufacturer == 1) app->app_local->extcap.change_force_chv = 1; + /* Check optional DO of "General Feature Management" for button. */ + relptr = get_one_do (app, 0x7f74, &buffer, &buflen, NULL); + if (relptr) + /* It must be: 03 81 01 20 */ + app->app_local->extcap.has_button = 1; + parse_login_data (app); if (opt.verbose) -- From wk at gnupg.org Fri Jun 26 11:25:13 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 26 Jun 2015 11:25:13 +0200 Subject: wiki / Re: GPGME pyme branch ready to merge with master In-Reply-To: <558C2F53.3080008@adversary.org> (Ben McGinnes's message of "Fri, 26 Jun 2015 02:41:55 +1000") References: <5557A7F2.5090002@adversary.org> <201506231637.24354.bernhard@intevation.de> <55897941.1070207@adversary.org> <201506240910.54156.bernhard@intevation.de> <558C2F53.3080008@adversary.org> Message-ID: <874mlurfd2.fsf@vigenere.g10code.de> On Thu, 25 Jun 2015 18:41, ben at adversary.org said: > Yeah, I've found similar results with text (mainly markdown or reST) > within a repo because it puts me in the frame of mind to write BTW, I noticed that you used reST for the python docs. Would you mind to convert this to org-mode (or let me do this after the merge) so that that we can use a common format for all GnuPG documentation? org-mode is easy readable and writable without any special software and renders nicely into all kind of formats (and yes, Emacs can be used in batch mode). I hope that eventually there will be a way to replace Texinfo by it as well (A @deftypefun substitute being the missing part). Shalom-Salam, Werner -- Direct from the all things must be org department. From wk at gnupg.org Fri Jun 26 11:30:32 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 26 Jun 2015 11:30:32 +0200 Subject: [PATCH] scd: Support button flag and AES key data for OpenPGPcard v3.0. In-Reply-To: <558CEFF1.3060005@fsij.org> (NIIBE Yutaka's message of "Fri, 26 Jun 2015 15:23:45 +0900") References: <558CEFF1.3060005@fsij.org> Message-ID: <87zj3mq0jr.fsf@vigenere.g10code.de> On Fri, 26 Jun 2015 08:23, gniibe at fsij.org said: > No, it's not ready yet (I mean, not fully implemented). This is only > a part of the feature. We need to consider about how symmetric > decryption will be asked from gpg-agent to scdaemon. What use case do you have in mind for secure messaging ? Is it how to tell scdaemon that SM needs to be used and how to store and convey the key? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ben at adversary.org Fri Jun 26 11:38:21 2015 From: ben at adversary.org (Ben McGinnes) Date: Fri, 26 Jun 2015 19:38:21 +1000 Subject: wiki / Re: GPGME pyme branch ready to merge with master In-Reply-To: <874mlurfd2.fsf@vigenere.g10code.de> References: <5557A7F2.5090002@adversary.org> <201506231637.24354.bernhard@intevation.de> <55897941.1070207@adversary.org> <201506240910.54156.bernhard@intevation.de> <558C2F53.3080008@adversary.org> <874mlurfd2.fsf@vigenere.g10code.de> Message-ID: <558D1D8D.5060200@adversary.org> On 26/06/2015 7:25 pm, Werner Koch wrote: > On Thu, 25 Jun 2015 18:41, ben at adversary.org said: > >> Yeah, I've found similar results with text (mainly markdown or reST) >> within a repo because it puts me in the frame of mind to write > > BTW, I noticed that you used reST for the python docs. Would you mind > to convert this to org-mode (or let me do this after the merge) so that > that we can use a common format for all GnuPG documentation? org-mode > is easy readable and writable without any special software and renders > nicely into all kind of formats (and yes, Emacs can be used in batch > mode). I hope that eventually there will be a way to replace Texinfo by > it as well (A @deftypefun substitute being the missing part). Yep, I can convert them afterwards. Or just learn another mark-ish (-up, -down, -sideways, etc.) language. Pandoc is my friend. I used reST more out of habit because of the reST/Python link. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From astieger at suse.com Fri Jun 26 14:04:32 2015 From: astieger at suse.com (Andreas Stieger) Date: Fri, 26 Jun 2015 14:04:32 +0200 Subject: [PATCH] gpgme: update FSF address Message-ID: <558D3FD0.60001@suse.com> Hello, please consider the following changes, split up to stay below message size limit: Use verbatim GPL-2.0 license text file Use verbatim LGPL-2.1 license text file Update FSF address - tests Update FSF address - code No functional change. With kind regards, Andreas Stieger -- Andreas Stieger Project Manager Security SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG N?rnberg) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-verbatim-GPL-2.0-license-text-file.patch Type: text/x-patch Size: 6060 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Use-verbatim-LGPL-2.1-license-text-file.patch Type: text/x-patch Size: 11252 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From astieger at suse.com Fri Jun 26 14:07:44 2015 From: astieger at suse.com (Andreas Stieger) Date: Fri, 26 Jun 2015 14:07:44 +0200 Subject: [PATCH 3/4] gpgme: update FSF address In-Reply-To: <558D3FD0.60001@suse.com> References: <558D3FD0.60001@suse.com> Message-ID: <558D4090.4080203@suse.com> On 06/26/2015 02:04 PM, Andreas Stieger wrote: > Update FSF address - tests -- Andreas Stieger Project Manager Security SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG N?rnberg) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Update-FSF-address-tests.patch Type: text/x-patch Size: 24206 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From astieger at suse.com Fri Jun 26 14:24:26 2015 From: astieger at suse.com (Andreas Stieger) Date: Fri, 26 Jun 2015 14:24:26 +0200 Subject: [PATCH 4/4] gpgme: update FSF address In-Reply-To: <558D3FD0.60001@suse.com> References: <558D3FD0.60001@suse.com> Message-ID: <558D447A.2040103@suse.com> On 06/26/2015 02:04 PM, Andreas Stieger wrote: > Update FSF address - code -- Andreas Stieger Project Manager Security SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG N?rnberg) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Update-FSF-address-code.patch.xz Type: application/x-xz Size: 3944 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Fri Jun 26 14:29:28 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 26 Jun 2015 21:29:28 +0900 Subject: [PATCH] scd: Support button flag and AES key data for OpenPGPcard v3.0. In-Reply-To: <87zj3mq0jr.fsf@vigenere.g10code.de> References: <558CEFF1.3060005@fsij.org> <87zj3mq0jr.fsf@vigenere.g10code.de> Message-ID: <558D45A8.7000805@fsij.org> On 06/26/2015 06:30 PM, Werner Koch wrote: > On Fri, 26 Jun 2015 08:23, gniibe at fsij.org said: > >> No, it's not ready yet (I mean, not fully implemented). This is only >> a part of the feature. We need to consider about how symmetric >> decryption will be asked from gpg-agent to scdaemon. > > What use case do you have in mind for secure messaging ? Is it how to > tell scdaemon that SM needs to be used and how to store and convey the > key? No, what I added today is not for secure messaging (and I don't have any idea to implement secure messaging). The change is adding data object handling for the operation of PSO:DECIPHER with symmetric key. This feature is added in v2.1. With the change of today, a user (or manufacturer) can put AES key onto the data object of 0xD5. Then, the (bare) use case will be something like: $ gpg-connect-agent "SETKEY " "SETHASH 02..." PKDECRYPT /bye In the specification of OpenPGPcard v2.1 or later, cryptogram with prefix 0x02 means symmetric decryption. I don't know well about the background of this enhancement of PSO:DECIPHER. This would be useful to send an initial encrypted message to a customer from a card manufacturer, I guess. -- From wk at gnupg.org Fri Jun 26 20:25:32 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 26 Jun 2015 20:25:32 +0200 Subject: [The IESG] [openpgp] WG Action: Rechartered Open Specification for Pretty Good Privacy (openpgp) Message-ID: <87fv5enx7n.fsf@vigenere.g10code.de> Hi, we have a go for working on a revision of OpenPGP. Salam-Shalom, Werner -------------- next part -------------- An embedded message was scrubbed... From: The IESG Subject: [openpgp] WG Action: Rechartered Open Specification for Pretty Good Privacy (openpgp) Date: Fri, 26 Jun 2015 09:57:58 -0700 Size: 6798 URL: -------------- next part -------------- -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From patrick at enigmail.net Sun Jun 28 17:47:04 2015 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sun, 28 Jun 2015 17:47:04 +0200 Subject: Memory Hole discussion / OpenPGP e-mail header protection In-Reply-To: <20150625155353-31430-65983-mailpile@slinky> References: <558AB874.5060301@rundquadrat.at> <20150625155353-31430-65983-mailpile@slinky> Message-ID: <559016F8.1070906@enigmail.net> On 25.06.15 18:12, Bjarni Runar Einarsson wrote: > OK, I sent out a pair of test messages, on encrypted, one signed. > > For a version/part-marker, I added an attribute to the Content-Type, > like so: > > memoryhole="v1," > > This allows for versioning and also binds the part to the message it > applies to, which was one of the questions raised in April. I suspect > we'll want to rename from "memoryhole" to something less cool but more > descriptive sooner rather than later; "pgp-mime-headers" comes to mind? The headers we protect are not PGP/MIME headers. I think something like "protected-headers" or "secure-headers" would be better. -Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From bre at pagekite.net Sun Jun 28 19:31:10 2015 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Sun, 28 Jun 2015 17:31:10 -0000 Subject: Memory Hole discussion / OpenPGP e-mail header protection In-Reply-To: <559016F8.1070906@enigmail.net> References: <559016F8.1070906@enigmail.net> Message-ID: <20150628172001-31604-82866-mailpile@slinky> Hello! Patrick Brunschwig wrote: > > This allows for versioning and also binds the part to the message it > > applies to, which was one of the questions raised in April. I suspect > > we'll want to rename from "memoryhole" to something less cool but more > > descriptive sooner rather than later; "pgp-mime-headers" comes to mind? > > The headers we protect are not PGP/MIME headers. I think something like > "protected-headers" or "secure-headers" would be better. I'm assuming this will be an extension to whatever RFCs discuss PGP/MIME, which is why I used those words. In fact, if/when there is an RFC for this, I'd vote for calling them rfc9999-headers. :-) Patrick wrote on another thread: > We should agree on certain specifics like how to display non-ASCII > characters in the memory hole headers. I would vote against using RFC > 2047, section 2 (e.g. =?UTF-8?blah?=), such that users can read the > headers easily if their mailers would not yet understand memory hole. I think I disagree. Although I applaud the sentiment (it's awesome that we're considering usability here), my gut feeling is the headers should be exactly like they are in the public header section. This will make both the spec and the code to implement it much simpler, lowering the bar to getting everyone to adopt this. Showing the headers to the user at all is a backwards-compatibility hack which should only be necessary for a relatively brief window in time, as all the PGP plugins and mailers implement the new standard. Considering how many folks we had in the room in April, I don't think I'm being overly optimistic... :-) Ideally once things are properly integrated, the visible duplicate header section simply disappears and friendly green locks or checkmarks appear in the MUA header display instead. If users get annoyed by ugly extra header sections, maybe that will encourage them to upgrade their tools. Cheers! - Bjarni -- Sent using Mailpile, Free Software from www.mailpile.is -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP Digital Signature URL: From dkg at fifthhorseman.net Mon Jun 29 05:27:24 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 28 Jun 2015 23:27:24 -0400 Subject: [PATCH] curses: remove hard-wired ncursesw include path In-Reply-To: <87mvzpz3s8.wl-neal@walfield.org> References: <1435139568-1565-1-git-send-email-imrehg@gmail.com> <87mvzpz3s8.wl-neal@walfield.org> Message-ID: <87fv5b2nz7.fsf@alice.fifthhorseman.net> On Wed 2015-06-24 08:31:19 -0400, Neal H. Walfield wrote: > Hi, > > At Wed, 24 Jun 2015 09:52:56 +0000, > Gergely Imreh wrote: >> >> * pinentry/pinentry-curses.c: pkg-config finds the correct include >> paths so should not hard-wire the path for the ncursesw header file. > > Thanks! I've applied and pushed this. hm, this is a reverse of 21e83f422667e431c1283b9ae3356fded3523e50, which is a changeset i'm the author on. the commit log for 21e83f states: Avoid implicit declaration of function addnwstr. * pinentry/pinentry-curses.c [HAVE_NCURSESW]: Include . [! HAVE_NCURSESW]: Only include in this case. -- When built with libncursesw, we see this problem: pinentry-curses.c:440:8: warning: implicit declaration of function ?addnwstr? [-Wimplicit-function-declaration] ADDCH (start[i]); ^ I ran into this on debian unstable systems. If we revert it, i'm concerned that this will mean restoring the warning again; i agree with Gergely that pkg-config *should* do things properly and the additional #ifdef shouldn't be needed, but that's not what i saw happening. Maybe there's some other way to fix this cleanly? --dkg From ueno at gnu.org Mon Jun 29 11:05:56 2015 From: ueno at gnu.org (Daiki Ueno) Date: Mon, 29 Jun 2015 18:05:56 +0900 Subject: [PATCH] curses: remove hard-wired ncursesw include path In-Reply-To: <87fv5b2nz7.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Sun, 28 Jun 2015 23:27:24 -0400") References: <1435139568-1565-1-git-send-email-imrehg@gmail.com> <87mvzpz3s8.wl-neal@walfield.org> <87fv5b2nz7.fsf@alice.fifthhorseman.net> Message-ID: Daniel Kahn Gillmor writes: > I ran into this on debian unstable systems. If we revert it, i'm > concerned that this will mean restoring the warning again; i agree with > Gergely that pkg-config *should* do things properly and the additional > #ifdef shouldn't be needed, but that's not what i saw happening. I observed a couple of things: - On Debian, pkg-config ncursesw --cflags returns: -D_GNU_SOURCE -I/usr/include/ -I/usr/include/ncursesw where the first -I is superfluous and causing the problem, as there is /usr/include/curses.h. This might be a bug in ncurses upstream (I've reported it). - On Fedora, /usr/include/{,ncurses/,ncursesw/}curses.h are identical and have the addnwstr declaration. This is legitimate because the header file for the wide-character configuration is upper compatible with the non-wide-character version, as noted in ncurses/INSTALL. > Maybe there's some other way to fix this cleanly? I guess the cleaner way is either to fix the former issue (though it might be a bit fragile to rely on the -I order), or to change the packaging like the latter. Regards, -- Daiki Ueno From astieger at suse.com Mon Jun 29 11:14:42 2015 From: astieger at suse.com (Andreas Stieger) Date: Mon, 29 Jun 2015 11:14:42 +0200 Subject: [PATCH] gpgme: update FSF address In-Reply-To: <558D3FD0.60001@suse.com> References: <558D3FD0.60001@suse.com> Message-ID: <55910C82.8070601@suse.com> Hello, On 06/26/2015 02:04 PM, Andreas Stieger wrote: > please consider the following changes, split up to stay below message > size limit: > Use verbatim GPL-2.0 license text file > Use verbatim LGPL-2.1 license text file > Update FSF address - tests > Update FSF address - code Also... https://github.com/andreasstieger/gpgme/tree/license https://github.com/andreasstieger/gpgme/compare/license.patch Andreas -- Andreas Stieger Project Manager Security SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG N?rnberg) From patrick at enigmail.net Mon Jun 29 20:33:17 2015 From: patrick at enigmail.net (Patrick Brunschwig) Date: Mon, 29 Jun 2015 20:33:17 +0200 Subject: Memory Hole discussion / OpenPGP e-mail header protection In-Reply-To: <20150628172001-31604-82866-mailpile@slinky> References: <559016F8.1070906@enigmail.net> <20150628172001-31604-82866-mailpile@slinky> Message-ID: <55918F6D.5030302@enigmail.net> On 28.06.15 19:31, Bjarni Runar Einarsson wrote: > Hello! > > Patrick Brunschwig wrote: >>> This allows for versioning and also binds the part to the message it >>> applies to, which was one of the questions raised in April. I suspect >>> we'll want to rename from "memoryhole" to something less cool but more >>> descriptive sooner rather than later; "pgp-mime-headers" comes to mind? >> >> The headers we protect are not PGP/MIME headers. I think something like >> "protected-headers" or "secure-headers" would be better. > > I'm assuming this will be an extension to whatever RFCs discuss > PGP/MIME, which is why I used those words. In fact, if/when there is an > RFC for this, I'd vote for calling them rfc9999-headers. :-) That's the worst of all options. RFCs are changed over time leading to new RFC numbers. Eg. RFC 2015 has been superseeded by RFC 3156. > Patrick wrote on another thread: >> We should agree on certain specifics like how to display non-ASCII >> characters in the memory hole headers. I would vote against using RFC >> 2047, section 2 (e.g. =?UTF-8?blah?=), such that users can read the >> headers easily if their mailers would not yet understand memory hole. > > I think I disagree. Although I applaud the sentiment (it's awesome that > we're considering usability here), my gut feeling is the headers should > be exactly like they are in the public header section. This will make > both the spec and the code to implement it much simpler, lowering the > bar to getting everyone to adopt this. > > Showing the headers to the user at all is a backwards-compatibility hack > which should only be necessary for a relatively brief window in time, as > all the PGP plugins and mailers implement the new standard. Considering > how many folks we had in the room in April, I don't think I'm being > overly optimistic... :-) True, but my point here is that it's not guaranteed that all clients will send charset="us-ascii". Therefore you will anyway need to apply the charset decoding _before_ you can apply the mail header decoding. That is, the mail header decoding is in any case an additional step. -Patrick From wk at gnupg.org Mon Jun 29 21:38:01 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 29 Jun 2015 21:38:01 +0200 Subject: Cygwin support for --enable-ssh-agent Message-ID: <87egkumhk6.fsf@vigenere.g10code.de> Hi, I hacked some support for Cygwin sockets to Libassuan. I have not tested it at all so it is unlikely that it will work without tweaks. For you fearless windows hackers I attach the patch. The current GnuPG master is prepared for it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Support-Cygwin-local-sockets.patch Type: text/x-diff Size: 20115 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Jun 30 06:13:47 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 30 Jun 2015 00:13:47 -0400 Subject: Memory Hole discussion / OpenPGP e-mail header protection In-Reply-To: <20150628172001-31604-82866-mailpile@slinky> References: <559016F8.1070906@enigmail.net> <20150628172001-31604-82866-mailpile@slinky> Message-ID: <87y4j1ygsk.fsf@alice.fifthhorseman.net> Many thanks to Bjarni and Patrick and everyone else who is moving this work forward! On Sun 2015-06-28 13:31:10 -0400, Bjarni Runar Einarsson wrote: > Patrick Brunschwig wrote: >> > This allows for versioning and also binds the part to the message it >> > applies to, which was one of the questions raised in April. I suspect >> > we'll want to rename from "memoryhole" to something less cool but more >> > descriptive sooner rather than later; "pgp-mime-headers" comes to mind? >> >> The headers we protect are not PGP/MIME headers. I think something like >> "protected-headers" or "secure-headers" would be better. > > I'm assuming this will be an extension to whatever RFCs discuss > PGP/MIME, which is why I used those words. In fact, if/when there is an > RFC for this, I'd vote for calling them rfc9999-headers. :-) technically, these are rfc822 headers, even though rfc 822 has been superceded by rfc 2822 and 5322. I think Patrick's suggestion of protected-headers is a good one. I'm not certain about inclusion of a message-id here, because the outer (wrapping) message headers are not themselves protected. In general, depending on non-signed context to interpret the meaning of signed elements is trouble. I suppose it's possible that the ability to edit the outer header isn't in any way exploitable, but if we believe that we should have a clear, well-documented outline explaining why this is the case. Do you think it's impossible to infer the correct header from the placement within the MIME structure? > Patrick wrote on another thread: >> We should agree on certain specifics like how to display non-ASCII >> characters in the memory hole headers. I would vote against using RFC >> 2047, section 2 (e.g. =?UTF-8?blah?=), such that users can read the >> headers easily if their mailers would not yet understand memory hole. > > I think I disagree. Although I applaud the sentiment (it's awesome that > we're considering usability here), my gut feeling is the headers should > be exactly like they are in the public header section. This will make > both the spec and the code to implement it much simpler, lowering the > bar to getting everyone to adopt this. I agree with Bjarni here -- i don't want any different parsers to have to apply to this stuff, and demanding that senders re-encode these embedded headers seems like trouble to me. fwiw, i think thunderbird already displays the headers correctly if they're packed with RFC 2047 encodings. > Ideally once things are properly integrated, the visible duplicate > header section simply disappears and friendly green locks or checkmarks > appear in the MUA header display instead. yes, i think that's the right endgame. > If users get annoyed by ugly extra header sections, maybe that will > encourage them to upgrade their tools. heh. not sure how convinced i am that this will happen at the timescale you want, but maybe we can push it :) --dkg From gniibe at fsij.org Tue Jun 30 10:04:42 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 30 Jun 2015 17:04:42 +0900 Subject: [PATCH] scd: Support AES decryption for OpenPGPcard v3.0. In-Reply-To: <558D45A8.7000805@fsij.org> References: <558CEFF1.3060005@fsij.org> <87zj3mq0jr.fsf@vigenere.g10code.de> <558D45A8.7000805@fsij.org> Message-ID: <55924D9A.3030000@fsij.org> On 06/26/2015 09:29 PM, NIIBE Yutaka wrote: > The change is adding data object handling for the operation of > PSO:DECIPHER with symmetric key. This feature is added in v2.1. > > With the change of today, a user (or manufacturer) can put AES key > onto the data object of 0xD5. Here is concrete example (I've tested with Gnuk modified). ==================================== $ gpg-connect-agent > /hex > scd setattr aeskey %f3%2e%34%fe%dc%ab%df%e3%47%ac%b3%4b%a5%10%d8%c6 OK > scd setdata 025D6C89682D07CCFC034AF508420BF227 OK > scd pkdecrypt OPENPGP.2 S PADDING 0 D[0000] E3 46 4A 4F FE C3 B0 67 EB DB 04 35 3E 88 98 49 .FJO...g...5>..I OK > scd setdata 026842488E4ECB02C7DEA372E78B320D16 OK > scd pkdecrypt OPENPGP.2 S PADDING 0 D[0000] CE 1C A0 39 6A 14 C2 C2 80 BC F2 80 F2 3B 67 A5 ...9j........;g. OK > scd setdata 026A5751041E3A319A4D8213F46B36A7D3 OK > scd pkdecrypt OPENPGP.2 S PADDING 0 D[0000] 20 33 EE D7 3F 62 F6 56 87 5A 3A 44 F1 90 1A A0 3..?b.V.Z:D.... OK > /bye ==================================== Note that setting aeskey data object requires admin privilege. In the current implementation of scdaemon, this feature can be only used when a user registered a private key for encryption (== the key OPENPGP.2 is valid). Here is a patch for GnuPG development version. For myself, I don't know if this feature is useful, but it seems that there are some demand... diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 467389d..f5911f3 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -4101,7 +4101,10 @@ do_decipher (app_t app, const char *keyidstr, if (rc) return rc; - if (app->app_local->keyattr[1].key_type == KEY_TYPE_RSA) + if (indatalen == 16 + 1 || indatalen == 32 + 1) + /* PSO:DECIPHER with symmetric key. */ + padind = -1; + else if (app->app_local->keyattr[1].key_type == KEY_TYPE_RSA) { /* We might encounter a couple of leading zeroes in the cryptogram. Due to internal use of MPIs these leading zeroes -- From bre at pagekite.net Tue Jun 30 10:10:04 2015 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Tue, 30 Jun 2015 08:10:04 -0000 Subject: Memory Hole discussion / OpenPGP e-mail header protection In-Reply-To: <87y4j1ygsk.fsf@alice.fifthhorseman.net> References: <87y4j1ygsk.fsf@alice.fifthhorseman.net> Message-ID: <20150630073023-3349-16897-mailpile@slinky> Good morning! Daniel Kahn Gillmor wrote: > > I'm assuming this will be an extension to whatever RFCs discuss > > PGP/MIME, which is why I used those words. In fact, if/when there is an > > RFC for this, I'd vote for calling them rfc9999-headers. :-) > > technically, these are rfc822 headers, even though rfc 822 has been > superceded by rfc 2822 and 5322. I think Patrick's suggestion of > protected-headers is a good one. True. It did occur to me that naming the header after an RFC actually accomplishes the versioning that was requested, but that's probably bordering on "too clever". I agree that protected-headers is fine. > I'm not certain about inclusion of a message-id here, because the outer > (wrapping) message headers are not themselves protected. In general, > depending on non-signed context to interpret the meaning of signed > elements is trouble. I suppose it's possible that the ability to edit > the outer header isn't in any way exploitable, but if we believe that we > should have a clear, well-documented outline explaining why this is the > case. This is an important point. However, I think my scheme makes such tampering easy to detect. Consider that the proposed protected-headers attribute is not user configurable; this attribute is not created if you attach a message/rfc822-headers part by hand, and is not generated by the bounces or delivery reports the MIME type is commonly used for. However, the protected-headers attribute *is* protected by the PGP encryption envelope or signature and is thus tamper resistant. That means that IF it is present, then it MUST be contained within a RFC2822 part with a matching message-ID. If that constraint is violated, then the message has been tampered with. Because message-IDs are important for so many things, threading etc., they are generally NOT routinely modified by MTAs or mailing lists. So the rate of false posities should be quite low. We were never going to be able to prevent tampering, the best we can do is detect it. This scheme accomplishes that. Does that hold water? > Do you think it's impossible to infer the correct header from the > placement within the MIME structure? It is possible, but it becomes very awkward to work with. Since MIME is effectively designed as a stream protocol (you can generate an infinite stream of data which is also infinitely nested, and is still valid MIME), it's just not designed to make inferring position (or relative position) easy to do. If you try to infer position you have two choices: 1. Parse the entire message into an intermediate data structure and then evaluate that. 2. Write code which evaluates a stream on the fly. Option 1 perpetuates the performance nightmares of PGP/MIME: you can't do anything useful with a message without parsing the whole thing. I'd like to avoid encoding this bad behavior into the spec. Option 2 is only marginally more performant than option 1, in that you can stop parsing when you've found what you need - but you still need to start at the beginning and parse everything from there, updating counters as you go and hoping that your MIME library traverses the message tree in a stable and predictable way. > I agree with Bjarni here -- i don't want any different parsers to have > to apply to this stuff, and demanding that senders re-encode these > embedded headers seems like trouble to me. > > fwiw, i think thunderbird already displays the headers correctly if > they're packed with RFC 2047 encodings. Yes, but Patrick is correct that the verifiation parser will need to correctly decode before comparing with the public header section. The simple case is simple: encodings on the public header and the protected one should simply be the same by default. If they're different, then the message has been tampered with. Unfortunately, such tampering is common. If I send 8bit headers (not an uncommon thing to do in Iceland a few years ago), some MTAs might helpfully re-encode the header section. A good implementation of Memory Hole will avoid raising a false positive here, but I'm not sure how much work is involved. As always, signtures are the difficult bit and some implementations might choose to not perform header validation at all just because it's hard to get it right. Encryption is easy: protected-headers in an encrypted part can just be trusted blindly and overwrite whatever was in the public section. Is there any need to warn the user about tampering (considering the high expected rate of false positives), if we're able to recover from it gracefully? Cheers, - Bjarni -- Sent using Mailpile, Free Software from www.mailpile.is -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP Digital Signature URL: From wk at gnupg.org Tue Jun 30 11:59:26 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Jun 2015 11:59:26 +0200 Subject: 2.1.6 planned for tomorrow Message-ID: <87r3otldoh.fsf@vigenere.g10code.de> Hi, due to the summer holidays I won't be able to release around the 10th. I will instead do 2.1.6 earlier; probably tomorrow. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jun 30 12:39:03 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Jun 2015 12:39:03 +0200 Subject: [PATCH] scd: Support AES decryption for OpenPGPcard v3.0. In-Reply-To: <55924D9A.3030000@fsij.org> (NIIBE Yutaka's message of "Tue, 30 Jun 2015 17:04:42 +0900") References: <558CEFF1.3060005@fsij.org> <87zj3mq0jr.fsf@vigenere.g10code.de> <558D45A8.7000805@fsij.org> <55924D9A.3030000@fsij.org> Message-ID: <87lhf1lbug.fsf@vigenere.g10code.de> On Tue, 30 Jun 2015 10:04, gniibe at fsij.org said: >> scd setattr aeskey %f3%2e%34%fe%dc%ab%df%e3%47%ac%b3%4b%a5%10%d8%c6 > OK >> scd setdata 025D6C89682D07CCFC034AF508420BF227 > OK Isn't it a bit surprising that the key is given in raw form (obviously precent escape) while the data is given hex encoded? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jun 30 13:07:53 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Jun 2015 13:07:53 +0200 Subject: Memory Hole discussion / OpenPGP e-mail header protection In-Reply-To: <87a8vps0de.fsf@vigenere.g10code.de> (Werner Koch's message of "Wed, 24 Jun 2015 15:26:53 +0200") References: <20150619135603-5988-65181-mailpile@slinky> <87a8vps0de.fsf@vigenere.g10code.de> Message-ID: <87egktlaie.fsf@vigenere.g10code.de> On Wed, 24 Jun 2015 15:26, wk at gnupg.org said: > whatever you guys use these days) on the client there will be a need for > unattended decryption. This raises the same security concerns as those > with Enigmail's auto decryption. What about using a second subkey to encrypt the header and the "abstract" (top part) of the message? The bulk of the message would then be a different sub-part and encrypted using the standard key. The advantage is that you can auto-decrypt the headers and the "abstract" while keeping the bulk encryption key on a secure medium (ie. a slow smartcard). Right, that would require a more complicated message structure but it can also help to solve the mobile IMAP case: If the bulk is not a sub-part but a separate second part, you would be able to download the first part with the headers and the abstract of the message and display that. Thus there is no need to download a large encrypted message. |--- multipart/mixed |--- multipart/encrypted | |--- application/pgp-encrypted | |--- application/octet-stream [1] [subkey-1] | (decrypts to) | | | |--- multipart/mixed [2] | |--- text/rfc822-headers inline [correct header] | |--- text/plain [abstract] |--- multipart/encrypted |--- application/pgp-encrypted |--- application/octet-stream [subkey-2] (decrypts to) | |---- text/plain [bulk message] [3] text/plain is only an example for any other MIME type. [3] should have a dedicated header with the hash of [1] (or for robustness of [2]) to bind the two parts. It depends on the MUAs on whether they can handle this. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Tue Jun 30 14:33:13 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 30 Jun 2015 21:33:13 +0900 Subject: [PATCH] scd: Support AES decryption for OpenPGPcard v3.0. In-Reply-To: <87lhf1lbug.fsf@vigenere.g10code.de> References: <558CEFF1.3060005@fsij.org> <87zj3mq0jr.fsf@vigenere.g10code.de> <558D45A8.7000805@fsij.org> <55924D9A.3030000@fsij.org> <87lhf1lbug.fsf@vigenere.g10code.de> Message-ID: <55928C89.3000906@fsij.org> On 06/30/2015 07:39 PM, Werner Koch wrote: > On Tue, 30 Jun 2015 10:04, gniibe at fsij.org said: > >>> scd setattr aeskey %f3%2e%34%fe%dc%ab%df%e3%47%ac%b3%4b%a5%10%d8%c6 >> OK >>> scd setdata 025D6C89682D07CCFC034AF508420BF227 >> OK > > Isn't it a bit surprising that the key is given in raw form (obviously > precent escape) while the data is given hex encoded? I don't intend to ask users to do that. I showed it so that I can demonstrate: how the feature is accessible with a patch now. The reason why one is %-escaped and another is not is: while SETDATA command takes a hexstring as an argument, SETATTR command takes simple string. I'm not sure if people use the feature with GnuPG, and I have no idea how it will be by gpg frontend (if people want to use it). I understand the feature would be useful for some cases, but, I've not yet decided if I will incorporate the feature in Gnuk. For me, shared secret is difficult to manage. -- From wk at gnupg.org Tue Jun 30 16:29:01 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Jun 2015 16:29:01 +0200 Subject: Cygwin support for --enable-ssh-agent In-Reply-To: <87egkumhk6.fsf@vigenere.g10code.de> (Werner Koch's message of "Mon, 29 Jun 2015 21:38:01 +0200") References: <87egkumhk6.fsf@vigenere.g10code.de> Message-ID: <87h9ppjmmq.fsf@vigenere.g10code.de> Hi, I splitted the patch into a generic part and the actual Cygwin socket code. The generic part has been pushed and the new Cygwin patch is attached. Also not tested. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Support-Cygwin-local-sockets.patch Type: text/x-diff Size: 15261 bytes Desc: not available URL: From bre at pagekite.net Tue Jun 30 16:41:45 2015 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Tue, 30 Jun 2015 14:41:45 -0000 Subject: MIME structure of encrypted mail and subkeys (was: Memory Hole discussion...) In-Reply-To: <87egktlaie.fsf@vigenere.g10code.de> References: <87egktlaie.fsf@vigenere.g10code.de> Message-ID: <20150630140526-3349-17291-mailpile@slinky> Hi Werner! I like your proposal - moving towards a world where encrypted or signed messages can be broken up into smaller units is desirable for many reasons. The subkey idea is an interesting twist on that, since it allows different security levels for different parts of the message. It feels a bit complicated, but it has potential. Very interesting! Of course, as discussed in April, as soon as the message is broken up into multiple parts like this, we start to want a summary of some sort (a manifest), so you know whether you have the entire message or only part of it. Whether it's 2 parts or 20 parts doesn't matter much, the problems and solutions are the same: we need a manifest. This manifest doesn't need to be complicated. It could be something as simple as a few X-headers in the Memory Hole part, each header describing an expected MIME part (things like mime-type, filename, sha256 sum and content-ID for linking). - Bjarni Werner Koch wrote: > On Wed, 24 Jun 2015 15:26, wk at gnupg.org said: > > > whatever you guys use these days) on the client there will be a need for > > unattended decryption. This raises the same security concerns as those > > with Enigmail's auto decryption. > > What about using a second subkey to encrypt the header and the > "abstract" (top part) of the message? The bulk of the message would > then be a different sub-part and encrypted using the standard key. The > advantage is that you can auto-decrypt the headers and the "abstract" > while keeping the bulk encryption key on a secure medium (ie. a slow > smartcard). > > Right, that would require a more complicated message structure but it > can also help to solve the mobile IMAP case: If the bulk is not a > sub-part but a separate second part, you would be able to download the > first part with the headers and the abstract of the message and display > that. Thus there is no need to download a large encrypted message. > > |--- multipart/mixed > |--- multipart/encrypted > | |--- application/pgp-encrypted > | |--- application/octet-stream [1] [subkey-1] > | (decrypts to) > | | > | |--- multipart/mixed [2] > | |--- text/rfc822-headers inline [correct header] > | |--- text/plain [abstract] > |--- multipart/encrypted > |--- application/pgp-encrypted > |--- application/octet-stream [subkey-2] > (decrypts to) > | > |---- text/plain [bulk message] [3] > > text/plain is only an example for any other MIME type. [3] should have > a dedicated header with the hash of [1] (or for robustness of [2]) to > bind the two parts. It depends on the MUAs on whether they can handle > this. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- Sent using Mailpile, Free Software from www.mailpile.is -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP Digital Signature URL: From wk at gnupg.org Tue Jun 30 17:38:29 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Jun 2015 17:38:29 +0200 Subject: MIME structure of encrypted mail and subkeys In-Reply-To: <20150630140526-3349-17291-mailpile@slinky> (Bjarni Runar Einarsson's message of "Tue, 30 Jun 2015 14:41:45 -0000") References: <87egktlaie.fsf@vigenere.g10code.de> <20150630140526-3349-17291-mailpile@slinky> Message-ID: <871tgtjjey.fsf@vigenere.g10code.de> On Tue, 30 Jun 2015 16:41, bre at pagekite.net said: > The subkey idea is an interesting twist on that, since it allows > different security levels for different parts of the message. It feels a > bit complicated, but it has potential. Very interesting! Some media agin picked up the radioexp thing (CVE-2014-3591) from February and for that a major enabler is the auto-decrypt feature of some MUAs. This is why I conclude to better have a meta-data only key compromised than the real content. > Of course, as discussed in April, as soon as the message is broken up > into multiple parts like this, we start to want a summary of some sort > (a manifest), so you know whether you have the entire message or only I did not attend the entire session so I am missing some details. > This manifest doesn't need to be complicated. It could be something as > simple as a few X-headers in the Memory Hole part, each header > describing an expected MIME part (things like mime-type, filename, This would inhibit one-pass processing. What about a boolean flag manifest-in-next-part and have the Manifest in that next part? With such a chain of Manifests you can read the message MIME part by part and verify up to the part you have read: Last-part: HASH, more=yes|no This requires only limited amount of look-ahead while composing a message. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Tue Jun 30 18:41:29 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 30 Jun 2015 12:41:29 -0400 Subject: [PATCH] pass DBUS_SESSION_BUS_ADDRESS for gnome3 Message-ID: <1435682489-25111-1-git-send-email-dkg@fifthhorseman.net> * common/session-env.c add DBUS_SESSION_BUS_ADDRESS to stdenvnames. pinentry-gnome3 talks to the gcr prompter via dbus. Without this environment variable, it can't find the correct session to talk to. --- common/session-env.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/common/session-env.c b/common/session-env.c index c0500ea..171bf8f 100644 --- a/common/session-env.c +++ b/common/session-env.c @@ -72,6 +72,8 @@ static struct modules (eg "@im=SCIM"). */ { "GTK_IM_MODULE" }, /* Used by gtk to select gtk input modules (eg "scim-bridge"). */ + { "DBUS_SESSION_BUS_ADDRESS" },/* Used by GNOME3 to talk to gcr over + dbus */ { "QT_IM_MODULE" }, /* Used by Qt to select qt input modules (eg "xim"). */ { "INSIDE_EMACS" }, /* Set by Emacs before running a -- 2.1.4 From bre at pagekite.net Tue Jun 30 18:50:49 2015 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Tue, 30 Jun 2015 16:50:49 -0000 Subject: MIME structure of encrypted mail and subkeys In-Reply-To: <871tgtjjey.fsf@vigenere.g10code.de> References: <871tgtjjey.fsf@vigenere.g10code.de> Message-ID: <20150630162259-3349-10506-mailpile@slinky> Werner Koch wrote: > > This manifest doesn't need to be complicated. It could be something as > > simple as a few X-headers in the Memory Hole part, each header > > describing an expected MIME part (things like mime-type, filename, > > This would inhibit one-pass processing. Is this a real concern or a theoretical one? Do any production libraries actually support one-pass PGP/MIME in practice? The APIs I have worked with certainly didn't - they all buffered things up into objects. I know it can be done (I've done similar things with MIME), but it requires your MIME parser/generator be written in a very specific way which is much more complicated than most developers want to deal with. Most devs these days are used to dealing with objects, not streams. As soon as you're buffering everything anyway, making one-pass processing a design constraint buys you nothing but complexity. > What about a boolean flag manifest-in-next-part and have the Manifest in > that next part? With such a chain of Manifests you can read the message > MIME part by part and verify up to the part you have read: > > Last-part: HASH, more=yes|no What if my mobile phone e-mail reader just wants to pull a part out of the middle? Or just display a list of parts without downloading them? I think this strategy becomes functionally equivalent to just putting everything in one big PGP/MIME blob as before. See below for a different approach. > This requires only limited amount of look-ahead while composing a > message. I don't think this is actually a real constraint in the real world anymore. These days we measure RAM in GBs and storage in TBs, while e-mail SMTP servers still commonly reject e-mail over 20MB in size. Message size just isn't a computational constraint the way it used to be. But, even if it were, then you could just put your manifest at the end, possibly with a hint in the header saying you planned to do (this is not a security-critical feature, so an in-the-clear header is fine). Cheers! - Bjarni -- Sent using Mailpile, Free Software from www.mailpile.is -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP Digital Signature URL: From wk at gnupg.org Tue Jun 30 22:41:33 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Jun 2015 22:41:33 +0200 Subject: [PATCH] pass DBUS_SESSION_BUS_ADDRESS for gnome3 In-Reply-To: <1435682489-25111-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 30 Jun 2015 12:41:29 -0400") References: <1435682489-25111-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87r3othqte.fsf@vigenere.g10code.de> On Tue, 30 Jun 2015 18:41, dkg at fifthhorseman.net said: > * common/session-env.c add DBUS_SESSION_BUS_ADDRESS to stdenvnames. Pushed. Thanks. I'll finish the getext thing tomorrow. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From eric at debian.org Tue Jun 30 22:17:59 2015 From: eric at debian.org (Eric Dorland) Date: Tue, 30 Jun 2015 16:17:59 -0400 Subject: [PATCH] Include defs.inc in BUILT_SOURCES Message-ID: <1435695479-18104-1-git-send-email-eric@debian.org> * doc/Makefile.am: Building the info files can fail on a clean source tree since the .texi files include defs.inc. Use BUILT_SOURCES to force it to be built early. -- Signed-off-by: Eric Dorland --- doc/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/Makefile.am b/doc/Makefile.am index ee8bca2..3ea19ad 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -41,7 +41,7 @@ EXTRA_DIST = samplekeys.asc mksamplekeys \ gpgv.texi yat2m.c ChangeLog-2011 whats-new-in-2.1.txt BUILT_SOURCES = gnupg-card-architecture.eps gnupg-card-architecture.png \ - gnupg-card-architecture.pdf defsincdate + gnupg-card-architecture.pdf defsincdate defs.inc info_TEXINFOS = gnupg.texi -- 2.1.4 From eric at debian.org Tue Jun 30 22:17:59 2015 From: eric at debian.org (Eric Dorland) Date: Tue, 30 Jun 2015 16:17:59 -0400 Subject: [PATCH] Include defs.inc in BUILT_SOURCES Message-ID: <1435695479-18104-1-git-send-email-eric@debian.org> * doc/Makefile.am: Building the info files can fail on a clean source tree since the .texi files include defs.inc. Use BUILT_SOURCES to force it to be built early. -- Signed-off-by: Eric Dorland --- doc/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/Makefile.am b/doc/Makefile.am index ee8bca2..3ea19ad 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -41,7 +41,7 @@ EXTRA_DIST = samplekeys.asc mksamplekeys \ gpgv.texi yat2m.c ChangeLog-2011 whats-new-in-2.1.txt BUILT_SOURCES = gnupg-card-architecture.eps gnupg-card-architecture.png \ - gnupg-card-architecture.pdf defsincdate + gnupg-card-architecture.pdf defsincdate defs.inc info_TEXINFOS = gnupg.texi -- 2.1.4