From wk at gnupg.org Wed Oct 4 17:46:34 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 04 Oct 2017 17:46:34 +0200 Subject: [GPGME PATCH] core: Restore get_max_fds optimization on Linux In-Reply-To: <87lgl9wkuo.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 20 Sep 2017 09:38:55 -0400") References: <20170916031644.gqkho4ow7kbrfdsf@riva.ucam.org> <20170916031719.6hqy5vruhbwrb7h6@riva.ucam.org> <877ewuzodd.fsf@fifthhorseman.net> <87y3p9j1zt.fsf@wheatstone.g10code.de> <87lgl9wkuo.fsf@fifthhorseman.net> Message-ID: <87tvzerk4l.fsf@wheatstone.g10code.de> On Wed, 20 Sep 2017 15:38, dkg at fifthhorseman.net said: > is there an explicit example of this race condition? debian stable is > currently shipping gpgme 1.8.0, and if there's a real risk here i might I can't find an example but, iirc, we found this while triaging another bug. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Oct 4 18:24:11 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 04 Oct 2017 18:24:11 +0200 Subject: [GPGME PATCH] core: Restore get_max_fds optimization on Linux In-Reply-To: <20170916031644.gqkho4ow7kbrfdsf@riva.ucam.org> (Colin Watson's message of "Sat, 16 Sep 2017 04:16:45 +0100") References: <20170916031644.gqkho4ow7kbrfdsf@riva.ucam.org> Message-ID: <87poa2ridw.fsf@wheatstone.g10code.de> On Sat, 16 Sep 2017 05:16, cjwatson at debian.org said: > * src/posix-io.c (get_max_fds): Restore Linux optimization, this time > using open/getdents/close rather than opendir/readdir/closedir. I pushed your patch along with a second one to add a configure option --disable-linux-getdents so that it is possible to disable this feature on platforms where we run into problems. Salam-Shalom, 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: 227 bytes Desc: not available URL: From dgouttegattat at incenp.org Sun Oct 8 18:30:52 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 8 Oct 2017 17:30:52 +0100 Subject: [PATCH] dirmngr: Do not follow https-to-http redirects. Message-ID: <20171008163052.21323-1-dgouttegattat@incenp.org> * dirmngr/ks-engine-http.c (ks_http_fetch): Forbid redirects from a https URI to a http URI. -- GnuPG-bug-id: 3436 Signed-off-by: Damien Goutte-Gattat --- dirmngr/ks-engine-http.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/dirmngr/ks-engine-http.c b/dirmngr/ks-engine-http.c index 7fb77312d..6492dda8a 100644 --- a/dirmngr/ks-engine-http.c +++ b/dirmngr/ks-engine-http.c @@ -73,12 +73,13 @@ ks_http_fetch (ctrl_t ctrl, const char *url, estream_t *r_fp) estream_t fp = NULL; char *request_buffer = NULL; parsed_uri_t uri = NULL; - int is_onion; + int is_onion, is_https; err = http_parse_uri (&uri, url, 0); if (err) goto leave; is_onion = uri->onion; + is_https = uri->use_tls; once_more: /* Note that we only use the system provided certificates with the @@ -152,17 +153,18 @@ ks_http_fetch (ctrl_t ctrl, const char *url, estream_t *r_fp) url, s?s:"[none]", http_get_status_code (http)); if (s && *s && redirects_left-- ) { - if (is_onion) + if (is_onion || is_https) { /* Make sure that an onion address only redirects to - * another onion address. */ + * another onion address, or that a https address + * only redirects to a https address. */ http_release_parsed_uri (uri); uri = NULL; err = http_parse_uri (&uri, s, 0); if (err) goto leave; - if (! uri->onion) + if ((is_onion && ! uri->onion) || (is_https && ! uri->use_tls)) { err = gpg_error (GPG_ERR_FORBIDDEN); goto leave; -- 2.14.1 From ionic at ionic.de Mon Oct 9 03:56:32 2017 From: ionic at ionic.de (Mihai Moldovan) Date: Mon, 9 Oct 2017 03:56:32 +0200 Subject: installing gnupg 2.2 as "gpg", vs coexistence with gpg 1.4 In-Reply-To: <878tgwotmy.fsf@fifthhorseman.net> References: <871smqqggd.fsf@fifthhorseman.net> <874lrl28ea.fsf@wheatstone.g10code.de> <878tgwotmy.fsf@fifthhorseman.net> Message-ID: <6daa0197-e668-226d-422b-1a86e9df510f@ionic.de> On 09/30/2017 09:48 PM, Daniel Kahn Gillmor wrote: > I agree that decryption (asymmetric and symmetric) of legacy encrypted > messages is the only interesting use case left for gpg1 in the long > term. To be clear, means that the following use cases aren't things > anyone should be doing with gpg 1.4: > > * keyserver or LDAP access > * signature verification > * signing data > * certifying keys > * Web-of-trust identity validation > * asymmetric encryption > * symmetric encryption > > maybe a deprecate 1.4 could start producing warnings when invoked for > those operations, if we want to encourage people to move off of it. Have you considered that 1.4 is widely used on constraint systems that want to avoid dependencies like the plague for automated tasks that don't require agent support? Signature verification would be one of such use cases. I'm not advocating this, just mentioning that this scheme seems to be widely deployed. In my opinion: 1.4 and 2.x coexistence would be nice to have and should be made the default - breaking the previous behavior explicitly. Installing everything with a postfix of "1" without making general (e.g., gpg -> gpg1) symlinks sounds like a good idea. This way, 1.4 can be installed and used if really needed (see Werners experience), but won't be accidentally used by users and tools that try to execute gpg. Distributions should not install 1.4 by default or even as a dependency of other packages, if can be avoided. Mihai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 898 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Oct 9 12:38:33 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 09 Oct 2017 12:38:33 +0200 Subject: installing gnupg 2.2 as "gpg", vs coexistence with gpg 1.4 In-Reply-To: <878tgwotmy.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Sat, 30 Sep 2017 15:48:05 -0400") References: <871smqqggd.fsf@fifthhorseman.net> <874lrl28ea.fsf@wheatstone.g10code.de> <878tgwotmy.fsf@fifthhorseman.net> Message-ID: <874lr8ppw6.fsf@wheatstone.g10code.de> On Sat, 30 Sep 2017 21:48, dkg at fifthhorseman.net said: > term. To be clear, means that the following use cases aren't things > anyone should be doing with gpg 1.4: > > * keyserver or LDAP access Ack > * signature verification I disagree; this still makes sense on some platforms. > * signing data > * certifying keys > * Web-of-trust identity validation Ack > * asymmetric encryption > * symmetric encryption As long as we have no new encryption format and RSA keys are okay for the recipient I can see use cases where this is still required. Of course that does not mean PGP-2 keys shall be used. > maybe a deprecate 1.4 could start producing warnings when invoked for > those operations, if we want to encourage people to move off of it. Agreed for signature creation and keyserver access. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Mon Oct 9 12:46:35 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 09 Oct 2017 12:46:35 +0200 Subject: card_status - change-request to update allways In-Reply-To: <8A0A4BE0-EAB1-48BF-91D4-EF52DE90AB17@gmail.com> (myonium@gmail.com's message of "Thu, 21 Sep 2017 19:18:35 +0200") References: <87zidmc1wq.fsf@fsij.org> <92939132-CE14-4B41-95F4-12478AD85E74@gmail.com> <87h8vy9c1h.fsf@iwagami.gniibe.org> <87shfgcr4z.fsf@fsij.org> <877ewsgrzs.fsf@wheatstone.g10code.de> <8A0A4BE0-EAB1-48BF-91D4-EF52DE90AB17@gmail.com> Message-ID: <87vajooayc.fsf@wheatstone.g10code.de> On Thu, 21 Sep 2017 19:18, myonium at gmail.com said: > Updating the stubs with ??card-status? would work for me. An automatic check on all connected cards would be cool ? but maybe slow ... Yes, that may delay other operations as well. In particular when scdaemon needs to test for several card applications. Did someone mentioned that you can update the serial number in the key stub using gpg-connect-agent 'learn --force' /bye ? Salam-Shalom, 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: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Mon Oct 9 17:34:27 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 09 Oct 2017 11:34:27 -0400 Subject: [PATCH] default-preference-list: prefer SHA512. In-Reply-To: <20170928123226.28189-1-dkg@fifthhorseman.net> References: <87wp50voca.fsf@fifthhorseman.net> <20170928123226.28189-1-dkg@fifthhorseman.net> Message-ID: <87y3okjpx8.fsf@fifthhorseman.net> On Thu 2017-09-28 08:32:26 -0400, Daniel Kahn Gillmor wrote: > * g10/keygen.c (keygen_set_std_prefs): when producing default internal > personal-digest-preferences, keep the same order. When publishing > external preferences, state preference for SHA512 first. Has anyone had time to review this patch? I'd like to get this merged if it's acceptable. If it's not acceptable, i'd like to understand the reasoning for it. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dkg at fifthhorseman.net Mon Oct 9 16:28:39 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 09 Oct 2017 10:28:39 -0400 Subject: installing gnupg 2.2 as "gpg", vs coexistence with gpg 1.4 In-Reply-To: <6daa0197-e668-226d-422b-1a86e9df510f@ionic.de> References: <871smqqggd.fsf@fifthhorseman.net> <874lrl28ea.fsf@wheatstone.g10code.de> <878tgwotmy.fsf@fifthhorseman.net> <6daa0197-e668-226d-422b-1a86e9df510f@ionic.de> Message-ID: <87d15wl7jc.fsf@fifthhorseman.net> On Mon 2017-10-09 03:56:32 +0200, Mihai Moldovan wrote: > Have you considered that 1.4 is widely used on constraint systems that > want to avoid dependencies like the plague for automated tasks that > don't require agent support? > > Signature verification would be one of such use cases. If the only thing you want to do is signature verification, you should be using gpgv, not the full GnuPG suite. coincidentally, gpgv requires no agent support. If you're using gpgv, you should use the modern (2.1.x/2.2.x) version of gpgv, since it is capable of verifying more signatures than the "classic" (1.4.x) version. for example, ECC and ed25519 signatures cannot be verified by "classic" gpgv. I like minimal systems as well, and help to maintain several such systems. But when i hear "avoid dependencies like the plague", i wonder what the specific purpose of that avoidance is. Is it about bytes on the storage medium? bytes in RAM? worries about software maintenance? concerns about complexity? Do those issues really outweigh more-active upstream support, and wider compatibility? RAM and storage today are cheap. and split-out dependencies (e.g. libgcrypt) actually should make updates and security maintenance easier. I'm not saying there are no cases where GnuPG's "classic" model could possibly be useful; but i'm saying that asking upstream to maintain two divergent branches indefinitely may not be the best use of the constrained amount of software engineering hours we have available. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From muelli at cryptobitch.de Mon Oct 9 18:43:50 2017 From: muelli at cryptobitch.de (Tobias Mueller) Date: Mon, 09 Oct 2017 18:43:50 +0200 Subject: [PATCH] python: Default whence argument for Data() to SEEK_SET. In-Reply-To: <1503416905.23294.52.camel@cryptobitch.de> References: <1503416905.23294.52.camel@cryptobitch.de> Message-ID: <1507567430.31190.7.camel@cryptobitch.de> Hi. I also wonder whether this patch has been reviewed and whether it is acceptable. Cheers, ? Tobi On Di, 2017-08-22 at 17:48 +0200, Tobias Mueller wrote: > * lang/python/gpgme.i: copied signature from gpgme.h and defaulted the > value to SEEK_SET. > * lang/python/tests/t-data.py: Added a test for no second argument > -- > > Having to import the os package when wanting to read a Data object is a > slight annoyance. With SWIG, we can define default parameters. This > change defaults the whence argument to SEEK_SET which is how StringIO > and BytesIO behave. > > Signed-off-by: Tobias Mueller > --- > lang/python/gpgme.i | 5 +++++ > lang/python/tests/t-data.py | 6 ++++++ > 2 files changed, 11 insertions(+) > > diff --git a/lang/python/gpgme.i b/lang/python/gpgme.i > index 58148b3..3fa2e0b 100644 > --- a/lang/python/gpgme.i > +++ b/lang/python/gpgme.i > @@ -557,6 +557,11 @@ gpgme_error_t gpgme_op_keylist_start (gpgme_ctx_t ctx, > const char *pattern="", > int secret_only=0); > > +/* The whence argument is surprising in Python-land, > + because BytesIO or StringIO objects do not require it. > + It defaults to SEEK_SET. Let's do that for Data objects, too */ > +off_t gpgme_data_seek (gpgme_data_t dh, off_t offset, int whence=SEEK_SET); > + > /* Include the unmodified for cc, and the cleaned-up local > version for SWIG. We do, however, want to hide certain fields on > some structs, which we provide prior to including the version for > diff --git a/lang/python/tests/t-data.py b/lang/python/tests/t-data.py > index 3301319..5cf074c 100755 > --- a/lang/python/tests/t-data.py > +++ b/lang/python/tests/t-data.py > @@ -51,6 +51,12 @@ data.write(b'Hello world!') > data.seek(0, os.SEEK_SET) > assert data.read() == b'Hello world!' > > +data = gpg.Data() > +data.write(b'Hello world!') > +# We expect the second argument to default to SEEK_SET > +data.seek(0) > +assert data.read() == b'Hello world!' > + > binjunk = bytes(range(256)) > data = gpg.Data() > data.write(binjunk) From wk at gnupg.org Mon Oct 9 19:19:20 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 09 Oct 2017 19:19:20 +0200 Subject: [PATCH] default-preference-list: prefer SHA512. In-Reply-To: <87y3okjpx8.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 09 Oct 2017 11:34:27 -0400") References: <87wp50voca.fsf@fifthhorseman.net> <20170928123226.28189-1-dkg@fifthhorseman.net> <87y3okjpx8.fsf@fifthhorseman.net> Message-ID: <87376snsrr.fsf@wheatstone.g10code.de> On Mon, 9 Oct 2017 17:34, dkg at fifthhorseman.net said: > Has anyone had time to review this patch? I'd like to get this merged Sorry I had not yet the time to review it. Please have some patience. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gdt at lexort.com Tue Oct 10 01:28:04 2017 From: gdt at lexort.com (Greg Troxel) Date: Mon, 09 Oct 2017 19:28:04 -0400 Subject: installing gnupg 2.2 as "gpg", vs coexistence with gpg 1.4 In-Reply-To: (Greg Troxel's message of "Thu, 28 Sep 2017 14:46:44 -0400") References: Message-ID: Thanks to everyone for the replies and discussion. From my packaging viewpoint, the ideal situation would be if there is a gnupg 1.4.x release which installs to gpg1 (and really, does not install any files which conflict with gnupg 2.2.x). Then I could upgrade that, flip off the gpg2 switch on 2.2.x, and make anything that depends on 1.4 change to 2.2, and then pick up the pieces from ununderstood consequences. Plan B would be just the rest of the steps, leading to people not being able to install 1.4.x. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From wk at gnupg.org Tue Oct 10 08:49:47 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 Oct 2017 08:49:47 +0200 Subject: installing gnupg 2.2 as "gpg", vs coexistence with gpg 1.4 In-Reply-To: <87d15wl7jc.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 09 Oct 2017 10:28:39 -0400") References: <871smqqggd.fsf@fifthhorseman.net> <874lrl28ea.fsf@wheatstone.g10code.de> <878tgwotmy.fsf@fifthhorseman.net> <6daa0197-e668-226d-422b-1a86e9df510f@ionic.de> <87d15wl7jc.fsf@fifthhorseman.net> Message-ID: <87lgkjmr90.fsf@wheatstone.g10code.de> On Mon, 9 Oct 2017 16:28, dkg at fifthhorseman.net said: > I'm not saying there are no cases where GnuPG's "classic" model could > possibly be useful; but i'm saying that asking upstream to maintain two > divergent branches indefinitely may not be the best use of the Right. However, I promised to keep on maintaining 1.4 so that it can be used on some uncommon platforms and also to decrypt old files. Let's track this as https://dev.gnupg.org/T3443 Salam-Shalom, 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: 227 bytes Desc: not available URL: From wk at gnupg.org Tue Oct 10 08:51:04 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 Oct 2017 08:51:04 +0200 Subject: [PATCH] python: Default whence argument for Data() to SEEK_SET. In-Reply-To: <1507567430.31190.7.camel@cryptobitch.de> (Tobias Mueller's message of "Mon, 09 Oct 2017 18:43:50 +0200") References: <1503416905.23294.52.camel@cryptobitch.de> <1507567430.31190.7.camel@cryptobitch.de> Message-ID: <87h8v7mr6v.fsf@wheatstone.g10code.de> On Mon, 9 Oct 2017 18:43, muelli at cryptobitch.de said: > I also wonder whether this patch has been reviewed and whether it is > acceptable. I don't known. Justus left g10 Code and thus we don't have a Python expert anymore. I need to get some more opinions before I can apply this. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From deloptes at gmail.com Tue Oct 10 21:42:09 2017 From: deloptes at gmail.com (deloptes) Date: Tue, 10 Oct 2017 21:42:09 +0200 Subject: pinentry-tqt for the trinity desktop (former KDE3/Qt3 code) Message-ID: Hi all, I once asked if it would be possible to add code for pinentry-tqt. TQt is for Trinity Qt3 which is part of the Trinity Desktop (TDE) project - the former KDE3. The Qt3 code was removed recently from gnupg, but the name remains the same. We now have the problem, that it does not work anymore as it should be. I ported the code to TQt and it looks like working great. It would be great if the pinentry-tqt code is part of the official code, so that we can easily rebuild. Damien already gave a positive sign for the integration. I would be thankful for any comments and follow ups. thanks and regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed Oct 11 08:34:20 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Oct 2017 08:34:20 +0200 Subject: pinentry-tqt for the trinity desktop (former KDE3/Qt3 code) In-Reply-To: (deloptes@gmail.com's message of "Tue, 10 Oct 2017 21:42:09 +0200") References: Message-ID: <87fuaqjiqb.fsf@wheatstone.g10code.de> On Tue, 10 Oct 2017 21:42, deloptes at gmail.com said: > It would be great if the pinentry-tqt code is part of the official code, so > that we can easily rebuild. We once had a problem with supporting several Qt versions in one build. It once somehow solved, though. To avoid possible problems, I would suggest to not build that tqt pinentry by default but require a --enable-pinentry-tqt and a --disable-pinentry-qt5 > Damien already gave a positive sign for the integration. Ack. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From deloptes at gmail.com Wed Oct 11 08:57:54 2017 From: deloptes at gmail.com (deloptes) Date: Wed, 11 Oct 2017 08:57:54 +0200 Subject: pinentry-tqt for the trinity desktop (former KDE3/Qt3 code) In-Reply-To: <87fuaqjiqb.fsf@wheatstone.g10code.de> References: <87fuaqjiqb.fsf@wheatstone.g10code.de> Message-ID: Hi Werner, thank you for the response. Indeed it is intended to be used as you highlighted above - build if explicitly enabled (assumes disabling qt5). TDE has own build system. We just want to build from original source, not patch it, and it would be of advantage to have it on your end. What are the next steps? I uploaded (hacked) version of pinentry-0.9.7 here https://bugs.trinitydesktop.org/show_bug.cgi?id=2830 One could get the tqt subdirectory out of it. Unfortunately I did not spent that much time fixing all the autotool stuff, but as I said I hacked it so that it could build the pinentry-tqt binary. Thank you and regards On Wed, Oct 11, 2017 at 8:34 AM, Werner Koch wrote: > On Tue, 10 Oct 2017 21:42, deloptes at gmail.com said: > > > It would be great if the pinentry-tqt code is part of the official code, > so > > that we can easily rebuild. > > We once had a problem with supporting several Qt versions in one build. > It once somehow solved, though. To avoid possible problems, I would > suggest to not build that tqt pinentry by default but require a > > --enable-pinentry-tqt > > and a > > --disable-pinentry-qt5 > > > Damien already gave a positive sign for the integration. > > Ack. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Wed Oct 11 17:38:39 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 11 Oct 2017 11:38:39 -0400 Subject: [GPGME PATCH] core: use getdents64 syscall on linux instead of getdents. In-Reply-To: <87poa2ridw.fsf@wheatstone.g10code.de> References: <87poa2ridw.fsf@wheatstone.g10code.de> Message-ID: <20171011153839.32662-1-dkg@fifthhorseman.net> * src/posix-io.c (get_max_fds): use getdents64 instead of getdents. -- getdents64 was introduced in linux 2.4, so it should be widely available. some Linux architectures which post-date 2.4 (e.g. arm64) appear to not have getdents at all, so it's probably better to use the more modern interface. Signed-off-by: Daniel Kahn Gillmor --- src/posix-io.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/src/posix-io.c b/src/posix-io.c index 9b7b181d..0448d296 100644 --- a/src/posix-io.c +++ b/src/posix-io.c @@ -282,13 +282,14 @@ _gpgme_io_set_nonblocking (int fd) #ifdef USE_LINUX_GETDENTS -/* This is not declared in public headers; getdents(2) says that we must +/* This is not declared in public headers; getdents64(2) says that we must * define it ourselves. */ -struct linux_dirent +struct linux_dirent64 { - unsigned long d_ino; - unsigned long d_off; + ino64_t d_ino; + off64_t d_off; unsigned short d_reclen; + unsigned char d_type; char d_name[]; }; @@ -316,7 +317,7 @@ get_max_fds (void) { int dir_fd; char dir_buf[DIR_BUF_SIZE]; - struct linux_dirent *dir_entry; + struct linux_dirent64 *dir_entry; int r, pos; const char *s; int x; @@ -326,7 +327,7 @@ get_max_fds (void) { for (;;) { - r = syscall(SYS_getdents, dir_fd, dir_buf, DIR_BUF_SIZE); + r = syscall(SYS_getdents64, dir_fd, dir_buf, DIR_BUF_SIZE); if (r == -1) { /* Fall back to other methods. */ @@ -338,7 +339,7 @@ get_max_fds (void) for (pos = 0; pos < r; pos += dir_entry->d_reclen) { - dir_entry = (struct linux_dirent *) (dir_buf + pos); + dir_entry = (struct linux_dirent64 *) (dir_buf + pos); s = dir_entry->d_name; if (*s < '0' || *s > '9') continue; -- 2.14.2 From wlt-ml at o-sinc.com Wed Oct 11 16:43:49 2017 From: wlt-ml at o-sinc.com (William L. Thomson Jr.) Date: Wed, 11 Oct 2017 10:43:49 -0400 Subject: pinentry-tqt for the trinity desktop (former KDE3/Qt3 code) In-Reply-To: References: <87fuaqjiqb.fsf@wheatstone.g10code.de> Message-ID: On Wed, 11 Oct 2017 08:57:54 +0200 deloptes wrote: > > What are the next steps? I did the recent pinentry-efl. https://dev.gnupg.org/T2905 The steps are as follows give or take 1. Open task on dev.gnupg.org and attach a patch of your contribution. This will need to include modifications to autotools/build system, complete patch. Which includes a NEWS entry. Example - https://dev.gnupg.org/D426 2. You need to send a copy of the DCO to this list for your contributions to be accepted. https://dev.gnupg.org/source/gnupg/browse/master/doc/DCO Then just follow up on the task addressing any issues till its accepted. Fairly simply process but may take a bit of time. > I uploaded (hacked) version of pinentry-0.9.7 here > https://bugs.trinitydesktop.org/show_bug.cgi?id=2830 > One could get the tqt subdirectory out of it. Unfortunately I did not > spent that much time fixing all the autotool stuff, but as I said I > hacked it so that it could build the pinentry-tqt binary. Ideally want to do the autotools stuff. That way a dev can apply patch and test directly. More you do, easier it is for others to test, and makes acceptance smoother and faster. -- William L. Thomson Jr. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From deloptes at gmail.com Wed Oct 11 19:46:53 2017 From: deloptes at gmail.com (deloptes) Date: Wed, 11 Oct 2017 19:46:53 +0200 Subject: pinentry-tqt for the trinity desktop (former KDE3/Qt3 code) In-Reply-To: References: <87fuaqjiqb.fsf@wheatstone.g10code.de> Message-ID: Thank you for the instructions and taking your time to answer. I wonder if Damien could help with the autotools stuff. It would ease the enormously process. regards On Wed, Oct 11, 2017 at 4:43 PM, William L. Thomson Jr. wrote: > On Wed, 11 Oct 2017 08:57:54 +0200 > deloptes wrote: > > > > What are the next steps? > > I did the recent pinentry-efl. https://dev.gnupg.org/T2905 > > The steps are as follows give or take > > 1. Open task on dev.gnupg.org and attach a patch of your > contribution. This will need to include modifications to > autotools/build system, complete patch. Which includes a NEWS entry. > Example - https://dev.gnupg.org/D426 > > 2. You need to send a copy of the DCO to this list for your > contributions to be accepted. > https://dev.gnupg.org/source/gnupg/browse/master/doc/DCO > > Then just follow up on the task addressing any issues till its > accepted. Fairly simply process but may take a bit of time. > > > I uploaded (hacked) version of pinentry-0.9.7 here > > https://bugs.trinitydesktop.org/show_bug.cgi?id=2830 > > One could get the tqt subdirectory out of it. Unfortunately I did not > > spent that much time fixing all the autotool stuff, but as I said I > > hacked it so that it could build the pinentry-tqt binary. > > Ideally want to do the autotools stuff. That way a dev can apply patch > and test directly. More you do, easier it is for others to test, and > makes acceptance smoother and faster. > > -- > William L. Thomson Jr. > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgouttegattat at incenp.org Wed Oct 11 22:40:35 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 11 Oct 2017 21:40:35 +0100 Subject: pinentry-tqt for the trinity desktop (former KDE3/Qt3 code) In-Reply-To: References: <87fuaqjiqb.fsf@wheatstone.g10code.de> Message-ID: <19879d8b-ca51-7981-f6a9-510d80cacef7@incenp.org> On 10/11/2017 06:46 PM, deloptes wrote: > I wonder if Damien could help with the autotools stuff. It would ease the > enormously process. On principle, I am willing to do that. However, when I tried to install tqt3 a few weeks ago (so that I can build your pinentry-tqt3), I could not make it to compile on my system. I was busy at the time, so I just gave up for the time being. I first need to fix that before I can start working on integrating your pinentry-tqt3 into the pinentry's build system. Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From deloptes at gmail.com Thu Oct 12 08:10:16 2017 From: deloptes at gmail.com (deloptes) Date: Thu, 12 Oct 2017 08:10:16 +0200 Subject: pinentry-tqt for the trinity desktop (former KDE3/Qt3 code) In-Reply-To: <19879d8b-ca51-7981-f6a9-510d80cacef7@incenp.org> References: <87fuaqjiqb.fsf@wheatstone.g10code.de> <19879d8b-ca51-7981-f6a9-510d80cacef7@incenp.org> Message-ID: Thank you in advance. I usually do this in a chrooted environment (debian + Preliminary_Stable_Builds ) Installation is a straight forward procedure. Let me know if I can do something else. Thank you in advance. Regards On Wed, Oct 11, 2017 at 10:40 PM, Damien Goutte-Gattat < dgouttegattat at incenp.org> wrote: > On 10/11/2017 06:46 PM, deloptes wrote: > >> I wonder if Damien could help with the autotools stuff. It would ease the >> enormously process. >> > > On principle, I am willing to do that. > > However, when I tried to install tqt3 a few weeks ago (so that I can build > your pinentry-tqt3), I could not make it to compile on my system. I was > busy at the time, so I just gave up for the time being. > > I first need to fix that before I can start working on integrating your > pinentry-tqt3 into the pinentry's build system. > > Damien > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ionic at ionic.de Thu Oct 12 08:11:23 2017 From: ionic at ionic.de (Mihai Moldovan) Date: Thu, 12 Oct 2017 08:11:23 +0200 Subject: installing gnupg 2.2 as "gpg", vs coexistence with gpg 1.4 In-Reply-To: <874lr8ppw6.fsf@wheatstone.g10code.de> References: <871smqqggd.fsf@fifthhorseman.net> <874lrl28ea.fsf@wheatstone.g10code.de> <878tgwotmy.fsf@fifthhorseman.net> <874lr8ppw6.fsf@wheatstone.g10code.de> Message-ID: On 10/09/2017 12:38 PM, Werner Koch wrote: > [...] > Agreed for signature creation and keyserver access. Agree here as well, but, personally, I would not remove these features. Not because these features are still useful or because they should be still maintained, but because removing stuff takes time, potentially breaks things and generally leads to more maintenance than just leaving it in. Again, personally, I'd just leave it as-is and make clear that if it doesn't work, it just won't work. Regarding general maintenance: don't make your life complicated. At most apply security fixes, nothing else. No bug fixes, no new features, rien. Keep the required maintenance work down. Mihai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 898 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Oct 12 09:01:44 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 12 Oct 2017 09:01:44 +0200 Subject: [GPGME PATCH] core: use getdents64 syscall on linux instead of getdents. In-Reply-To: <20171011153839.32662-1-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 11 Oct 2017 11:38:39 -0400") References: <87poa2ridw.fsf@wheatstone.g10code.de> <20171011153839.32662-1-dkg@fifthhorseman.net> Message-ID: <8760bkhmsn.fsf@wheatstone.g10code.de> On Wed, 11 Oct 2017 17:38, dkg at fifthhorseman.net said: > * src/posix-io.c (get_max_fds): use getdents64 instead of getdents. Thanks. Applied. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Oct 11 17:40:37 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 11 Oct 2017 11:40:37 -0400 Subject: [GPGME PATCH] core: Restore get_max_fds optimization on Linux In-Reply-To: <87poa2ridw.fsf@wheatstone.g10code.de> References: <20170916031644.gqkho4ow7kbrfdsf@riva.ucam.org> <87poa2ridw.fsf@wheatstone.g10code.de> Message-ID: <87k201g0ay.fsf@fifthhorseman.net> On Wed 2017-10-04 18:24:11 +0200, Werner Koch wrote: > On Sat, 16 Sep 2017 05:16, cjwatson at debian.org said: >> * src/posix-io.c (get_max_fds): Restore Linux optimization, this time >> using open/getdents/close rather than opendir/readdir/closedir. > > I pushed your patch along with a second one to add a configure option > > --disable-linux-getdents > > so that it is possible to disable this feature on platforms where we run > into problems. I have moved the debian package to using getdents64 instead of getdents, and it resolves the build problem on arm64 without introducing new failures on any of the debian platforms. I recommend taking this change upstream as well. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Oct 13 01:03:43 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 12 Oct 2017 19:03:43 -0400 Subject: pinentry's new window titles could be more (less?) informative In-Reply-To: <87zi9dzxoc.fsf@wheatstone.g10code.de> References: <87zi9fqe05.fsf@fifthhorseman.net> <87zi9dzxoc.fsf@wheatstone.g10code.de> Message-ID: <87mv4wrmsw.fsf@fifthhorseman.net> On Fri 2017-09-29 11:00:51 +0200, Werner Koch wrote: > On Thu, 28 Sep 2017 20:03, rjh at sixdemonbag.org said: > >> So my question is, yes, I see what the intent is here: to give users >> some assurance their PIN is being requested by the program they expect. > > Actually the reason I implemented this was to see the ssh invocation. I > have a few cron jobs connecting to other boxes running and thus it is > interesting to see which kicked the pinentry. I understand this desire, but i think the concerns raised in the rest of this thread still stand. Can we figure out some path forward that will make this more useful and less intimidating? I've just pushed a few minor cleanups to pinentry that shouldn't interfere with the ssh use case you describe, but don't do anything significant to fix the other problems mentioned here. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From matthew.summers at syapse.com Fri Oct 13 06:44:55 2017 From: matthew.summers at syapse.com (Matthew Summers) Date: Thu, 12 Oct 2017 23:44:55 -0500 Subject: Please Consider Increasing SECMEM_BUFFER_SIZE To 1048576 Message-ID: Hello, This is following up on an issue that started around in the 2.1.17 days, and I have been carrying a small patch addressing this for my team since we figured it out. This is all documented in an earlier set of threads to this ML. Would you consider increasing SECMEM_BUFFER_SIZE to 1048576 in the case where the configure option `large_secmem` = yes, please? The patch itself is a super trivial in both configure and/or configure.ac. Many thanks for your kind consideration! Cheers, Matt Summers quantumsummers -------------- next part -------------- An HTML attachment was scrubbed... URL: From astieger at suse.com Fri Oct 13 15:00:00 2017 From: astieger at suse.com (Andreas Stieger) Date: Fri, 13 Oct 2017 15:00:00 +0200 Subject: Please Consider Increasing SECMEM_BUFFER_SIZE To 1048576 In-Reply-To: References: Message-ID: <768f49c6-e0b9-c63a-8104-9d51cf28fd60@suse.com> Hello, On 10/13/2017 06:44 AM, Matthew Summers wrote: > This is following up on an issue that started around in the 2.1.17 > days, and I have been carrying a small patch addressing this for my > team since we figured it out. This is all documented in an earlier set > of threads to this ML. > > Would you consider increasing?SECMEM_BUFFER_SIZE to?1048576 in the > case where the configure option `large_secmem` = yes, please? > > The patch itself is a super trivial in both configure and/or > configure.ac . > You haven't explicitly referenced the rationale for this. Is this about RSA keys in excession of 4096 bits? I would like to point out that this creates an issue on systems with the max locked memory size (ulimit -l) is limited to 64k: gpg: Warning: using insecure memory! mlock(0x7f5814308000, 262144) = -1 ENOMEM (Cannot allocate memory) Thus exposing private key material to being swapped out to permanent storage. I am not sure if a mere warning is sufficient here. Andreas -- Andreas Stieger Project Manager Security SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri Oct 13 19:42:09 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 13 Oct 2017 13:42:09 -0400 Subject: Please Consider Increasing SECMEM_BUFFER_SIZE To 1048576 In-Reply-To: <768f49c6-e0b9-c63a-8104-9d51cf28fd60@suse.com> References: <768f49c6-e0b9-c63a-8104-9d51cf28fd60@suse.com> Message-ID: <871sm7rlla.fsf@fifthhorseman.net> On Fri 2017-10-13 15:00:00 +0200, Andreas Stieger wrote: > I would like to point out that this creates an issue on systems with the > max locked memory size (ulimit -l) is limited to 64k: > gpg: Warning: using insecure memory! > mlock(0x7f5814308000, 262144) = -1 ENOMEM (Cannot allocate memory) > Thus exposing private key material to being swapped out to permanent > storage. I am not sure if a mere warning is sufficient here. there are (at least) three ways that your RAM could be non-ephemeral that you don't get any warnings about at all: * "cold boot" attacks -- not all DRAM is actually fully wiped just because power is removed from it. * hibernation -- if your computer suspends to disk, it doesn't matter than the memory was locked. * virtual machines -- if you are running gpg inside a virtual machine of any type, it's possible that the memory of the virtual machine is subject to monitoring or recording from the host. Also, any sensible use of swap today on any machine that has sensitive data should be done with an ephemerally-encrypted swap device. In particular, on GNU/Linux systems with cryptsetup, that means something like: * a line which creates the mapped device and runs mkswap on it, in /etc/crypttab: cswap /dev/sda6 /dev/random swap * and a line which points to that newly-mapped device in /etc/fstab: /dev/mapper/cswap swap swap defaults 0 0 So for me, it's not clear that even the warning about not using locked memory itself is warranted, and i suspect that any requirement to use locked memory today would inhibit the use of crypto more than it would avoid the risk of leaks. Also, the use of locked memory feeds into these interminable discussions about "how much is enough?" which is time that we could spend on fixing usability instead :) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From wk at gnupg.org Tue Oct 17 09:01:53 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Oct 2017 09:01:53 +0200 Subject: ROCA detection in GnuPG Message-ID: <87bml6uuji.fsf@wheatstone.g10code.de> Hi! Over at gnupg-verein, Phil asked whether it would make sense to have an auto-detection of ROCA affected keys in GnuPG. Only a few gpg generated keys seem to be affected. Probably those created on certain smartcards: Yubikey seems to be affected but the commonly used Zeitcontrol card should be fine because, afaik, that card uses an NXP and not an Infinion chip. I wondered on how to best implement this in GnuPG: We have no central place to test _public_ keys and thus a check needs to be implemented in gpgsm, and gpg. I expect that OpenSSH will provide a tool to check ssh public keys, thus there is no need for us to do that in gpg-agent. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 357 bytes Desc: not available URL: From gniibe at fsij.org Tue Oct 17 12:45:01 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 17 Oct 2017 19:45:01 +0900 Subject: ROCA detection in GnuPG In-Reply-To: <87bml6uuji.fsf@wheatstone.g10code.de> References: <87bml6uuji.fsf@wheatstone.g10code.de> Message-ID: <87d15m3vf6.fsf@fsij.org> Werner Koch writes: > I wondered on how to best implement this in GnuPG: We have no central > place to test _public_ keys and thus a check needs to be implemented in > gpgsm, and gpg. I expect that OpenSSH will provide a tool to check ssh > public keys, thus there is no need for us to do that in gpg-agent. In case of the Debian SSH problem, it was Colin Watson who added ssh-vulnkey to openssh source package in Debian. It was dropped in 1:6.5p1-1. The discussion of dropping ssh-vulnkey can be found here: https://lists.debian.org/debian-ssh/2013/09/msg00014.html So, I'm not sure if OpenSSH will provide a tool. -- From kristian.fiskerstrand at sumptuouscapital.com Tue Oct 17 13:52:50 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 17 Oct 2017 13:52:50 +0200 Subject: ROCA detection in GnuPG In-Reply-To: <87bml6uuji.fsf@wheatstone.g10code.de> References: <87bml6uuji.fsf@wheatstone.g10code.de> Message-ID: On 10/17/2017 09:01 AM, Werner Koch wrote: > I wondered on how to best implement this in GnuPG: We have no central > place to test _public_ keys and thus a check needs to be implemented in > gpgsm, and gpg. I expect that OpenSSH will provide a tool to check ssh > public keys, thus there is no need for us to do that in gpg-agent. I'm somewhat ambivalent on this issue as well, on one side we likely want to implement all kinds of protection methods we're aware of and can possibly fathom, even if it increases import time and complexity, and on the other side, and at least the details I've seen is that this attack is very specific for the bias of the implementation of the Infineon library, whereby the remainder from division on small primes can be reasonably identified. This means any protection for the overall userbase would be marginal, as it isn't a generic class or a new attack on RSA. For that reason alone, a stand-alone tool for testing is better than a test that always happens in gnupg. But the greater concern is, given users apparent behavior, will they consider this a proof of good entropy of the key as long as it is not rejected, and we're entering into territory with even more technical / algorithmical focus whereby the real improvements to security likely relates to proper definition of threat models and operational security considerations to begin with. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "Whatever you do in life, surround yourself with smart people who'll argue with you." John Wooden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From fgrieu at gmail.com Tue Oct 17 16:33:59 2017 From: fgrieu at gmail.com (Francois Grieu) Date: Tue, 17 Oct 2017 16:33:59 +0200 Subject: ROCA detection in GnuPG In-Reply-To: <87bml6uuji.fsf@wheatstone.g10code.de> References: <87bml6uuji.fsf@wheatstone.g10code.de> Message-ID: <4e90d315-463a-eebb-c75c-64b5c901c934@gmail.com> Werner Koch wrote: > Over at gnupg-verein, Phil asked whether it would make sense to > have an auto-detection of ROCA affected keys in GnuPG. The ROCA test can have false positives, with probability 1/238878720 that a perfectly fine RSA key raise alarm. See details at https://crypto.stackexchange.com/questions/52292/what-is-fast-prime This is low enough that it will seldom happen by chance, but on the other hand it is very possible to intentionally make a (secure) key that raise this alarm, just for the nastiness of it. ? Francois Grieu -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Oct 17 21:19:38 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Oct 2017 21:19:38 +0200 Subject: ROCA detection in GnuPG In-Reply-To: <4e90d315-463a-eebb-c75c-64b5c901c934@gmail.com> (Francois Grieu's message of "Tue, 17 Oct 2017 16:33:59 +0200") References: <87bml6uuji.fsf@wheatstone.g10code.de> <4e90d315-463a-eebb-c75c-64b5c901c934@gmail.com> Message-ID: <87o9p5twdx.fsf@wheatstone.g10code.de> On Tue, 17 Oct 2017 16:33, fgrieu at gmail.com said: > The ROCA test can have false positives, with probability 1/238878720 > that a perfectly fine RSA key raise alarm. See details at Indeed. Thus we should not reject such a key but at best print a warning. What I did today is a new option --with-key-screening, which can be used to detect such keys by doing a keylisting in gpg and gpgsm. It is in master and allows for fast scanning: $ gpg -k --with-key-screening --with-colons | gawk -F: \ '$1~/pub|sub|sec|ssb|crt/ && $18~/\<6001\>/ {found=1;next}; $1=="fpr" && found {print $10}; {found=0}' The same works for gpgsm. Note that we need gawk due to the "\<" in the r.e. This adds a framework which should make it easy to add such scans in the future. Note that this does not only work with "-k" but also with "--import-options show-only --import" to avoid the need for importing a key. Salam-Shalom, 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: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Oct 18 01:44:50 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 17 Oct 2017 19:44:50 -0400 Subject: tests/openpgp/tofu.scm failing ("Missing key BE04EB2B") Message-ID: <87y3o9tk3x.fsf@fifthhorseman.net> Hi folks-- Trying to build against the current master branch (commit ID 825abec0e7f38667a34dce3025fc2f3a05001dde) I get the following failed test: [...] PASS: tests/openpgp/4gb-packet.scm Missing key BE04EB2B FAIL: tests/openpgp/tofu.scm Checking basic WoT (classic trust model)... PASS: tests/openpgp/trust-pgp-1.scm [...] Is anyone else seeing the same behavior? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Oct 18 01:46:33 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 17 Oct 2017 19:46:33 -0400 Subject: [PINENTRY PATCH] core: Expect (and verify) a uid on "owner" option. In-Reply-To: <20171017234536.7502-1-dkg@fifthhorseman.net> References: <20171017234536.7502-1-dkg@fifthhorseman.net> Message-ID: <20171017234633.7652-1-dkg@fifthhorseman.net> * pinentry/pinentry.h (struct pinentry): Add field 'owner_uid'. * pinentry/pinentry.c (pinentry_reset): Handle this new field. (get_pid_name_for_uid): New. Atomic check for the base process name contingent on process ownership. (pinentry_get_title): Only scan for full commandline if the process actually belongs to the claimed uid. (option_handler): Option "owner" now expects "pid uid hostname". -- This requires an update to gpg's use of the "owner" option to emit the uid (which will follow shortly). It is not as atomic as it should be. In particular, there's a race condition between reading from /proc/PID/status and reading from /proc/PID/cmdline, but it's a much smaller race than there was previously. Signed-off-by: Daniel Kahn Gillmor --- pinentry/pinentry.c | 94 +++++++++++++++++++++++++++++++++++++++++++++-------- pinentry/pinentry.h | 6 +++- 2 files changed, 86 insertions(+), 14 deletions(-) diff --git a/pinentry/pinentry.c b/pinentry/pinentry.c index 2ba4baa..1ed7412 100644 --- a/pinentry/pinentry.c +++ b/pinentry/pinentry.c @@ -101,6 +101,7 @@ pinentry_reset (int use_defaults) char *default_tt_hide = pinentry.default_tt_hide; char *touch_file = pinentry.touch_file; unsigned long owner_pid = pinentry.owner_pid; + int owner_uid = pinentry.owner_uid; char *owner_host = pinentry.owner_host; /* These options are set from the command line. Don't reset @@ -176,6 +177,8 @@ pinentry_reset (int use_defaults) pinentry.color_bg = PINENTRY_COLOR_DEFAULT; pinentry.color_so = PINENTRY_COLOR_DEFAULT; pinentry.color_so_bright = 0; + + pinentry.owner_uid = -1; } else /* Restore the options. */ { @@ -195,6 +198,7 @@ pinentry_reset (int use_defaults) pinentry.default_tt_hide = default_tt_hide; pinentry.touch_file = touch_file; pinentry.owner_pid = owner_pid; + pinentry.owner_uid = owner_uid; pinentry.owner_host = owner_host; pinentry.debug = debug; @@ -429,6 +433,54 @@ get_cmdline (unsigned long pid) } +/* Atomically ask the kernel for information about process PID. + * Return a malloc'ed copy of the process name as long as the process + * uid matches UID. If it cannot determine that the process has uid + * UID, it returns NULL. + + * This is not as informative as get_cmdline, but it verifies that the + * process does belong to the user in question. + */ +static char * +get_pid_name_for_uid (unsigned long pid, int uid) +{ + char buffer[400]; + FILE *fp; + size_t end, n; + char *uidstr; + + snprintf (buffer, sizeof buffer, "/proc/%lu/status", pid); + buffer[sizeof buffer - 1] = 0; + + fp = fopen (buffer, "rb"); + if (!fp) + return NULL; + n = fread (buffer, 1, sizeof buffer - 1, fp); + if (n < sizeof buffer -1 && ferror (fp)) + { + /* Some error occurred. */ + fclose (fp); + return NULL; + } + fclose (fp); + if (n == 0) + return NULL; + if (strncmp (buffer, "Name:\t", 6)) + return NULL; + end = strcspn (buffer + 6, "\n") + 6; + buffer[end] = 0; + + /* check that uid matches what we expect */ + uidstr = strstr (buffer + end + 1, "\nUid:\t"); + if (!uidstr) + return NULL; + if (atoi (uidstr + 6) != uid) + return NULL; + + return strdup (buffer + 6); +} + + /* Return a malloced string with the title. The caller mus free the * string. If no title is available or the title string has an error * NULL is returned. */ @@ -443,16 +495,21 @@ pinentry_get_title (pinentry_t pe) { char buf[200]; struct utsname utsbuf; + char *pidname = NULL; char *cmdline = NULL; if (pe->owner_host && !uname (&utsbuf) && utsbuf.nodename && !strcmp (utsbuf.nodename, pe->owner_host)) - cmdline = get_cmdline (pe->owner_pid); + { + pidname = get_pid_name_for_uid (pe->owner_pid, pe->owner_uid); + if (pidname) + cmdline = get_cmdline (pe->owner_pid); + } - if (pe->owner_host && cmdline) + if (pe->owner_host && (cmdline || pidname)) snprintf (buf, sizeof buf, "[%lu]@%s (%s)", - pe->owner_pid, pe->owner_host, cmdline); + pe->owner_pid, pe->owner_host, cmdline ? cmdline : pidname); else if (pe->owner_host) snprintf (buf, sizeof buf, "[%lu]@%s", pe->owner_pid, pe->owner_host); @@ -460,6 +517,7 @@ pinentry_get_title (pinentry_t pe) snprintf (buf, sizeof buf, "[%lu] ", pe->owner_pid); buf[sizeof buf - 1] = 0; + free (pidname); free (cmdline); title = strdup (buf); } @@ -1027,24 +1085,34 @@ option_handler (assuan_context_t ctx, const char *key, const char *value) free (pinentry.owner_host); pinentry.owner_host = NULL; + pinentry.owner_uid = -1; + pinentry.owner_pid = 0; errno = 0; along = strtol (value, &endp, 10); - if (along < 0 || errno) - pinentry.owner_pid = 0; - else + if (along && !errno) { pinentry.owner_pid = (unsigned long)along; - while (endp && *endp == ' ') - endp++; if (*endp) { - pinentry.owner_host = strdup (endp); - if (pinentry.owner_host) + errno = 0; + along = strtol (endp, &endp, 10); + if (along >= 0 && !errno) { - for (endp=pinentry.owner_host; *endp && *endp != ' '; endp++) - ; - *endp = 0; + pinentry.owner_uid = (int)along; + if (endp) + { + while (*endp == ' ') + endp++; + if (*endp) + { + pinentry.owner_host = strdup (endp); + for (endp=pinentry.owner_host; + *endp && *endp != ' '; endp++) + ; + *endp = 0; + } + } } } } diff --git a/pinentry/pinentry.h b/pinentry/pinentry.h index a4447a8..128331c 100644 --- a/pinentry/pinentry.h +++ b/pinentry/pinentry.h @@ -98,7 +98,11 @@ struct pinentry * which actually triggered the the pinentry. For example gpg. */ unsigned long owner_pid; - /* The malloced hostname of the owener or NULL. */ + /* The numeric uid (user ID) of the owner process or -1 if not + * known. */ + int owner_uid; + + /* The malloced hostname of the owner or NULL. */ char *owner_host; /* The window ID of the parent window over which the pinentry window -- 2.14.2 From dkg at fifthhorseman.net Wed Oct 18 01:45:36 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 17 Oct 2017 19:45:36 -0400 Subject: [PATCH] agent: Send pinentry the uid of connecting process where possible. Message-ID: <20171017234536.7502-1-dkg@fifthhorseman.net> * agent/agent.h (server_control_s): Add field 'client_uid'. * agent/call-pinentry.c (start_pinentry): Add uid field to assuan option "owner" sent to pinentry. * agent/command-ssh.c (peer_info_s): New static struct. (get_client_pid): Rename to... (get_client_info): Here, and extract uid in addition to pid. (start_command_handler_ssh): Use get_client_info() instead of get_client_pid(). * agent/command.c (start_command_handler): Use assuan_get_peercred instead of assuan_get_pid. -- This also requires an update to pinentry to handle the new uid field. Distributing the uid as well as the pid makes it harder for a different user on the same machine to take advantage of any race conditions between when a requesting process might ask for something that needs pinentry, and when pinentry gets around to inspecting the state of that process. We put the uid before the nodename because the uid is guaranteed to be a integer (represented in decimal), which makes it much simpler to parse past than the potentially arbitrarily structured nodename. If we were willing to depend on the nodename being whitespace-delimited (as the current, unreleased pinentry code does), then we could add the uid after the nodename. But since no released pinentry depends on this option anyway, i think we should make the more conservative, easily-parseable choice and put the user ID first. Signed-off-by: Daniel Kahn Gillmor --- agent/agent.h | 1 + agent/call-pinentry.c | 5 +++-- agent/command-ssh.c | 29 +++++++++++++++++++++++------ agent/command.c | 23 +++++++++++++++++------ 4 files changed, 44 insertions(+), 14 deletions(-) diff --git a/agent/agent.h b/agent/agent.h index f5df75e6e..af64f335e 100644 --- a/agent/agent.h +++ b/agent/agent.h @@ -226,6 +226,7 @@ struct server_control_s char *lc_ctype; char *lc_messages; unsigned long client_pid; + int client_uid; /* The current pinentry mode. */ pinentry_mode_t pinentry_mode; diff --git a/agent/call-pinentry.c b/agent/call-pinentry.c index 6a5c1fe1e..35766b6b1 100644 --- a/agent/call-pinentry.c +++ b/agent/call-pinentry.c @@ -593,8 +593,9 @@ start_pinentry (ctrl_t ctrl) nodename = utsbuf.nodename; #endif /*!HAVE_W32_SYSTEM*/ - if ((optstr = xtryasprintf ("OPTION owner=%lu %s", - ctrl->client_pid, nodename))) + if ((optstr = xtryasprintf ("OPTION owner=%lu %d %s", + ctrl->client_pid, ctrl->client_uid, + nodename))) { assuan_transact (entry_ctx, optstr, NULL, NULL, NULL, NULL, NULL, NULL); diff --git a/agent/command-ssh.c b/agent/command-ssh.c index 9d45a1864..71f311845 100644 --- a/agent/command-ssh.c +++ b/agent/command-ssh.c @@ -255,6 +255,11 @@ static gpg_error_t ssh_signature_encoder_eddsa (ssh_key_type_spec_t *spec, static gpg_error_t ssh_key_extract_comment (gcry_sexp_t key, char **comment); +struct peer_info_s +{ + unsigned long pid; + int uid; +}; /* Global variables. */ @@ -3581,10 +3586,12 @@ ssh_request_process (ctrl_t ctrl, estream_t stream_sock) /* Return the peer's pid. */ -static unsigned long -get_client_pid (int fd) +static struct peer_info_s +get_client_info (int fd) { - pid_t client_pid = (pid_t)0; + struct peer_info_s out; + pid_t client_pid = (pid_t)(-1); + uid_t client_uid = (uid_t)-1; #ifdef SO_PEERCRED { @@ -3599,8 +3606,10 @@ get_client_pid (int fd) { #if defined (HAVE_STRUCT_SOCKPEERCRED_PID) || defined (HAVE_STRUCT_UCRED_PID) client_pid = cr.pid; + client_uid = cr.uid; #elif defined (HAVE_STRUCT_UCRED_CR_PID) client_pid = cr.cr_pid; + client_pid = cr.cr_uid; #else #error "Unknown SO_PEERCRED struct" #endif @@ -3611,6 +3620,7 @@ get_client_pid (int fd) socklen_t len = sizeof (pid_t); getsockopt (fd, SOL_LOCAL, LOCAL_PEERPID, &client_pid, &len); + getsockopt (fd, SOL_LOCAL, LOCAL_PEERUID, &client_uid, &len); } #elif defined (LOCAL_PEEREID) { @@ -3619,6 +3629,7 @@ get_client_pid (int fd) if (getsockopt (fd, 0, LOCAL_PEEREID, &unp, &unpl) != -1) client_pid = unp.unp_pid; + client_uid = unp.unp_euid; } #elif defined (HAVE_GETPEERUCRED) { @@ -3626,7 +3637,8 @@ get_client_pid (int fd) if (getpeerucred (fd, &ucred) != -1) { - client_pid= ucred_getpid (ucred); + client_pid = ucred_getpid (ucred); + client_uid = ucred_geteuid (ucred); ucred_free (ucred); } } @@ -3634,7 +3646,9 @@ get_client_pid (int fd) (void)fd; #endif - return (unsigned long)client_pid; + out.pid = (client_pid == (pid_t)(-1)? 0 : (unsigned long)client_pid); + out.uid = (int)client_uid; + return out; } @@ -3645,12 +3659,15 @@ start_command_handler_ssh (ctrl_t ctrl, gnupg_fd_t sock_client) estream_t stream_sock = NULL; gpg_error_t err; int ret; + struct peer_info_s peer_info; err = agent_copy_startup_env (ctrl); if (err) goto out; - ctrl->client_pid = get_client_pid (FD2INT(sock_client)); + peer_info = get_client_info (FD2INT(sock_client)); + ctrl->client_pid = peer_info.pid; + ctrl->client_uid = peer_info.uid; /* Create stream from socket. */ stream_sock = es_fdopen (FD2INT(sock_client), "r+"); diff --git a/agent/command.c b/agent/command.c index fd39c680f..de7ba2051 100644 --- a/agent/command.c +++ b/agent/command.c @@ -3328,7 +3328,7 @@ start_command_handler (ctrl_t ctrl, gnupg_fd_t listen_fd, gnupg_fd_t fd) for (;;) { - pid_t client_pid; + assuan_peercred_t client_creds; rc = assuan_accept (ctx); if (gpg_err_code (rc) == GPG_ERR_EOF || rc == -1) @@ -3341,12 +3341,23 @@ start_command_handler (ctrl_t ctrl, gnupg_fd_t listen_fd, gnupg_fd_t fd) break; } - client_pid = assuan_get_pid (ctx); - ctrl->server_local->connect_from_self = (client_pid == getpid ()); - if (client_pid != ASSUAN_INVALID_PID) - ctrl->client_pid = (unsigned long)client_pid; + rc = assuan_get_peercred (ctx, &client_creds); + if (rc) + { + log_info ("Assuan get_peercred failed: %s\n", gpg_strerror (rc)); + ctrl->client_pid = 0; + ctrl->client_uid = -1; + } else - ctrl->client_pid = 0; + { + ctrl->server_local->connect_from_self = + (client_creds->pid == getpid ()); + if (client_creds->pid != ASSUAN_INVALID_PID) + ctrl->client_pid = (unsigned long)client_creds->pid; + else + ctrl->client_pid = 0; + ctrl->client_uid = client_creds->uid; + } rc = assuan_process (ctx); if (rc) -- 2.14.2 From wk at gnupg.org Wed Oct 18 09:45:36 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Oct 2017 09:45:36 +0200 Subject: [PATCH] agent: Send pinentry the uid of connecting process where possible. In-Reply-To: <20171017234536.7502-1-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 17 Oct 2017 19:45:36 -0400") References: <20171017234536.7502-1-dkg@fifthhorseman.net> Message-ID: <87a80oucf3.fsf@wheatstone.g10code.de> On Wed, 18 Oct 2017 01:45, dkg at fifthhorseman.net said: > Distributing the uid as well as the pid makes it harder for a > different user on the same machine to take advantage of any race Do you have an example on how this can happen? Two users on the same X-server pose a problem anyway. However, adding a user ID does not harm. > We put the uid before the nodename because the uid is guaranteed to be > a integer (represented in decimal), which makes it much simpler to > parse past than the potentially arbitrarily structured nodename. Well, that breaks the API between gpg-agent and Pinentry. Becuase the hostname is only additionl information which can't be intrepreted any further I think this break is acceptable. However, to be future proof I would suggest to change it this way: - if ((optstr = xtryasprintf ("OPTION owner=%lu %d %s", - ctrl->client_pid, ctrl->client_uid, - nodename))) + if ((optstr = xtryasprintf ("OPTION owner=%lu/%d %s", + ctrl->client_pid, ctrl->client_uid, + nodename))) The existing Pinentries would then use "/NNN HOSTNAME" for the hostname because of the its too simple parser. If we ever need the gid or whatever, it can be added by using another slash as delimiter. We also need to define how to indicate "UID not available". "-1" might be okay but an emtpy string like in "/PID// HOSTNAME" avoids the need to parse negative numbers. > -static unsigned long > -get_client_pid (int fd) > +static struct peer_info_s > +get_client_info (int fd) > { Please don't return a structure but pass it by reference. > - client_pid = assuan_get_pid (ctx); > - ctrl->server_local->connect_from_self = (client_pid == getpid ()); > - if (client_pid != ASSUAN_INVALID_PID) > - ctrl->client_pid = (unsigned long)client_pid; > + rc = assuan_get_peercred (ctx, &client_creds); > + if (rc) > + { > + log_info ("Assuan get_peercred failed: %s\n", gpg_strerror (rc)); assuan_get_peercred may actually fail (e.g. "gpg-agent --server" or certain platforms). There should be a fallback to assuan_get_pid in this case. I have not looked closely at the Pinentry patch but adjusted to the here discussed changes it seems okay. Salam-Shalom, 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: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Oct 18 13:46:07 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Oct 2017 13:46:07 +0200 Subject: tests/openpgp/tofu.scm failing ("Missing key BE04EB2B") In-Reply-To: <87y3o9tk3x.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 17 Oct 2017 19:44:50 -0400") References: <87y3o9tk3x.fsf@fifthhorseman.net> Message-ID: <87d15ksmps.fsf@wheatstone.g10code.de> On Wed, 18 Oct 2017 01:44, dkg at fifthhorseman.net said: > Missing key BE04EB2B > FAIL: tests/openpgp/tofu.scm This is because the tofu code assumes that a fingerprint is always MAX_FINGERPRINT_LEN long - which is not the case. The constant is only used to allocate sufficient large buffers for fingerprints. To prepare for version 5 keys I already increased the size of that bufffer. I will take care of it - no need for a bug report. Salam-Shalom, 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: 227 bytes Desc: not available URL: From dario at darioniedermann.it Thu Oct 19 02:38:28 2017 From: dario at darioniedermann.it (Dario Niedermann) Date: Thu, 19 Oct 2017 02:38:28 +0200 Subject: [PATCH] 1.4.22 historical gcc compatibility Message-ID: <20171019003828.GD823@darioniedermann.it> The enclosed patch enables gnupg-1.4.22 to compile with gcc-2.95.3. An accomplishment which - while probably not very high on most people's priority lists - did allow me to build it on OpenBSD 3.3 (2001 vintage, not quite ancient). The patch is of my own doing and just removes what the old compiler sees as a syntax error. Regards, Dario Niedermann =====BEGIN PATCH===== --- cipher/rsa.c.orig Mon Jul 10 10:48:39 2017 +++ cipher/rsa.c Wed Oct 18 14:34:21 2017 @@ -304,6 +304,9 @@ #if 0 mpi_powm( output, input, skey->d, skey->n ); #else + MPI D_blind; + MPI rr; + unsigned int rr_nbits; int nlimbs = mpi_get_nlimbs (skey->n)+1; MPI m1 = mpi_alloc_secure (nlimbs); MPI m2 = mpi_alloc_secure (nlimbs); @@ -326,9 +329,7 @@ # endif /* USE_BLINDING */ /* RSA secret operation: */ - MPI D_blind = mpi_alloc_secure (nlimbs); - MPI rr; - unsigned int rr_nbits; + D_blind = mpi_alloc_secure (nlimbs); rr_nbits = mpi_get_nbits (skey->p) / 4; if (rr_nbits < 96) =====END PATCH===== -- Dario Niedermann. Also on the Internet at: gopher://darioniedermann.it/ <> https://www.darioniedermann.it/ From dkg at fifthhorseman.net Thu Oct 19 09:43:10 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 19 Oct 2017 03:43:10 -0400 Subject: [PATCH] agent: Send pinentry the uid of connecting process where possible. In-Reply-To: <87a80oucf3.fsf@wheatstone.g10code.de> References: <20171017234536.7502-1-dkg@fifthhorseman.net> <87a80oucf3.fsf@wheatstone.g10code.de> Message-ID: <87efpz1t2p.fsf@fifthhorseman.net> On Wed 2017-10-18 09:45:36 +0200, Werner Koch wrote: > However, to be future proof I would suggest to change it this way: > > - if ((optstr = xtryasprintf ("OPTION owner=%lu %d %s", > - ctrl->client_pid, ctrl->client_uid, > - nodename))) > + if ((optstr = xtryasprintf ("OPTION owner=%lu/%d %s", > + ctrl->client_pid, ctrl->client_uid, > + nodename))) > > The existing Pinentries would then use "/NNN HOSTNAME" for the > hostname because of the its too simple parser. I don't think that's the case because of: if (pinentry.owner_host) { for (endp=pinentry.owner_host; *endp && *endp != ' '; endp++) ; *endp = 0; } So it would just take the hostname as "/NNN", not "/NNN HOSTNAME". That said, it's easy to use a / instead of whitespace as a delimiter, so i've adopted that suggestion. I just don't think it's worth fretting about it too much either way because those versions of pinentry haven't had an official release yet. >> -static unsigned long >> -get_client_pid (int fd) >> +static struct peer_info_s >> +get_client_info (int fd) >> { > > Please don't return a structure but pass it by reference. ok. >> - client_pid = assuan_get_pid (ctx); >> - ctrl->server_local->connect_from_self = (client_pid == getpid ()); >> - if (client_pid != ASSUAN_INVALID_PID) >> - ctrl->client_pid = (unsigned long)client_pid; >> + rc = assuan_get_peercred (ctx, &client_creds); >> + if (rc) >> + { >> + log_info ("Assuan get_peercred failed: %s\n", gpg_strerror (rc)); > > assuan_get_peercred may actually fail (e.g. "gpg-agent --server" or > certain platforms). There should be a fallback to assuan_get_pid in > this case. Gotcha, thanks for catching that. I've pushed the variant of the patch that addresses all of your suggestions here to master, as 28aa6890588cc108639951bb4bef03ac17743046 And i've pushed the adjusted pinentry patch to 6aafa61b199ab9091d6c9e190129f2ead2a647c7. Hope that's helpful, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From wk at gnupg.org Thu Oct 19 12:29:48 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Oct 2017 12:29:48 +0200 Subject: [PATCH] agent: Send pinentry the uid of connecting process where possible. In-Reply-To: <87efpz1t2p.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 19 Oct 2017 03:43:10 -0400") References: <20171017234536.7502-1-dkg@fifthhorseman.net> <87a80oucf3.fsf@wheatstone.g10code.de> <87efpz1t2p.fsf@fifthhorseman.net> Message-ID: <87efpzph0j.fsf@wheatstone.g10code.de> On Thu, 19 Oct 2017 09:43, dkg at fifthhorseman.net said: > I don't think that's the case because of: Right, I stopped looking at the detection of the hostname, which unfortunately did not skip non-whitespace after the PID. > I just don't think it's worth fretting about it too much either way > because those versions of pinentry haven't had an official release yet. Ack. > I've pushed the variant of the patch that addresses all of your > suggestions here to master, as 28aa6890588cc108639951bb4bef03ac17743046 Thanks. The Phrabicator is also up again. Salam-Shalom, 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: 227 bytes Desc: not available URL: From wk at gnupg.org Thu Oct 19 17:37:20 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Oct 2017 17:37:20 +0200 Subject: Please Consider Increasing SECMEM_BUFFER_SIZE To 1048576 In-Reply-To: <871sm7rlla.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 13 Oct 2017 13:42:09 -0400") References: <768f49c6-e0b9-c63a-8104-9d51cf28fd60@suse.com> <871sm7rlla.fsf@fifthhorseman.net> Message-ID: <87wp3rkv2n.fsf@wheatstone.g10code.de> On Fri, 13 Oct 2017 19:42, dkg at fifthhorseman.net said: > Also, any sensible use of swap today on any machine that has sensitive > data should be done with an ephemerally-encrypted swap device. In Indeed. Back in the late 90ies, avoidance of such secret leakage was on the wishlist of all security folks and thus gpg implemented this right From its beginning. To use mlock for this was actually a kludge for Linux, other Unices, and (later) Windows where we had no encrypted swap or it used to be really complicate to setup. The *BSDs had useful encrypted swap much earlier but GnuPG wanted to address all platforms. > particular, on GNU/Linux systems with cryptsetup, that means something > like: Thanks for that short howto. Is there a reason why it is not done by default in Debian? Can we expect it in Buster? Salam-Shalom, 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: 227 bytes Desc: not available URL: From peter at digitalbrains.com Thu Oct 19 18:08:52 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 19 Oct 2017 18:08:52 +0200 Subject: Please Consider Increasing SECMEM_BUFFER_SIZE To 1048576 In-Reply-To: <871sm7rlla.fsf@fifthhorseman.net> References: <768f49c6-e0b9-c63a-8104-9d51cf28fd60@suse.com> <871sm7rlla.fsf@fifthhorseman.net> Message-ID: <8f6f6e20-3e30-a872-3ee6-693ba853434b@digitalbrains.com> On 13/10/17 19:42, Daniel Kahn Gillmor wrote: > Also, any sensible use of swap today on any machine that has sensitive > data should be done with an ephemerally-encrypted swap device. In > particular, on GNU/Linux systems with cryptsetup, that means something > like: What about a laptop that needs to hibernate? I use full disk encryption, but my swap is just part of the same encrypted LVM physical volume, encrypted with the same non-ephemeral key as the rest of the disk. It would be nice to refresh the key for swap quite often, but this seems non-trivial. Peter. PS: In earlier Debian releases, I also found out that if I used an ephemeral key for both swap and /tmp, my system would run out of entropy during boot. I don't know if this is still an issue. The way I solved it back then would not have worked with systemd, since they decided to not support the "keyscript" option. This seems like quite a big omission in systemd to me. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From guilhem at fripost.org Thu Oct 19 18:50:43 2017 From: guilhem at fripost.org (Guilhem Moulin) Date: Thu, 19 Oct 2017 18:50:43 +0200 Subject: cryptsetup keyscripts (Was: Please Consider Increasing SECMEM_BUFFER_SIZE To 1048576) In-Reply-To: <8f6f6e20-3e30-a872-3ee6-693ba853434b@digitalbrains.com> References: <768f49c6-e0b9-c63a-8104-9d51cf28fd60@suse.com> <871sm7rlla.fsf@fifthhorseman.net> <8f6f6e20-3e30-a872-3ee6-693ba853434b@digitalbrains.com> Message-ID: <20171019165043.r542husepx7yx3hr@localhost.localdomain> Hi Peter, On Thu, 19 Oct 2017 at 18:08:52 +0200, Peter Lebbing wrote: > The way I solved it back then would not have worked with systemd, > since they decided to not support the "keyscript" option. This seems > like quite a big omission in systemd to me. Agreed, and we're trying to convince the systemd maintainers to adopt a Debian-specific patch for keyscript support :-) (To be fair we haven't really tested the patch yet, AFAIK.) In the meantime, editing your crypttab(5) to add ?initramfs? to the 4th field of your device(s) forces it to be considered for unlocking at initramfs stage. Cheers, -- Guilhem. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From guilhem at fripost.org Thu Oct 19 18:28:42 2017 From: guilhem at fripost.org (Guilhem Moulin) Date: Thu, 19 Oct 2017 18:28:42 +0200 Subject: Please Consider Increasing SECMEM_BUFFER_SIZE To 1048576 In-Reply-To: <87wp3rkv2n.fsf@wheatstone.g10code.de> References: <768f49c6-e0b9-c63a-8104-9d51cf28fd60@suse.com> <871sm7rlla.fsf@fifthhorseman.net> <87wp3rkv2n.fsf@wheatstone.g10code.de> Message-ID: <20171019162842.jsit6c7j2oqtbbz4@localhost.localdomain> On Thu, 19 Oct 2017 at 17:37:20 +0200, Werner Koch wrote: > On Fri, 13 Oct 2017 19:42, dkg at fifthhorseman.net said: >> particular, on GNU/Linux systems with cryptsetup, that means something >> like: > > Thanks for that short howto. Is there a reason why it is not done by > default in Debian? Can we expect it in Buster? I read this list (and perhaps so does my co-maintainer), but the Debian BTS would be a better place to discuss this :-P Ephemeral keys are unlikely to be the default because it prevents hibernation; but I agree that a d-i option would be nice. Moreover while using /dev/random might lead to entropy starvation at initramfs stage (especially on headless server), /dev/urandom is not an option currently since the PRNG isn't seeded early enough. AFAIK the linux kernel doesn't expose a source device interfacing with its RNG and having the Right? semantics (like /dev/urandom but blocking if there is not enough entropy), but once we have a libc exporting getrandom(2) I intend to write a trivial keyscript emulating that behavior. That is, unless cryptsetup upstream can be convinced to add a ?--key-random? flag doing the same thing (also in my TODO list). -- Guilhem, from the cryptsetup maintenance team. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu Oct 19 18:21:00 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 19 Oct 2017 12:21:00 -0400 Subject: Please Consider Increasing SECMEM_BUFFER_SIZE To 1048576 In-Reply-To: <87wp3rkv2n.fsf@wheatstone.g10code.de> References: <768f49c6-e0b9-c63a-8104-9d51cf28fd60@suse.com> <871sm7rlla.fsf@fifthhorseman.net> <87wp3rkv2n.fsf@wheatstone.g10code.de> Message-ID: <8760bb153n.fsf@fifthhorseman.net> On Thu 2017-10-19 17:37:20 +0200, Werner Koch wrote: > On Fri, 13 Oct 2017 19:42, dkg at fifthhorseman.net said: >> particular, on GNU/Linux systems with cryptsetup, that means something >> like: > > Thanks for that short howto. Is there a reason why it is not done by > default in Debian? Can we expect it in Buster? Please see https://bugs.debian.org/795735 for more discussion. It seems to be a bit stymied by the concerns around suspend-to-disk (or rather, concerns around resume-from-disk :P) Regards, --dkg From wk at gnupg.org Fri Oct 20 09:08:02 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 20 Oct 2017 09:08:02 +0200 Subject: Please Consider Increasing SECMEM_BUFFER_SIZE To 1048576 In-Reply-To: <8760bb153n.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 19 Oct 2017 12:21:00 -0400") References: <768f49c6-e0b9-c63a-8104-9d51cf28fd60@suse.com> <871sm7rlla.fsf@fifthhorseman.net> <87wp3rkv2n.fsf@wheatstone.g10code.de> <8760bb153n.fsf@fifthhorseman.net> Message-ID: <87sheejnzh.fsf@wheatstone.g10code.de> On Thu, 19 Oct 2017 18:21, dkg at fifthhorseman.net said: > Please see https://bugs.debian.org/795735 for more discussion. It > seems to be a bit stymied by the concerns around suspend-to-disk (or Thanks for kicking this again. Salam-Shalom, 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: 227 bytes Desc: not available URL: From rainer.perske at uni-muenster.de Fri Oct 20 14:05:09 2017 From: rainer.perske at uni-muenster.de (Rainer Perske) Date: Fri, 20 Oct 2017 14:05:09 +0200 (CEST) Subject: Patch for T1644 Message-ID: Hello all Werner Koch asked me to post it here: As described in my report T1644, it is possible that multiple certificates exist with the same Distinguished Name and the same key. In this case, verifying S/MIME signatures and other actions fail with "certificate not found: Ambiguous name". For details see the bug report. To circumvent the problem, I am patching GnuPG since 2014 so that in this case the newest of the ambiguous certificates is used. This is not an ultimate solution of the problem: You should try every certificate with the same DN until verification succeeds or until all certificates fail, and if multiple certificates of a chain are ambiguous you even have to check every combination. You may even consider checking the keyUsage attributes of the ambiguous certificates to reduce the number of combinations. But in the existing case of the certificates in the German Research Network (DFN) PKI where the newest one is the valid one and all ambiguous certificates have the same keyUsage attributes, this patch has proven to be sufficient over the last three years. With every GnuPG update, I have adapted the patch, luckily I never needed to change anything except line numbers. See attachment. Hope this helps you. Thank you all for your great work :-) Best greetings -- Rainer Perske System operations dept. and director of the certification authority (WWUCA) Center for Information Processing (university computer center) Westf?lische Wilhelms-Universit?t Zentrum f?r Informationsverarbeitung Rainer Perske R?ntgenstra?e 7-13 48149 M?nster Germany phone: +49 251 83-31582 fax: +49 251 83-31555 e-mail: rainer.perske at uni-muenster.de WWW: https://www.uni-muenster.de/ZIV/Mitarbeiter/RainerPerske.shtml office: room 006, R?ntgenstra?e 11 site map: http://wwwuv2.uni-muenster.de/uniplan/?action=spot&gebnr=7474 Certification Authority of the University of M?nster (WWUCA): phone: +49 251 83-31590 fax: +49 251 83-31555 e-mail: ca at uni-muenster.de WWW: https://www.uni-muenster.de/WWUCA/ Center for Information Processing: phone: +49 251 83-31600 (Mon-Fri 7:30-17:30) fax: +49 251 83-31555 e-mail: ziv at uni-muenster.de WWW: https://www.uni-muenster.de/ZIV/ -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-2.2.0.T1644.diff Type: text/x-patch Size: 5534 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6807 bytes Desc: S/MIME cryptographic signature URL: From rainer.perske at uni-muenster.de Fri Oct 20 16:51:11 2017 From: rainer.perske at uni-muenster.de (Rainer Perske) Date: Fri, 20 Oct 2017 16:51:11 +0200 (CEST) Subject: DCO, was Re: Patch for T1644 In-Reply-To: Message-ID: GnuPG Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the GnuPG project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: Rainer Perske Signed with OpenPGP and with S/MIME Best regards -- Rainer Perske System operations dept. and director of the certification authority (WWUCA) Center for Information Processing (university computer center) Westf?lische Wilhelms-Universit?t Zentrum f?r Informationsverarbeitung Rainer Perske R?ntgenstra?e 7-13 48149 M?nster Germany phone: +49 251 83-31582 fax: +49 251 83-31555 e-mail: rainer.perske at uni-muenster.de WWW: https://www.uni-muenster.de/ZIV/Mitarbeiter/RainerPerske.shtml office: room 006, R?ntgenstra?e 11 site map: http://wwwuv2.uni-muenster.de/uniplan/?action=spot&gebnr=7474 Certification Authority of the University of M?nster (WWUCA): phone: +49 251 83-31590 fax: +49 251 83-31555 e-mail: ca at uni-muenster.de WWW: https://www.uni-muenster.de/WWUCA/ Center for Information Processing: phone: +49 251 83-31600 (Mon-Fri 7:30-17:30) fax: +49 251 83-31555 e-mail: ziv at uni-muenster.de WWW: https://www.uni-muenster.de/ZIV/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP cryptographic signature URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6807 bytes Desc: S/MIME cryptographic signature URL: From matthew.summers at syapse.com Fri Oct 20 23:42:16 2017 From: matthew.summers at syapse.com (Matthew Summers) Date: Fri, 20 Oct 2017 16:42:16 -0500 Subject: Please Consider Increasing SECMEM_BUFFER_SIZE To 1048576 In-Reply-To: <768f49c6-e0b9-c63a-8104-9d51cf28fd60@suse.com> References: <768f49c6-e0b9-c63a-8104-9d51cf28fd60@suse.com> Message-ID: On Fri, Oct 13, 2017 at 8:00 AM, Andreas Stieger wrote: > Hello, > > > On 10/13/2017 06:44 AM, Matthew Summers wrote: > > This is following up on an issue that started around in the 2.1.17 > > days, and I have been carrying a small patch addressing this for my > > team since we figured it out. This is all documented in an earlier set > > of threads to this ML. > > > > Would you consider increasing SECMEM_BUFFER_SIZE to 1048576 in the > > case where the configure option `large_secmem` = yes, please? > > > > The patch itself is a super trivial in both configure and/or > > configure.ac . > > > > You haven't explicitly referenced the rationale for this. Is this about > RSA keys in excession of 4096 bits? > Yes, we are using 4096bit RSA keys, and generally recommend/require that internally at this stage in the game. Here is the start of the 1st thread: https://lists.gnutls.org/pipermail/gnupg-devel/2017-January/032486.html Here is the start of the 2nd thread: https://lists.gnupg.org/pipermail/gnupg-devel/2017-June/032894.html I would like to point out that this creates an issue on systems with the > max locked memory size (ulimit -l) is limited to 64k: > gpg: Warning: using insecure memory! > mlock(0x7f5814308000, 262144) = -1 ENOMEM (Cannot allocate memory) > Thus exposing private key material to being swapped out to permanent > storage. I am not sure if a mere warning is sufficient here. I have been adjusting this ulimit as a matter of course, so it's not been an issue. It appears that 64k 'default' max locked memory and/or max memory size may vary from distro to disto as well. I would like to stress that this is not a theoretical problem we are dealing with, but rather an issue that were we not able to patch the SECMEM_BUFFER_SIZE we would not be able to use GnuPG to protect sensitive data as we currently do (via saltstack). What about an extra arg in configure.ac that would let us either specify the SECMEM_BUFFER_SIZE or set it with `--extra-large-secmem`? I'd be happy to provide a patch for that, of course. Thanks, Matt Summers -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.summers at syapse.com Sat Oct 21 06:20:07 2017 From: matthew.summers at syapse.com (Matthew Summers) Date: Fri, 20 Oct 2017 23:20:07 -0500 Subject: [RFC PATCH] enable configurable SECMEM_BUFFER_SIZE [WAS Re: Please Consider Increasing SECMEM_BUFFER_SIZE To 1048576] Message-ID: Please see the attached patch, I'll also include it in the body since it's very short. What this does is change configure.ac to allow the end user to choose a value for secmem, or accept one of the two existing values. Following `autoreconf` on STABLE-BRANCH-2-2 with this patch applied, the following options are available: ./configure --enable-large-secmem # uses default 64k ./configure --enable-large-secmem=no # uses 32k value ./configure --enable-large-secmem=SIZE # can input any number > 32k (probably could use an upper bound too, perhaps) I attempted to follow the style and structure used for PK_UID_CACHE_SIZE via the --enable-key-cache option. If you prefer, I can make a pull request against github >From 5fd1e60f65048b3d0ccfd309f8c195e70d9fd027 Mon Sep 17 00:00:00 2001 From: Matthew Summers Date: Fri, 20 Oct 2017 23:14:51 -0500 Subject: [RFC PATCH] enable configurable SECMEM_BUFFER_SIZE --- configure.ac | 30 ++++++++++++++++++++---------- 1 file changed, 20 insertions(+), 10 deletions(-) diff --git a/configure.ac b/configure.ac index 70c122615..46cfd855a 100644 --- a/configure.ac +++ b/configure.ac @@ -236,20 +236,30 @@ AC_ARG_ENABLE(selinux-support, AC_MSG_RESULT($selinux_support) -AC_MSG_CHECKING([whether to allocate extra secure memory]) +# +# Check for size of secure memory allocation. If on Linux and if > 65536, it may be +# necessary to increase max locked memory, ulimit -l to accommodate. +# +AC_MSG_CHECKING([for the size of the secure memory allocation]) AC_ARG_ENABLE(large-secmem, - AC_HELP_STRING([--enable-large-secmem], - [allocate extra secure memory]), - large_secmem=$enableval, large_secmem=no) -AC_MSG_RESULT($large_secmem) -if test "$large_secmem" = yes ; then - SECMEM_BUFFER_SIZE=65536 -else - SECMEM_BUFFER_SIZE=32768 + AC_HELP_STRING([--enable-large-secmem=SIZE], + [set secure memory allocation to SIZE (default 65536)]),,enableval=65536) +if test "$enableval" = "no"; then + enableval=32768 +elif test "$enableval" = "yes" || test "$enableval" = ""; then + enableval=65536 fi -AC_DEFINE_UNQUOTED(SECMEM_BUFFER_SIZE,$SECMEM_BUFFER_SIZE, +changequote(,)dnl +secmem_buffer_size=`echo "$enableval" | sed 's/[A-Za-z]//g'` +changequote([,])dnl +if test "$enableval" != "$secmem_buffer_size" || test "$secmem_buffer_size" -lt 32768; then + AC_MSG_ERROR([invalid large-secmem buffersize]) +fi +AC_MSG_RESULT($secmem_buffer_size) +AC_DEFINE_UNQUOTED(SECMEM_BUFFER_SIZE,$secmem_buffer_size, [Size of secure memory buffer]) + AC_MSG_CHECKING([whether to enable trust models]) AC_ARG_ENABLE(trust-models, AC_HELP_STRING([--disable-trust-models], -- 2.13.6 On Fri, Oct 20, 2017 at 4:42 PM, Matthew Summers wrote: > > On Fri, Oct 13, 2017 at 8:00 AM, Andreas Stieger wrote: >> >> Hello, >> >> >> On 10/13/2017 06:44 AM, Matthew Summers wrote: >> > This is following up on an issue that started around in the 2.1.17 >> > days, and I have been carrying a small patch addressing this for my >> > team since we figured it out. This is all documented in an earlier set >> > of threads to this ML. >> > >> > Would you consider increasing SECMEM_BUFFER_SIZE to 1048576 in the >> > case where the configure option `large_secmem` = yes, please? >> > >> > The patch itself is a super trivial in both configure and/or >> > configure.ac . >> > >> >> You haven't explicitly referenced the rationale for this. Is this about >> RSA keys in excession of 4096 bits? > > > Yes, we are using 4096bit RSA keys, and generally recommend/require that internally at this stage in the game. > > Here is the start of the 1st thread: https://lists.gnutls.org/pipermail/gnupg-devel/2017-January/032486.html > > Here is the start of the 2nd thread: https://lists.gnupg.org/pipermail/gnupg-devel/2017-June/032894.html > >> I would like to point out that this creates an issue on systems with the >> max locked memory size (ulimit -l) is limited to 64k: >> gpg: Warning: using insecure memory! >> mlock(0x7f5814308000, 262144) = -1 ENOMEM (Cannot allocate memory) >> Thus exposing private key material to being swapped out to permanent >> storage. I am not sure if a mere warning is sufficient here. > > > I have been adjusting this ulimit as a matter of course, so it's not been an issue. It appears that 64k 'default' max locked memory and/or max memory size may vary from distro to disto as well. > > I would like to stress that this is not a theoretical problem we are dealing with, but rather an issue that were we not able to patch the SECMEM_BUFFER_SIZE we would not be able to use GnuPG to protect sensitive data as we currently do (via saltstack). > > What about an extra arg in configure.ac that would let us either specify the SECMEM_BUFFER_SIZE or set it with `--extra-large-secmem`? I'd be happy to provide a patch for that, of course. > > Thanks, > Matt Summers -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-enable-configurable-SECMEM_BUFFER_SIZE.patch Type: text/x-patch Size: 2068 bytes Desc: not available URL: From wk at gnupg.org Sat Oct 21 11:07:04 2017 From: wk at gnupg.org (Werner Koch) Date: Sat, 21 Oct 2017 11:07:04 +0200 Subject: Please Consider Increasing SECMEM_BUFFER_SIZE To 1048576 In-Reply-To: (Matthew Summers's message of "Fri, 20 Oct 2017 16:42:16 -0500") References: <768f49c6-e0b9-c63a-8104-9d51cf28fd60@suse.com> Message-ID: <87efpwhnt3.fsf@wheatstone.g10code.de> On Fri, 20 Oct 2017 23:42, matthew.summers at syapse.com said: > I would like to point out that this creates an issue on systems with the >> max locked memory size (ulimit -l) is limited to 64k: >> gpg: Warning: using insecure memory! >> mlock(0x7f5814308000, 262144) = -1 ENOMEM (Cannot allocate memory) >> Thus exposing private key material to being swapped out to permanent >> storage. I am not sure if a mere warning is sufficient here. dkg already explained the problem using mlock to avoid swapping/paging out memory. That mechanism likely did what it was expected do when I introduced it 20 years ago. Nowadays we should more care about hibernation [1] than about swapped memory with sensitive data. Swapping is anyway rare for running processes. An idle gpg-agent has only one sensitive memory area of 16 bytes which could - with some work - also be moved to the TPM or an NVRAM. The real solution, which will also protect other processes with sensitive data, is an encrypted swap space. Note also that increasing the secmem size is not anymore needed with current GnuPG versions. The secmem area is increased on demand (but this new memory areas are anyway not mlock-ed). The reason why we still have the secmem is to wipe out an allocated area with the call to free() and to, to a minor extend, to know whether we are working on sensitive data. Shalom-Salam, Werner [1] Do you call "gpgconf --reload gpg-agent" before you hibernate? -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dgouttegattat at incenp.org Sat Oct 21 13:41:53 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sat, 21 Oct 2017 12:41:53 +0100 Subject: pinentry-tqt for the trinity desktop (former KDE3/Qt3 code) In-Reply-To: References: <87fuaqjiqb.fsf@wheatstone.g10code.de> Message-ID: On 10/11/2017 06:46 PM, deloptes wrote: > I wonder if Damien could help with the autotools stuff. It would ease the > enormously process. I got a tentative patch which is working-for-me. It is too big (~ 140kb) to send on the mailing-list, so you can pull it from here: git://git.incenp.org/pinentry.git pinentry-tqt As suggested elsewhere in the discussion by Werner, pinentry-tqt is only built if explicitly requested with --enable-pinentry-tqt. Furthermore, if any Qt version is detected, pinentry-qt must be explicitly disabled (with --disable-pinentry-qt) to allow building the TQt pinentry. I have tested this patch on Slackware and Debian systems, with TQt version R14.0.4. Further testing, especially from TDE users, is welcome. ---------------------------------------------------------------- Damien Goutte-Gattat (1): tqt: Add a TQt-based pinentry. .gitignore | 2 + Makefile.am | 9 +- configure.ac | 44 +- tqt/Makefile.am | 60 ++ tqt/README.SecQ | 17 + tqt/main.cpp | 241 ++++++ tqt/pinentrydialog.cpp | 234 ++++++ tqt/pinentrydialog.h | 92 +++ tqt/secqinternal.cpp | 635 ++++++++++++++++ tqt/secqinternal_p.h | 140 ++++ tqt/secqlineedit.cpp | 1955 ++++++++++++++++++++++++++++++++++++++++++++++++ tqt/secqlineedit.h | 228 ++++++ tqt/secqstring.cpp | 939 +++++++++++++++++++++++ tqt/secqstring.h | 307 ++++++++ 14 files changed, 4901 insertions(+), 2 deletions(-) create mode 100644 tqt/Makefile.am create mode 100644 tqt/README.SecQ create mode 100644 tqt/main.cpp create mode 100644 tqt/pinentrydialog.cpp create mode 100644 tqt/pinentrydialog.h create mode 100644 tqt/secqinternal.cpp create mode 100644 tqt/secqinternal_p.h create mode 100644 tqt/secqlineedit.cpp create mode 100644 tqt/secqlineedit.h create mode 100644 tqt/secqstring.cpp create mode 100644 tqt/secqstring.h -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wlt-ml at o-sinc.com Sat Oct 21 16:34:15 2017 From: wlt-ml at o-sinc.com (William L. Thomson Jr.) Date: Sat, 21 Oct 2017 10:34:15 -0400 Subject: pinentry-tqt for the trinity desktop (former KDE3/Qt3 code) In-Reply-To: References: <87fuaqjiqb.fsf@wheatstone.g10code.de> Message-ID: On Sat, 21 Oct 2017 12:41:53 +0100 Damien Goutte-Gattat wrote: > On 10/11/2017 06:46 PM, deloptes wrote: > > I wonder if Damien could help with the autotools stuff. It would > > ease the enormously process. > > I got a tentative patch which is working-for-me. It is too big (~ > 140kb) to send on the mailing-list, so you can pull it from here: > > git://git.incenp.org/pinentry.git pinentry-tqt You can also add it to phabricator as a differential. That way devs can merge directly from there. You can also update the patch in phabricator as needed. Usually the preferred work flow to pulling patch. I did both, made patch available to public via repo, and added it to phabricator. Pretty sure only the one in phabricator was used. -- William L. Thomson Jr. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From deloptes at gmail.com Sat Oct 21 17:00:06 2017 From: deloptes at gmail.com (deloptes) Date: Sat, 21 Oct 2017 17:00:06 +0200 Subject: pinentry-tqt for the trinity desktop (former KDE3/Qt3 code) In-Reply-To: References: <87fuaqjiqb.fsf@wheatstone.g10code.de> Message-ID: Thank you Damien, really appreciate it. I'll be traveling next week, but the week after I might have time to test it and give feedback. I'll ask on TDE devel list if someone else is willing to test and give feed back. Thank you again Kind regards On Sat, Oct 21, 2017 at 1:41 PM, Damien Goutte-Gattat < dgouttegattat at incenp.org> wrote: > On 10/11/2017 06:46 PM, deloptes wrote: > >> I wonder if Damien could help with the autotools stuff. It would ease the >> enormously process. >> > > I got a tentative patch which is working-for-me. It is too big (~ 140kb) > to send on the mailing-list, so you can pull it from here: > > git://git.incenp.org/pinentry.git pinentry-tqt > > As suggested elsewhere in the discussion by Werner, pinentry-tqt is only > built if explicitly requested with --enable-pinentry-tqt. Furthermore, if > any Qt version is detected, pinentry-qt must be explicitly disabled (with > --disable-pinentry-qt) to allow building the TQt pinentry. > > I have tested this patch on Slackware and Debian systems, with TQt version > R14.0.4. Further testing, especially from TDE users, is welcome. > > ---------------------------------------------------------------- > Damien Goutte-Gattat (1): > tqt: Add a TQt-based pinentry. > > .gitignore | 2 + > Makefile.am | 9 +- > configure.ac | 44 +- > tqt/Makefile.am | 60 ++ > tqt/README.SecQ | 17 + > tqt/main.cpp | 241 ++++++ > tqt/pinentrydialog.cpp | 234 ++++++ > tqt/pinentrydialog.h | 92 +++ > tqt/secqinternal.cpp | 635 ++++++++++++++++ > tqt/secqinternal_p.h | 140 ++++ > tqt/secqlineedit.cpp | 1955 ++++++++++++++++++++++++++++++ > ++++++++++++++++++ > tqt/secqlineedit.h | 228 ++++++ > tqt/secqstring.cpp | 939 +++++++++++++++++++++++ > tqt/secqstring.h | 307 ++++++++ > 14 files changed, 4901 insertions(+), 2 deletions(-) > create mode 100644 tqt/Makefile.am > create mode 100644 tqt/README.SecQ > create mode 100644 tqt/main.cpp > create mode 100644 tqt/pinentrydialog.cpp > create mode 100644 tqt/pinentrydialog.h > create mode 100644 tqt/secqinternal.cpp > create mode 100644 tqt/secqinternal_p.h > create mode 100644 tqt/secqlineedit.cpp > create mode 100644 tqt/secqlineedit.h > create mode 100644 tqt/secqstring.cpp > create mode 100644 tqt/secqstring.h > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Sun Oct 22 14:54:52 2017 From: wk at gnupg.org (Werner Koch) Date: Sun, 22 Oct 2017 14:54:52 +0200 Subject: pinentry-tqt for the trinity desktop (former KDE3/Qt3 code) In-Reply-To: (William L. Thomson, Jr.'s message of "Sat, 21 Oct 2017 10:34:15 -0400") References: <87fuaqjiqb.fsf@wheatstone.g10code.de> Message-ID: <87inf7filf.fsf@wheatstone.g10code.de> On Sat, 21 Oct 2017 16:34, wlt-ml at o-sinc.com said: > You can also add it to phabricator as a differential. That way devs can > merge directly from there. You can also update the patch in phabricator > as needed. Usually the preferred work flow to pulling patch. FWIW, I try to avoid that Phrabicator thing because it requires me to use a pretty large, aehm, PHP command line tool along with online access while merging a patch. If someone knows a way to extract a proper GIT patch out of Phrabicator, please let me know. To me patches via mail are much easier to work with. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wlt-ml at o-sinc.com Sun Oct 22 18:20:54 2017 From: wlt-ml at o-sinc.com (William L. Thomson Jr.) Date: Sun, 22 Oct 2017 12:20:54 -0400 Subject: pinentry-tqt for the trinity desktop (former KDE3/Qt3 code) In-Reply-To: <87inf7filf.fsf@wheatstone.g10code.de> References: <87fuaqjiqb.fsf@wheatstone.g10code.de> <87inf7filf.fsf@wheatstone.g10code.de> Message-ID: On Sun, 22 Oct 2017 14:54:52 +0200 Werner Koch wrote: > On Sat, 21 Oct 2017 16:34, wlt-ml at o-sinc.com said: > > > You can also add it to phabricator as a differential. That way devs > > can merge directly from there. You can also update the patch in > > phabricator as needed. Usually the preferred work flow to pulling > > patch. > > FWIW, I try to avoid that Phrabicator thing because it requires me to > use a pretty large, aehm, PHP command line tool along with online > access while merging a patch. If someone knows a way to extract a > proper GIT patch out of Phrabicator, please let me know. To me > patches via mail are much easier to work with. That is good to know! I was not clear before and seemed the ones I added to phab via differential got reviews and feedback. At first I kept posting updates to list with URL link to git repo, direct patch. But those never seemed to get any comments. That was surely easier to provide than messing with phabricator. Maybe I should have send the actual patch to list vs link. If phabricator is not making it easier for the developer to merge. Then its pointless as its not convenient for either contributor or developer. Though that may improve in time. Seems its still pretty new, and does stuff like sending people emails of their own activity :) I am not familiar with phabricator, but seems it has some archanist tool. If that is what you were referring to had a large CLI command. Seemed fairly simple but I haven't used it so cannot say. https://secure.phabricator.com/book/phabricator/article/arcanist/ -- William L. Thomson Jr. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Oct 24 17:17:10 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 24 Oct 2017 17:17:10 +0200 Subject: DCO, was Re: Patch for T1644 In-Reply-To: (Rainer Perske's message of "Fri, 20 Oct 2017 16:51:11 +0200 (CEST)") References: Message-ID: <87h8uobmo9.fsf@wheatstone.g10code.de> Thanks. Salam-Shalom, 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: 227 bytes Desc: not available URL: From wk at gnupg.org Tue Oct 24 17:33:21 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 24 Oct 2017 17:33:21 +0200 Subject: DCO registry Message-ID: <87d15cblxa.fsf@wheatstone.g10code.de> Hi! We currently put the DCOs into the file AUTHORS of each project. Given that we maintain several branches it is not immediately clear where to look for a DCO (it is always in master). Thus I would like to remove them from the AUTHORS file and instead keep them only in the gnupg-doc repo (where web pages and other doc stuff lives), for example under gnupg-doc/misc/DCOs. Please speak up if you think that is a bad idea. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Tue Oct 24 21:16:34 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 24 Oct 2017 21:16:34 +0200 Subject: Patch for T1644 In-Reply-To: (Rainer Perske's message of "Fri, 20 Oct 2017 14:05:09 +0200 (CEST)") References: Message-ID: <874lqobbl9.fsf@wheatstone.g10code.de> Pushed. Tanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Oct 27 08:34:34 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 27 Oct 2017 02:34:34 -0400 Subject: DCO registry In-Reply-To: <87d15cblxa.fsf@wheatstone.g10code.de> References: <87d15cblxa.fsf@wheatstone.g10code.de> Message-ID: <87d159gkud.fsf@fifthhorseman.net> On Tue 2017-10-24 17:33:21 +0200, Werner Koch wrote: > We currently put the DCOs into the file AUTHORS of each project. Given > that we maintain several branches it is not immediately clear where to > look for a DCO (it is always in master). Thus I would like to remove > them from the AUTHORS file and instead keep them only in the gnupg-doc > repo (where web pages and other doc stuff lives), for example under > gnupg-doc/misc/DCOs. this sounds like it would make it even harder to locate a DCO. if i'm working on a specific project that is under sane revision control, and i questions about the contributors and their status, the master branch of the upstream repo is a natural place to look. if it goes in the gnupg-doc repo, then i have to figure out how to find it, clone a new repo, figure out which branch of *that* repo is relevant, etc. If you want to keep a synced copy in the gnupg-doc repo i think that's fine, but i'm not sure what we gain from moving it entirely to gnupg-doc (and removing it from the master branch). Why not just put a note in the file on all maintained branches that says "the current version of this registry of DCOs is on the master branch"? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From wk at gnupg.org Fri Oct 27 10:18:41 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Oct 2017 10:18:41 +0200 Subject: DCO registry In-Reply-To: <87d159gkud.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 27 Oct 2017 02:34:34 -0400") References: <87d15cblxa.fsf@wheatstone.g10code.de> <87d159gkud.fsf@fifthhorseman.net> Message-ID: <87wp3h57ha.fsf@wheatstone.g10code.de> On Fri, 27 Oct 2017 08:34, dkg at fifthhorseman.net said: > this sounds like it would make it even harder to locate a DCO. if i'm > working on a specific project that is under sane revision control, and i > questions about the contributors and their status, the master branch of Thanks for your opinion. So better no changes. > Why not just put a note in the file on all maintained branches that says > "the current version of this registry of DCOs is on the master branch"? 2.0 already has this The list of authors who signed the Developer's Certificate of Origin is kept in the GIT master branch's copy of this file. I need to copy that to 2.2. Thanks for the hint. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bernhard at intevation.de Fri Oct 27 16:06:55 2017 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 27 Oct 2017 16:06:55 +0200 Subject: GnuPG 2.2 on elder Debian & Ubuntu distros Message-ID: <201710271606.59244.bernhard@intevation.de> Hello! As a number of GNU distributions are still around and maintained, the questions comes up: How does someone get packages for GnuPG 2.2? Right now I focus on deb based systems: Debian Jessie, Stretch Ubuntu LTS 12.04, 14.06, 16.04 There is a difference in packaging as Jessie and Ubuntu LTS still have gnupg and gnupg2 while Stretch (and Ubuntu 17.04) already have done the jump to 2.1.x replacing GnuPG 1.4.x in the gnupg package. So how would a good packaging for these systems work? (Intevation has a potential customer that is interested in a packaging for Ubuntu 12.04 LTS for instance.) Is somebody already working on it? Build instructions for 2.2.1 could help other users as well. Here is one I've found for some Ubuntu versions: https://gist.github.com/vt0r/a2f8c0bcb1400131ff51 == potential advantages of GnuPG 2.2 * GnuPG 2.0.x is running out of support https://lists.gnupg.org/pipermail/gnupg-announce/2017q3/000413.html | the 2.0.x series which will reach end-of-life on 2017-12-31 * ECC support * (for some public agencies) GnuPG 2.2/Gpg4win aims for an approval to handle governmental documents that are classified 'restricted' ('VS-NUR F?R DEN DIENSTGEBRAUCH') by the German Federal Office for Information Security (BSI). https://wiki.gnupg.org/Gpg4vsnfd2015 Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer 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 gnupg-devel at spodhuis.org Fri Oct 27 18:24:45 2017 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Fri, 27 Oct 2017 12:24:45 -0400 Subject: GnuPG 2.2 on elder Debian & Ubuntu distros In-Reply-To: <201710271606.59244.bernhard@intevation.de> References: <201710271606.59244.bernhard@intevation.de> Message-ID: <20171027162445.GA17617@breadbox.private.spodhuis.org> On 2017-10-27 at 16:06 +0200, Bernhard Reiter wrote: > As a number of GNU distributions are still around and maintained, > the questions comes up: How does someone get packages > for GnuPG 2.2? > > Right now I focus on deb based systems: > > Debian Jessie, Stretch > Ubuntu LTS 12.04, 14.06, 16.04 Because the package repo verification uses PGP and other bits of system tooling have certain expectations of GnuPG as-installed, I have taken the stance of "leave the system installs alone". Instead, I use `/opt/gnupg` and I install everything under there. I then use Vagrant to build for various different OS/distribution releases. Thus at I have packages for 4 of the 5 releases you mention (amd64-only). I install the `optgnupg-gnupg` package and I end up with: ii optgnupg-gmp 6.1.2-pt2 ii optgnupg-gnupg 2.2.1-pt1 ii optgnupg-gnutls 3.5.15-pt2 ii optgnupg-libassuan 2.4.3-pt1 ii optgnupg-libgcrypt 1.8.1-pt1 ii optgnupg-libgpg-error 1.27-pt1 ii optgnupg-libksba 1.3.5-pt1 ii optgnupg-nettle 3.3-pt1 ii optgnupg-npth 1.5-pt1 ii optgnupg-pinentry 1.0.0-pt3 It's then just a matter of using `$PATH` for users so that I can use a capable modern GnuPG for all my stuff, while leaving the system tooling alone. I'm using `aptly` for managing the apt repo setup. There's a `swdb.lst` file (and associated signature) which tells you the current versions of all the GnuPG software. I have an "X depends on Y" config file which I can feed into tsort(1) which currently produces this package dependency ordering: libgpg-error npth gmp libassuan libksba libgcrypt nettle pinentry gnutls gnupg22 To help you get started, I've attached two JSON files which I use as configuration for the builds, reading them should help see how things fit together and what options are needed. -Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: configures.json Type: application/json Size: 3089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: versions.json Type: application/json Size: 748 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 996 bytes Desc: Digital signature URL: From dkg at fifthhorseman.net Fri Oct 27 21:06:32 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 27 Oct 2017 15:06:32 -0400 Subject: releasing yat2m with gpg-error? Message-ID: <8760b0h0lj.fsf@fifthhorseman.net> I note that the master branch of gpg-error intends to ship yat2m. I welcome that decision :) For debian, i'll likely ship it as /usr/bin/yat2m in the libgpg-error-dev package. But it looks like this has been pending (and gpg-error has been idle) for several months. Any plans for a point release so that the other packages can rely on it during build? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From wk at gnupg.org Sat Oct 28 00:03:49 2017 From: wk at gnupg.org (Werner Koch) Date: Sat, 28 Oct 2017 00:03:49 +0200 Subject: releasing yat2m with gpg-error? In-Reply-To: <8760b0h0lj.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 27 Oct 2017 15:06:32 -0400") References: <8760b0h0lj.fsf@fifthhorseman.net> Message-ID: <87efpo2qpm.fsf@wheatstone.g10code.de> On Fri, 27 Oct 2017 21:06, dkg at fifthhorseman.net said: > But it looks like this has been pending (and gpg-error has been idle) > for several months. Any plans for a point release so that the other > packages can rely on it during build? Actually I started to work again on libgpg-error. for th next release I plan to add the exec/spawn functions from gnupg and the logging fucntions to libgpg-error. We just have too many similar functions in all modules. By moving them to libgpg-error we can eventually remove them from the other packages. Right now I am preparing a GnuPG 2.2.2 - some recent fixes need some more testing; I hope to get it out next week. The I will turn back to libgpg-error. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Sat Oct 28 00:28:21 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 27 Oct 2017 18:28:21 -0400 Subject: GnuPG 2.2 on elder Debian & Ubuntu distros In-Reply-To: <201710271606.59244.bernhard@intevation.de> References: <201710271606.59244.bernhard@intevation.de> Message-ID: <87po98fcoq.fsf@fifthhorseman.net> On Fri 2017-10-27 16:06:55 +0200, Bernhard Reiter wrote: > There is a difference in packaging as > Jessie and Ubuntu LTS still have gnupg and gnupg2 > while > Stretch (and Ubuntu 17.04) already have done the jump to 2.1.x > replacing GnuPG 1.4.x in the gnupg package. I've looked into this for jessie, and i'm sad to say that there is enough system integration work to make me want to spend my time elsewhere. A backport to stretch should be relatively easy to pull off. The Jessie problems aren't necessarily problems with gpg itself -- it's the ecosystem that has grown up around gpg, much of which is written as though whatever idiosyncracies and corner cases the author encountered with some particular version of gpg was exactly the way gpg should behave, forever. So introducing 2.1 or 2.2 to jessie results in breakage of a number of other packages (see the litany of Breaks: at [0] for what is probably not even a full set; now think about all the other packages which depend on the packages listed as broken). In stretch, all of that has been cleaned up, which is why the backport should be relatively easy. And in future versions of debian, we can hopefully keep the cruft down by providing upstream-maintained language bindings that are more attractive than the weird side-projects that seem to have sprung up around trying to automate a complex, multifaceted tool with long history of configuration choices. It is helpful to have GnuPG upstream be really clear about what is an expected stable machine-readable interface (and about what is *not* expected to be stable for mechanical interaction). So any contributions that help to clarifying the formal API (even a "best minimal subset" of it) would be a great positive contribution. Sorry to not have better news for your Jessie and Ubuntu LTS systems :( I'd love to be wrong! --dkg [0] https://anonscm.debian.org/git/pkg-gnupg/gnupg2.git/tree/debian/control#n259 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From deloptes at gmail.com Sat Oct 28 02:19:29 2017 From: deloptes at gmail.com (deloptes) Date: Sat, 28 Oct 2017 02:19:29 +0200 Subject: pinentry-tqt for the trinity desktop (former KDE3/Qt3 code) In-Reply-To: References: <87fuaqjiqb.fsf@wheatstone.g10code.de> Message-ID: Hi Damien, I'm sorry for bothering, but I had 5min free and cloned pinentry-tqt - I did not see tqt in this location. git clone git://git.incenp.org/pinentry.git pinentry-tqt ls pinentry-tqt/tqt ls: cannot access 'pinentry-tqt/tqt': No such file or directory I surely missed something. regards On Sat, Oct 21, 2017 at 1:41 PM, Damien Goutte-Gattat < dgouttegattat at incenp.org> wrote: > On 10/11/2017 06:46 PM, deloptes wrote: > >> I wonder if Damien could help with the autotools stuff. It would ease the >> enormously process. >> > > I got a tentative patch which is working-for-me. It is too big (~ 140kb) > to send on the mailing-list, so you can pull it from here: > > git://git.incenp.org/pinentry.git pinentry-tqt > > As suggested elsewhere in the discussion by Werner, pinentry-tqt is only > built if explicitly requested with --enable-pinentry-tqt. Furthermore, if > any Qt version is detected, pinentry-qt must be explicitly disabled (with > --disable-pinentry-qt) to allow building the TQt pinentry. > > I have tested this patch on Slackware and Debian systems, with TQt version > R14.0.4. Further testing, especially from TDE users, is welcome. > > ---------------------------------------------------------------- > Damien Goutte-Gattat (1): > tqt: Add a TQt-based pinentry. > > .gitignore | 2 + > Makefile.am | 9 +- > configure.ac | 44 +- > tqt/Makefile.am | 60 ++ > tqt/README.SecQ | 17 + > tqt/main.cpp | 241 ++++++ > tqt/pinentrydialog.cpp | 234 ++++++ > tqt/pinentrydialog.h | 92 +++ > tqt/secqinternal.cpp | 635 ++++++++++++++++ > tqt/secqinternal_p.h | 140 ++++ > tqt/secqlineedit.cpp | 1955 ++++++++++++++++++++++++++++++ > ++++++++++++++++++ > tqt/secqlineedit.h | 228 ++++++ > tqt/secqstring.cpp | 939 +++++++++++++++++++++++ > tqt/secqstring.h | 307 ++++++++ > 14 files changed, 4901 insertions(+), 2 deletions(-) > create mode 100644 tqt/Makefile.am > create mode 100644 tqt/README.SecQ > create mode 100644 tqt/main.cpp > create mode 100644 tqt/pinentrydialog.cpp > create mode 100644 tqt/pinentrydialog.h > create mode 100644 tqt/secqinternal.cpp > create mode 100644 tqt/secqinternal_p.h > create mode 100644 tqt/secqlineedit.cpp > create mode 100644 tqt/secqlineedit.h > create mode 100644 tqt/secqstring.cpp > create mode 100644 tqt/secqstring.h > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgouttegattat at incenp.org Sat Oct 28 11:01:15 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sat, 28 Oct 2017 10:01:15 +0100 Subject: pinentry-tqt for the trinity desktop (former KDE3/Qt3 code) In-Reply-To: References: <87fuaqjiqb.fsf@wheatstone.g10code.de> Message-ID: On 10/28/2017 01:19 AM, deloptes wrote: > Hi Damien, > I'm sorry for bothering, but I had 5min free and cloned pinentry-tqt - I > did not see tqt in this location. > git clone git://git.incenp.org/pinentry.git pinentry-tqt > ls pinentry-tqt/tqt > ls: cannot access 'pinentry-tqt/tqt': No such file or directory > > I surely missed something. The TQt code is in the "pinentry-tqt" branch. Here, you cloned my repo in the pinentry-tqt folder, but the repo's current branch is still "master". You need to switch to the "pinentry-tqt" branch first. $ git clone git://git.incenp.org/pinentry.git pinentry-tqt $ cd pinentry-tqt $ git checkout pinentry-tqt When I said "pull", I was expecting you to actually run git pull git://git.incenp.org/pinentry.git pinentry-tqt from an already existing copy of the upstream pinentry repo. That command would have had the effect of merging the pinentry-tqt branch of the remote repo to your current local branch. (In other words, the two following commands have similar syntax but completely different effects: $ git clone git://git.incenp.org/pinentry.git pinentry-tqt $ git pull git://git.incenp.org/pinentry.git pinentry-tqt The first one creates a copy of the remote repo in the pinentry-tqt directory. The second one fetches and merges the pinentry-tqt branch from the remote repo into the current repo.) Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Sat Oct 28 14:38:55 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 28 Oct 2017 14:38:55 +0200 Subject: [PATCH] default-preference-list: prefer SHA512. In-Reply-To: <87376snsrr.fsf@wheatstone.g10code.de> References: <87wp50voca.fsf@fifthhorseman.net> <20170928123226.28189-1-dkg@fifthhorseman.net> <87y3okjpx8.fsf@fifthhorseman.net> <87376snsrr.fsf@wheatstone.g10code.de> Message-ID: <87vaize9b4.fsf@fifthhorseman.net> On Mon 2017-10-09 19:19:20 +0200, Werner Koch wrote: > On Mon, 9 Oct 2017 17:34, dkg at fifthhorseman.net said: > >> Has anyone had time to review this patch? I'd like to get this merged > > Sorry I had not yet the time to review it. Please have some patience. ping again! it would be great if this could make it into 2.2.2 :) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From deloptes at gmail.com Sun Oct 29 06:47:54 2017 From: deloptes at gmail.com (deloptes) Date: Sun, 29 Oct 2017 06:47:54 +0100 Subject: pinentry-tqt for the trinity desktop (former KDE3/Qt3 code) In-Reply-To: References: <87fuaqjiqb.fsf@wheatstone.g10code.de> Message-ID: Thank you for the clarification. I was using the debian source as base for my work. The above made tqt visible, but when trying to compile (create debian packages on stretch) configure: Pinentry v1.0.1-beta34 has been configured as follows: Revision: 4ebfa0b (20159) Platform: x86_64-pc-linux-gnu Curses Pinentry ..: no TTY Pinentry .....: yes Emacs Pinentry ...: no GTK+-2 Pinentry ..: no GNOME 3 Pinentry .: no Qt Pinentry ......: no TQt Pinentry .....: yes W32 Pinentry .....: no FLTK Pinentry ....: no Fallback to Curses: no Emacs integration : no libsecret ........: no Default Pinentry .: pinentry-tty 1. I get following error: In file included from ../../tqt/secqlineedit.cpp:1955:0: ./secqlineedit.moc: In member function 'virtual bool SecTQLineEdit::tqt_property(int, int, TQVariant*)': ./secqlineedit.moc:355:32: error: 'class SecTQLineEdit' has no member named 'hasMarkedText'; did you mean 'hasSelectedText'? case 1: *v = TQVariant( this->hasMarkedText(), 0 ); break; ^~~~~~~~~~~~~ Makefile:486: recipe for target 'secqlineedit.o' failed => I see #include "secqlineedit.moc" was introduced --- pinentry-0.9.7-trinity/tqt/secqlineedit.cpp 2017-08-19 21:42:59.326843222 +0000 +++ pinentry-tqt/tqt/secqlineedit.cpp 2017-10-28 21:11:55.000000000 +0000 @@ -1951,3 +1951,5 @@ textDirty = TRUE; } } + +#include "secqlineedit.moc" => removing hasMarkedText (as it is flagged obsolete) solves the problem 2. Compile still failed with: rm -rf $backupdir; exit $rc ../../doc/pinentry.texi:5: @include: could not find version.texi ../../doc/pinentry.texi:63: warning: undefined flag: EDITION ../../doc/pinentry.texi:63: warning: undefined flag: UPDATED ../../doc/pinentry.texi:64: warning: undefined flag: VERSION ../../doc/pinentry.texi:79: warning: undefined flag: VERSION ../../doc/pinentry.texi:80: warning: undefined flag: UPDATED Makefile:402: recipe for target '../../doc/pinentry.info' failed make[4]: *** [../../doc/pinentry.info] Error 1 => creating version.texi in doc solves the problem and packages are build correctly 3. How we can set pinentry-tqt to default? How can be above issues approached? I did not install and tested the packages. thanks and regards On Sat, Oct 28, 2017 at 11:01 AM, Damien Goutte-Gattat < dgouttegattat at incenp.org> wrote: > On 10/28/2017 01:19 AM, deloptes wrote: > >> Hi Damien, >> I'm sorry for bothering, but I had 5min free and cloned pinentry-tqt - I >> did not see tqt in this location. >> git clone git://git.incenp.org/pinentry.git pinentry-tqt >> ls pinentry-tqt/tqt >> ls: cannot access 'pinentry-tqt/tqt': No such file or directory >> >> I surely missed something. >> > > The TQt code is in the "pinentry-tqt" branch. Here, you cloned my repo in > the pinentry-tqt folder, but the repo's current branch is still "master". > You need to switch to the "pinentry-tqt" branch first. > > $ git clone git://git.incenp.org/pinentry.git pinentry-tqt > $ cd pinentry-tqt > $ git checkout pinentry-tqt > > When I said "pull", I was expecting you to actually run > > git pull git://git.incenp.org/pinentry.git pinentry-tqt > > from an already existing copy of the upstream pinentry repo. That command > would have had the effect of merging the pinentry-tqt branch > of the remote repo to your current local branch. > > (In other words, the two following commands have similar syntax but > completely different effects: > > $ git clone git://git.incenp.org/pinentry.git pinentry-tqt > $ git pull git://git.incenp.org/pinentry.git pinentry-tqt > > The first one creates a copy of the remote repo in the pinentry-tqt > directory. > > The second one fetches and merges the pinentry-tqt branch from the remote > repo into the current repo.) > > Damien > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgouttegattat at incenp.org Sun Oct 29 11:43:15 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 29 Oct 2017 10:43:15 +0000 Subject: pinentry-tqt for the trinity desktop (former KDE3/Qt3 code) In-Reply-To: References: <87fuaqjiqb.fsf@wheatstone.g10code.de> Message-ID: On 10/29/2017 05:47 AM, deloptes wrote: > 1. I get following error: Strange, I don't get that error. Maybe we're using a slightly different version of TQt3... > => removing hasMarkedText (as it is flagged obsolete) solves the problem OK. > > 2. Compile still failed with: > [...] > => creating version.texi in doc solves the problem and packages are build > correctly Are you building directly from a Git checkout? Then you need to call the configure script with --enable-maintainer-mode. And you should also call the the autogen.sh script before that. To test building a package I would suggest creating first a proper tarball: $ ./autogen.sh $ ./configure --enable-maintainer-mode $ make $ make distcheck This will create a tarball that you should be able to use in your packaging script as if it came directly from GnuPG upstream. > 3. How we can set pinentry-tqt to default? As far as I know the current build system has no option to explicitly set the default pinentry. The default pinentry is automatically selected among the enabled pinentries, using a hardcoded preference order. Since we're adding a new pinentry, I have put it at the end of the preference list, so it will never be selected as the default unless all other pinentries are disabled. I don't want to change that without prior approval from other pinentry developers. Making a pinentry the default simply means installing a symlink from $prefix/bin/pinentry to the selected pinentry. So if you're building a package for TDE, where it makes perfect sense to use pinentry-tqt as the default, I would suggest that in your packaging script, you remove the symlink created by pinentry's "make install" and replace it by your own symlink to pinentry-tqt. Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dgouttegattat at incenp.org Sun Oct 29 12:19:39 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 29 Oct 2017 11:19:39 +0000 Subject: [PINENTRY PATCH] fltk: Fix compilation and distcheck errors. Message-ID: <20171029111939.21497-1-dgouttegattat@incenp.org> * fltk/Makefile.am (AM_CXXFLAGS): Add -std=c++11 flag. (pinentry_fltk_SOURCES): Add header files. (EXTRA_DIST): Add icon files. * .gitignore: Ignore autoconf-generated files in fltk/. -- The FLTK pinentry requires C++11 due to the use of std::unique_ptr. Signed-off-by: Damien Goutte-Gattat --- .gitignore | 2 ++ fltk/Makefile.am | 7 ++++++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/.gitignore b/.gitignore index e9d3966..8d709c1 100644 --- a/.gitignore +++ b/.gitignore @@ -20,6 +20,8 @@ doc/Makefile doc/pinentry.info doc/stamp-vti doc/version.texi +fltk/Makefile.in +fltk/Makefile gtk+-2/Makefile.in gtk+-2/Makefile gnome3/Makefile.in diff --git a/fltk/Makefile.am b/fltk/Makefile.am index 2c9338f..54209f9 100644 --- a/fltk/Makefile.am +++ b/fltk/Makefile.am @@ -11,6 +11,11 @@ libcurses = endif AM_CPPFLAGS = $(COMMON_CFLAGS) $(FLTKCXXFLAGS) $(ncurses_include) -I$(top_srcdir)/secmem -I$(top_srcdir)/pinentry +AM_CXXFLAGS = -std=c++11 LDADD = ../pinentry/libpinentry.a ../secmem/libsecmem.a $(COMMON_LIBS) $(LIBCAP) $(FLTKLIBS) $(libcurses) -pinentry_fltk_SOURCES = main.cxx pinwindow.cxx passwindow.cxx qualitypasswindow.cxx +pinentry_fltk_SOURCES = main.cxx pinwindow.cxx pinwindow.h \ + passwindow.cxx passwindow.h \ + qualitypasswindow.cxx qualitypasswindow.h + +EXTRA_DIST = encrypt.xpm icon.xpm -- 2.14.1 From deloptes at gmail.com Sun Oct 29 12:41:46 2017 From: deloptes at gmail.com (deloptes) Date: Sun, 29 Oct 2017 12:41:46 +0100 Subject: pinentry-tqt for the trinity desktop (former KDE3/Qt3 code) In-Reply-To: References: <87fuaqjiqb.fsf@wheatstone.g10code.de> Message-ID: On Sun, Oct 29, 2017 at 11:43 AM, Damien Goutte-Gattat < dgouttegattat at incenp.org> wrote: > On 10/29/2017 05:47 AM, deloptes wrote: > >> 1. I get following error: >> > > Strange, I don't get that error. Maybe we're using a slightly different > version of TQt3... > > => removing hasMarkedText (as it is flagged obsolete) solves the problem >> > > OK. > > >> 2. Compile still failed with: > [...] >> => creating version.texi in doc solves the problem and packages are build >> correctly >> > > Are you building directly from a Git checkout? Then you need to call the > configure script with --enable-maintainer-mode. And you should also call > the the autogen.sh script before that. > > To test building a package I would suggest creating first a proper tarball: > > $ ./autogen.sh > $ ./configure --enable-maintainer-mode > $ make > $ make distcheck > Thanks for the mainainer-mode - this solved the problem. I indeed build from the git directory by running "debuild -b -uc -us". The autogen.sh is invoked by debuild automatically. > > This will create a tarball that you should be able to use in your > packaging script as if it came directly from GnuPG upstream. > > > 3. How we can set pinentry-tqt to default? >> > > As far as I know the current build system has no option to explicitly set > the default pinentry. The default pinentry is automatically selected among > the enabled pinentries, using a hardcoded preference order. > > Since we're adding a new pinentry, I have put it at the end of the > preference list, so it will never be selected as the default unless all > other pinentries are disabled. I don't want to change that without prior > approval from other pinentry developers. > > Making a pinentry the default simply means installing a symlink from > $prefix/bin/pinentry to the selected pinentry. So if you're building a > package for TDE, where it makes perfect sense to use pinentry-tqt as the > default, I would suggest that in your packaging script, you remove the > symlink created by pinentry's "make install" and replace it by your own > symlink to pinentry-tqt. > > > Ok, thanks this explains why pinentry-tty is marked default by the configure script. I'll need to adjust this and that in the debian directory and I think I'll give it a try later and report back on how it works. Cool Damien, thank you very much for the help. regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Sun Oct 29 13:07:03 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 29 Oct 2017 13:07:03 +0100 Subject: pinentry-tqt for the trinity desktop (former KDE3/Qt3 code) In-Reply-To: References: <87fuaqjiqb.fsf@wheatstone.g10code.de> Message-ID: On 29/10/17 11:43, Damien Goutte-Gattat wrote: > I would suggest that in your packaging script, you remove the > symlink created by pinentry's "make install" and replace it by your own > symlink to pinentry-tqt. In Debian, the alternatives system is used to configure the default pinentry: $ ll /usr/bin/pinentry /etc/alternatives/pinentry lrwxrwxrwx 1 root root 23 Jul 16 20:18 /etc/alternatives/pinentry -> /usr/bin/pinentry-gtk-2 lrwxrwxrwx 1 root root 26 Jan 11 2017 /usr/bin/pinentry -> /etc/alternatives/pinentry And there's also pinentry-x11: $ ll /usr/bin/pinentry-x11 /etc/alternatives/pinentry-x11 lrwxrwxrwx 1 root root 23 Jul 16 20:18 /etc/alternatives/pinentry-x11 -> /usr/bin/pinentry-gtk-2 lrwxrwxrwx 1 root root 30 Jan 11 2017 /usr/bin/pinentry-x11 -> /etc/alternatives/pinentry-x11 HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From deloptes at gmail.com Sun Oct 29 20:20:54 2017 From: deloptes at gmail.com (deloptes) Date: Sun, 29 Oct 2017 20:20:54 +0100 Subject: pinentry-tqt for the trinity desktop (former KDE3/Qt3 code) In-Reply-To: References: <87fuaqjiqb.fsf@wheatstone.g10code.de> Message-ID: Hi and thank you all, I just performed a basic functional test and it seems to be working just fine. I am not authorized to speak in the name of the TDE community, but I guess many people will be happy to see this part of the official gnupg code ( as there were often questions regarding native pinentry app). @Peter, thanks, I know the alternative system would provide the link to the binary. I'll handle the debian scripts for TDE next. There is more than this to take care of in this context. regards On Sun, Oct 29, 2017 at 1:07 PM, Peter Lebbing wrote: > On 29/10/17 11:43, Damien Goutte-Gattat wrote: > > I would suggest that in your packaging script, you remove the > > symlink created by pinentry's "make install" and replace it by your own > > symlink to pinentry-tqt. > > In Debian, the alternatives system is used to configure the default > pinentry: > > $ ll /usr/bin/pinentry /etc/alternatives/pinentry > lrwxrwxrwx 1 root root 23 Jul 16 20:18 /etc/alternatives/pinentry -> > /usr/bin/pinentry-gtk-2 > lrwxrwxrwx 1 root root 26 Jan 11 2017 /usr/bin/pinentry -> > /etc/alternatives/pinentry > > And there's also pinentry-x11: > > $ ll /usr/bin/pinentry-x11 /etc/alternatives/pinentry-x11 > lrwxrwxrwx 1 root root 23 Jul 16 20:18 /etc/alternatives/pinentry-x11 -> > /usr/bin/pinentry-gtk-2 > lrwxrwxrwx 1 root root 30 Jan 11 2017 /usr/bin/pinentry-x11 -> > /etc/alternatives/pinentry-x11 > > HTH, > > Peter. > > -- > I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. > You can send me encrypted mail if you want some privacy. > My key is available at > > -------------- next part -------------- An HTML attachment was scrubbed... URL: