From alon.barlev at gmail.com Sun Apr 2 01:29:52 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sun, 2 Apr 2017 02:29:52 +0300 Subject: [PATCH GPGME] python: Generate files into build directory Message-ID: <20170401232952.26151-1-alon.barlev@gmail.com> * lang/python/setup.py.in: Generate files within BuildExtFirstHack adjust build flags at this point instead of global. * lang/python/Makefile.am: Remove logic of separate source directory per python version in favor of build directory. * lang/python/tests/run-tests.py: Adjust build directory location. -- Generate files into build directory, leaving the source directory clean. Use the same source directory for multiple python version build. Result of 'prepare' target is a standard distutil layout that can be used easily by downstream to build all python targets in-place. Signed-off-by: Alon Bar-Lev --- lang/python/Makefile.am | 79 +++++++++++++++--------------------------- lang/python/setup.py.in | 48 +++++++++++++++++++------ lang/python/tests/run-tests.py | 1 - 3 files changed, 64 insertions(+), 64 deletions(-) diff --git a/lang/python/Makefile.am b/lang/python/Makefile.am index a18a014..b9145f5 100644 --- a/lang/python/Makefile.am +++ b/lang/python/Makefile.am @@ -27,70 +27,45 @@ EXTRA_DIST = \ SUBDIRS = . tests -COPY_FILES = \ - $(srcdir)/gpgme.i \ - $(srcdir)/README \ - $(srcdir)/MANIFEST.in \ - $(srcdir)/gpgme-h-clean.py \ - $(srcdir)/examples \ - $(srcdir)/helpers.c $(srcdir)/helpers.h $(srcdir)/private.h - -COPY_FILES_GPG = \ - $(srcdir)/gpg/callbacks.py \ - $(srcdir)/gpg/constants \ - $(srcdir)/gpg/core.py \ - $(srcdir)/gpg/errors.py \ - $(srcdir)/gpg/__init__.py \ - $(srcdir)/gpg/results.py \ - $(srcdir)/gpg/util.py - .PHONY: prepare -prepare: - test -n "$(PREPAREDIR)" - $(MKDIR_P) "$(PREPAREDIR)/gpg" - cp -R $(COPY_FILES) "$(PREPAREDIR)" - cp setup.py "$(PREPAREDIR)" - cp gpg/version.py "$(PREPAREDIR)/gpg" - ln -sf "$(abs_top_srcdir)/src/data.h" "$(PREPAREDIR)" - ln -sf "$(abs_top_builddir)/config.h" "$(PREPAREDIR)" - cp -R $(COPY_FILES_GPG) "$(PREPAREDIR)/gpg" +prepare: copystamp # For VPATH builds we need to copy some files because Python's # distutils are not VPATH-aware. -copystamp: $(COPY_FILES) $(COPY_FILES_GPG) - set -e ; for VERSION in $(PYTHON_VERSIONS); do \ - $(MAKE) PREPAREDIR=python$${VERSION}-gpg prepare; \ - done +copystamp: + ln -sf "$(abs_top_srcdir)/src/data.h" . + ln -sf "$(abs_top_builddir)/config.h" . touch $@ all-local: copystamp set -e ; set $(PYTHONS); for VERSION in $(PYTHON_VERSIONS); do \ PYTHON="$$1" ; shift ; \ - cd python$${VERSION}-gpg && \ CFLAGS="$(CFLAGS)" \ abs_top_builddir="$(abs_top_builddir)" \ - $$PYTHON setup.py build --verbose ; \ - cd .. ; \ + $$PYTHON setup.py build --verbose --build-base=python$${VERSION}-gpg ; \ done -python$(PYTHON_VERSION)-gpg/dist/gpg-$(VERSION).tar.gz \ python$(PYTHON_VERSION)-gpg/dist/gpg-$(VERSION).tar.gz.asc: copystamp - cd python$(PYTHON_VERSION)-gpg && \ + $(MKDIR_P) python$(PYTHON_VERSION)-gpg-dist CFLAGS="$(CFLAGS)" \ abs_top_builddir="$(abs_top_builddir)" \ - $(PYTHON) setup.py sdist --verbose - gpg2 --detach-sign --armor python$(PYTHON_VERSION)-gpg/dist/gpg-$(VERSION).tar.gz + $(PYTHON) setup.py sdist --verbose --dist-dir=python$(PYTHON_VERSION)-gpg-dist \ + --manifest=python$(PYTHON_VERSION)-gpg-dist/MANIFEST + gpg2 --detach-sign --armor python$(PYTHON_VERSION)-gpg-dist/gpg-$(VERSION).tar.gz .PHONY: sdist -sdist: python$(PYTHON_VERSION)-gpg/dist/gpg-$(VERSION).tar.gz \ - python$(PYTHON_VERSION)-gpg/dist/gpg-$(VERSION).tar.gz.asc +sdist: python$(PYTHON_VERSION)-gpg/dist/gpg-$(VERSION).tar.gz.asc .PHONY: upload -upload: python$(PYTHON_VERSION)-gpg/dist/gpg-$(VERSION).tar.gz \ - python$(PYTHON_VERSION)-gpg/dist/gpg-$(VERSION).tar.gz.asc +upload: python$(PYTHON_VERSION)-gpg-dist/gpg-$(VERSION).tar.gz \ + python$(PYTHON_VERSION)-gpg-dist/gpg-$(VERSION).tar.gz.asc twine upload $^ -CLEANFILES = copystamp +CLEANFILES = copystamp \ + config.h \ + data.h \ + files.txt \ + install_files.txt # Remove the rest. # @@ -104,22 +79,22 @@ clean-local: done install-exec-local: - rm -f install_files.txt set -e ; set $(PYTHONS); for VERSION in $(PYTHON_VERSIONS); do \ PYTHON="$$1" ; shift ; \ - cd python$${VERSION}-gpg ; \ abs_top_builddir="$(abs_top_builddir)" \ - $$PYTHON setup.py install \ - --prefix $(DESTDIR)$(prefix) \ + $$PYTHON setup.py \ + build \ + --build-base=python$${VERSION}-gpg \ + install \ + --prefix "$(DESTDIR)$(prefix)" \ --record files.txt \ --verbose ; \ - cat files.txt >> ../install_files.txt ; \ + cat files.txt >> install_files.txt ; \ rm files.txt ; \ - cd .. ; \ done - $(MKDIR_P) $(DESTDIR)$(pythondir)/gpg - mv install_files.txt $(DESTDIR)$(pythondir)/gpg + $(MKDIR_P) "$(DESTDIR)$(pythondir)/gpg" + mv install_files.txt "$(DESTDIR)$(pythondir)/gpg" uninstall-local: - xargs <$(DESTDIR)$(pythondir)/gpg/install_files.txt -- rm -rf -- - rm -rf -- $(DESTDIR)$(pythondir)/gpg + xargs < "$(DESTDIR)$(pythondir)/gpg/install_files.txt" -- rm -rf -- + rm -rf -- "$(DESTDIR)$(pythondir)/gpg" diff --git a/lang/python/setup.py.in b/lang/python/setup.py.in index 8ddbf27..6692de6 100755 --- a/lang/python/setup.py.in +++ b/lang/python/setup.py.in @@ -21,6 +21,7 @@ from distutils.core import setup, Extension import os, os.path, sys import glob +import shutil import subprocess # Out-of-tree build of the gpg bindings. @@ -89,14 +90,6 @@ if not os.path.exists(gpg_error_h): glob.glob(os.path.join(gpg_error_prefix, "include", "*", "gpg-error.h"))[0] -print("Building python gpg module using {} and {}.".format(gpgme_h, gpg_error_h)) - -# Cleanup gpgme.h from deprecated functions and typedefs. -subprocess.check_call([sys.executable, "gpgme-h-clean.py", gpgme_h], - stdout=open("gpgme.h", "w")) -subprocess.check_call([sys.executable, "gpgme-h-clean.py", gpg_error_h], - stdout=open("errors.i", "w")) - define_macros = [] libs = getconfig('libs') @@ -149,14 +142,47 @@ if uname_s.startswith("MINGW32"): # http://stackoverflow.com/questions/12491328/python-distutils-not-include-the-swig-generated-module from distutils.command.build import build class BuildExtFirstHack(build): + + def _generate(self): + print("Building python gpg module using {} and {}.".format(gpgme_h, gpg_error_h)) + + # Cleanup gpgme.h from deprecated functions and typedefs. + # Keep timestamp to avoid rebuild + if not os.path.exists(self.build_base): + os.makedirs(self.build_base) + + for src, dst in ( + (gpgme_h, os.path.join(self.build_base, "gpgme.h")), + (gpg_error_h, os.path.join(self.build_base, "errors.i")) + ): + subprocess.check_call([sys.executable, "gpgme-h-clean.py", src], + stdout=open(dst, "w")) + shutil.copystat(src, dst) + + # Copy due to http://bugs.python.org/issue2624 + # Avoid creating in srcdir + shutil.copy2("gpgme.i", self.build_base) + def run(self): + self._generate() + + # Append generated files via build_base + if not os.path.exists(os.path.join(self.build_lib, "gpg")): + os.makedirs(os.path.join(self.build_lib, "gpg")) + + swig_sources.append(os.path.join(self.build_base, 'gpgme.i')) + swig_opts.extend(['-I' + self.build_base, '-outdir', os.path.join(self.build_lib, 'gpg')]) + include_dirs.append(self.build_base) + self.run_command('build_ext') build.run(self) py3 = [] if sys.version_info.major < 3 else ['-py3'] -swige = Extension("gpg._gpgme", ["gpgme.i", "helpers.c"], - swig_opts = ['-threads', - '-outdir', 'gpg'] + py3 + extra_swig_opts, +swig_sources = ['helpers.c'] +swig_opts = ['-threads'] + py3 + extra_swig_opts +swige = Extension("gpg._gpgme", + sources = swig_sources, + swig_opts = swig_opts, include_dirs = include_dirs, define_macros = define_macros, library_dirs = library_dirs, diff --git a/lang/python/tests/run-tests.py b/lang/python/tests/run-tests.py index 9e061d8..9e2fb78 100644 --- a/lang/python/tests/run-tests.py +++ b/lang/python/tests/run-tests.py @@ -71,7 +71,6 @@ for interpreter in args.interpreters: pattern = os.path.join(args.builddir, "..", "python{0}-gpg".format(version), - "build", "lib*"+version) builddirs = glob.glob(pattern) if len(builddirs) == 0: -- 2.10.2 From alon.barlev at gmail.com Sun Apr 2 01:32:40 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sun, 2 Apr 2017 02:32:40 +0300 Subject: [PATCH GPGME] python: build: reinstate prepare target In-Reply-To: References: <20170328185559.2109-1-alon.barlev@gmail.com> <87vaqsla6j.fsf@europa.jade-hamburg.de> Message-ID: On 29 March 2017 at 12:18, Alon Bar-Lev wrote: > On 29 March 2017 at 12:11, Justus Winter wrote: >> >> Alon Bar-Lev writes: >> >> > Please consider to avoid. >> >> We are a free software project. Please consider to submit a patch. > > I was hoping we first agree that this is to be fixed so that the > effort will not be wasted. I have not gotten a response, however, I implemented a solution. I hope I got the commit message format correct this time. From jestedfa at microsoft.com Sun Apr 2 02:16:05 2017 From: jestedfa at microsoft.com (Jeffrey Stedfast) Date: Sun, 2 Apr 2017 00:16:05 +0000 Subject: Unknown algorithm 22 Message-ID: Hey all, I?m working on writing my own program to fetch unknown pgp keys that has its own pgp packet reader. The problem I?m facing is that a few of the keys (including Werner?s!) that I?ve been trying to test against have an unknown public key algorithm (id #22) that I can?t find *any* information on. Since everyone that has this problem with their keys uses gnupg, I?m wondering if it?s some sort of gnupg-specific algorithm? For example, these 2 key ids both have subkey packets with said unknown algorithm: 24ECFF5AFF68370A 4F0540D577F95F95 I thought this was just a bug in my code, but gpg ?list-packets also shows unknown algorithm 22 (and in Werner?s case, unknown algorithm 18 as well ? altho that is supposedly EC ? I guess gpg 2.0.30 doesn?t support that algorithm). Thanks, Jeff From jestedfa at microsoft.com Sun Apr 2 02:43:00 2017 From: jestedfa at microsoft.com (Jeffrey Stedfast) Date: Sun, 2 Apr 2017 00:43:00 +0000 Subject: Unknown algorithm 22 In-Reply-To: References: Message-ID: <6192A8A2-E1A2-4FED-B312-D1B44EA7BED5@microsoft.com> Somewhat never mind? my google search results eventually turned up Werner?s draft proposal for EdDSA support in OpenPGP which uses an algorithm value of 22. And it looks like that is only supported in gnupg 2.1.x, which explains why 2.0.30 doesn?t know about it either. New Question: is there a newer draft than 04 which expired back in August? Was it accepted as a standard? Thanks, Jeff On 4/1/17, 8:16 PM, "Gnupg-devel on behalf of Jeffrey Stedfast via Gnupg-devel" wrote: Hey all, I?m working on writing my own program to fetch unknown pgp keys that has its own pgp packet reader. The problem I?m facing is that a few of the keys (including Werner?s!) that I?ve been trying to test against have an unknown public key algorithm (id #22) that I can?t find *any* information on. Since everyone that has this problem with their keys uses gnupg, I?m wondering if it?s some sort of gnupg-specific algorithm? For example, these 2 key ids both have subkey packets with said unknown algorithm: 24ECFF5AFF68370A 4F0540D577F95F95 I thought this was just a bug in my code, but gpg ?list-packets also shows unknown algorithm 22 (and in Werner?s case, unknown algorithm 18 as well ? altho that is supposedly EC ? I guess gpg 2.0.30 doesn?t support that algorithm). Thanks, Jeff _______________________________________________ Gnupg-devel mailing list Gnupg-devel at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-devel From ilf at zeromail.org Sun Apr 2 15:53:13 2017 From: ilf at zeromail.org (ilf) Date: Sun, 2 Apr 2017 15:53:13 +0200 Subject: unknown critical bit Message-ID: <20170402135313.GB1130@zeromail.org> With current GnuPG, I get an error with a specific key: % gpg --version gpg (GnuPG) 2.1.19 libgcrypt 1.7.6 % mkdir test; cd test # new empty GnuPG homedir % gpg --homedir=. --recv 631EFC0642A8D5D22C52FBA0E62E990F36377134 gpg: keybox '/home/user/test/pubring.kbx' created gpg: assuming bad signature from key E62E990F36377134 due to an unknown critical bit gpg: assuming bad signature from key E62E990F36377134 due to an unknown critical bit gpg: /home/user/test/trustdb.gpg: trustdb created gpg: key E62E990F36377134: public key "Dan Blah Meredith (This is my current primary key. This replaces my old key ID 1024D/0x9C1BDFB4.)" imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 gpg: imported: 1 % gpg --homedir=. --recv 631EFC0642A8D5D22C52FBA0E62E990F36377134 gpg: WARNING: unsafe permissions on homedir '/home/user/bar' gpg: assuming bad signature from key E62E990F36377134 due to an unknown critical bit gpg: assuming bad signature from key E62E990F36377134 due to an unknown critical bit gpg: key E62E990F36377134: "Dan Blah Meredith (This is my current primary key. This replaces my old key ID 1024D/0x9C1BDFB4.)" not changed gpg: Total number processed: 1 gpg: unchanged: 1 % gpg --export-options export-minimal --export 631EFC0642A8D5D22C52FBA0E62E990F36377134 | pgpdump | grep critical | sort | uniq -c 10 Hashed Sub: features(sub 30)(critical)(1 bytes) 11 Hashed Sub: key expiration time(sub 9)(critical)(4 bytes) 11 Hashed Sub: key flags(sub 27)(critical)(1 bytes) 11 Hashed Sub: signature creation time(sub 2)(critical)(4 bytes) The "critical" bit is defined in https://tools.ietf.org/html/rfc4880#section-5.2.3.1 In GnuPG, this is caused in https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=g10/sig-check.c;hb=refs/heads/master#l473 But both my OpenPGP *and* GnuPG skills fail me at that point. Can someone help me understand why this is failing? Thanks! -- ilf ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From neal at walfield.org Sun Apr 2 19:20:33 2017 From: neal at walfield.org (Neal H. Walfield) Date: Sun, 02 Apr 2017 19:20:33 +0200 Subject: unknown critical bit In-Reply-To: <20170402135313.GB1130@zeromail.org> References: <20170402135313.GB1130@zeromail.org> Message-ID: <877f32zpy6.wl-neal@walfield.org> Hi Ilf, The subpacket signature that includes the unhandled critical bit is in a signature's hashed area. The contents are: 0x02 0x9d 0x00 0x05 0x82 0x57 0xb3 0xd3 0xa0 ^ ^ ^ ^ | | | subpacket #2, length = 5 | | "No reason specified" | type = 29 (reason for revocation), critical (high bit = 1) subpacket #1, length = 2 In other words, we have a well-formed "reason for revocation" subpacket (see page 24-25 of RFC 4880). Looking at can_handle_critical in parse-packet.c, we see that SIGSUBPKT_REVOC_REASON is not considered to be supported with respect to the critical bit. Examining a few gpg revocation generated packets, it looks like gpg doesn't set the critical bit on these subpackets (look for "revocation" in the output of sed 's/^://' | pgpdump). So, I'm guessing that these revocation signatures were probably generated by some other software. HTH, :) Neal At Sun, 2 Apr 2017 15:53:13 +0200, ilf wrote: > > [1 ] > [1.1 ] > With current GnuPG, I get an error with a specific key: > > % gpg --version > gpg (GnuPG) 2.1.19 > libgcrypt 1.7.6 > > > % mkdir test; cd test # new empty GnuPG homedir > > % gpg --homedir=. --recv 631EFC0642A8D5D22C52FBA0E62E990F36377134 > gpg: keybox '/home/user/test/pubring.kbx' created > gpg: assuming bad signature from key E62E990F36377134 due to an unknown critical bit > gpg: assuming bad signature from key E62E990F36377134 due to an unknown critical bit > gpg: /home/user/test/trustdb.gpg: trustdb created > gpg: key E62E990F36377134: public key "Dan Blah Meredith (This is my current primary key. This replaces my old key ID 1024D/0x9C1BDFB4.)" imported > gpg: no ultimately trusted keys found > gpg: Total number processed: 1 > gpg: imported: 1 > > % gpg --homedir=. --recv 631EFC0642A8D5D22C52FBA0E62E990F36377134 > gpg: WARNING: unsafe permissions on homedir '/home/user/bar' > gpg: assuming bad signature from key E62E990F36377134 due to an unknown critical bit > gpg: assuming bad signature from key E62E990F36377134 due to an unknown critical bit > gpg: key E62E990F36377134: "Dan Blah Meredith (This is my current primary key. This replaces my old key ID 1024D/0x9C1BDFB4.)" not changed > gpg: Total number processed: 1 > gpg: unchanged: 1 > > % gpg --export-options export-minimal --export 631EFC0642A8D5D22C52FBA0E62E990F36377134 | pgpdump | grep critical | sort | uniq -c > 10 Hashed Sub: features(sub 30)(critical)(1 bytes) > 11 Hashed Sub: key expiration time(sub 9)(critical)(4 bytes) > 11 Hashed Sub: key flags(sub 27)(critical)(1 bytes) > 11 Hashed Sub: signature creation time(sub 2)(critical)(4 bytes) > > The "critical" bit is defined in > https://tools.ietf.org/html/rfc4880#section-5.2.3.1 > > In GnuPG, this is caused in > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=g10/sig-check.c;hb=refs/heads/master#l473 > > But both my OpenPGP *and* GnuPG skills fail me at that point. > > Can someone help me understand why this is failing? > > Thanks! > > -- > ilf > > ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! > -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung > [1.2 signature.asc ] > Good signature from 153FE398821C8394 ilf created at 2017-04-02T15:53:13+0200 using RSA > [2 ] > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From wk at gnupg.org Mon Apr 3 08:56:46 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Apr 2017 08:56:46 +0200 Subject: unknown critical bit In-Reply-To: <877f32zpy6.wl-neal@walfield.org> (Neal H. Walfield's message of "Sun, 02 Apr 2017 19:20:33 +0200") References: <20170402135313.GB1130@zeromail.org> <877f32zpy6.wl-neal@walfield.org> Message-ID: <87inmmt1w1.fsf@wheatstone.g10code.de> > Looking at can_handle_critical in parse-packet.c, we see that > SIGSUBPKT_REVOC_REASON is not considered to be supported with respect > to the critical bit. That is the first time such an issue was reported. I am a bit taken aback to learn that this implementation did not test against gpg. Anyway, I just committed gpg: Handle critical marked 'Reason for Revocation'. * g10/parse-packet.c (can_handle_critical): Add SIGSUBPKT_REVOC_REASON. -- Some software seems to mark that subpacket as criticial. Although gpg has no special treatment for a revocation reasons (except for --list-packets) we can accept a criticial marked anyway. There are no mandatary rules specified on how to handle a revocation reason. to master to go into 2.1.20. 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 Mon Apr 3 09:05:11 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Apr 2017 09:05:11 +0200 Subject: Unknown algorithm 22 In-Reply-To: (Jeffrey Stedfast via Gnupg-devel's message of "Sun, 2 Apr 2017 00:16:05 +0000") References: Message-ID: <87efxat1i0.fsf@wheatstone.g10code.de> On Sun, 2 Apr 2017 02:16, gnupg-devel at gnupg.org said: > I thought this was just a bug in my code, but gpg ?list-packets also > shows unknown algorithm 22 (and in Werner?s case, unknown algorithm 18 > as well ? altho that is supposedly EC ? I guess gpg 2.0.30 doesn?t Right we are a bit faster than the specs. The OpenPGP WG agreed on using 22 for EdDSA in mid 2014. The draft-koch-eddsa-for-openpgp-00 specified the algorithms; meanwhile superseded by draft-ietf-openpgp-rfc4880bis-01. Hre is the current list: +-----------+----------------------------------------------------+ | ID | Algorithm | +-----------+----------------------------------------------------+ | 1 | RSA (Encrypt or Sign) [HAC] | | 2 | RSA Encrypt-Only [HAC] | | 3 | RSA Sign-Only [HAC] | | 16 | Elgamal (Encrypt-Only) [ELGAMAL] [HAC] | | 17 | DSA (Digital Signature Algorithm) [FIPS186] [HAC] | | 18 | ECDH public key algorithm | | 19 | ECDSA public key algorithm [FIPS186] | | 20 | Reserved (formerly Elgamal Encrypt or Sign) | | 21 | Reserved for Diffie-Hellman | | | (X9.42, as defined for IETF-S/MIME) | | 22 | EdDSA [I-D.irtf-cfrg-eddsa] | | 100--110 | Private/Experimental algorithm | +-----------+----------------------------------------------------+ Right GnuPG 2.0 does not support them. 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 Alexander.Strobel at giepa.de Mon Apr 3 17:45:55 2017 From: Alexander.Strobel at giepa.de (Alexander Strobel) Date: Mon, 3 Apr 2017 17:45:55 +0200 Subject: dirmngr without ipv6 connectivity fails Message-ID: Hello list, I found out that (sometimes) I am unable to retrieve keys from pool.sks-keyservers.net when using GnuPG 2.1.19 (on Windows x64). After enabling the logging of the dirmngr I found out that I can't get any keys when GnuPG tries to get the keys via ipv6 instead of ipv4. When I explicitly use ipv4.pool.sks-keyservers.net everything works fine. I am within a network that isn't connected via ipv6 to the rest of the world (until now), so the problem seems clear to me. I would like to know if my suspicion is correct and if there is any way to fix this? Will be there a newer version of GnuPG that will check if a keyserver is accessible over ipv6 and fall back to ipv4 if necessary? Or am I completely wrong and something other is causing the problem here? (Short logs of dirmngr attached) Best regards Alex Strobel -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gnupg_2-1_dirmgr_ipv6Problem.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Apr 3 22:24:35 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Apr 2017 22:24:35 +0200 Subject: [Announce] GnuPG 2.1.20 released Message-ID: <87h925qlx8.fsf@wheatstone.g10code.de> Hello! The GnuPG team is pleased to announce the availability of a new release of GnuPG: version 2.1.20. See below for a list of new features and bug fixes. About GnuPG ============= The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard which is commonly abbreviated as PGP. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. As an Universal Crypto Engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.1.20 ==================================== * gpg: New properties 'expired', 'revoked', and 'disabled' for the import and export filters. * gpg: New command --quick-set-primary-uid. * gpg: New compliance field for the --with-colon key listing. * gpg: Changed the key parser to generalize the processing of local meta data packets. * gpg: Fixed assertion failure in the TOFU trust model. * gpg: Fixed exporting of zero length user ID packets. * scd: Improved support for multiple readers. * scd: Fixed timeout handling for key generation. * agent: New option --enable-extended-key-format. * dirmngr: Do not add a keyserver to a new dirmngr.conf. Dirmngr uses a default keyserver. * dimngr: Do not treat TLS warning alerts as severe error when building with GNUTLS. * dirmngr: Actually take /etc/hosts in account. * wks: Fixed client problems on Windows. Published keys are now set to world-readable. * tests: Fixed creation of temporary directories. * A socket directory for a non standard GNUGHOME is now created on the fly under /run/user. Thus "gpgconf --create-socketdir" is now optional. The use of "gpgconf --remove-socketdir" to clean up obsolete socket directories is however recommended to avoid cluttering /run/user with useless directories. * Fixed build problems on some platforms. A detailed description of the changes found in this 2.1 branch can be found at . Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.1.20 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.20.tar.bz2 (6304k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.20.tar.bz2.sig or via FTP: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.20.tar.bz2 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.20.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.20_20170403.exe (3755k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.20_20170403.exe.sig or via FTP: ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.20_20170403.exe ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.20_20170403.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. The Windows installer now comes with TOFU support, many translations, support for Tor, and support for HKPS and the Web Key Directory. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.1.20.tar.bz2 you would use this command: gpg --verify gnupg-2.1.20.tar.bz2.sig gnupg-2.1.20.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.1.20.tar.bz2, you run the command like this: sha1sum gnupg-2.1.20.tar.bz2 and check that the output matches the next line: 500ddae8e4225ae2e300934090f9b9a427b8def1 gnupg-2.1.20.tar.bz2 69308ee80699ebb48a055963418597767a76d1d8 gnupg-w32-2.1.20_20170403.exe 6d9054625a6515971fd121e6648f6d0b0d4d9e44 gnupg-w32-2.1.20_20170403.tar.xz Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Norwegian, Russian, and Ukrainian being almost completely translated. Due to expected changes in forthcoming releases some strings pertaining to the TOFU code are not yet translated. Documentation ============= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete user manual of the system. Separate man pages are included as well but they have not all the details available as are the manual. It is also possible to read the complete manual online in HTML format at https://gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. You may also want to follow our postings at and . Support ======== Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . If you need commercial support check out . If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project employs 4 full-time developers, one part-timer, and one contractor. They all work exclusivly on GnuPG and closely related software like Libgcrypt, GPGME, and GPA. Please consider to donate via: https://gnupg.org/donate/ Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, and donating money. The GnuPG hackers, Andre, dkg, gniibe, Justus, Marcus, Neal, and Werner p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these five keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) rsa3072/4B092E28 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) You may retrieve these keys from a keyserver using this command gpg --keyserver hkp://keys.gnupg.net --recv-keys \ 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 BCEF7E294B092E28 The keys are also available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From alon.barlev at gmail.com Mon Apr 3 22:59:13 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon, 3 Apr 2017 23:59:13 +0300 Subject: [Announce] GnuPG 2.1.20 released In-Reply-To: <87h925qlx8.fsf@wheatstone.g10code.de> References: <87h925qlx8.fsf@wheatstone.g10code.de> Message-ID: Hi, decrypt-unwrap-verify.scm is trying to execute /usr/bin/gpg-agent. Regards, Alon --- Checking unwrapping the encryption. > encsig-2-keys-3 ("/var/tmp/portage/app-crypt/gnupg-2.1.20/work/gnupg-2.1.20/g10/gpg" --no-permission-warning --always-trust --import "/tmp/gscmdecrypt-unwrap-verifycotEDf/steve's-key") failed: ("gpg: keybox '/tmp/gscmdecrypt-unwrap-verifyM9SSZh/pubring.kbx' created\ngpg: key AA43F1DCC7FED1B7: public key \"steve.biko at example.net\" imported\ngpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory\ngpg: can't connect to the agent: No such file or directory\ngpg: Total number processed: 1\ngpg: imported: 1\n") 0: tests.scm:133: (throw (string-append (stringify what) " failed") (:stderr result)) 1: decrypt-unwrap-verify.scm:39: (call-check `(, at gpg --import ,steve's-key)) 2: init.scm:443: (thunk) 3: (dynamic-wind (lambda () (setenv "GNUPGHOME" gensym-33 #t)) (lambda () (call-check `(, at gpg --import ,steve's-key)) (call-check `(, at gpg --verify ,unwrapped))) (lambda () (setenv "GNUPGHOME" gensym-32 #t))) From dkg at fifthhorseman.net Mon Apr 3 23:24:55 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 03 Apr 2017 17:24:55 -0400 Subject: [Announce] GnuPG 2.1.20 released In-Reply-To: <87h925qlx8.fsf@wheatstone.g10code.de> References: <87h925qlx8.fsf@wheatstone.g10code.de> Message-ID: <87bmsd2nh4.fsf@alice.fifthhorseman.net> Thanks for publishing 2.1.20! On Mon 2017-04-03 16:24:35 -0400, Werner Koch wrote: > https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.20.tar.bz2 (6304k) > https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.20.tar.bz2.sig The directory listings at https://gnupg.org/ftp/gcrypt/gnupg/ appear not to have been updated. Could you kick the regeneration scripts again? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From gnupg-devel at spodhuis.org Tue Apr 4 01:46:01 2017 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Mon, 3 Apr 2017 23:46:01 +0000 Subject: Bug: dirmngr latches SRV port cross-scheme In-Reply-To: <20170331203323.GA9502@breadbox.private.spodhuis.org> References: <20170331203323.GA9502@breadbox.private.spodhuis.org> Message-ID: <20170403234601.GA94973@tower.spodhuis.org> On 2017-03-31 at 16:33 -0400, Phil Pennock wrote: > % gpg --keyserver hkp://keyserver.spodhuis.org --refresh-key 0x4D1E900E14C1CC04 > [success] > % gpg --keyserver hkps://keyserver.spodhuis.org --refresh-key 0x4D1E900E14C1CC04 > gpg: refreshing 1 key from hkps://keyserver.spodhuis.org > gpg: keyserver refresh failed: No keyserver available > % gpgconf --kill dirmngr > % gpg --keyserver hkps://keyserver.spodhuis.org --refresh-key 0x4D1E900E14C1CC04 > [success] Filed in Phabricator as: https://dev.gnupg.org/T3033 -Phil From wfisher at maclab.tk Tue Apr 4 03:55:20 2017 From: wfisher at maclab.tk (Wesley Fisher) Date: Mon, 03 Apr 2017 20:55:20 -0500 Subject: Libgpg-error mkerrcodes.awk not firing Message-ID: <3400F4A4-F1E7-4DEA-893F-F023C0591455@maclab.tk> Hi: Someone on IRC told me to take this to the gpg-devel mailing list. I?m trying to compile libgpg-error on IRIX 6.5.22 (yeah, I?m one of those zany SGI collectors) and it?s failing when mkerrcodes.awk is supposed to be kicked off in the Makefile. It says: cc-116 cc: ERROR File = ./mkerrcodes.h, Line = 3 ??????????????? Expected a declaration. }; If I try to manually execute ?gawk ?f ./mkerrcodes.awk >mkerrcodes.h? , it just hangs. Any help is appreciated!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From zdenek.hatas at gmail.com Tue Apr 4 09:51:23 2017 From: zdenek.hatas at gmail.com (Zdenek Hatas) Date: Tue, 4 Apr 2017 09:51:23 +0200 Subject: [PATCH GPA] po czech translation update Message-ID: Here I send update to GPA Czech translation. Regards, Zden?k -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-czech-translation-update.patch.gz Type: application/x-gzip Size: 6420 bytes Desc: not available URL: From wk at gnupg.org Tue Apr 4 15:43:55 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 04 Apr 2017 15:43:55 +0200 Subject: Bug: dirmngr latches SRV port cross-scheme In-Reply-To: <20170403234601.GA94973@tower.spodhuis.org> (Phil Pennock's message of "Mon, 3 Apr 2017 23:46:01 +0000") References: <20170331203323.GA9502@breadbox.private.spodhuis.org> <20170403234601.GA94973@tower.spodhuis.org> Message-ID: <87wpb0l23o.fsf@wheatstone.g10code.de> On Tue, 4 Apr 2017 01:46, gnupg-devel at spodhuis.org said: > Filed in Phabricator as: > > https://dev.gnupg.org/T3033 Thanks. Sorry, that a fix didn't made it into 2.1.20. We try to keep our monthly release schedule. 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 zmike at samsung.com Tue Apr 4 16:06:22 2017 From: zmike at samsung.com (Mike Blumenkrantz) Date: Tue, 04 Apr 2017 10:06:22 -0400 Subject: [PINENTRY PATCH] add efl-based frontend In-Reply-To: <871svhx69t.fsf@wheatstone.g10code.de> References: <20161012113515.675d5a30@Sir.Pimpleton> <87y41swi1i.fsf@europa.jade-hamburg.de> <87inso1r02.fsf@europa.jade-hamburg.de> <20161019100137.66563eb7@Sir.Pimpleton> <877f5kzpab.fsf@europa.jade-hamburg.de> <20170125081219.4d666e71@Sir.Pimpleton> <871svhx69t.fsf@wheatstone.g10code.de> Message-ID: <20170404100622.5f3e217a@Sir.Pimpleton> On Wed, 1 Feb 2017 16:47:10 +0100 Werner Koch wrote: > On Mon, 30 Jan 2017 15:59, michael.blumenkrantz at gmail.com said: > > > in moderation because the patch size is 41kb which exceeds the mailing list > > limit of 40kb. > > Approved and bumped the limit up to 60k. > > > Shalom-Salam, > > Werner > Hi, Is there any progress on reviewing this? Regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From justus at g10code.com Wed Apr 5 16:46:50 2017 From: justus at g10code.com (Justus Winter) Date: Wed, 05 Apr 2017 16:46:50 +0200 Subject: [PATCH GPGME] python: Generate files into build directory In-Reply-To: <20170401232952.26151-1-alon.barlev@gmail.com> References: <20170401232952.26151-1-alon.barlev@gmail.com> Message-ID: <87pogqj4it.fsf@europa.jade-hamburg.de> Alon Bar-Lev writes: > * lang/python/setup.py.in: Generate files within BuildExtFirstHack > adjust build flags at this point instead of global. > * lang/python/Makefile.am: Remove logic of separate source directory per > python version in favor of build directory. > * lang/python/tests/run-tests.py: Adjust build directory location. > -- > > Generate files into build directory, leaving the source directory clean. > Use the same source directory for multiple python version build. Result > of 'prepare' target is a standard distutil layout that can be used > easily by downstream to build all python targets in-place. Yes, this is very nice :). I merged it. Unfortunately it broke out-of-tree builds and 'make distcheck'. So I brought some of the copying back, and did some cleanups. I hope I didn't stomp over your workflow again. Thanks, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From alon.barlev at gmail.com Wed Apr 5 17:06:55 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed, 5 Apr 2017 18:06:55 +0300 Subject: [PATCH GPGME] python: Generate files into build directory In-Reply-To: <87pogqj4it.fsf@europa.jade-hamburg.de> References: <20170401232952.26151-1-alon.barlev@gmail.com> <87pogqj4it.fsf@europa.jade-hamburg.de> Message-ID: On 5 April 2017 at 17:46, Justus Winter wrote: > Alon Bar-Lev writes: > Yes, this is very nice :). I merged it. Unfortunately it broke > out-of-tree builds and 'make distcheck'. So I brought some of the > copying back, and did some cleanups. I hope I didn't stomp over your > workflow again. Hi, Thanks! Please consider to quote all -$(srcdir) != . -"$(srcdir)" != . Maybe instead of copying back and forth, we can have gpg renamed to gpg-src for example. Then have a target like: gpg: ln -s "$(srcdir)/gpg-src" gpg This is unconditional and will probably work. This will also remove the concern of srcdir in the setup.py as files are always in builddir. The problem is that the python tests never work for me, so make check and make distcheck cannot be validated by me. Alon From alon.barlev at gmail.com Wed Apr 5 17:17:03 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed, 5 Apr 2017 18:17:03 +0300 Subject: [PATCH GPGME] python: Generate files into build directory In-Reply-To: References: <20170401232952.26151-1-alon.barlev@gmail.com> <87pogqj4it.fsf@europa.jade-hamburg.de> Message-ID: On 5 April 2017 at 18:06, Alon Bar-Lev wrote: > On 5 April 2017 at 17:46, Justus Winter wrote: >> Alon Bar-Lev writes: >> Yes, this is very nice :). I merged it. Unfortunately it broke >> out-of-tree builds and 'make distcheck'. So I brought some of the >> copying back, and did some cleanups. I hope I didn't stomp over your >> workflow again. > > Hi, > > Thanks! > > Please consider to quote all > -$(srcdir) != . > -"$(srcdir)" != . > > Maybe instead of copying back and forth, we can have gpg renamed to > gpg-src for example. > Then have a target like: > > gpg: > ln -s "$(srcdir)/gpg-src" gpg > > This is unconditional and will probably work. > This will also remove the concern of srcdir in the setup.py as files > are always in builddir. > > The problem is that the python tests never work for me, so make check > and make distcheck cannot be validated by me. I will try to produce this patch. From alon.barlev at gmail.com Wed Apr 5 18:47:08 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed, 5 Apr 2017 19:47:08 +0300 Subject: [PATCH GPGME] python: simplify build, some fixups In-Reply-To: References: Message-ID: <20170405164708.14269-1-alon.barlev@gmail.com> * lang/python/gpg/version.py.in: Rename to lang/python/version.py.in. configure.ac: Generate version.py.in in lang/python * lang/python/MANIFEST.in: Include version.py explicitly. * lang/python/gpg: Rename to gpg-src * lang/python/Makefile.am: Do not copy source files, do not use absolute directories, support lib64 in uninstall, clean also dist directory, use symlink for gpg src. * lang/python/setup.py.in: Use builddir, copy sources into builddir, copy version.py into module. -- Simplify build to symlink the gpg sources into builddir instead of copying. This requires handling of version.py as generated file. In addition apply some cleanups: Drop the absolution pathes, clean the dist directory as well, support lib64 for sitelib at uninstall. Signed-off-by: Alon Bar-Lev --- configure.ac | 2 +- lang/python/MANIFEST.in | 1 + lang/python/Makefile.am | 38 +++++++--------------- lang/python/{gpg => gpg-src}/__init__.py | 0 lang/python/{gpg => gpg-src}/callbacks.py | 0 lang/python/{gpg => gpg-src}/constants/__init__.py | 0 lang/python/{gpg => gpg-src}/constants/create.py | 0 .../{gpg => gpg-src}/constants/data/__init__.py | 0 .../{gpg => gpg-src}/constants/data/encoding.py | 0 lang/python/{gpg => gpg-src}/constants/event.py | 0 lang/python/{gpg => gpg-src}/constants/import.py | 0 .../{gpg => gpg-src}/constants/keylist/__init__.py | 0 .../{gpg => gpg-src}/constants/keylist/mode.py | 0 lang/python/{gpg => gpg-src}/constants/keysign.py | 0 lang/python/{gpg => gpg-src}/constants/md.py | 0 lang/python/{gpg => gpg-src}/constants/pk.py | 0 lang/python/{gpg => gpg-src}/constants/protocol.py | 0 .../{gpg => gpg-src}/constants/sig/__init__.py | 0 lang/python/{gpg => gpg-src}/constants/sig/mode.py | 0 .../{gpg => gpg-src}/constants/sig/notation.py | 0 lang/python/{gpg => gpg-src}/constants/sigsum.py | 0 lang/python/{gpg => gpg-src}/constants/status.py | 0 .../{gpg => gpg-src}/constants/tofu/__init__.py | 0 .../{gpg => gpg-src}/constants/tofu/policy.py | 0 lang/python/{gpg => gpg-src}/constants/validity.py | 0 lang/python/{gpg => gpg-src}/core.py | 0 lang/python/{gpg => gpg-src}/errors.py | 0 lang/python/{gpg => gpg-src}/results.py | 0 lang/python/{gpg => gpg-src}/util.py | 0 lang/python/setup.py.in | 23 ++++++------- lang/python/{gpg => }/version.py.in | 0 31 files changed, 24 insertions(+), 40 deletions(-) rename lang/python/{gpg => gpg-src}/__init__.py (100%) rename lang/python/{gpg => gpg-src}/callbacks.py (100%) rename lang/python/{gpg => gpg-src}/constants/__init__.py (100%) rename lang/python/{gpg => gpg-src}/constants/create.py (100%) rename lang/python/{gpg => gpg-src}/constants/data/__init__.py (100%) rename lang/python/{gpg => gpg-src}/constants/data/encoding.py (100%) rename lang/python/{gpg => gpg-src}/constants/event.py (100%) rename lang/python/{gpg => gpg-src}/constants/import.py (100%) rename lang/python/{gpg => gpg-src}/constants/keylist/__init__.py (100%) rename lang/python/{gpg => gpg-src}/constants/keylist/mode.py (100%) rename lang/python/{gpg => gpg-src}/constants/keysign.py (100%) rename lang/python/{gpg => gpg-src}/constants/md.py (100%) rename lang/python/{gpg => gpg-src}/constants/pk.py (100%) rename lang/python/{gpg => gpg-src}/constants/protocol.py (100%) rename lang/python/{gpg => gpg-src}/constants/sig/__init__.py (100%) rename lang/python/{gpg => gpg-src}/constants/sig/mode.py (100%) rename lang/python/{gpg => gpg-src}/constants/sig/notation.py (100%) rename lang/python/{gpg => gpg-src}/constants/sigsum.py (100%) rename lang/python/{gpg => gpg-src}/constants/status.py (100%) rename lang/python/{gpg => gpg-src}/constants/tofu/__init__.py (100%) rename lang/python/{gpg => gpg-src}/constants/tofu/policy.py (100%) rename lang/python/{gpg => gpg-src}/constants/validity.py (100%) rename lang/python/{gpg => gpg-src}/core.py (100%) rename lang/python/{gpg => gpg-src}/errors.py (100%) rename lang/python/{gpg => gpg-src}/results.py (100%) rename lang/python/{gpg => gpg-src}/util.py (100%) rename lang/python/{gpg => }/version.py.in (100%) diff --git a/configure.ac b/configure.ac index 7ab94e7..9974abb 100644 --- a/configure.ac +++ b/configure.ac @@ -881,7 +881,7 @@ AC_CONFIG_FILES([lang/Makefile lang/cl/Makefile lang/cl/gpgme.asd]) AM_COND_IF([HAVE_DOXYGEN], [AC_CONFIG_FILES([lang/qt/doc/Doxyfile])]) AC_CONFIG_FILES(lang/qt/doc/Makefile) AC_CONFIG_FILES([lang/python/Makefile - lang/python/gpg/version.py + lang/python/version.py lang/python/tests/Makefile]) AC_CONFIG_FILES([lang/python/setup.py], [chmod a+x lang/python/setup.py]) AC_OUTPUT diff --git a/lang/python/MANIFEST.in b/lang/python/MANIFEST.in index ff38172..c34e84a 100644 --- a/lang/python/MANIFEST.in +++ b/lang/python/MANIFEST.in @@ -1,4 +1,5 @@ recursive-include examples *.py include gpgme.i include helpers.c helpers.h private.h +include version.py recursive-include gpg *.py diff --git a/lang/python/Makefile.am b/lang/python/Makefile.am index 42beeee..0903c7b 100644 --- a/lang/python/Makefile.am +++ b/lang/python/Makefile.am @@ -22,28 +22,19 @@ EXTRA_DIST = \ gpgme.i \ helpers.c helpers.h private.h \ examples \ - gpg + gpg-src SUBDIRS = . tests -COPY_FILES_GPG = \ - $(srcdir)/gpg/callbacks.py \ - $(srcdir)/gpg/constants \ - $(srcdir)/gpg/core.py \ - $(srcdir)/gpg/errors.py \ - $(srcdir)/gpg/__init__.py \ - $(srcdir)/gpg/results.py \ - $(srcdir)/gpg/util.py - .PHONY: prepare prepare: copystamp # For VPATH builds we need to copy some files because Python's # distutils are not VPATH-aware. copystamp: - ln -sf "$(abs_top_srcdir)/src/data.h" . - ln -sf "$(abs_top_builddir)/config.h" . - if test $(srcdir) != . ; then cp -R $(COPY_FILES_GPG) gpg ; fi + ln -sf "$(top_srcdir)/src/data.h" . + ln -sf "$(top_builddir)/config.h" . + ln -sf "$(srcdir)/gpg-src" gpg touch $@ all-local: copystamp @@ -51,7 +42,7 @@ all-local: copystamp PYTHON="$$1" ; shift ; \ CFLAGS="$(CFLAGS)" \ srcdir="$(srcdir)" \ - abs_top_builddir="$(abs_top_builddir)" \ + top_builddir="$(top_builddir)" \ $$PYTHON setup.py build --verbose --build-base=python$${VERSION}-gpg ; \ done @@ -59,7 +50,7 @@ python$(PYTHON_VERSION)-gpg/dist/gpg-$(VERSION).tar.gz.asc: copystamp $(MKDIR_P) python$(PYTHON_VERSION)-gpg-dist CFLAGS="$(CFLAGS)" \ srcdir="$(srcdir)" \ - abs_top_builddir="$(abs_top_builddir)" \ + top_builddir="$(top_builddir)" \ $(PYTHON) setup.py sdist --verbose --dist-dir=python$(PYTHON_VERSION)-gpg-dist \ --manifest=python$(PYTHON_VERSION)-gpg-dist/MANIFEST gpg2 --detach-sign --armor python$(PYTHON_VERSION)-gpg-dist/gpg-$(VERSION).tar.gz @@ -75,6 +66,7 @@ upload: python$(PYTHON_VERSION)-gpg-dist/gpg-$(VERSION).tar.gz \ CLEANFILES = copystamp \ config.h \ data.h \ + gpg \ files.txt \ install_files.txt @@ -84,22 +76,16 @@ CLEANFILES = copystamp \ # permissions. clean-local: rm -rf -- build - if test $(srcdir) != . ; then \ - find gpg -type d ! -perm -200 -exec chmod u+w {} ';' ; \ - for FILE in $(COPY_FILES_GPG); do \ - rm -rf -- gpg/$$(basename $$FILE) ; \ - done \ - fi for VERSION in $(PYTHON_VERSIONS); do \ - find python$${VERSION}-gpg -type d ! -perm -200 -exec chmod u+w {} ';' ; \ - rm -rf -- python$${VERSION}-gpg ; \ + find python$${VERSION}-gpg* -type d ! -perm -200 -exec chmod u+w {} ';' ; \ + rm -rf -- python$${VERSION}-gpg* ; \ done install-exec-local: set -e ; set $(PYTHONS); for VERSION in $(PYTHON_VERSIONS); do \ PYTHON="$$1" ; shift ; \ srcdir="$(srcdir)" \ - abs_top_builddir="$(abs_top_builddir)" \ + top_builddir="$(top_builddir)" \ $$PYTHON setup.py \ build \ --build-base=python$${VERSION}-gpg \ @@ -110,6 +96,6 @@ install-exec-local: uninstall-local: GV=$$(echo $(VERSION) | tr - _); for PV in $(PYTHON_VERSIONS); do \ - rm -rf -- "$(DESTDIR)$(prefix)/lib/python$$PV/site-packages/gpg" \ -"$(DESTDIR)$(prefix)/lib/python$$PV/site-packages/gpg-$$GV-py$$PV.egg-info" ; \ + rm -rf -- "$(DESTDIR)$(prefix)"/lib*/python$$PV/site-packages/gpg \ +"$(DESTDIR)$(prefix)"/lib*/python$$PV/site-packages/gpg-$$GV-py$$PV.egg-info ; \ done diff --git a/lang/python/gpg/__init__.py b/lang/python/gpg-src/__init__.py similarity index 100% rename from lang/python/gpg/__init__.py rename to lang/python/gpg-src/__init__.py diff --git a/lang/python/gpg/callbacks.py b/lang/python/gpg-src/callbacks.py similarity index 100% rename from lang/python/gpg/callbacks.py rename to lang/python/gpg-src/callbacks.py diff --git a/lang/python/gpg/constants/__init__.py b/lang/python/gpg-src/constants/__init__.py similarity index 100% rename from lang/python/gpg/constants/__init__.py rename to lang/python/gpg-src/constants/__init__.py diff --git a/lang/python/gpg/constants/create.py b/lang/python/gpg-src/constants/create.py similarity index 100% rename from lang/python/gpg/constants/create.py rename to lang/python/gpg-src/constants/create.py diff --git a/lang/python/gpg/constants/data/__init__.py b/lang/python/gpg-src/constants/data/__init__.py similarity index 100% rename from lang/python/gpg/constants/data/__init__.py rename to lang/python/gpg-src/constants/data/__init__.py diff --git a/lang/python/gpg/constants/data/encoding.py b/lang/python/gpg-src/constants/data/encoding.py similarity index 100% rename from lang/python/gpg/constants/data/encoding.py rename to lang/python/gpg-src/constants/data/encoding.py diff --git a/lang/python/gpg/constants/event.py b/lang/python/gpg-src/constants/event.py similarity index 100% rename from lang/python/gpg/constants/event.py rename to lang/python/gpg-src/constants/event.py diff --git a/lang/python/gpg/constants/import.py b/lang/python/gpg-src/constants/import.py similarity index 100% rename from lang/python/gpg/constants/import.py rename to lang/python/gpg-src/constants/import.py diff --git a/lang/python/gpg/constants/keylist/__init__.py b/lang/python/gpg-src/constants/keylist/__init__.py similarity index 100% rename from lang/python/gpg/constants/keylist/__init__.py rename to lang/python/gpg-src/constants/keylist/__init__.py diff --git a/lang/python/gpg/constants/keylist/mode.py b/lang/python/gpg-src/constants/keylist/mode.py similarity index 100% rename from lang/python/gpg/constants/keylist/mode.py rename to lang/python/gpg-src/constants/keylist/mode.py diff --git a/lang/python/gpg/constants/keysign.py b/lang/python/gpg-src/constants/keysign.py similarity index 100% rename from lang/python/gpg/constants/keysign.py rename to lang/python/gpg-src/constants/keysign.py diff --git a/lang/python/gpg/constants/md.py b/lang/python/gpg-src/constants/md.py similarity index 100% rename from lang/python/gpg/constants/md.py rename to lang/python/gpg-src/constants/md.py diff --git a/lang/python/gpg/constants/pk.py b/lang/python/gpg-src/constants/pk.py similarity index 100% rename from lang/python/gpg/constants/pk.py rename to lang/python/gpg-src/constants/pk.py diff --git a/lang/python/gpg/constants/protocol.py b/lang/python/gpg-src/constants/protocol.py similarity index 100% rename from lang/python/gpg/constants/protocol.py rename to lang/python/gpg-src/constants/protocol.py diff --git a/lang/python/gpg/constants/sig/__init__.py b/lang/python/gpg-src/constants/sig/__init__.py similarity index 100% rename from lang/python/gpg/constants/sig/__init__.py rename to lang/python/gpg-src/constants/sig/__init__.py diff --git a/lang/python/gpg/constants/sig/mode.py b/lang/python/gpg-src/constants/sig/mode.py similarity index 100% rename from lang/python/gpg/constants/sig/mode.py rename to lang/python/gpg-src/constants/sig/mode.py diff --git a/lang/python/gpg/constants/sig/notation.py b/lang/python/gpg-src/constants/sig/notation.py similarity index 100% rename from lang/python/gpg/constants/sig/notation.py rename to lang/python/gpg-src/constants/sig/notation.py diff --git a/lang/python/gpg/constants/sigsum.py b/lang/python/gpg-src/constants/sigsum.py similarity index 100% rename from lang/python/gpg/constants/sigsum.py rename to lang/python/gpg-src/constants/sigsum.py diff --git a/lang/python/gpg/constants/status.py b/lang/python/gpg-src/constants/status.py similarity index 100% rename from lang/python/gpg/constants/status.py rename to lang/python/gpg-src/constants/status.py diff --git a/lang/python/gpg/constants/tofu/__init__.py b/lang/python/gpg-src/constants/tofu/__init__.py similarity index 100% rename from lang/python/gpg/constants/tofu/__init__.py rename to lang/python/gpg-src/constants/tofu/__init__.py diff --git a/lang/python/gpg/constants/tofu/policy.py b/lang/python/gpg-src/constants/tofu/policy.py similarity index 100% rename from lang/python/gpg/constants/tofu/policy.py rename to lang/python/gpg-src/constants/tofu/policy.py diff --git a/lang/python/gpg/constants/validity.py b/lang/python/gpg-src/constants/validity.py similarity index 100% rename from lang/python/gpg/constants/validity.py rename to lang/python/gpg-src/constants/validity.py diff --git a/lang/python/gpg/core.py b/lang/python/gpg-src/core.py similarity index 100% rename from lang/python/gpg/core.py rename to lang/python/gpg-src/core.py diff --git a/lang/python/gpg/errors.py b/lang/python/gpg-src/errors.py similarity index 100% rename from lang/python/gpg/errors.py rename to lang/python/gpg-src/errors.py diff --git a/lang/python/gpg/results.py b/lang/python/gpg-src/results.py similarity index 100% rename from lang/python/gpg/results.py rename to lang/python/gpg-src/results.py diff --git a/lang/python/gpg/util.py b/lang/python/gpg-src/util.py similarity index 100% rename from lang/python/gpg/util.py rename to lang/python/gpg-src/util.py diff --git a/lang/python/setup.py.in b/lang/python/setup.py.in index 2114aaf..5d94c70 100755 --- a/lang/python/setup.py.in +++ b/lang/python/setup.py.in @@ -38,18 +38,17 @@ gpgme_config = ["gpgme-config"] + gpgme_config_flags gpgme_h = "" include_dirs = [os.getcwd()] library_dirs = [] -vpath_build = os.environ.get('srcdir', '.') != '.' in_tree = False extra_swig_opts = [] extra_macros = dict() -abs_top_builddir = os.environ.get("abs_top_builddir") -if abs_top_builddir: +top_builddir = os.environ.get("top_builddir") +if top_builddir: # In-tree build. in_tree = True - gpgme_config = [os.path.join(abs_top_builddir, "src/gpgme-config")] + gpgme_config_flags - gpgme_h = os.path.join(abs_top_builddir, "src/gpgme.h") - library_dirs = [os.path.join(abs_top_builddir, "src/.libs")] # XXX uses libtool internals + gpgme_config = [os.path.join(top_builddir, "src/gpgme-config")] + gpgme_config_flags + gpgme_h = os.path.join(top_builddir, "src/gpgme.h") + library_dirs = [os.path.join(top_builddir, "src/.libs")] # XXX uses libtool internals extra_macros.update( HAVE_CONFIG_H=1, HAVE_DATA_H=1, @@ -210,23 +209,21 @@ class BuildExtFirstHack(build): # Copy due to http://bugs.python.org/issue2624 # Avoid creating in srcdir for source, target in ((in_srcdir(n), in_build_base(n)) - for n in ('gpgme.i', 'helpers.c')): + for n in ('gpgme.i', 'helpers.c', 'private.h', 'helpers.h')): if not up_to_date(source, target): shutil.copy2(source, target) - def run(self): - self._generate() - # Append generated files via build_base if not os.path.exists(os.path.join(self.build_lib, "gpg")): os.makedirs(os.path.join(self.build_lib, "gpg")) + shutil.copy2("version.py", os.path.join(self.build_lib, "gpg")) + + def run(self): + self._generate() swig_sources.append(os.path.join(self.build_base, 'gpgme.i')) swig_opts.extend(['-I' + self.build_base, - '-I' + in_srcdir('.'), '-outdir', os.path.join(self.build_lib, 'gpg')]) - if vpath_build: - include_dirs.append(in_srcdir('.')) include_dirs.append(self.build_base) self.run_command('build_ext') diff --git a/lang/python/gpg/version.py.in b/lang/python/version.py.in similarity index 100% rename from lang/python/gpg/version.py.in rename to lang/python/version.py.in -- 2.10.2 From Amul.Shah at fisglobal.com Wed Apr 5 17:23:42 2017 From: Amul.Shah at fisglobal.com (Shah, Amul) Date: Wed, 5 Apr 2017 15:23:42 +0000 Subject: Follow-up to Crashes with gpg-agent 2.1.18 Message-ID: Please excuse any Outlook formatting oddities. I am re-sending this as it has not shown up on the mailing list. I think that this is a follow up to a thread from January (last email in thread https://lists.gnupg.org/pipermail/gnupg-devel/2017-January/032516.html) because it started with me seeing the message "Ohhhh jeeee: ... this is a bug (sexp.c:1433:do_vsexp_sscan)" in the gpg-agent log. Now in trying to reproduce the error, the gpg- agent hits a PKDECRYPT failure claiming that it cannot allocate memory. I tried debugging the error down into libgcrypt, but could not see where things could go wrong unless the memory manager is not npthread safe. Since I made no progress, I'm sending this mail along with a test case similar to the one from the previous thread. Note that we don't encounter this problem with older GnuPG versions, GnuPG 2.15 and earlier. Could someone take a look at this or give me some pointers on how I can help myself? Thanks, Amul ---- Host Information ---- Distributor ID: Debian Description: Debian GNU/Linux 9.0 (stretch) Release: 9.0 Codename: stretch Package: gnupg2 Version: 2.1.18-6 Package: gnupg-agent Version: 2.1.18-6 Package: libgcrypt20 Version: 1.7.6-1 Package: libgpgme11 Version: 1.8.0-3+b2 Package: libnpth0 Version: 1.3-1 Package: libassuan0 Version: 2.4.3-2 ---- Error Information ---- 2017-03-30 19:34:43 gpg-agent[745886] starting a new PIN Entry 2017-03-30 19:34:43 gpg-agent[745886] failed to build S-Exp (off=0): Cannot allocate memory 2017-03-30 19:34:43 gpg-agent[745886] failed to read the secret key 2017-03-30 19:34:43 gpg-agent[745886] command 'PKDECRYPT' failed: Cannot allocate memory 2017-03-30 19:34:43 gpg-agent[745886] failed to build S-Exp (off=0): Cannot allocate memory 2017-03-30 19:34:43 gpg-agent[745886] failed to read the secret key 2017-03-30 19:34:44 gpg-agent[745886] handler 0x7ff368f81700 for fd 184 started 2017-03-30 19:34:44 gpg-agent[745886] Warning: using insecure memory! 2017-03-30 19:34:44 gpg-agent[745886] retrieving cache entry '29395A5EFE485B83873C2B5435FCB4DC482765FD' failed: Invalid cipher mode -- 2017-03-30 19:34:44 gpg-agent[745886] retrieving cache entry '29395A5EFE485B83873C2B5435FCB4DC482765FD' failed: Invalid cipher mode 2017-03-30 19:34:44 gpg-agent[745886] command 'PKDECRYPT' failed: Cannot allocate memory 2017-03-30 19:34:44 gpg-agent[745886] retrieving cache entry '29395A5EFE485B83873C2B5435FCB4DC482765FD' failed: Invalid cipher mode ---- Test case ---- echo "# Setup agent config to avoid interactive password prompting" echo "verbose" >> $GNUPGHOME/gpg-agent.conf echo "log-file $GNUPGHOME/agent.log" >> $GNUPGHOME/gpg-agent.conf echo "pinentry-program $GNUPGHOME/pinentry.csh" >> $GNUPGHOME/gpg-agent.conf cat >$GNUPGHOME/pinentry.csh << EOF #!/bin/tcsh set word = "" while (("\$word" != "getpin") && ("\$word" != "GETPIN")) echo "OK" set word = "\$<" end echo "D abc123" echo "OK" EOF chmod a+rx $GNUPGHOME/pinentry.csh yes | gpg2 --passphrase abc123 --quick-gen-key user at host.com echo # Encrypt a file rm -f test.gpg echo testme > test gpg2 -e -r user at host.com test echo "# This had better work" gpg2 -d test.gpg || exit 9 echo "# Hit the agent hard" for i in $(seq 1 200); do (gpg2 -d test.gpg > test${i}.log 2>&1 & ); done wait gpg-connect-agent 'getinfo pid' /bye sleep 1 gpg-connect-agent killagent /bye grep 'fail' *.log grep -C1 --color -E "jee|memory" $GNUPGHOME/agent.log echo "Doit!" echo "rm -rf $GNUPGHOME" gpg-connect-agent killagent /bye ---- Full test case output ---- # Do Setup # Setup agent config to avoid interactive password prompting gpg: keybox '/tmp/tmp.t40xj0I2lY/pubring.kbx' created We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. gpg: /tmp/tmp.t40xj0I2lY/trustdb.gpg: trustdb created gpg: key 4DB73400DF6568DF marked as ultimately trusted gpg: directory '/tmp/tmp.t40xj0I2lY/openpgp-revocs.d' created gpg: revocation certificate stored as '/tmp/tmp.t40xj0I2lY/openpgp-revocs.d/61F7B673B3ABCE0A308314AE4DB73400DF6568DF.rev' public and secret key created and signed. pub rsa2048 2017-03-30 [SC] [expires: 2019-03-30] 61F7B673B3ABCE0A308314AE4DB73400DF6568DF 61F7B673B3ABCE0A308314AE4DB73400DF6568DF uid user at host.com sub rsa2048 2017-03-30 [E] gpg: checking the trustdb gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: next trustdb check due at 2019-03-30 # This had better work gpg: encrypted with 2048-bit RSA key, ID 5941F75AFA9801E6, created 2017-03-30 "user at host.com" testme # Hit the agent hard D 745886 OK OK closing connection test25.log:gpg: public key decryption failed: Cannot allocate memory test25.log:gpg: decryption failed: No secret key test7.log:gpg: public key decryption failed: Cannot allocate memory test7.log:gpg: decryption failed: No secret key 2017-03-30 19:34:43 gpg-agent[745886] starting a new PIN Entry 2017-03-30 19:34:43 gpg-agent[745886] failed to build S-Exp (off=0): Cannot allocate memory 2017-03-30 19:34:43 gpg-agent[745886] failed to read the secret key 2017-03-30 19:34:43 gpg-agent[745886] command 'PKDECRYPT' failed: Cannot allocate memory 2017-03-30 19:34:43 gpg-agent[745886] failed to build S-Exp (off=0): Cannot allocate memory 2017-03-30 19:34:43 gpg-agent[745886] failed to read the secret key 2017-03-30 19:34:44 gpg-agent[745886] handler 0x7ff368f81700 for fd 184 started 2017-03-30 19:34:44 gpg-agent[745886] Warning: using insecure memory! 2017-03-30 19:34:44 gpg-agent[745886] retrieving cache entry '29395A5EFE485B83873C2B5435FCB4DC482765FD' failed: Invalid cipher mode -- 2017-03-30 19:34:44 gpg-agent[745886] retrieving cache entry '29395A5EFE485B83873C2B5435FCB4DC482765FD' failed: Invalid cipher mode 2017-03-30 19:34:44 gpg-agent[745886] command 'PKDECRYPT' failed: Cannot allocate memory 2017-03-30 19:34:44 gpg-agent[745886] retrieving cache entry '29395A5EFE485B83873C2B5435FCB4DC482765FD' failed: Invalid cipher mode Doit! rm -rf /tmp/tmp.t40xj0I2lY OK closing connection The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilf at zeromail.org Wed Apr 5 21:41:51 2017 From: ilf at zeromail.org (ilf) Date: Wed, 5 Apr 2017 21:41:51 +0200 Subject: unknown critical bit In-Reply-To: <87inmmt1w1.fsf@wheatstone.g10code.de> References: <20170402135313.GB1130@zeromail.org> <877f32zpy6.wl-neal@walfield.org> <87inmmt1w1.fsf@wheatstone.g10code.de> Message-ID: <20170405194151.GW1130@zeromail.org> Werner Koch: > That is the first time such an issue was reported. I am a bit taken > aback to learn that this implementation did not test against gpg. Apparently, that implementation is OpenKeychain of Vincent in Cc. > Anyway, I just committed Thanks! -- ilf ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From look at my.amazin.horse Thu Apr 6 16:11:11 2017 From: look at my.amazin.horse (Vincent Breitmoser) Date: Thu, 6 Apr 2017 16:11:11 +0200 Subject: unknown critical bit In-Reply-To: <20170405194151.GW1130@zeromail.org> References: <20170402135313.GB1130@zeromail.org> <877f32zpy6.wl-neal@walfield.org> <87inmmt1w1.fsf@wheatstone.g10code.de> <20170405194151.GW1130@zeromail.org> Message-ID: <20170406141111.vdoqmspw6mmraqw2@calamity> Hi, thanks for bringing this to our attention! Interesting that this never came up before. We do indeed set the critical flag for the reason for revocation subpacket, for no good reason. A related question came up when we looked at our implementation: We set the reason as NO_REASON, with an empty string. Dominik says he included the packet for compatibility reasons, but we can't remember the specifics at this point. We could now either set the flag to false, or drop the subpacket altogether. I have no strong preference, would probably just drop the critical bit to change as little as necessary. Any thoughts? - V ilf(ilf at zeromail.org)@Wed, Apr 05, 2017 at 09:41:51PM +0200: > Werner Koch: > > That is the first time such an issue was reported. I am a bit taken > > aback to learn that this implementation did not test against gpg. > > Apparently, that implementation is OpenKeychain of Vincent in Cc. > > > Anyway, I just committed > > Thanks! > > -- > ilf > > ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! > -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung From wk at gnupg.org Thu Apr 6 18:32:05 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Apr 2017 18:32:05 +0200 Subject: unknown critical bit In-Reply-To: <20170406141111.vdoqmspw6mmraqw2@calamity> (Vincent Breitmoser's message of "Thu, 6 Apr 2017 16:11:11 +0200") References: <20170402135313.GB1130@zeromail.org> <877f32zpy6.wl-neal@walfield.org> <87inmmt1w1.fsf@wheatstone.g10code.de> <20170405194151.GW1130@zeromail.org> <20170406141111.vdoqmspw6mmraqw2@calamity> Message-ID: <87lgrdh4ze.fsf@wheatstone.g10code.de> On Thu, 6 Apr 2017 16:11, look at my.amazin.horse said: > A related question came up when we looked at our implementation: We set > the reason as NO_REASON, with an empty string. Dominik says he > included GnuPG does the same for the revocation certs created with the key. In interactive mode the user is asked for a reason and an optional description. > the packet for compatibility reasons, but we can't remember the > specifics at this point. To support v3 keys. > We could now either set the flag to false, or drop the subpacket > altogether. I have no strong preference, would probably just drop the > critical bit to change as little as necessary. Any thoughts? That would certainly be helpful. 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 justus at g10code.com Fri Apr 7 13:23:27 2017 From: justus at g10code.com (Justus Winter) Date: Fri, 07 Apr 2017 13:23:27 +0200 Subject: [PATCH GPGME] python: simplify build, some fixups In-Reply-To: <20170405164708.14269-1-alon.barlev@gmail.com> References: <20170405164708.14269-1-alon.barlev@gmail.com> Message-ID: <87h920tqa8.fsf@europa.jade-hamburg.de> Alon Bar-Lev writes: > * lang/python/gpg/version.py.in: Rename to lang/python/version.py.in. > configure.ac: Generate version.py.in in lang/python > * lang/python/MANIFEST.in: Include version.py explicitly. > * lang/python/gpg: Rename to gpg-src I changed 'gpg-src' to 'src' because the other bindings also have their sources in 'src'. Merged, many thanks! Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From wk at gnupg.org Fri Apr 7 14:28:31 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 Apr 2017 14:28:31 +0200 Subject: [PATCH GPA] po czech translation update In-Reply-To: (Zdenek Hatas's message of "Tue, 4 Apr 2017 09:51:23 +0200") References: Message-ID: <87o9w8e70w.fsf@wheatstone.g10code.de> On Tue, 4 Apr 2017 09:51, zdenek.hatas at gmail.com said: > Here I send update to GPA Czech translation. Thanks. We track that as https://dev.gnupg.org/T3046 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 Alexander.Strobel at giepa.de Fri Apr 7 14:52:57 2017 From: Alexander.Strobel at giepa.de (Alexander Strobel) Date: Fri, 7 Apr 2017 14:52:57 +0200 Subject: GnuPG 2.1 not reading from Windows registry Message-ID: <1c09be36-5b91-9243-8788-6cc173227f4c@giepa.de> There seems to be a problem in GnuPG 2.1.x when reading from the Windows registry. The default_homedir() function in "homedir.c" uses the following code to read from the registry: tmp = read_w32_registry_string (NULL, GNUPG_REGISTRY_DIR, "HomeDir"); GNUPG_REGISTRY_DIR is defined with leading back slashes. If you remove the leading back slashes passed to read_w32_registry_string the correct value is returned. There is a thread describes problems with leading back slashes: https://groups.google.com/forum/#!topic/microsoft.public.vc.language/vy_faecyIkM > For RegCreateKeyEx, the documentation says: > The subkey name specified by lpSubKey must not begin with the backslash > character ('\'). If it does, ERROR_BAD_PATHNAME is returned. > > Windows Me/98/95: Beginning backslash characters in the subkey name > specified by lpSubKey are ignored. > I think, the same requirement applies to RegOpenKeyEx, even though it's not > mentioned. Best regards Alex Strobel gpg4o.com From alon.barlev at gmail.com Fri Apr 7 16:32:18 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 7 Apr 2017 17:32:18 +0300 Subject: [PATCH GPGME] tests: Do not use check-local magic as dependency Message-ID: <20170407143218.4810-1-alon.barlev@gmail.com> * tests/gpg/Makefile.am: Use BUILT_SOURCES instead of check-local and initial.test. * lang/qt/tests/Makefile.am: Ditto. -- This fixes "make dist" failure when source tree is clean: git clean -dxf autoreconf -ivf ./configure make dist BUILT_SOURCES should be used when file as generated without explicit dependency. The check-local is all-am dependency, this means that it will be resolved also in "make dist". Signed-off-by: Alon Bar-Lev --- lang/qt/tests/Makefile.am | 12 +++--------- tests/gpg/Makefile.am | 9 ++------- 2 files changed, 5 insertions(+), 16 deletions(-) diff --git a/lang/qt/tests/Makefile.am b/lang/qt/tests/Makefile.am index 93dce07..fb45eec 100644 --- a/lang/qt/tests/Makefile.am +++ b/lang/qt/tests/Makefile.am @@ -43,12 +43,6 @@ AM_CPPFLAGS = -I$(top_srcdir)/lang/cpp/src -I$(top_builddir)/src \ -I$(top_srcdir)/lang/qt/src \ -DTOP_SRCDIR="$(top_srcdir)" -check-local: ./pubring-stamp - -# To guarantee that check-local is run before any tests we -# add this dependency: -initial.test : check-local - support_src = t-support.h t-support.cpp t_keylist_SOURCES = t-keylist.cpp $(support_src) @@ -64,7 +58,7 @@ run_keyformailboxjob_SOURCES = run-keyformailboxjob.cpp nodist_t_keylist_SOURCES = $(moc_files) -BUILT_SOURCES = $(moc_files) +BUILT_SOURCES = $(moc_files) pubring-stamp noinst_PROGRAMS = t-keylist t-keylocate t-ownertrust t-tofuinfo t-encrypt \ run-keyformailboxjob t-wkspublish t-verify t-various t-config @@ -79,7 +73,7 @@ clean-local: export GNUPGHOME := $(abs_builddir) -./pubring-stamp: $(top_srcdir)/tests/gpg/pubdemo.asc \ +pubring-stamp: $(top_srcdir)/tests/gpg/pubdemo.asc \ $(top_srcdir)/tests/gpg/secdemo.asc echo "ignore-invalid-option allow-loopback-pinentry" > $(abs_builddir)/gpg-agent.conf echo "allow-loopback-pinentry" >> gpg-agent.conf @@ -90,7 +84,7 @@ export GNUPGHOME := $(abs_builddir) $(GPG) --no-permission-warning \ --passphrase "abc" \ --import $(top_srcdir)/tests/gpg/secdemo.asc - touch ./pubring-stamp + touch pubring-stamp .cpp.moc: $(MOC) `test -f '$<' || echo '$(srcdir)/'`$< -o $@ diff --git a/tests/gpg/Makefile.am b/tests/gpg/Makefile.am index 9b74ba6..1d9a6df 100644 --- a/tests/gpg/Makefile.am +++ b/tests/gpg/Makefile.am @@ -60,6 +60,8 @@ EXTRA_DIST = initial.test final.test \ pubdemo.asc secdemo.asc cipher-1.asc cipher-2.asc \ geheim.txt pubkey-1.asc seckey-1.asc pinentry $(private_keys) +BUILT_SOURCES = gpg.conf gpg-agent.conf pubring-stamp \ + private-keys-v1.d/gpg-sample.stamp AM_CPPFLAGS = -I$(top_builddir)/src @GPG_ERROR_CFLAGS@ AM_LDFLAGS = -no-install LDADD = ../../src/libgpgme.la @@ -82,13 +84,6 @@ clean-local: -$(top_srcdir)/tests/start-stop-agent --stop -rm -fR private-keys-v1.d -check-local: ./gpg.conf ./gpg-agent.conf ./pubring-stamp \ - ./private-keys-v1.d/gpg-sample.stamp - -# To guarantee that check-local is run before any tests we -# add this dependency: -initial.test : check-local - export GNUPGHOME := $(abs_builddir) export GPG_AGENT_INFO := -- 2.10.2 From alon.barlev at gmail.com Fri Apr 7 16:31:47 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 7 Apr 2017 17:31:47 +0300 Subject: [PATCH GPGME] python: support .pydistutils.cfg mode Message-ID: <20170407143147.4671-1-alon.barlev@gmail.com> * lang/python/setup.py.in: Do not parse arguments. -- The distutils settings can come from either command-line or configuration file. Parsing parameters is not working in all cases. Signed-off-by: Alon Bar-Lev --- lang/python/setup.py.in | 25 ++++++++++--------------- 1 file changed, 10 insertions(+), 15 deletions(-) diff --git a/lang/python/setup.py.in b/lang/python/setup.py.in index 5d94c70..e50971c 100755 --- a/lang/python/setup.py.in +++ b/lang/python/setup.py.in @@ -19,18 +19,12 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA from distutils.core import setup, Extension -import argparse import os, os.path, sys import glob import re import shutil import subprocess -# We parse a subset of the arguments. -parser = argparse.ArgumentParser(add_help=False) -parser.add_argument('--build-base', default='') -options, _ = parser.parse_known_args() - # Out-of-tree build of the gpg bindings. gpg_error_config = ["gpg-error-config"] gpgme_config_flags = ["--thread=pthread"] @@ -142,8 +136,6 @@ if uname_s.startswith("MINGW32"): def in_srcdir(name): return os.path.join(os.environ.get("srcdir", ""), name) -def in_build_base(name): - return os.path.join(options.build_base, name) def up_to_date(source, target): return (os.path.exists(target) and os.path.getmtime(source) <= os.path.getmtime(target)) @@ -190,6 +182,9 @@ class BuildExtFirstHack(build): continue sink.write(rewrite_re.sub(r'%constant long \1 = \1;'+'\n', line.strip())) + def _in_build_base(self, name): + return os.path.join(self.build_base, name) + def _generate(self): print("Building python gpg module using {} and {}.".format(gpgme_h, gpg_error_h)) @@ -197,18 +192,18 @@ class BuildExtFirstHack(build): if not os.path.exists(self.build_base): os.makedirs(self.build_base) - self._generate_gpgme_h(gpgme_h, in_build_base("gpgme.h")) - self._generate_errors_i(gpg_error_h, in_build_base("errors.i")) + self._generate_gpgme_h(gpgme_h, self._in_build_base("gpgme.h")) + self._generate_errors_i(gpg_error_h, self._in_build_base("errors.i")) # Keep timestamp to avoid rebuild - for source, target in ((gpgme_h, in_build_base("gpgme.h")), - (gpg_error_h, in_build_base("errors.i"))): + for source, target in ((gpgme_h, self._in_build_base("gpgme.h")), + (gpg_error_h, self._in_build_base("errors.i"))): if not up_to_date(source, target): shutil.copystat(source, target) # Copy due to http://bugs.python.org/issue2624 # Avoid creating in srcdir - for source, target in ((in_srcdir(n), in_build_base(n)) + for source, target in ((in_srcdir(n), self._in_build_base(n)) for n in ('gpgme.i', 'helpers.c', 'private.h', 'helpers.h')): if not up_to_date(source, target): shutil.copy2(source, target) @@ -221,7 +216,7 @@ class BuildExtFirstHack(build): def run(self): self._generate() - swig_sources.append(os.path.join(self.build_base, 'gpgme.i')) + swig_sources.extend((self._in_build_base('gpgme.i'), self._in_build_base('helpers.c'))) swig_opts.extend(['-I' + self.build_base, '-outdir', os.path.join(self.build_lib, 'gpg')]) include_dirs.append(self.build_base) @@ -230,7 +225,7 @@ class BuildExtFirstHack(build): build.run(self) py3 = [] if sys.version_info.major < 3 else ['-py3'] -swig_sources = [in_build_base('helpers.c')] +swig_sources = [] swig_opts = ['-threads'] + py3 + extra_swig_opts swige = Extension("gpg._gpgme", sources = swig_sources, -- 2.10.2 From wk at gnupg.org Fri Apr 7 20:56:03 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 Apr 2017 20:56:03 +0200 Subject: [PATCH GPGME] tests: Do not use check-local magic as dependency In-Reply-To: <20170407143218.4810-1-alon.barlev@gmail.com> (Alon Bar-Lev's message of "Fri, 7 Apr 2017 17:32:18 +0300") References: <20170407143218.4810-1-alon.barlev@gmail.com> Message-ID: <874ly0caik.fsf@wheatstone.g10code.de> On Fri, 7 Apr 2017 16:32, alon.barlev at gmail.com said: > autoreconf -ivf FWIW: Please do not use autoreconf. All software the GnuPG Project maintains uses the script ./autogen.sh to create configure from sources distributed in the repo. 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 alon.barlev at gmail.com Fri Apr 7 21:25:05 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 7 Apr 2017 22:25:05 +0300 Subject: [PATCH GPGME] tests: Do not use check-local magic as dependency In-Reply-To: <874ly0caik.fsf@wheatstone.g10code.de> References: <20170407143218.4810-1-alon.barlev@gmail.com> <874ly0caik.fsf@wheatstone.g10code.de> Message-ID: On 7 April 2017 at 21:56, Werner Koch wrote: > On Fri, 7 Apr 2017 16:32, alon.barlev at gmail.com said: > >> autoreconf -ivf > > FWIW: Please do not use autoreconf. All software the GnuPG Project > maintains uses the script ./autogen.sh to create configure from sources > distributed in the repo. Thanks. I am aware of it. However, this issue was hidden and may be addressed if you are doing this one way or the other. The generation of the stamps should be done unless actually trying to build. Regardless, in recent years (more than I can remember) the autoreconf is doing a wonderful work, a complex autogen should not be required any more. But this is not why I submitted this fix. Regards, Alon From wk at gnupg.org Fri Apr 7 21:47:31 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 Apr 2017 21:47:31 +0200 Subject: [PATCH GPGME] tests: Do not use check-local magic as dependency In-Reply-To: (Alon Bar-Lev's message of "Fri, 7 Apr 2017 22:25:05 +0300") References: <20170407143218.4810-1-alon.barlev@gmail.com> <874ly0caik.fsf@wheatstone.g10code.de> Message-ID: <87d1coatkc.fsf@wheatstone.g10code.de> On Fri, 7 Apr 2017 21:25, alon.barlev at gmail.com said: > I am aware of it. I merely took the opportunity to state how we think about this. I know that Debian updates the autconf files too but that is up to them and in fact it makes sense for a sistro to do tha. This way they have identical support on all packages. We do it for the same reason: to exclude bugs from using different autoconf tools and to minimize differences between the configuraion of our developer's boxes. > is doing a wonderful work, a complex autogen should not be required > any more. But this is not why I submitted this fix. autogen.sh is our central configuration script which does things which can't be done in configure.ac. For example there are helper function to build a stable beta version number out of the git revision. Doing that with M4 macros turned out to be too fragile. 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 alon.barlev at gmail.com Sat Apr 8 15:34:28 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 8 Apr 2017 16:34:28 +0300 Subject: [PATCH GPGME 0/5] python: misc build fixes Message-ID: <20170408133433.23139-1-alon.barlev@gmail.com> This concludes the work to make the build downstream friendly. It enables to build using downstream specific build and test using the in-tree tests. It also support a distro wrapper instead of gpg-error.h. Alon Bar-Lev (5): python: support .pydistutils.cfg mode python: Remove usage of PYTHON_VERSIONS python: Remove unneeded stats copy python: Read gpg-error.h using the pre-processor python: Support alternatate libdir for tests configure.ac | 1 - lang/python/Makefile.am | 23 ++++++------ lang/python/setup.py.in | 85 +++++++++++++++++++++--------------------- lang/python/tests/run-tests.py | 25 ++++++++----- 4 files changed, 68 insertions(+), 66 deletions(-) -- 2.10.2 From alon.barlev at gmail.com Sat Apr 8 15:34:31 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 8 Apr 2017 16:34:31 +0300 Subject: [PATCH GPGME 3/5] python: Remove unneeded stats copy In-Reply-To: <20170408133433.23139-1-alon.barlev@gmail.com> References: <20170408133433.23139-1-alon.barlev@gmail.com> Message-ID: <20170408133433.23139-4-alon.barlev@gmail.com> * lang/python/setup.py.in: errors.i, gpgme.h are generated and always newer than the original. Signed-off-by: Alon Bar-Lev --- lang/python/setup.py.in | 6 ------ 1 file changed, 6 deletions(-) diff --git a/lang/python/setup.py.in b/lang/python/setup.py.in index e50971c..f4ce64f 100755 --- a/lang/python/setup.py.in +++ b/lang/python/setup.py.in @@ -195,12 +195,6 @@ class BuildExtFirstHack(build): self._generate_gpgme_h(gpgme_h, self._in_build_base("gpgme.h")) self._generate_errors_i(gpg_error_h, self._in_build_base("errors.i")) - # Keep timestamp to avoid rebuild - for source, target in ((gpgme_h, self._in_build_base("gpgme.h")), - (gpg_error_h, self._in_build_base("errors.i"))): - if not up_to_date(source, target): - shutil.copystat(source, target) - # Copy due to http://bugs.python.org/issue2624 # Avoid creating in srcdir for source, target in ((in_srcdir(n), self._in_build_base(n)) -- 2.10.2 From alon.barlev at gmail.com Sat Apr 8 15:34:29 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 8 Apr 2017 16:34:29 +0300 Subject: [PATCH GPGME 1/5] python: support .pydistutils.cfg mode In-Reply-To: <20170408133433.23139-1-alon.barlev@gmail.com> References: <20170408133433.23139-1-alon.barlev@gmail.com> Message-ID: <20170408133433.23139-2-alon.barlev@gmail.com> * lang/python/setup.py.in: Do not parse arguments. -- The distutils settings can come from either command-line or configuration file. Parsing parameters is not working in all cases. Signed-off-by: Alon Bar-Lev --- lang/python/setup.py.in | 25 ++++++++++--------------- 1 file changed, 10 insertions(+), 15 deletions(-) diff --git a/lang/python/setup.py.in b/lang/python/setup.py.in index 5d94c70..e50971c 100755 --- a/lang/python/setup.py.in +++ b/lang/python/setup.py.in @@ -19,18 +19,12 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA from distutils.core import setup, Extension -import argparse import os, os.path, sys import glob import re import shutil import subprocess -# We parse a subset of the arguments. -parser = argparse.ArgumentParser(add_help=False) -parser.add_argument('--build-base', default='') -options, _ = parser.parse_known_args() - # Out-of-tree build of the gpg bindings. gpg_error_config = ["gpg-error-config"] gpgme_config_flags = ["--thread=pthread"] @@ -142,8 +136,6 @@ if uname_s.startswith("MINGW32"): def in_srcdir(name): return os.path.join(os.environ.get("srcdir", ""), name) -def in_build_base(name): - return os.path.join(options.build_base, name) def up_to_date(source, target): return (os.path.exists(target) and os.path.getmtime(source) <= os.path.getmtime(target)) @@ -190,6 +182,9 @@ class BuildExtFirstHack(build): continue sink.write(rewrite_re.sub(r'%constant long \1 = \1;'+'\n', line.strip())) + def _in_build_base(self, name): + return os.path.join(self.build_base, name) + def _generate(self): print("Building python gpg module using {} and {}.".format(gpgme_h, gpg_error_h)) @@ -197,18 +192,18 @@ class BuildExtFirstHack(build): if not os.path.exists(self.build_base): os.makedirs(self.build_base) - self._generate_gpgme_h(gpgme_h, in_build_base("gpgme.h")) - self._generate_errors_i(gpg_error_h, in_build_base("errors.i")) + self._generate_gpgme_h(gpgme_h, self._in_build_base("gpgme.h")) + self._generate_errors_i(gpg_error_h, self._in_build_base("errors.i")) # Keep timestamp to avoid rebuild - for source, target in ((gpgme_h, in_build_base("gpgme.h")), - (gpg_error_h, in_build_base("errors.i"))): + for source, target in ((gpgme_h, self._in_build_base("gpgme.h")), + (gpg_error_h, self._in_build_base("errors.i"))): if not up_to_date(source, target): shutil.copystat(source, target) # Copy due to http://bugs.python.org/issue2624 # Avoid creating in srcdir - for source, target in ((in_srcdir(n), in_build_base(n)) + for source, target in ((in_srcdir(n), self._in_build_base(n)) for n in ('gpgme.i', 'helpers.c', 'private.h', 'helpers.h')): if not up_to_date(source, target): shutil.copy2(source, target) @@ -221,7 +216,7 @@ class BuildExtFirstHack(build): def run(self): self._generate() - swig_sources.append(os.path.join(self.build_base, 'gpgme.i')) + swig_sources.extend((self._in_build_base('gpgme.i'), self._in_build_base('helpers.c'))) swig_opts.extend(['-I' + self.build_base, '-outdir', os.path.join(self.build_lib, 'gpg')]) include_dirs.append(self.build_base) @@ -230,7 +225,7 @@ class BuildExtFirstHack(build): build.run(self) py3 = [] if sys.version_info.major < 3 else ['-py3'] -swig_sources = [in_build_base('helpers.c')] +swig_sources = [] swig_opts = ['-threads'] + py3 + extra_swig_opts swige = Extension("gpg._gpgme", sources = swig_sources, -- 2.10.2 From alon.barlev at gmail.com Sat Apr 8 15:34:32 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 8 Apr 2017 16:34:32 +0300 Subject: [PATCH GPGME 4/5] python: Read gpg-error.h using the pre-processor In-Reply-To: <20170408133433.23139-1-alon.barlev@gmail.com> References: <20170408133433.23139-1-alon.barlev@gmail.com> Message-ID: <20170408133433.23139-5-alon.barlev@gmail.com> * lang/python/setup.py.in: Read gpg-error.h using the pre-processor. -- The libgpg-error may be installed in multilib configuration in which there is a wrapper header at /usr/include that includes the actual header at /usr/include/*. This causes invalid errors.i generation. Let the pre-processor extract the header content instead reading it explicitly. Signed-off-by: Alon Bar-Lev --- lang/python/setup.py.in | 60 ++++++++++++++++++++++++++++--------------------- 1 file changed, 35 insertions(+), 25 deletions(-) diff --git a/lang/python/setup.py.in b/lang/python/setup.py.in index f4ce64f..a1279f8 100755 --- a/lang/python/setup.py.in +++ b/lang/python/setup.py.in @@ -55,13 +55,6 @@ else: devnull = open(os.devnull, "w") try: - subprocess.check_call(gpg_error_config + ['--version'], - stdout=devnull) -except: - sys.exit("Could not find gpg-error-config. " + - "Please install the libgpg-error development package.") - -try: subprocess.check_call(gpgme_config + ['--version'], stdout=devnull) except: @@ -84,13 +77,6 @@ if not (major > 1 or (major == 1 and minor >= 7)): if not gpgme_h: gpgme_h = os.path.join(getconfig("prefix")[0], "include", "gpgme.h") -gpg_error_prefix = getconfig("prefix", config=gpg_error_config)[0] -gpg_error_h = os.path.join(gpg_error_prefix, "include", "gpg-error.h") -if not os.path.exists(gpg_error_h): - gpg_error_h = \ - glob.glob(os.path.join(gpg_error_prefix, "include", - "*", "gpg-error.h"))[0] - define_macros = [] libs = getconfig('libs') @@ -150,10 +136,27 @@ def up_to_date(source, target): from distutils.command.build import build class BuildExtFirstHack(build): + def _read_header(self, header, cflags): + tmp_include = self._in_build_base("include1.h") + with open(tmp_include, 'w') as f: + f.write("#include <%s>" % header) + return subprocess.check_output(os.environ.get('CPP', 'cc -E').split() + cflags + [tmp_include]).decode('utf-8') + + def _write_if_unchanged(self, target, content): + if os.path.exists(target): + with open(target) as f: + if f.read() == content: + return + + with open(target, "w") as sink: + sink.write(content) + def _generate_gpgme_h(self, source_name, sink_name): if up_to_date(source_name, sink_name): return + print("Using gpgme.h from {}".format(source_name)) + deprec_func = re.compile(r'^(.*typedef.*|.*\(.*\)|[^#]+\s+.+)' + r'\s*_GPGME_DEPRECATED(_OUTSIDE_GPGME)?\(.*\);\s*', re.S) @@ -169,31 +172,38 @@ class BuildExtFirstHack(build): text = '' sink.write(text) - def _generate_errors_i(self, source_name, sink_name): - if up_to_date(source_name, sink_name): - return + def _generate_errors_i(self): + + try: + subprocess.check_call(gpg_error_config + ['--version'], + stdout=devnull) + except: + sys.exit("Could not find gpg-error-config. " + + "Please install the libgpg-error development package.") + + gpg_error_content = self._read_header("gpg-error.h", getconfig("cflags", config=gpg_error_config)) filter_re = re.compile(r'GPG_ERR_[^ ]* =') rewrite_re = re.compile(r' *(.*) = .*') - with open(sink_name, "w") as sink, open(source_name) as source: - for line in source: - if not filter_re.search(line): - continue - sink.write(rewrite_re.sub(r'%constant long \1 = \1;'+'\n', line.strip())) + errors_i_content = '' + for line in gpg_error_content.splitlines(): + if not filter_re.search(line): + continue + errors_i_content += rewrite_re.sub(r'%constant long \1 = \1;'+'\n', line.strip()) + + self._write_if_unchanged(self._in_build_base("errors.i"), errors_i_content) def _in_build_base(self, name): return os.path.join(self.build_base, name) def _generate(self): - print("Building python gpg module using {} and {}.".format(gpgme_h, gpg_error_h)) - # Cleanup gpgme.h from deprecated functions and typedefs. if not os.path.exists(self.build_base): os.makedirs(self.build_base) self._generate_gpgme_h(gpgme_h, self._in_build_base("gpgme.h")) - self._generate_errors_i(gpg_error_h, self._in_build_base("errors.i")) + self._generate_errors_i() # Copy due to http://bugs.python.org/issue2624 # Avoid creating in srcdir -- 2.10.2 From alon.barlev at gmail.com Sat Apr 8 15:34:30 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 8 Apr 2017 16:34:30 +0300 Subject: [PATCH GPGME 2/5] python: Remove usage of PYTHON_VERSIONS In-Reply-To: <20170408133433.23139-1-alon.barlev@gmail.com> References: <20170408133433.23139-1-alon.barlev@gmail.com> Message-ID: <20170408133433.23139-3-alon.barlev@gmail.com> * configure.ac: Remove PYTHON_VERSIONS subst. * lang/python/Makefile.am: Use basename of python as builddir prefix. * lang/python/tests/run-tests.py: Likewise. -- Two variables needs be at sync PYTHONS and PYTHON_VERSIONS, these may go out of sync in some cases, for example in Gentoo where default python is 3.4 we get: PYTHON='/usr/bin/python2' PYTHONS='/usr/bin/python /usr/bin/python2' PYTHON_VERSIONS='2.7 3.4' We can use the basename of the python interpreter to achieve similar effect without having to sync indexes between these two variables. Signed-off-by: Alon Bar-Lev --- configure.ac | 1 - lang/python/Makefile.am | 23 +++++++++++------------ lang/python/tests/run-tests.py | 4 ++-- 3 files changed, 13 insertions(+), 15 deletions(-) diff --git a/configure.ac b/configure.ac index 9974abb..becd156 100644 --- a/configure.ac +++ b/configure.ac @@ -474,7 +474,6 @@ if test "$found_py" = "1" -o "$found_py2" = "1" -o "$found_py3" = "1"; then fi AC_SUBST(PYTHONS, $PYTHONS) - AC_SUBST(PYTHON_VERSIONS, $PYTHON_VERSIONS) fi fi diff --git a/lang/python/Makefile.am b/lang/python/Makefile.am index 4ebd214..90075f7 100644 --- a/lang/python/Makefile.am +++ b/lang/python/Makefile.am @@ -38,12 +38,11 @@ copystamp: touch $@ all-local: copystamp - set -e ; set $(PYTHONS); for VERSION in $(PYTHON_VERSIONS); do \ - PYTHON="$$1" ; shift ; \ + set -e ; for PYTHON in $(PYTHONS); do \ CFLAGS="$(CFLAGS)" \ srcdir="$(srcdir)" \ top_builddir="$(top_builddir)" \ - $$PYTHON setup.py build --verbose --build-base=python$${VERSION}-gpg ; \ + $$PYTHON setup.py build --verbose --build-base="$$(basename "$${PYTHON}")-gpg" ; \ done python$(PYTHON_VERSION)-gpg/dist/gpg-$(VERSION).tar.gz.asc: copystamp @@ -76,26 +75,26 @@ CLEANFILES = copystamp \ # permissions. clean-local: rm -rf -- build - for VERSION in $(PYTHON_VERSIONS); do \ - find python$${VERSION}-gpg* -type d ! -perm -200 -exec chmod u+w {} ';' ; \ - rm -rf -- python$${VERSION}-gpg* ; \ + for PYTHON in $(PYTHONS); do \ + find "$$(basename "$${PYTHON}")-gpg" -type d ! -perm -200 -exec chmod u+w {} ';' ; \ + rm -rf -- "$$(basename "$${PYTHON}")-gpg" ; \ done install-exec-local: - set -e ; set $(PYTHONS); for VERSION in $(PYTHON_VERSIONS); do \ - PYTHON="$$1" ; shift ; \ + set -e ; for PYTHON in $(PYTHONS); do \ srcdir="$(srcdir)" \ top_builddir="$(top_builddir)" \ $$PYTHON setup.py \ build \ - --build-base=python$${VERSION}-gpg \ + --build-base="$$(basename "$${PYTHON}")-gpg" \ install \ --prefix "$(DESTDIR)$(prefix)" \ --verbose ; \ done uninstall-local: - GV=$$(echo $(VERSION) | tr - _); for PV in $(PYTHON_VERSIONS); do \ - rm -rf -- "$(DESTDIR)$(prefix)"/lib*/python$$PV/site-packages/gpg \ -"$(DESTDIR)$(prefix)"/lib*/python$$PV/site-packages/gpg-$$GV-py$$PV.egg-info ; \ + GV=$$(echo $(VERSION) | tr - _); for PYTHON in $(PYTHONS); do \ + PLATLIB="$(prefix)/$$("$${PYTHON}" -c 'import sysconfig, os; print(os.path.relpath(sysconfig.get_path("platlib"), sysconfig.get_config_var("prefix")))')" ; \ + rm -rf -- "$(DESTDIR)$${PLATLIB}/gpg" \ + "$(DESTDIR)$${PLATLIB}"/gpg-$$GV-py*.egg-info ; \ done diff --git a/lang/python/tests/run-tests.py b/lang/python/tests/run-tests.py index 9e2fb78..f236712 100644 --- a/lang/python/tests/run-tests.py +++ b/lang/python/tests/run-tests.py @@ -70,8 +70,8 @@ for interpreter in args.interpreters: [interpreter, "-c", "import sys; print('{0}.{1}'.format(sys.version_info[0], sys.version_info[1]))"]).strip().decode() pattern = os.path.join(args.builddir, "..", - "python{0}-gpg".format(version), - "lib*"+version) + "{0}-gpg".format(os.path.basename(interpreter)), + "lib*") builddirs = glob.glob(pattern) if len(builddirs) == 0: sys.exit("Build directory matching {0!r} not found.".format(pattern)) -- 2.10.2 From alon.barlev at gmail.com Sat Apr 8 15:34:33 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 8 Apr 2017 16:34:33 +0300 Subject: [PATCH GPGME 5/5] python: Support alternatate libdir for tests In-Reply-To: <20170408133433.23139-1-alon.barlev@gmail.com> References: <20170408133433.23139-1-alon.barlev@gmail.com> Message-ID: <20170408133433.23139-6-alon.barlev@gmail.com> * lang/python/tests/run-tests.py: Add --python-libdir optional parameter. -- This will make the python tests usable for downstream that build python module outside of autotools build system. Signed-off-by: Alon Bar-Lev --- lang/python/tests/run-tests.py | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/lang/python/tests/run-tests.py b/lang/python/tests/run-tests.py index f236712..78a0ec2 100644 --- a/lang/python/tests/run-tests.py +++ b/lang/python/tests/run-tests.py @@ -51,6 +51,9 @@ parser.add_argument('--srcdir', type=str, parser.add_argument('--builddir', type=str, default=os.environ.get("abs_builddir", ""), help='Location of the tests.') +parser.add_argument('--python-libdir', type=str, + default=None, + help='Optional location of the in-tree module lib directory.') parser.add_argument('--parallel', action="store_true", default=False, help='Ignored. For compatibility with run-tests.scm.') @@ -69,18 +72,20 @@ for interpreter in args.interpreters: version = subprocess.check_output( [interpreter, "-c", "import sys; print('{0}.{1}'.format(sys.version_info[0], sys.version_info[1]))"]).strip().decode() - pattern = os.path.join(args.builddir, "..", - "{0}-gpg".format(os.path.basename(interpreter)), - "lib*") - builddirs = glob.glob(pattern) - if len(builddirs) == 0: - sys.exit("Build directory matching {0!r} not found.".format(pattern)) - elif len(builddirs) > 1: - sys.exit("Multiple build directories matching {0!r} found: {1}".format( - pattern, builddirs)) + if not args.python_libdir: + pattern = os.path.join(args.builddir, "..", + "{0}-gpg".format(os.path.basename(interpreter)), + "lib*") + libdirs = glob.glob(pattern) + if len(libdirs) == 0: + sys.exit("Build directory matching {0!r} not found.".format(pattern)) + elif len(libdirs) > 1: + sys.exit("Multiple build directories matching {0!r} found: {1}".format( + pattern, libdirs)) + python_libdir = libdirs[0] env = dict(os.environ) - env["PYTHONPATH"] = builddirs[0] + env["PYTHONPATH"] = python_libdir if not args.quiet: print("Running tests using {0} ({1})...".format(interpreter, version)) -- 2.10.2 From dan at dephekt.net Sat Apr 8 22:02:01 2017 From: dan at dephekt.net (Dan Snider) Date: Sat, 8 Apr 2017 15:02:01 -0500 Subject: GPGME keyserver/key retrieval operations Message-ID: I am working on a project that uses the Python GPGME 1.8 bindings. When the program encounters a BadSignature exception due to a missing public key in the keyring, I have the program call a 'refresh_keyring' method, passing the missing fingerprint to that function, so I can shell out to /usr/bin/gpg and run a --recv-keys operation against a remote key server using the passed fingerprint as the argument. After looking and searching through the GPGME PDF documentation, I did not find a mechanism in the library to retrieve keys or refresh the keyring from a remote keyserver. Am I just missing something obvious? If the functionality is not in the library, I'm just curious if Justus has considered it worthy of time or not to add it to the library sometime or if there's any thoughts on a better way to deal with auto-recovering from missing keys, if my approach is bad. Specific details on the issue I'm working on is available here for the curious or in case it adds context to my question: https://github.com/micahflee/torbrowser-launcher/issues/271 Thanks (in advance), as always, for your assistance! Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xD9A67A2E.asc Type: application/pgp-keys Size: 7485 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From justus at g10code.com Mon Apr 10 15:47:11 2017 From: justus at g10code.com (Justus Winter) Date: Mon, 10 Apr 2017 15:47:11 +0200 Subject: [PATCH GPGME 0/5] python: misc build fixes In-Reply-To: <20170408133433.23139-1-alon.barlev@gmail.com> References: <20170408133433.23139-1-alon.barlev@gmail.com> Message-ID: <87vaqcml28.fsf@europa.jade-hamburg.de> Hi :) Alon Bar-Lev writes: > This concludes the work to make the build downstream friendly. It enables > to build using downstream specific build and test using the in-tree tests. > It also support a distro wrapper instead of gpg-error.h. > > Alon Bar-Lev (5): > python: support .pydistutils.cfg mode > python: Remove usage of PYTHON_VERSIONS > python: Remove unneeded stats copy > python: Read gpg-error.h using the pre-processor > python: Support alternatate libdir for tests I merged all your patches with a small fixup. Many thanks for working on this :) Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From Amul.Shah at fisglobal.com Mon Apr 10 18:10:20 2017 From: Amul.Shah at fisglobal.com (Shah, Amul) Date: Mon, 10 Apr 2017 16:10:20 +0000 Subject: Follow-up to Crashes with gpg-agent 2.1.18 In-Reply-To: References: Message-ID: > From: Shah, Amul Sent: Wednesday, April 05, 2017 11:24 AM > Subject: Follow-up to Crashes with gpg-agent 2.1.18 > > I think that this is a follow up to a thread from January (last email in thread > https://lists.gnupg.org/pipermail/gnupg-devel/2017-January/032516.html) because it > started with me seeing the message "Ohhhh jeeee: ... this is a bug > (sexp.c:1433:do_vsexp_sscan)" in the gpg-agent log. Now in trying to reproduce the > error, the gpg- agent hits a PKDECRYPT failure claiming that it cannot allocate > memory. > > I tried debugging the error down into libgcrypt, but could not see where things > could go wrong unless the memory manager is not npthread safe. Since I made no > progress, I'm sending this mail along with a test case similar to the one from the > previous thread. > > Note that we don't encounter this problem with older GnuPG versions, GnuPG 2.15 > and earlier. > > Could someone take a look at this or give me some pointers on how I can help > myself? [amul:1] No hints or suggestions? I guess I'll file a bug report instead and downgrade my Software. Amul The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From dkg at fifthhorseman.net Mon Apr 10 21:55:18 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 10 Apr 2017 15:55:18 -0400 Subject: Follow-up to Crashes with gpg-agent 2.1.18 In-Reply-To: References: Message-ID: <87k26savh5.fsf@fifthhorseman.net> On Mon 2017-04-10 16:10:20 +0000, Shah, Amul wrote: >> From: Shah, Amul Sent: Wednesday, April 05, 2017 11:24 AM >> Subject: Follow-up to Crashes with gpg-agent 2.1.18 >> >> I think that this is a follow up to a thread from January (last email in thread >> https://lists.gnupg.org/pipermail/gnupg-devel/2017-January/032516.html) because it >> started with me seeing the message "Ohhhh jeeee: ... this is a bug >> (sexp.c:1433:do_vsexp_sscan)" in the gpg-agent log. Now in trying to reproduce the >> error, the gpg- agent hits a PKDECRYPT failure claiming that it cannot allocate >> memory. >> >> I tried debugging the error down into libgcrypt, but could not see where things >> could go wrong unless the memory manager is not npthread safe. Since I made no >> progress, I'm sending this mail along with a test case similar to the one from the >> previous thread. >> >> Note that we don't encounter this problem with older GnuPG versions, GnuPG 2.15 >> and earlier. >> >> Could someone take a look at this or give me some pointers on how I can help >> myself? > > [amul:1] No hints or suggestions? I guess I'll file a bug report instead and downgrade my > Software. Could you try with the version in debian experimental (2.1.20)? I believe the "Ohhh jeeee" crash was fixed upstream by commit e175152ef7515921635bf1e00383e812668d13fc --dkg From Amul.Shah at fisglobal.com Mon Apr 10 22:31:40 2017 From: Amul.Shah at fisglobal.com (Shah, Amul) Date: Mon, 10 Apr 2017 20:31:40 +0000 Subject: Follow-up to Crashes with gpg-agent 2.1.18 In-Reply-To: <87k26savh5.fsf@fifthhorseman.net> References: <87k26savh5.fsf@fifthhorseman.net> Message-ID: > From: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] Sent: Monday, April 10, 2017 3:55 PM > > On Mon 2017-04-10 16:10:20 +0000, Shah, Amul wrote: > >> From: Shah, Amul Sent: Wednesday, April 05, 2017 11:24 AM > >> Subject: Follow-up to Crashes with gpg-agent 2.1.18 > >> > >> I think that this is a follow up to a thread from January (last email > >> in thread > >> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli > >> sts.gnupg.org%2Fpipermail%2Fgnupg-devel%2F2017- > January%2F032516.html& > >> > data=01%7C01%7CAmul.Shah%40fisglobal.com%7Cdcd940ffdc2e4e47cf0608 > d480 > >> > 4b87dc%7Ce3ff91d834c84b15a0b418910a6ac575%7C0&sdata=qqETArFrGjgm > gOQFu > >> 30JIawLjopx0VegGTzapNmtxco%3D&reserved=0) because it started with > me seeing the message "Ohhhh jeeee: ... this is a bug > (sexp.c:1433:do_vsexp_sscan)" in the gpg-agent log. Now in trying to > reproduce the error, the gpg- agent hits a PKDECRYPT failure claiming that it > cannot allocate memory. > >> > >> I tried debugging the error down into libgcrypt, but could not see > >> where things could go wrong unless the memory manager is not > npthread > >> safe. Since I made no progress, I'm sending this mail along with a > >> test case similar to the one from the previous thread. > >> > >> Note that we don't encounter this problem with older GnuPG versions, > >> GnuPG 2.15 and earlier. > >> > >> Could someone take a look at this or give me some pointers on how I > >> can help myself? > > > > [amul:1] No hints or suggestions? I guess I'll file a bug report > > instead and downgrade my Software. > > Could you try with the version in debian experimental (2.1.20)? I believe > the "Ohhh jeeee" crash was fixed upstream by commit > e175152ef7515921635bf1e00383e812668d13fc > > --dkg I didn't try 2.20 since I didn't see anything promising in git log. I will give it a try since you asked. Next time I write back, I'll try to include some more useful details like a stack trace of all threads at the point of failure. Debian 9's gnupg-2.18-6 has that patch (see below). I thought you were the one who put it in. :) $ apt-get source gnupg $ cd gnupg2-2.1.18 $ cat debian/patches/0017-agent-Fix-double-free.patch From: Justus Winter Date: Wed, 25 Jan 2017 13:51:57 +0100 Subject: agent: Fix double free. * agent/cache.c (agent_store_cache_hit): Make sure the update is atomic. -- Previously, the function freed the last key, and duplicated the new key after doing that. There is a chance, however, that calling the allocator surrenders control to a different thread, causing a double free if a different thread also calls this function. To make sure the update is atomic under the non-preemptive thread model, we must make sure not to surrender control to a different thread. Therefore, we avoid calling the allocator during the update. Signed-off-by: Justus Winter (cherry picked from commit e175152ef7515921635bf1e00383e812668d13fc) .... Thanks, Amul The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From alon.barlev at gmail.com Tue Apr 11 00:55:13 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 11 Apr 2017 01:55:13 +0300 Subject: [PATCH GPGME] python: fix run-tests missing python_libdir Message-ID: <20170410225513.22904-1-alon.barlev@gmail.com> * lang/python/tests/run-tests.py: Set python_libdir if --python-libdir is set. Signed-off-by: Alon Bar-Lev --- lang/python/tests/run-tests.py | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lang/python/tests/run-tests.py b/lang/python/tests/run-tests.py index 78a0ec2..95df197 100644 --- a/lang/python/tests/run-tests.py +++ b/lang/python/tests/run-tests.py @@ -72,7 +72,9 @@ for interpreter in args.interpreters: version = subprocess.check_output( [interpreter, "-c", "import sys; print('{0}.{1}'.format(sys.version_info[0], sys.version_info[1]))"]).strip().decode() - if not args.python_libdir: + if args.python_libdir: + python_libdir = args.python_libdir + else: pattern = os.path.join(args.builddir, "..", "{0}-gpg".format(os.path.basename(interpreter)), "lib*") -- 2.10.2 From alon.barlev at gmail.com Tue Apr 11 00:56:43 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 11 Apr 2017 01:56:43 +0300 Subject: [PATCH GPGME 0/5] python: misc build fixes In-Reply-To: <87vaqcml28.fsf@europa.jade-hamburg.de> References: <20170408133433.23139-1-alon.barlev@gmail.com> <87vaqcml28.fsf@europa.jade-hamburg.de> Message-ID: On 10 April 2017 at 16:47, Justus Winter wrote: > > Hi :) > > Alon Bar-Lev writes: > > > This concludes the work to make the build downstream friendly. It enables > > to build using downstream specific build and test using the in-tree tests. > > It also support a distro wrapper instead of gpg-error.h. > > > > Alon Bar-Lev (5): > > python: support .pydistutils.cfg mode > > python: Remove usage of PYTHON_VERSIONS > > python: Remove unneeded stats copy > > python: Read gpg-error.h using the pre-processor > > python: Support alternatate libdir for tests > > I merged all your patches with a small fixup. Many thanks for working > on this :) Thanks! One leftover, I sent a patch to fix. And one test that is failing, I will open a new thread. From alon.barlev at gmail.com Tue Apr 11 01:04:38 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 11 Apr 2017 02:04:38 +0300 Subject: [GPGME] python t-quick-key-manipulation.py fails Message-ID: Hi, All tests are passing except this one: --- Traceback (most recent call last): File "./t-quick-key-manipulation.py", line 112, in assert len(keys) == 1 AssertionError --- Happens for both python2.7 and python3.4. Any clue? len(keys) == 0 Thanks! Alon --- $ gpg --version gpg (GnuPG) 2.1.18 libgcrypt 1.7.6 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /home/alonbl/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 From alon.barlev at gmail.com Tue Apr 11 02:56:00 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 11 Apr 2017 03:56:00 +0300 Subject: [PATCH GPGME] python: use autoconf pre-processor when building via autoconf Message-ID: <20170411005600.3348-1-alon.barlev@gmail.com> * configure.ac: Add AC_PROG_CPP. * lang/python/Makefile.am: Set CPP environment for setup.py to use. Signed-off-by: Alon Bar-Lev --- configure.ac | 1 + lang/python/Makefile.am | 4 ++++ 2 files changed, 5 insertions(+) diff --git a/configure.ac b/configure.ac index becd156..b4878cc 100644 --- a/configure.ac +++ b/configure.ac @@ -109,6 +109,7 @@ AH_VERBATIM([_REENTRANT], #endif]) AC_PROG_CC +AC_PROG_CPP AC_PROG_CXX # Note: A suitable gitlog-to-changelog script can be found in GnuPG master. diff --git a/lang/python/Makefile.am b/lang/python/Makefile.am index 3fa98b5..8d74cbd 100644 --- a/lang/python/Makefile.am +++ b/lang/python/Makefile.am @@ -39,6 +39,7 @@ copystamp: all-local: copystamp set -e ; for PYTHON in $(PYTHONS); do \ + CPP="$(CPP)" \ CFLAGS="$(CFLAGS)" \ srcdir="$(srcdir)" \ top_builddir="$(top_builddir)" \ @@ -47,6 +48,7 @@ all-local: copystamp python$(PYTHON_VERSION)-gpg/dist/gpg-$(VERSION).tar.gz.asc: copystamp $(MKDIR_P) python$(PYTHON_VERSION)-gpg-dist + CPP="$(CPP)" \ CFLAGS="$(CFLAGS)" \ srcdir="$(srcdir)" \ top_builddir="$(top_builddir)" \ @@ -80,6 +82,8 @@ clean-local: install-exec-local: set -e ; for PYTHON in $(PYTHONS); do \ + CPP="$(CPP)" \ + CFLAGS="$(CFLAGS)" \ srcdir="$(srcdir)" \ top_builddir="$(top_builddir)" \ $$PYTHON setup.py \ -- 2.10.2 From justus at g10code.com Tue Apr 11 10:21:54 2017 From: justus at g10code.com (Justus Winter) Date: Tue, 11 Apr 2017 10:21:54 +0200 Subject: [GPGME] python t-quick-key-manipulation.py fails In-Reply-To: References: Message-ID: <87y3v7bbh9.fsf@europa.jade-hamburg.de> Alon Bar-Lev writes: > Hi, > > All tests are passing except this one: > --- > Traceback (most recent call last): > File "./t-quick-key-manipulation.py", line 112, in > assert len(keys) == 1 > AssertionError > --- > > Happens for both python2.7 and python3.4. > > Any clue? > len(keys) == 0 Does your GnuPG support the TOFU trust model? A way to check this is: gpg --trust-model=tofu --list-config This part of the test should probably be skipped if TOFU is not supported, but I don't know how to check that from GPGME. I'll have a look at the qt test for TOFU for inspiration. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From justus at g10code.com Tue Apr 11 10:23:29 2017 From: justus at g10code.com (Justus Winter) Date: Tue, 11 Apr 2017 10:23:29 +0200 Subject: [PATCH GPGME] python: fix run-tests missing python_libdir In-Reply-To: <20170410225513.22904-1-alon.barlev@gmail.com> References: <20170410225513.22904-1-alon.barlev@gmail.com> Message-ID: <87vaqbbbem.fsf@europa.jade-hamburg.de> Alon Bar-Lev writes: > * lang/python/tests/run-tests.py: Set python_libdir if --python-libdir > is set. Merged, thanks! Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From alon.barlev at gmail.com Tue Apr 11 10:29:58 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 11 Apr 2017 11:29:58 +0300 Subject: [GPGME] python t-quick-key-manipulation.py fails In-Reply-To: <87y3v7bbh9.fsf@europa.jade-hamburg.de> References: <87y3v7bbh9.fsf@europa.jade-hamburg.de> Message-ID: On 11 April 2017 at 11:21, Justus Winter wrote: > Alon Bar-Lev writes: > >> Hi, >> >> All tests are passing except this one: >> --- >> Traceback (most recent call last): >> File "./t-quick-key-manipulation.py", line 112, in >> assert len(keys) == 1 >> AssertionError >> --- >> >> Happens for both python2.7 and python3.4. >> >> Any clue? >> len(keys) == 0 > > Does your GnuPG support the TOFU trust model? A way to check this is: > > gpg --trust-model=tofu --list-config > > This part of the test should probably be skipped if TOFU is not > supported, but I don't know how to check that from GPGME. I'll have a > look at the qt test for TOFU for inspiration. Here: $ gpg --trust-model=tofu --list-config gpg: unknown trust model 'tofu' From aheinecke at intevation.de Tue Apr 11 11:24:28 2017 From: aheinecke at intevation.de (Andre Heinecke) Date: Tue, 11 Apr 2017 11:24:28 +0200 Subject: [GPGME] python t-quick-key-manipulation.py fails In-Reply-To: <87y3v7bbh9.fsf@europa.jade-hamburg.de> References: <87y3v7bbh9.fsf@europa.jade-hamburg.de> Message-ID: <5132026.KFn2xqrD00@esus> Hi, On Tuesday 11 April 2017 10:21:54 Justus Winter wrote: > This part of the test should probably be skipped if TOFU is not > supported, but I don't know how to check that from GPGME. I'll have a > look at the qt test for TOFU for inspiration. I don't know a proper way either. The Qt test just bails out if even a simple keylisting fails in the environment that has trust-model tofu+pgp. But I don't consider this a big problem for Applications / users of GPGME because it's basically the users fault if he has a GnuPG without tofu support (probably self compiled) and then activates this trust model. I even considered keeping the test failing in that case to show "Ok you have a setup where some things just don't work." but as GPGME should support all GnuPG versions I disabled it to avoid problems in such a case. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 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: 228 bytes Desc: This is a digitally signed message part. URL: From justus at g10code.com Tue Apr 11 11:28:29 2017 From: justus at g10code.com (Justus Winter) Date: Tue, 11 Apr 2017 11:28:29 +0200 Subject: [PATCH GPGME] python: use autoconf pre-processor when building via autoconf In-Reply-To: <20170411005600.3348-1-alon.barlev@gmail.com> References: <20170411005600.3348-1-alon.barlev@gmail.com> Message-ID: <87shlfb8ea.fsf@europa.jade-hamburg.de> Alon Bar-Lev writes: > * configure.ac: Add AC_PROG_CPP. > * lang/python/Makefile.am: Set CPP environment for setup.py to use. Merged, thanks! Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From alon.barlev at gmail.com Tue Apr 11 11:29:51 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 11 Apr 2017 12:29:51 +0300 Subject: [GPGME] python t-quick-key-manipulation.py fails In-Reply-To: <5132026.KFn2xqrD00@esus> References: <87y3v7bbh9.fsf@europa.jade-hamburg.de> <5132026.KFn2xqrD00@esus> Message-ID: On 11 April 2017 at 12:24, Andre Heinecke wrote: > > Hi, > > On Tuesday 11 April 2017 10:21:54 Justus Winter wrote: > > This part of the test should probably be skipped if TOFU is not > > supported, but I don't know how to check that from GPGME. I'll have a > > look at the qt test for TOFU for inspiration. > > I don't know a proper way either. The Qt test just bails out if even a simple > keylisting fails in the environment that has trust-model tofu+pgp. But I don't > consider this a big problem for Applications / users of GPGME because it's > basically the users fault if he has a GnuPG without tofu support (probably > self compiled) and then activates this trust model. > > I even considered keeping the test failing in that case to show "Ok you have a > setup where some things just don't work." but as GPGME should support all > GnuPG versions I disabled it to avoid problems in such a case. How can it be user fault if gnupg formally supports --disable-tofu? Tests should succeeded or skipped based on enabled features of gnupg. In Gentoo we are trying to support package configuration to allow choice of what features to enable, gnupg is included. Please skip tests and not fail if a valid supported feature is disabled. Thanks, Alon From aheinecke at intevation.de Tue Apr 11 12:21:03 2017 From: aheinecke at intevation.de (Andre Heinecke) Date: Tue, 11 Apr 2017 12:21:03 +0200 Subject: [GPGME] python t-quick-key-manipulation.py fails In-Reply-To: References: <5132026.KFn2xqrD00@esus> Message-ID: <3388219.X9TNJ1pSuZ@esus> Hi, On Tuesday 11 April 2017 12:29:51 Alon Bar-Lev wrote: > How can it be user fault if gnupg formally supports --disable-tofu? > Tests should succeeded or skipped based on enabled features of gnupg. > In Gentoo we are trying to support package configuration to allow > choice of what features to enable, gnupg is included. > Please skip tests and not fail if a valid supported feature is disabled. Well you can configure all kinds of stuff in GnuPG or worse, just install some parts of it (like gpg but no gpg-agent) to create broken setups. So I'm kind of wondering if GPGME's testsuite is not supposed to fail in cases where the GnuPG system is missing features. If you decide to live with that breakage / missing features then you just have to accept that the tests will fail. But the information that the features are missing is conveyed at build time instead of users facing Problems at runtime. For this specific point, disabled tofu, I agree that it truly should be optional but I'm starting to rethink / question if our approach to make the tests work against any GnuPG version is the right one or if it would be better for GPGME's test suite to fail and complain if something will not work with this GnuPG version. It's more about the problems we had regarding 2.0.x support for the test suite so maybe that should be a different thread. E.g. Kleopatra has a selftest to check some basic GnuPG functionality on startup and if that fails it tells the user what's wrong and why it can't work with that and bails out. Instead of trying to handle every special installation that might be conceivable. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 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: 228 bytes Desc: This is a digitally signed message part. URL: From alon.barlev at gmail.com Tue Apr 11 12:27:49 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 11 Apr 2017 13:27:49 +0300 Subject: [GPGME] python t-quick-key-manipulation.py fails In-Reply-To: <3388219.X9TNJ1pSuZ@esus> References: <5132026.KFn2xqrD00@esus> <3388219.X9TNJ1pSuZ@esus> Message-ID: On 11 April 2017 at 13:21, Andre Heinecke wrote: > Hi, > > On Tuesday 11 April 2017 12:29:51 Alon Bar-Lev wrote: >> How can it be user fault if gnupg formally supports --disable-tofu? >> Tests should succeeded or skipped based on enabled features of gnupg. >> In Gentoo we are trying to support package configuration to allow >> choice of what features to enable, gnupg is included. >> Please skip tests and not fail if a valid supported feature is disabled. > > Well you can configure all kinds of stuff in GnuPG or worse, just install some > parts of it (like gpg but no gpg-agent) to create broken setups. So I'm kind > of wondering if GPGME's testsuite is not supposed to fail in cases where the > GnuPG system is missing features. If you decide to live with that breakage / > missing features then you just have to accept that the tests will fail. But > the information that the features are missing is conveyed at build time > instead of users facing Problems at runtime. > > For this specific point, disabled tofu, I agree that it truly should be > optional but I'm starting to rethink / question if our approach to make the > tests work against any GnuPG version is the right one or if it would be better > for GPGME's test suite to fail and complain if something will not work with > this GnuPG version. It's more about the problems we had regarding 2.0.x > support for the test suite so maybe that should be a different thread. > > E.g. Kleopatra has a selftest to check some basic GnuPG functionality on > startup and if that fails it tells the user what's wrong and why it can't work > with that and bails out. Instead of trying to handle every special > installation that might be conceivable. If gpgme must have specific feature set of gnupg then please explicitly state what configuration is supported. However, I thought that gpgme should be an API to whatever available in gnupg and it should not fail unless critical for its operation. Just to understand the resolution Gentoo has: + + bzip2 : Use the bzlib compression library - - doc : Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally + + gnutls : Add support for net-libs/gnutls (TLS 1.0 and SSL 3.0 support) - - ldap : Add LDAP support (Lightweight Directory Access Protocol) + + nls : Add Native Language Support (using gettext - GNU locale utilities) + + readline : Enable support for libreadline, a GNU line-editing library that almost everyone wants + + smartcard : Build scdaemon software. Enables usage of OpenPGP cards. For other type of smartcards, try app-crypt/gnupg-pkcs11-scd. Bring in dev-libs/libusb as a dependency; enable scdaemon. - - tofu : Enable support for Trust of First use trust model; requires dev-db/sqlite. - - tools : Install extra tools (including gpgsplit and gpg-zip). - - usb : Build direct CCID access for scdaemon; requires dev-libs/libusb. - - wks-server : Install the wks-server Thanks, Alon From justus at g10code.com Tue Apr 11 12:29:59 2017 From: justus at g10code.com (Justus Winter) Date: Tue, 11 Apr 2017 12:29:59 +0200 Subject: [GPGME] python t-quick-key-manipulation.py fails In-Reply-To: <3388219.X9TNJ1pSuZ@esus> References: <5132026.KFn2xqrD00@esus> <3388219.X9TNJ1pSuZ@esus> Message-ID: <87pogjb5js.fsf@europa.jade-hamburg.de> Andre Heinecke writes: > Hi, > > On Tuesday 11 April 2017 12:29:51 Alon Bar-Lev wrote: >> How can it be user fault if gnupg formally supports --disable-tofu? >> Tests should succeeded or skipped based on enabled features of gnupg. >> In Gentoo we are trying to support package configuration to allow >> choice of what features to enable, gnupg is included. >> Please skip tests and not fail if a valid supported feature is disabled. > > Well you can configure all kinds of stuff in GnuPG or worse, just install some > parts of it (like gpg but no gpg-agent) to create broken setups. So I'm kind > of wondering if GPGME's testsuite is not supposed to fail in cases where the > GnuPG system is missing features. If you decide to live with that breakage / > missing features then you just have to accept that the tests will fail. But > the information that the features are missing is conveyed at build time > instead of users facing Problems at runtime. > > For this specific point, disabled tofu, I agree that it truly should > be Agreed. Done. > optional but I'm starting to rethink / question if our approach to make the > tests work against any GnuPG version is the right one or if it would be better > for GPGME's test suite to fail and complain if something will not work with > this GnuPG version. It's more about the problems we had regarding 2.0.x > support for the test suite so maybe that should be a different thread. > > E.g. Kleopatra has a selftest to check some basic GnuPG functionality on > startup and if that fails it tells the user what's wrong and why it can't work > with that and bails out. Instead of trying to handle every special > installation that might be conceivable. I'd go even further. I believe GnuPG has way too many knobs, both in the programs as well as in the build system. I strongly believe that any configuration that we do not test as part of our continous integration setup is simply broken. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From jwilk at jwilk.net Tue Apr 11 10:49:46 2017 From: jwilk at jwilk.net (Jakub Wilk) Date: Tue, 11 Apr 2017 10:49:46 +0200 Subject: git clone over HTTPS Message-ID: <20170411084946.ssfqkq63tqf5jy6a@jwilk.net> https://git.gnupg.org/ reads: >For actual work you should clone a repository; use > > git clone https://git.gnupg.org/foo.git > >or > > git clone git://git.gnupg.org/foo.git > >and replace foo by the name of the project (e.g. gnupg or libgcrypt). The latter works fine, but the former doesn't work for me. I get: $ git clone https://git.gnupg.org/gnupg.git Cloning into 'gnupg'... fatal: repository 'https://git.gnupg.org/gnupg.git/' not found -- Jakub Wilk From ilf at zeromail.org Tue Apr 11 13:03:08 2017 From: ilf at zeromail.org (ilf) Date: Tue, 11 Apr 2017 13:03:08 +0200 Subject: git clone over HTTPS In-Reply-To: <20170411084946.ssfqkq63tqf5jy6a@jwilk.net> References: <20170411084946.ssfqkq63tqf5jy6a@jwilk.net> Message-ID: <20170411110308.GX26453@zeromail.org> This issue is being tracked here: https://dev.gnupg.org/T2844 Jakub Wilk: > fatal: repository 'https://git.gnupg.org/gnupg.git/' not found -- ilf ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From justus at g10code.com Tue Apr 11 13:06:10 2017 From: justus at g10code.com (Justus Winter) Date: Tue, 11 Apr 2017 13:06:10 +0200 Subject: git clone over HTTPS In-Reply-To: <20170411084946.ssfqkq63tqf5jy6a@jwilk.net> References: <20170411084946.ssfqkq63tqf5jy6a@jwilk.net> Message-ID: <87lgr7b3vh.fsf@europa.jade-hamburg.de> Jakub Wilk writes: > https://git.gnupg.org/ reads: > >>For actual work you should clone a repository; use >> >> git clone https://git.gnupg.org/foo.git >> >>or >> >> git clone git://git.gnupg.org/foo.git >> >>and replace foo by the name of the project (e.g. gnupg or libgcrypt). > > The latter works fine, but the former doesn't work for me. I get: > > $ git clone https://git.gnupg.org/gnupg.git > Cloning into 'gnupg'... > fatal: repository 'https://git.gnupg.org/gnupg.git/' not found https://dev.gnupg.org/T2844 Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From alon.barlev at gmail.com Tue Apr 11 13:33:17 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 11 Apr 2017 14:33:17 +0300 Subject: [GPGME] python t-quick-key-manipulation.py fails In-Reply-To: <87pogjb5js.fsf@europa.jade-hamburg.de> References: <5132026.KFn2xqrD00@esus> <3388219.X9TNJ1pSuZ@esus> <87pogjb5js.fsf@europa.jade-hamburg.de> Message-ID: Thank you! Can we please release 1.9.1 so that I can publish it downstream? Recent work was very important: 1. python: build: Reinstate prepare target. 2. python: build: Do not write into srcdir but into builddir. 3. python: build: Use pre-processor to load gpg-error.h. 4. python: build: Skip sync between PYTHONS and PYTHON_VERSIONS 5. python: tests: Skip TOFU if not enabled. 6. python: tests: Support python-libdir parameter to make it usable for downstream. 7. qt: tests: Skip TOFU if not enabled. Thanks, Alon From justus at g10code.com Tue Apr 11 13:48:41 2017 From: justus at g10code.com (Justus Winter) Date: Tue, 11 Apr 2017 13:48:41 +0200 Subject: [GPGME] python t-quick-key-manipulation.py fails In-Reply-To: References: <5132026.KFn2xqrD00@esus> <3388219.X9TNJ1pSuZ@esus> <87pogjb5js.fsf@europa.jade-hamburg.de> Message-ID: <87bms3b1wm.fsf@europa.jade-hamburg.de> Alon Bar-Lev writes: > Can we please release 1.9.1 so that I can publish it downstream? Unfortunately not until Werner returns from his vacation. I'd say it will have to wait to the 24th. You'll have to use patches for now. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From alon.barlev at gmail.com Tue Apr 11 13:49:49 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 11 Apr 2017 14:49:49 +0300 Subject: [GPGME] python t-quick-key-manipulation.py fails In-Reply-To: <87bms3b1wm.fsf@europa.jade-hamburg.de> References: <5132026.KFn2xqrD00@esus> <3388219.X9TNJ1pSuZ@esus> <87pogjb5js.fsf@europa.jade-hamburg.de> <87bms3b1wm.fsf@europa.jade-hamburg.de> Message-ID: On 11 April 2017 at 14:48, Justus Winter wrote: > > Alon Bar-Lev writes: > > > Can we please release 1.9.1 so that I can publish it downstream? > > Unfortunately not until Werner returns from his vacation. I'd say it > will have to wait to the 24th. You'll have to use patches for now. Thanks! I will wait, too many patches to publish. From Amul.Shah at fisglobal.com Wed Apr 12 16:41:32 2017 From: Amul.Shah at fisglobal.com (Shah, Amul) Date: Wed, 12 Apr 2017 14:41:32 +0000 Subject: Follow-up to Crashes with gpg-agent 2.1.18 In-Reply-To: References: <87k26savh5.fsf@fifthhorseman.net> Message-ID: > From: Shah, Amul Sent: Monday, April 10, 2017 4:32 PM > > From: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] Sent: Monday, > > April 10, 2017 3:55 PM > > > > On Mon 2017-04-10 16:10:20 +0000, Shah, Amul wrote: > > >> From: Shah, Amul Sent: Wednesday, April 05, 2017 11:24 AM > > >> Subject: Follow-up to Crashes with gpg-agent 2.1.18 > > >> > > >> I think that this is a follow up to a thread from January (last > > >> email in thread https://lists.gnupg.org/pipermail/gnupg-devel/2017-January/032486.html) > > because it started with me seeing the message "Ohhhh jeeee: ... this is a bug > > (sexp.c:1433:do_vsexp_sscan)" in the gpg-agent log. Now in trying to > > reproduce the error, the gpg- agent hits a PKDECRYPT failure claiming > > that it cannot allocate memory. > > >> > > >> I tried debugging the error down into libgcrypt, but could not see > > >> where things could go wrong unless the memory manager is not > > npthread > > >> safe. Since I made no progress, I'm sending this mail along with a > > >> test case similar to the one from the previous thread. > > >> > > >> Note that we don't encounter this problem with older GnuPG > > >> versions, GnuPG 2.15 and earlier. > > >> > > >> Could someone take a look at this or give me some pointers on how I > > >> can help myself? > > > > > > [amul:1] No hints or suggestions? I guess I'll file a bug report > > > instead and downgrade my Software. > > > > Could you try with the version in debian experimental (2.1.20)? I > > believe the "Ohhh jeeee" crash was fixed upstream by commit > > e175152ef7515921635bf1e00383e812668d13fc > > > > --dkg > > I didn't try 2.20 since I didn't see anything promising in git log. I will > give it a try since you asked. Next time I write back, I'll try to include > some more useful details like a stack trace of all threads at the point of > failure. > > Debian 9's gnupg-2.18-6 has that patch (see below). I thought you were the > one who put it in. :) > $ apt-get source gnupg > $ cd gnupg2-2.1.18 > $ cat debian/patches/0017-agent-Fix-double-free.patch > From: Justus Winter > Date: Wed, 25 Jan 2017 13:51:57 +0100 > Subject: agent: Fix double free. [snip] [amul] No luck with GPG 2.1.20. I turned up the agent logging all the way (--debug-level guru --debug-all) and repeated my testing. In the last few lines we see the bug message. 13817 2017-04-11 16:54:29 gpg-agent[973941] DBG: rsa_decrypt => Success 13818 2017-04-11 16:54:29 gpg-agent[973941] DBG: plain: [data="\x02\xc1-\xd1'\xaa\x13\x96`\x0ebH\x8d\xf0\x18\xc3q\xf6\xcaw\x1da\x8d\xe1\xcc\x9a\xc0\xe5\xfa\xf9\xa2\x14\xea!\x98\xaa1\xad\xe5A\xf4\xe1sXc\xb6b\x 13819 2017-04-11 16:54:29 gpg-agent[973941] DBG: chan_9 -> [ 44 20 28 35 3a 76 61 6c 75 65 32 35 35 3a 02 c1 ...(261 byte(s) skipped) ] 13820 2017-04-11 16:54:29 gpg-agent[973941] DBG: chan_9 -> OK 13821 2017-04-11 16:54:29 gpg-agent[973941] DBG: chan_9 <- [eof] 13822 2017-04-11 16:54:29 gpg-agent[973941] DBG: rsa_decrypt res:+02c12dd127aa1396600e62488df018c371f6ca771d618de1cc9ac0e5faf9a214 \ 13823 2017-04-11 16:54:29 gpg-agent[973941] DBG: ea2198aa31ade541f4e1735863b6628d840e471f654163ed444097553755db79 \ 13824 2017-04-11 16:54:29 gpg-agent[973941] DBG: 739f476f56fa57400333a7612198865275e41a7ab427434df30d931e272322c3 \ 13825 2017-04-11 16:54:29 gpg-agent[973941] DBG: a7c722a9b524c62ba90837f39627bce1afe26050e9a55e9d52af5135d876c9f3 \ 13826 2017-04-11 16:54:29 gpg-agent[973941] DBG: 3489d0ec4295c515813f2cb866f1424010b9a24e5d0e7ee40ec833d75229488f \ 13827 2017-04-11 16:54:29 gpg-agent[973941] DBG: 67473945b2484cb2e1448c9f278fff09bf3e5507cb1067a32d439ca82c229ac4 \ 13828 2017-04-11 16:54:29 gpg-agent[973941] DBG: b96c82419e1a0c74c8a64fd0f5cdade98464a5f4a95a3beb4f888a0009e61826 \ 13829 2017-04-11 16:54:29 gpg-agent[973941] DBG: d423ecd9250af4bdb50ebd83e64309228d3687d7f9e9919fa1ecd8a3431195 13830 2017-04-11 16:54:29 gpg-agent[973941] DBG: rsa_decrypt => Success 13831 2017-04-11 16:54:29 gpg-agent[973941] DBG: plain: [data="\x02\xc1-\xd1'\xaa\x13\x96`\x0ebH\x8d\xf0\x18\xc3q\xf6\xcaw\x1da\x8d\xe1\xcc\x9a\xc0\xe5\xfa\xf9\xa2\x14\xea!\x98\xaa1\xad\xe5A\xf4\xe1sXc\xb6b\x 13832 2017-04-11 16:54:29 gpg-agent[973941] DBG: chan_50 -> [ 44 20 28 35 3a 76 61 6c 75 65 32 35 35 3a 02 c1 ...(261 byte(s) skipped) ] 13833 2017-04-11 16:54:29 gpg-agent[973941] DBG: chan_50 -> OK 13834 2017-04-11 16:54:29 gpg-agent[973941] DBG: chan_50 <- [eof] 13835 2017-04-11 16:54:29 gpg-agent[973941] DBG: rsa_decrypt res: [out of core] 13836 2017-04-11 16:54:29 gpg-agent[973941] Ohhhh jeeee: ... this is a bug (../../src/sexp.c:1433:do_vsexp_sscan) (I can share the full log if that helps) I drilled into libgcrypt and saw that there is a lock, use_m_guard, but the threaded gpg-agent is not using it. Not using the memory manager's thread lock looks like a problem. I don't see where the current code would enable the memory guard (via GCRYCTL_ENABLE_M_GUARD). Am I barking up the wrong tree? Amul The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From steve at gpgtools.org Thu Apr 13 19:07:01 2017 From: steve at gpgtools.org (steve (GPGTools)) Date: Thu, 13 Apr 2017 19:07:01 +0200 Subject: name field restriction when creating key Message-ID: <355A8258-52F0-4721-AD31-F9735325E2D0@gpgtools.org> Dear all, we've recently noticed that gnupg imposes some interesting restrictions on the name field when creating a key. The name can either be empty or must have a minimum of 5 characters. Since that strikes us as kind of odd, we were wondering if someone could shed some light on why it was implemented this way. We're thinking of removing this restriction in GPG Keychain (by using the --batch option) and also wanted to make sure that the removal doesn't cause any potential incompatibilities or other problems. Best, Steve GPGTools -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From wlt-ml at o-sinc.com Thu Apr 13 22:26:12 2017 From: wlt-ml at o-sinc.com (William L. Thomson Jr.) Date: Thu, 13 Apr 2017 16:26:12 -0400 Subject: Pinentry grabbing keyboard and mouse Message-ID: I was recently discussing the EFL/Enlightenment version of Pinentry with the author of the patches previously sent to list, Mike Blumenkrantz. Mike based his work off the GTK version. I opened a task/ticket on the issue[1]. In looking at the QT and the newly added FLTK versions. I noticed neither seem to be, unless I missed something, grabbing the keyboard and mouse as the GTK version does. I am not sure if that is legacy or the proper way. Or why other versions do not seem to have that feature. Not sure if it is a requirement that pinentry be blocking, take over keyboard and mouse. Such that the window cannot be moved, nothing else done till passphrase entered, confirmation, etc. Or that was just the choice of the GTK author at the time of making that version. Which is the correct way? Is there a requirement on grabbing keyboard and mouse? How come other versions seem to lack such feature? I just want to be consistent with other versions. Also meet project requirements, etc. I will be looking to further Mike's work to get it accepted into Pinentry. Hopefully sooner than later, but I understand this process can take some time. Any information or assistance is greatly appreciated. Thank you! -- 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 ilf at zeromail.org Fri Apr 14 14:17:18 2017 From: ilf at zeromail.org (ilf) Date: Fri, 14 Apr 2017 14:17:18 +0200 Subject: name field restriction when creating key In-Reply-To: <355A8258-52F0-4721-AD31-F9735325E2D0@gpgtools.org> References: <355A8258-52F0-4721-AD31-F9735325E2D0@gpgtools.org> Message-ID: <20170414121718.GM26453@zeromail.org> steve (GPGTools): > we've recently noticed that gnupg imposes some interesting > restrictions on the name field when creating a key. The name can > either be empty or must have a minimum of 5 characters. Since that > strikes us as kind of odd, we were wondering if someone could shed > some light on why it was implemented this way. There's an option "allow-freeform-uid", described as: > Disable all checks on the form of the user ID while generating a new > one. This option should only be used in very special environments as > it does not ensure the de-facto standard format of user IDs. -- ilf ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From aheinecke at intevation.de Tue Apr 18 07:39:41 2017 From: aheinecke at intevation.de (Andre Heinecke) Date: Tue, 18 Apr 2017 07:39:41 +0200 Subject: Pinentry grabbing keyboard and mouse In-Reply-To: References: Message-ID: <2601647.XnFRBhgTKB@esus> Hi, On Thursday 13 April 2017 16:26:12 William L. Thomson Jr. wrote: > In looking at the QT and the newly added FLTK versions. I noticed > neither seem to be, unless I missed something, grabbing the keyboard > and mouse as the GTK version does. > > I am not sure if that is legacy or the proper way. Or why other versions > do not seem to have that feature. Not sure if it is a requirement that > pinentry be blocking, take over keyboard and mouse. Such that the > window cannot be moved, nothing else done till passphrase entered, > confirmation, etc. Or that was just the choice of the GTK author at the > time of making that version. > > Which is the correct way? > Is there a requirement on grabbing keyboard and mouse? > How come other versions seem to lack such feature? Speaking for Qt I "recently" changed that behavior from a global grab to a focus depending grab. Now only when the input field has focus the keyboard is grabbed, with the intention to protect a bit against dumb keyloggers. The discussion about this can be found here: https://lists.gnupg.org/pipermail/gnupg-devel/2016-June/031277.html The biggest concern speaking for the global grab was, as I understood it, that it might help users not to enter their passphrase in the wrong window (e.g. a chat window). My personal opinion is that the usability cost of global grabbing from a popup Window is too great for that advantage though. But others have different Opinions. > I just want to be consistent with other versions. Also meet project > requirements, etc. I don't think there is any grabbing requirement. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 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: 228 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Wed Apr 19 18:01:57 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 19 Apr 2017 12:01:57 -0400 Subject: name field restriction when creating key In-Reply-To: <355A8258-52F0-4721-AD31-F9735325E2D0@gpgtools.org> References: <355A8258-52F0-4721-AD31-F9735325E2D0@gpgtools.org> Message-ID: <87o9vs75e2.fsf@fifthhorseman.net> On Thu 2017-04-13 19:07:01 +0200, steve (GPGTools) wrote: > we've recently noticed that gnupg imposes some interesting > restrictions on the name field when creating a key. The name can > either be empty or must have a minimum of 5 characters. Since that > strikes us as kind of odd, we were wondering if someone could shed > some light on why it was implemented this way. > > We're thinking of removing this restriction in GPG Keychain (by using > the --batch option) and also wanted to make sure that the removal > doesn't cause any potential incompatibilities or other problems. I also recommend that toolkit developers (like gpgtools) should use --quick-gen-key (assuming you're depending on the 2.1.x branch of GnuPG, which you should be in 2017), which accepts an arbitrary string as the full User ID (no distinction between different "fields" at all). --dkg From matthew.summers at syapse.com Wed Apr 19 18:08:33 2017 From: matthew.summers at syapse.com (Matthew Summers) Date: Wed, 19 Apr 2017 11:08:33 -0500 Subject: Follow-up to Crashes with gpg-agent 2.1.18 In-Reply-To: References: <87k26savh5.fsf@fifthhorseman.net> Message-ID: On Mon, Apr 10, 2017 at 3:31 PM, Shah, Amul wrote: > > > Could you try with the version in debian experimental (2.1.20)? I believe > > the "Ohhh jeeee" crash was fixed upstream by commit > > e175152ef7515921635bf1e00383e812668d13fc Hello, I have been experiencing this problem for roughly a week and a half. Although that specific error (do_vsexp_sscan) appears intermittently, I can very reliably crash gpg-agent, cause a race that results in a second pin-entry, and/or cause memory allocation errors. The trick to reproducing this is to employ a high level of parallelism when calling `gpg -d` against some small example cipher text. I do this sort of thing, where the recipient is a new test id I created, 4096 bit RSA: $ echo "test" | gpg -aer test at example.com -o gpg.txt $ yes gpg.txt | head -100 | xargs -n 1 -P 5 gpg --decrypt -q # 5 processes works reliably $ yes gpg.txt | head -100 | xargs -n 1 -P 10 gpg --decrypt -q # 10 processes fails 50% of the time $ yes gpg.txt | head -100 | xargs -n 1 -P 100 gpg --decrypt -q # 100 processes fails 100% For versions, I started experiencing this problem with gnupg-2.1.18, but only after upgrading to nettle-3.3 and glib-2.50.3 (gnutls-3.3.26 was consistent). I later upgrade gnupg to 2.1.20 and the issue persisted. One interesting thing is that I was using 2.1.18 with great success in handling highly parallel tasks until the time of these upgrades. It is no small thing to track down every library that gnupg utilizes for the agent, so any help here would be wonderful. I am also happy to provide any further details regarding the test env I am using here, which is based on Gentoo. I intend to continue debugging as time permits. Thanks! Matt Summers From gerhard.poul at gmail.com Thu Apr 20 09:15:13 2017 From: gerhard.poul at gmail.com (Gerhard Poul) Date: Thu, 20 Apr 2017 07:15:13 +0000 Subject: gpg-agent with OpenSSH on Windows Message-ID: Hi, I've recently started using a Windows notebook at work and wanted to take this as an opportunity to use gpg-agent because I'm planning to use a YubiKey as well to sign future git commits. After reading about Microsoft's OpenSSH Port beta [1] that works from PowerShell I decided to try using it instead of PuTTY, but the ssh-add was not able to connect to gpg-agent. To figure out why I learned more than I wanted to know, but I guess that's how one usually gets involved in projects ;-) I opened an issue [2] and it seems that ssh-add has been adapted to use named pipes on Windows, wheres that is not the mechanism that gpg-agent currently uses. If my understanding of what I read over the last days is correct, then gpg-agent on Windows only works with enable-putty-support, but there is currently no client that works with enable-ssh-support and the enable-ssh-support does not currently use named pipes on Windows. Now I'd like to confirm with you whether my understanding is correct and whether there are any current plans in regards to using named pipes on Windows. If the enable-ssh-support is currently not working on Windows with any client anyway, then that could be ported to use the same mechanism that [1] uses and no functionality would be harmed. Is there currently any ongoing work in this direction? Has something like this already been discussed? Regards, Gerhard [1] https://github.com/PowerShell/Win32-OpenSSH/wiki/Project-Status [2] https://github.com/PowerShell/Win32-OpenSSH/issues/669#issuecomment-294310292 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Fri Apr 21 03:19:14 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 21 Apr 2017 10:19:14 +0900 Subject: Follow-up to Crashes with gpg-agent 2.1.18 In-Reply-To: References: <87k26savh5.fsf@fifthhorseman.net> Message-ID: <87bmrqblrh.fsf@iwagami.gniibe.org> Hello, Matthew Summers writes: > The trick to reproducing this is to employ a high level of parallelism > when calling `gpg -d` against some small example cipher text. [...] > For versions, I started experiencing this problem with gnupg-2.1.18, > but only after upgrading to nettle-3.3 and glib-2.50.3 (gnutls-3.3.26 > was consistent). I later upgrade gnupg to 2.1.20 and the issue > persisted. One interesting thing is that I was using 2.1.18 with great > success in handling highly parallel tasks until the time of these > upgrades. It is no small thing to track down every library that gnupg > utilizes for the agent, so any help here would be wonderful. Thank you for your information. GnuPG doesn't use nettle and glib, so, I wonder if it's related. Recently, after 2.1.20, I fixed a race in gpg-agent, which is possible to cause double free (and crash). https://dev.gnupg.org/T3027 This may be related. -- From matthew.summers at syapse.com Fri Apr 21 17:27:24 2017 From: matthew.summers at syapse.com (Matthew Summers) Date: Fri, 21 Apr 2017 10:27:24 -0500 Subject: Follow-up to Crashes with gpg-agent 2.1.18 In-Reply-To: <87bmrqblrh.fsf@iwagami.gniibe.org> References: <87k26savh5.fsf@fifthhorseman.net> <87bmrqblrh.fsf@iwagami.gniibe.org> Message-ID: On Thu, Apr 20, 2017 at 8:19 PM, NIIBE Yutaka wrote: > > Thank you for your information. > > GnuPG doesn't use nettle and glib, so, I wonder if it's related. > > Recently, after 2.1.20, I fixed a race in gpg-agent, which is > possible to cause double free (and crash). > > https://dev.gnupg.org/T3027 > > This may be related. That explanation in https://dev.gnupg.org/T3027#95879 sounds very accurate based on what I have seen. I'll give the patch a shot! The dependency chain for nettle is via gnutls, though I admit to not attempting to identify what dependency that might be. As far as glib, I am not sure why I thought that may be involved somehow ... maybe a socket routine or something. I apologize for incompleteness here, I have been time limited in debugging this issue as thoroughly as I would like to. Thanks! MattS From matthew.summers at syapse.com Fri Apr 21 18:55:01 2017 From: matthew.summers at syapse.com (Matthew Summers) Date: Fri, 21 Apr 2017 11:55:01 -0500 Subject: Follow-up to Crashes with gpg-agent 2.1.18 In-Reply-To: References: <87k26savh5.fsf@fifthhorseman.net> <87bmrqblrh.fsf@iwagami.gniibe.org> Message-ID: On Fri, Apr 21, 2017 at 10:27 AM, Matthew Summers wrote: > On Thu, Apr 20, 2017 at 8:19 PM, NIIBE Yutaka wrote: >> >> Thank you for your information. >> >> GnuPG doesn't use nettle and glib, so, I wonder if it's related. >> >> Recently, after 2.1.20, I fixed a race in gpg-agent, which is >> possible to cause double free (and crash). >> >> https://dev.gnupg.org/T3027 >> >> This may be related. > > > That explanation in https://dev.gnupg.org/T3027#95879 sounds very > accurate based on what I have seen. I'll give the patch a shot! Testing that patch in the ticket above, I am still encountering failures with parallelism greater than the number of CPU "cores" on my machine (8 cores). The behavior is somewhat interesting. On occasions I can force an error that looks like: gpg-agent[15942] failed to build S-Exp (off=0): Cannot allocate memory gpg-agent[15942] failed to read the secret key gpg-agent[15942] command 'PKDECRYPT' failed: Cannot allocate memory gpg-agent[15942] DBG: chan_16 -> ERR 16810070 Cannot allocate memory in this case, decryption totally fails. Whereas on other occasions I just get a new pin-entry pop up, with decryption succeeding in the end. It seems like there is a race for the socket, somehow, but I am not sure how to verify this. From wk at gnupg.org Sun Apr 23 19:01:23 2017 From: wk at gnupg.org (Werner Koch) Date: Sun, 23 Apr 2017 19:01:23 +0200 Subject: gpg-agent with OpenSSH on Windows In-Reply-To: (Gerhard Poul's message of "Thu, 20 Apr 2017 07:15:13 +0000") References: Message-ID: <8737czt5wb.fsf@wheatstone.g10code.de> On Thu, 20 Apr 2017 09:15, gerhard.poul at gmail.com said: > I opened an issue [2] and it seems that ssh-add has been adapted to use > named pipes on Windows, wheres that is not the mechanism that gpg-agent Arghh. Named Pipes under Windows are very hard to use as an emulation for local sockets. The problem is that there is no mechanism to make sure that they work only on the local machine. With the right credentials you can use them remotely - which is a bad idea to implement a local (ie. non-remote) IPC. Frankly, OpenSSH should not use that and resort to our or the new Cygwin way of emulating local sockets. On Unix we use plain local sockets. On Windows we listen on 127.0.0.1 for a TCP connection; the port and a cookie is given in a file created by the server and thus the connection is secured using file permissions. Cygwin does something very similar. Putty (and GnuPG's pageant support) support wraps the communication into Windows messages. 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: 194 bytes Desc: not available URL: From wk at gnupg.org Mon Apr 24 14:58:54 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Apr 2017 14:58:54 +0200 Subject: name field restriction when creating key In-Reply-To: <87o9vs75e2.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 19 Apr 2017 12:01:57 -0400") References: <355A8258-52F0-4721-AD31-F9735325E2D0@gpgtools.org> <87o9vs75e2.fsf@fifthhorseman.net> Message-ID: <87vapu7yi9.fsf@wheatstone.g10code.de> On Wed, 19 Apr 2017 18:01, dkg at fifthhorseman.net said: > I also recommend that toolkit developers (like gpgtools) should use > --quick-gen-key (assuming you're depending on the 2.1.x branch of GnuPG, > which you should be in 2017), which accepts an arbitrary string as the > full User ID (no distinction between different "fields" at all). Let me add that GPGME wraps this into the new gpgme_op_createkey API. See: https://gnupg.org/documentation/manuals/gpgme/Generating-Keys.html 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: 194 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Apr 26 03:27:41 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 25 Apr 2017 21:27:41 -0400 Subject: [PATCH] g10: Skip signing keys where no secret key is available. In-Reply-To: <6bda9d2a-ff86-f9b5-c6bd-e6347e6848fc@enigmail.net> References: <20170205213135.17465-1-dkg@fifthhorseman.net> <6bda9d2a-ff86-f9b5-c6bd-e6347e6848fc@enigmail.net> Message-ID: <87vaps6jqq.fsf@fifthhorseman.net> On Mon 2017-02-06 09:57:59 +0100, Patrick Brunschwig wrote: > Would this patch still issue a "MISSING_KEY" line for --status-fd? If > no, you break existing logic (which for example Enigmail relies on). in what case does enigmail expect a "MISSING_KEY" line? the scenario is that the user has a primary key A and two valid, non-expired, signing-capable subkeys, B and C. C is the newer subkey, and the user has specified that they want to sign with A. We'd like to go ahead and sign with B if it is available and C is missing. What should enigmail do in that case with a MISSING_KEY line? shouldn't it just accept that a valid signature has been made? I've pushed the proposed fix to a new git branch dkg/T1967, and updated https://dev.gnupg.org/T1967 to note that 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 dkg at fifthhorseman.net Wed Apr 26 03:17:38 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 25 Apr 2017 21:17:38 -0400 Subject: [STABLE-BRANCH-1-4 PATCH] g10: secmem leak In-Reply-To: <20170217085247.GM18144@gnu.org> References: <20160414161817.GA9527@gnu.org> <87r3e85bnp.fsf@wheatstone.g10code.de> <20170217085247.GM18144@gnu.org> Message-ID: <87y3uo6k7h.fsf@fifthhorseman.net> On Fri 2017-02-17 02:52:47 -0500, Ineiev wrote: > On Thu, Apr 14, 2016 at 07:43:22PM +0200, Werner Koch wrote: >> On Thu, 14 Apr 2016 18:18, ineiev at gnu.org said: >> >> > I attach a patch for GnuPG-bug 1371. in short, secure memory >> > is leaked because proc_parameter_file() adds new entries >> > to the head of the list of parameters, and these entries >> > aren't accessible to the caller that releases the list. >> >> Thanks for the patch - I will look at it later. > > It still applies. I've just pushed it to a git branch dkg/T1371, and linked to it from the phabricator issue: https://dev.gnupg.org/T1371 --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From patrick at enigmail.net Wed Apr 26 08:22:31 2017 From: patrick at enigmail.net (Patrick Brunschwig) Date: Wed, 26 Apr 2017 08:22:31 +0200 Subject: [PATCH] g10: Skip signing keys where no secret key is available. In-Reply-To: <87vaps6jqq.fsf@fifthhorseman.net> References: <20170205213135.17465-1-dkg@fifthhorseman.net> <6bda9d2a-ff86-f9b5-c6bd-e6347e6848fc@enigmail.net> <87vaps6jqq.fsf@fifthhorseman.net> Message-ID: <7a55fb10-98ad-164c-496f-a197ca5ae37e@enigmail.net> On 26.04.17 03:27, Daniel Kahn Gillmor wrote: > On Mon 2017-02-06 09:57:59 +0100, Patrick Brunschwig wrote: >> Would this patch still issue a "MISSING_KEY" line for --status-fd? If >> no, you break existing logic (which for example Enigmail relies on). > > in what case does enigmail expect a "MISSING_KEY" line? the scenario is > that the user has a primary key A and two valid, non-expired, > signing-capable subkeys, B and C. C is the newer subkey, and the user > has specified that they want to sign with A. We'd like to go ahead and > sign with B if it is available and C is missing. > > What should enigmail do in that case with a MISSING_KEY line? shouldn't > it just accept that a valid signature has been made? > > I've pushed the proposed fix to a new git branch dkg/T1967, and updated > https://dev.gnupg.org/T1967 to note that branch. Sorry, I meant INV_SGNR. Enigmail looks for this when a message is supposed to be signed but there is no suitable key. -Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From ineiev at gnu.org Wed Apr 26 16:58:34 2017 From: ineiev at gnu.org (Ineiev) Date: Wed, 26 Apr 2017 10:58:34 -0400 Subject: [STABLE-BRANCH-1-4 PATCH] g10: secmem leak In-Reply-To: <87y3uo6k7h.fsf@fifthhorseman.net> References: <20160414161817.GA9527@gnu.org> <87r3e85bnp.fsf@wheatstone.g10code.de> <20170217085247.GM18144@gnu.org> <87y3uo6k7h.fsf@fifthhorseman.net> Message-ID: <20170426145834.GN3854@gnu.org> On Tue, Apr 25, 2017 at 09:17:38PM -0400, Daniel Kahn Gillmor wrote: > > I've just pushed it to a git branch dkg/T1371, and linked to it from the > phabricator issue: > > https://dev.gnupg.org/T1371 Thank you! I thought the 1-4 branch is not supported any more. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Digital signature URL: From dkg at fifthhorseman.net Thu Apr 27 04:02:33 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 26 Apr 2017 19:02:33 -0700 Subject: [PATCH] g10: Skip signing keys where no secret key is available. In-Reply-To: <7a55fb10-98ad-164c-496f-a197ca5ae37e@enigmail.net> References: <20170205213135.17465-1-dkg@fifthhorseman.net> <6bda9d2a-ff86-f9b5-c6bd-e6347e6848fc@enigmail.net> <87vaps6jqq.fsf@fifthhorseman.net> <7a55fb10-98ad-164c-496f-a197ca5ae37e@enigmail.net> Message-ID: <87vapq6212.fsf@fifthhorseman.net> On Wed 2017-04-26 08:22:31 +0200, Patrick Brunschwig wrote: > On 26.04.17 03:27, Daniel Kahn Gillmor wrote: >> On Mon 2017-02-06 09:57:59 +0100, Patrick Brunschwig wrote: >>> Would this patch still issue a "MISSING_KEY" line for --status-fd? If >>> no, you break existing logic (which for example Enigmail relies on). >> >> in what case does enigmail expect a "MISSING_KEY" line? the scenario is >> that the user has a primary key A and two valid, non-expired, >> signing-capable subkeys, B and C. C is the newer subkey, and the user >> has specified that they want to sign with A. We'd like to go ahead and >> sign with B if it is available and C is missing. >> >> What should enigmail do in that case with a MISSING_KEY line? shouldn't >> it just accept that a valid signature has been made? >> >> I've pushed the proposed fix to a new git branch dkg/T1967, and updated >> https://dev.gnupg.org/T1967 to note that branch. > > Sorry, I meant INV_SGNR. Enigmail looks for this when a message is > supposed to be signed but there is no suitable key. So you're asking whether INV_SGNR shows up in the case where there really is *no* signing subkey, right? because if gpg finds a different signing subkey available and uses it successfully, you don't want it to appear. right? I just did the following test in a fresh $GNUPGHOME (manually extracting $PRIMARY_FPR and $SUBKEY0_GRIP from the relevant places), with the patch under discussion applied here. Note that i'm renaming private-keys-v1.d/*.key files to emulate removal of secret key material by any other means: gpg --quick-gen-key 'testing ' rsa cert gpg --quick-add-key ${PRIMARY_FPR} rsa sign # signing-capable subkey 0 gpg --with-keygrip --list-keys echo test | gpg -u 'testing ' --status-fd=2 --clearsign ## makes valid signature with subkey 0, no INV_SGNR mv $GNUPGHOME/private-keys-v1.d/${SUBKEY0_GRIP}{,.bak} echo test | gpg -u 'testing ' --status-fd=2 --clearsign ## produces INV_SGNR on stderr gpg --quick-add-key ${PRIMARY_FPR} rsa sign # signing-capable subkey 1 echo test | gpg -u 'testing ' --status-fd=2 --clearsign ## makes valid signature with subkey 1, no INV_SGNR mv $GNUPGHOME/private-keys-v1.d/${SUBKEY1_GRIP}{,.bak} echo test | gpg -u 'testing ' --status-fd=2 --clearsign ## produces INV_SGNR on stderr mv $GNUPGHOME/private-keys-v1.d/${SUBKEY1_GRIP}{,.bak} echo test | gpg -u 'testing ' --status-fd=2 --clearsign ## makes valid signature with subkey 0, no INV_SGNR This seems like the sensible logic to me -- as long as some signing-capable subkey is available. Does enigmail need something different? --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 Thu Apr 27 03:39:21 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 26 Apr 2017 18:39:21 -0700 Subject: [STABLE-BRANCH-1-4 PATCH] g10: secmem leak In-Reply-To: <20170426145834.GN3854@gnu.org> References: <20160414161817.GA9527@gnu.org> <87r3e85bnp.fsf@wheatstone.g10code.de> <20170217085247.GM18144@gnu.org> <87y3uo6k7h.fsf@fifthhorseman.net> <20170426145834.GN3854@gnu.org> Message-ID: <87y3um633q.fsf@fifthhorseman.net> On Wed 2017-04-26 10:58:34 -0400, Ineiev wrote: > On Tue, Apr 25, 2017 at 09:17:38PM -0400, Daniel Kahn Gillmor wrote: >> >> I've just pushed it to a git branch dkg/T1371, and linked to it from the >> phabricator issue: >> >> https://dev.gnupg.org/T1371 > > Thank you! I thought the 1-4 branch is not supported any more. support on 1.4 is low priority for the upstream team, but i don't think it's entirely EOL yet. 2.0 has an EOL at the end of this year, though. --dkg From patrick at enigmail.net Thu Apr 27 08:22:23 2017 From: patrick at enigmail.net (Patrick Brunschwig) Date: Thu, 27 Apr 2017 08:22:23 +0200 Subject: [PATCH] g10: Skip signing keys where no secret key is available. In-Reply-To: <87vapq6212.fsf@fifthhorseman.net> References: <20170205213135.17465-1-dkg@fifthhorseman.net> <6bda9d2a-ff86-f9b5-c6bd-e6347e6848fc@enigmail.net> <87vaps6jqq.fsf@fifthhorseman.net> <7a55fb10-98ad-164c-496f-a197ca5ae37e@enigmail.net> <87vapq6212.fsf@fifthhorseman.net> Message-ID: <15b42e71-1257-3bff-edc3-64a1b36ccb6d@enigmail.net> On 27.04.17 04:02, Daniel Kahn Gillmor wrote: > On Wed 2017-04-26 08:22:31 +0200, Patrick Brunschwig wrote: >> On 26.04.17 03:27, Daniel Kahn Gillmor wrote: >>> On Mon 2017-02-06 09:57:59 +0100, Patrick Brunschwig wrote: >>>> Would this patch still issue a "MISSING_KEY" line for --status-fd? If >>>> no, you break existing logic (which for example Enigmail relies on). >>> >>> in what case does enigmail expect a "MISSING_KEY" line? the scenario is >>> that the user has a primary key A and two valid, non-expired, >>> signing-capable subkeys, B and C. C is the newer subkey, and the user >>> has specified that they want to sign with A. We'd like to go ahead and >>> sign with B if it is available and C is missing. >>> >>> What should enigmail do in that case with a MISSING_KEY line? shouldn't >>> it just accept that a valid signature has been made? >>> >>> I've pushed the proposed fix to a new git branch dkg/T1967, and updated >>> https://dev.gnupg.org/T1967 to note that branch. >> >> Sorry, I meant INV_SGNR. Enigmail looks for this when a message is >> supposed to be signed but there is no suitable key. > > So you're asking whether INV_SGNR shows up in the case where there > really is *no* signing subkey, right? because if gpg finds a different > signing subkey available and uses it successfully, you don't want it to > appear. right? > > I just did the following test in a fresh $GNUPGHOME (manually extracting > $PRIMARY_FPR and $SUBKEY0_GRIP from the relevant places), with the patch > under discussion applied here. Note that i'm renaming > private-keys-v1.d/*.key files to emulate removal of secret key material > by any other means: > > > gpg --quick-gen-key 'testing ' rsa cert > gpg --quick-add-key ${PRIMARY_FPR} rsa sign # signing-capable subkey 0 > gpg --with-keygrip --list-keys > echo test | gpg -u 'testing ' --status-fd=2 --clearsign > ## makes valid signature with subkey 0, no INV_SGNR > mv $GNUPGHOME/private-keys-v1.d/${SUBKEY0_GRIP}{,.bak} > echo test | gpg -u 'testing ' --status-fd=2 --clearsign > ## produces INV_SGNR on stderr > gpg --quick-add-key ${PRIMARY_FPR} rsa sign # signing-capable subkey 1 > echo test | gpg -u 'testing ' --status-fd=2 --clearsign > ## makes valid signature with subkey 1, no INV_SGNR > mv $GNUPGHOME/private-keys-v1.d/${SUBKEY1_GRIP}{,.bak} > echo test | gpg -u 'testing ' --status-fd=2 --clearsign > ## produces INV_SGNR on stderr > mv $GNUPGHOME/private-keys-v1.d/${SUBKEY1_GRIP}{,.bak} > echo test | gpg -u 'testing ' --status-fd=2 --clearsign > ## makes valid signature with subkey 0, no INV_SGNR > > This seems like the sensible logic to me -- as long as some > signing-capable subkey is available. Does enigmail need something > different? Perfect - that's exactly what Enigmail would expect. Thanks, Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From alon.barlev at gmail.com Thu Apr 27 11:16:25 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Thu, 27 Apr 2017 12:16:25 +0300 Subject: [GPGME] python t-quick-key-manipulation.py fails In-Reply-To: References: <5132026.KFn2xqrD00@esus> <3388219.X9TNJ1pSuZ@esus> <87pogjb5js.fsf@europa.jade-hamburg.de> <87bms3b1wm.fsf@europa.jade-hamburg.de> Message-ID: On 11 April 2017 at 14:49, Alon Bar-Lev wrote: > On 11 April 2017 at 14:48, Justus Winter wrote: >> >> Alon Bar-Lev writes: >> >> > Can we please release 1.9.1 so that I can publish it downstream? >> >> Unfortunately not until Werner returns from his vacation. I'd say it >> will have to wait to the 24th. You'll have to use patches for now. > > Thanks! > I will wait, too many patches to publish. Hi, A kind reminder. Thanks! From dgouttegattat at incenp.org Thu Apr 27 14:41:40 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Thu, 27 Apr 2017 14:41:40 +0200 Subject: Status of --auto-key-locate ldap? Message-ID: <6c614e90-dc47-af16-12b1-5999414297a6@incenp.org> Hi GnuPG developers, The manual for gpg mentions the "ldap" method for the --auto-key-locate feature. If I understand correctly, with this method, when gpg is asked to locate a key for alice at example.com, it should query a LDAP server (which it finds either through a SRV record in the DNS, or by assuming it is at keys.example.com) for the requested key. That behavior is currently not implemented. The logic for it is still present in the keyserver_import_ldap function (in g10/keyserver.c), but has been commented out. Is there any plan to reactivate this feature? I don't remember seeing anyone complaining about its absence. Was it deactivated because no one was actually using it? The reason I'm asking this is that I'm currently writing an article attempting to describe all the available methods for publishing and locating public keys (from the "classic" HKP keyservers to the recently introduced Web Key Directories), and I would like to know whether it is worthwhile to mention LDAP auto-discovery. Thanks, 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 bcl at redhat.com Thu Apr 27 17:32:31 2017 From: bcl at redhat.com (Brian C. Lane) Date: Thu, 27 Apr 2017 08:32:31 -0700 Subject: Please help us test the behavior of different Unices In-Reply-To: <8760jtb08v.fsf@europa.jade-hamburg.de> References: <8760jtb08v.fsf@europa.jade-hamburg.de> Message-ID: <20170427153231.GJ2543@lister.brianlane.com> On Wed, Mar 01, 2017 at 02:22:08PM +0100, Justus Winter wrote: > Hello, > > I have written a small test program and I would like to ask you to run > it on UNIX platforms that you care about. (Care as in you want to be > able to run GnuPG on it the future). A bit late to the party, but I didn't notice any Fedora/RHEL systems: System: Linux:3.10.0-327.el7.x86_64:#1 SMP Thu Oct 29 17:29:29 EDT 2015 sizeof addr.sun_path: 108 Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket' getsockname returned '/tmp/test-unix-sockets/socket', addrlen: 32 Running test with strlen (cwd): 22, name: 'socket' getsockname returned 'socket', addrlen: 9 Running test with strlen (cwd): 130, name: 'socket' getsockname returned 'socket', addrlen: 9 Running test with strlen (cwd): 1102, name: 'socket' getsockname returned 'socket', addrlen: 9 System: Linux:4.10.10-200.fc25.x86_64:#1 SMP Thu Apr 13 01:11:51 UTC 2017 sizeof addr.sun_path: 108 Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket' getsockname returned '/tmp/test-unix-sockets/socket', addrlen: 32 Running test with strlen (cwd): 22, name: 'socket' getsockname returned 'socket', addrlen: 9 Running test with strlen (cwd): 130, name: 'socket' getsockname returned 'socket', addrlen: 9 Running test with strlen (cwd): 1102, name: 'socket' getsockname returned 'socket', addrlen: 9 And a Beagle Bone Black: System: Linux:4.4.30-ti-r64:#1 SMP Fri Nov 4 21:23:33 UTC 2016 sizeof addr.sun_path: 108 Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket' getsockname returned '/tmp/test-unix-sockets/socket', addrlen: 32 Running test with strlen (cwd): 22, name: 'socket' getsockname returned 'socket', addrlen: 9 Running test with strlen (cwd): 130, name: 'socket' getsockname returned 'socket', addrlen: 9 Running test with strlen (cwd): 1102, name: 'socket' getsockname returned 'socket', addrlen: 9 -- Brian C. Lane (PST8PDT)