From hongxu.jia at windriver.com Thu Feb 1 03:49:06 2018 From: hongxu.jia at windriver.com (Hongxu Jia) Date: Wed, 31 Jan 2018 21:49:06 -0500 Subject: [PATCH] qt/python: Add variables to tests Message-ID: <1517453346-229896-1-git-send-email-hongxu.jia@windriver.com> * configure.ac, lang/python/Makefile.am: New variable to `lang/python', set to `lang/python' if RUN_LANG_PYTHON_TESTS * configure.ac, lang/qt/Makefile.am: New variable to `lang/qt', set to `lang/qt' if RUN_LANG_QT_TESTS Signed-off-by: Hongxu Jia --- configure.ac | 11 +++++++++++ lang/python/Makefile.am | 3 +++ lang/qt/Makefile.am | 8 +++++++- 3 files changed, 21 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 608c376..fad7467 100644 --- a/configure.ac +++ b/configure.ac @@ -536,6 +536,17 @@ AC_ARG_ENABLE(g13-test, run_g13_test=$enableval) AM_CONDITIONAL(RUN_G13_TESTS, test "$run_g13_test" = "yes") +run_lang_python_test="yes" +AC_ARG_ENABLE(lang-python-test, + AC_HELP_STRING([--disable-lang-python-test], [disable Python regression test]), + run_lang_python_test=$enableval) +AM_CONDITIONAL(RUN_LANG_PYTHON_TESTS, test "$run_lang_python_test" = "yes") + +run_lang_qt_test="yes" +AC_ARG_ENABLE(lang-qt-test, + AC_HELP_STRING([--disable-lang-qt-test], [disable Qt regression test]), + run_lang_qt_test=$enableval) +AM_CONDITIONAL(RUN_LANG_QT_TESTS, test "$run_lang_qt_test" = "yes") # Checks for header files. AC_CHECK_HEADERS_ONCE([locale.h sys/select.h sys/uio.h argp.h diff --git a/lang/python/Makefile.am b/lang/python/Makefile.am index 8d74cbd..43b5d1e 100644 --- a/lang/python/Makefile.am +++ b/lang/python/Makefile.am @@ -24,7 +24,10 @@ EXTRA_DIST = \ examples \ src +if RUN_LANG_PYTHON_TESTS SUBDIRS = . tests +endif + .PHONY: prepare prepare: copystamp diff --git a/lang/qt/Makefile.am b/lang/qt/Makefile.am index ab85960..a244ede 100644 --- a/lang/qt/Makefile.am +++ b/lang/qt/Makefile.am @@ -19,6 +19,12 @@ # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA # 02111-1307, USA -SUBDIRS = src tests doc +if RUN_LANG_QT_TESTS +qttests = tests +else +qttests = +endif + +SUBDIRS = src ${qttests} doc EXTRA_DIST = README -- 1.8.3.1 From hongxu.jia at windriver.com Thu Feb 1 07:08:16 2018 From: hongxu.jia at windriver.com (Hongxu Jia) Date: Thu, 1 Feb 2018 01:08:16 -0500 Subject: [PATCH] python: fix build path issue to improve reproducibility Message-ID: <1517465296-136974-1-git-send-email-hongxu.jia@windriver.com> * lang/python/Makefile.am: Get the "--root" directory supplied to the "install" command, and use it as a prefix to strip off the purported filename encoded in bytecode files. Signed-off-by: Hongxu Jia --- lang/python/Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lang/python/Makefile.am b/lang/python/Makefile.am index 43b5d1e..2470efd 100644 --- a/lang/python/Makefile.am +++ b/lang/python/Makefile.am @@ -93,7 +93,8 @@ install-exec-local: build \ --build-base="$$(basename "$${PYTHON}")-gpg" \ install \ - --prefix "$(DESTDIR)$(prefix)" \ + --root "${DESTDIR}" \ + --prefix "$(prefix)" \ --verbose ; \ done -- 1.8.3.1 From wk at gnupg.org Thu Feb 1 08:52:30 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Feb 2018 08:52:30 +0100 Subject: [PATCH] qt/python: Add variables to tests In-Reply-To: <1517453346-229896-1-git-send-email-hongxu.jia@windriver.com> (Hongxu Jia's message of "Wed, 31 Jan 2018 21:49:06 -0500") References: <1517453346-229896-1-git-send-email-hongxu.jia@windriver.com> Message-ID: <87bmh9p2o1.fsf@wheatstone.g10code.de> Hi, and thanks for the patche. Please also send a DCO (see doc/HACKING and doc/DCO) to this mailing list. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Thu Feb 1 08:55:46 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Feb 2018 08:55:46 +0100 Subject: [admin] Sending patches Message-ID: <877erxp2il.fsf@wheatstone.g10code.de> Hi! this is quick note to ask you to always include a tag like [gpgme] or [gnupg] etc. in the subject when sending a patch. This mailing list is used for several projects and it makes the maintainer task easier if there is no need to guess for which project the patch is intended. 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 hongxu.jia at windriver.com Thu Feb 1 10:25:46 2018 From: hongxu.jia at windriver.com (Hongxu Jia) Date: Thu, 1 Feb 2018 17:25:46 +0800 Subject: [gpgme] DCO for Hongxu Jia In-Reply-To: <87bmh9p2o1.fsf@wheatstone.g10code.de> References: <1517453346-229896-1-git-send-email-hongxu.jia@windriver.com> <87bmh9p2o1.fsf@wheatstone.g10code.de> Message-ID: <7a05b7e7-1723-88e8-09a5-73416eb07b3f@windriver.com> GPGME Developer's Certificate of Origin.? Version 1.0 ===================================================== By making a contribution to the GPGME project, I certify that: (a) The contribution was created in whole or in part by me and I ??? have the right to submit it under the free software license ??? indicated in the file; or (b) The contribution is based upon previous work that, to the ??? best of my knowledge, is covered under an appropriate free ??? software license and I have the right under that license to ??? submit that work with modifications, whether created in whole ??? or in part by me, under the same free software license ??? (unless I am permitted to submit under a different license), ??? as indicated in the file; or (c) The contribution was provided directly to me by some other ??? person who certified (a), (b) or (c) and I have not modified ??? it. (d) I understand and agree that this project and the contribution ??? are public and that a record of the contribution (including ??? all personal information I submit with it, including my ??? sign-off) is maintained indefinitely and may be redistributed ??? consistent with this project or the free software license(s) ??? involved. Signed-off-by: Hongxu Jia //Hongxu From hongxu.jia at windriver.com Thu Feb 1 10:29:12 2018 From: hongxu.jia at windriver.com (Hongxu Jia) Date: Thu, 1 Feb 2018 17:29:12 +0800 Subject: [admin] Sending patches In-Reply-To: <877erxp2il.fsf@wheatstone.g10code.de> References: <877erxp2il.fsf@wheatstone.g10code.de> Message-ID: <7341f788-9127-3581-6a14-7e7aacad5638@windriver.com> On 2018?02?01? 15:55, Werner Koch wrote: > Hi! > > this is quick note to ask you to always include a tag like [gpgme] or > [gnupg] etc. in the subject when sending a patch. Got it, thanks for pointing it out > This mailing list is used for several projects and it makes the > maintainer task easier if there is no need to guess for which project > the patch is intended. Sorry for the confusion //Hongxu > > Salam-Shalom, > > Werner > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From hongxu.jia at windriver.com Thu Feb 1 10:29:47 2018 From: hongxu.jia at windriver.com (Hongxu Jia) Date: Thu, 1 Feb 2018 17:29:47 +0800 Subject: [admin] Sending patches In-Reply-To: <877erxp2il.fsf@wheatstone.g10code.de> References: <877erxp2il.fsf@wheatstone.g10code.de> Message-ID: <8c26be5a-1445-4094-6688-dbc9e1a21e86@windriver.com> On 2018?02?01? 15:55, Werner Koch wrote: > Hi! > > this is quick note to ask you to always include a tag like [gpgme] or > [gnupg] etc. in the subject when sending a patch. Got it, thanks for pointing it out > This mailing list is used for several projects and it makes the > maintainer task easier if there is no need to guess for which project > the patch is intended. > Sorry for the confusion //Hongxu > Salam-Shalom, > > Werner > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From Thorsten.Behrens at CIB.de Thu Feb 1 14:21:47 2018 From: Thorsten.Behrens at CIB.de (Thorsten Behrens) Date: Thu, 1 Feb 2018 14:21:47 +0100 Subject: [PATCH gpgme] doc: clarify patch submission workflow Message-ID: <20180201132147.7597-1-Thorsten.Behrens@CIB.de> Signed-off-by: Thorsten Behrens --- doc/HACKING | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/doc/HACKING b/doc/HACKING index 83c0f517..3d3a2adf 100644 --- a/doc/HACKING +++ b/doc/HACKING @@ -89,6 +89,34 @@ It is recommended to send the patches using a PGP/MIME signed mail. +** Sending patches + + - submitting patches, and subsequent discussions around them, + happens via the gnupg-devel at gnupg.org public mailing list + + - send your patches to that list, preferably PGP/MIME signed. Make + sure to include a mention of 'gpgme' in the subject line, + the list is used for several different projects + + - if you're working from the git repo, here's a suggested workflow: + + - hack hack hack + + - commit your changes; group changes into easily-reviewable commit + units, feel free to submit several patches at once + + - e.g. if you want to submit a single patch on top of master, do: + git send-email --to=gnupg-devel at gnupg.org --annotate -1 + (please put a mention of gpgme into the subjects, + annotate lets you do that) + + - e.g. if you have two commits on top of master, do: + git send-email --to=gnupg-devel at gnupg.org --annotate --cover-letter -2 + (that prompts you for a summary mail to precede your actual + patch mails) + + - use --dry-run to test your setup + ** Coding standards Please follow the GNU coding standards. If you are in doubt consult -- 2.13.6 From Thorsten.Behrens at CIB.de Thu Feb 1 14:21:24 2018 From: Thorsten.Behrens at CIB.de (Thorsten Behrens) Date: Thu, 1 Feb 2018 14:21:24 +0100 Subject: [PATCH libassuan] doc: clarify patch submission workflow Message-ID: <20180201132124.7481-1-Thorsten.Behrens@CIB.de> Signed-off-by: Thorsten Behrens --- doc/HACKING | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/doc/HACKING b/doc/HACKING index 0e32f58..95ca4ec 100644 --- a/doc/HACKING +++ b/doc/HACKING @@ -108,3 +108,31 @@ grammar fixes." - That's it. From now on you only need to add a "Signed-off-by:" line with your name and mail address to the commit message. It is recommended to send the patches using a PGP/MIME signed mail. + +** Sending patches + + - submitting patches, and subsequent discussions around them, + happens via the gnupg-devel at gnupg.org public mailing list + + - send your patches to that list, preferably PGP/MIME signed. Make + sure to include a mention of 'libassuan' in the subject line, + the list is used for several different projects + + - if you're working from the git repo, here's a suggested workflow: + + - hack hack hack + + - commit your changes; group changes into easily-reviewable commit + units, feel free to submit several patches at once + + - e.g. if you want to submit a single patch on top of master, do: + git send-email --to=gnupg-devel at gnupg.org --annotate -1 + (please put a mention of libassuan into the subjects, + annotate lets you do that) + + - e.g. if you have two commits on top of master, do: + git send-email --to=gnupg-devel at gnupg.org --annotate --cover-letter -2 + (that prompts you for a summary mail to precede your actual + patch mails) + + - use --dry-run to test your setup -- 2.13.6 From Thorsten.Behrens at CIB.de Thu Feb 1 14:24:07 2018 From: Thorsten.Behrens at CIB.de (Thorsten Behrens) Date: Thu, 1 Feb 2018 14:24:07 +0100 Subject: [PATCH libgpg-error] doc: clarify patch submission workflow Message-ID: <20180201132407.7791-1-Thorsten.Behrens@CIB.de> Signed-off-by: Thorsten Behrens --- doc/HACKING | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/doc/HACKING b/doc/HACKING index e30b2f8..d379099 100644 --- a/doc/HACKING +++ b/doc/HACKING @@ -2,6 +2,11 @@ #+TITLE: Various hacking notes #+STARTUP: showall +* How to contribute + + The following stuff explains some basic procedures you need to + follow if you want to contribute code or documentation. + * No more ChangeLog files Do not modify any of the ChangeLog files in Libgpg-error. Starting @@ -23,3 +28,48 @@ in a "real" ChangeLog file, but keep the maximum line length at 72 or smaller, so that the generated ChangeLog lines, each with its leading TAB, will not exceed 80 columns. + +* Commit log keywords + + - GnuPG-bug-id :: Values are comma or space delimited bug numbers + from bug.gnupg.org pertaining to this commit. + - Debian-bug-id :: Same as above but from the Debian bug tracker. + - CVE-id :: CVE id number pertaining to this commit. + - Regression-due-to :: Commit id of the regression fixed by this commit. + - Fixes-commit :: Commit id this commit fixes. + - Reported-by :: Value is a name or mail address of a bug reporte. + - Suggested-by :: Value is a name or mail address of someone how + suggested this change. + - Co-authored-by :: Name or mail address of a co-author + - Some-comments-by :: Name or mail address of the author of + additional comments (commit log or code). + - Proofread-by :: Sometimes used by translation commits. + - Signed-off-by :: Name or mail address of the developer + +* Sending patches + + - submitting patches, and subsequent discussions around them, + happens via the gnupg-devel at gnupg.org public mailing list + + - send your patches to that list, preferably PGP/MIME signed. Make + sure to include a mention of 'libgpg-error' in the subject line, + the list is used for several different projects + + - if you're working from the git repo, here's a suggested workflow: + + - hack hack hack + + - commit your changes; group changes into easily-reviewable commit + units, feel free to submit several patches at once + + - e.g. if you want to submit a single patch on top of master, do: + git send-email --to=gnupg-devel at gnupg.org --annotate -1 + (please put a mention of libgpg-error into the subjects, + annotate lets you do that) + + - e.g. if you have two commits on top of master, do: + git send-email --to=gnupg-devel at gnupg.org --annotate --cover-letter -2 + (that prompts you for a summary mail to precede your actual + patch mails) + + - use --dry-run to test your setup -- 2.13.6 From thb at libreoffice.org Thu Feb 1 14:37:27 2018 From: thb at libreoffice.org (Thorsten Behrens) Date: Thu, 1 Feb 2018 14:37:27 +0100 Subject: [PATCH 1/5] cpp: expose minimal key export flag from C In-Reply-To: <87607hrhxs.fsf@wheatstone.g10code.de> References: <20180130141810.4073-1-thb@libreoffice.org> <87bmhatn8j.fsf@wheatstone.g10code.de> <20180131102946.xz3sdfq6ggbfwapl@thinkpad.thebehrens.net> <1659414.VPt5P5tGK7@esus> <87607hrhxs.fsf@wheatstone.g10code.de> Message-ID: <20180201133727.cjgrcqtcjq6fo5x3@thinkpad.thebehrens.net> Werner Koch wrote: > I noticed things like > > -# ifdef WIN32 > +# ifdef _MSC_VER > # define GPGMEPP_EXPORT __declspec(dllexport) > Hmm - but WIN32 is an equally-bad choice, since it's only defined for mingw builds. Looking at https://gist.github.com/jonforums/968522, how about going with _WIN32 for the while? > After all this boils down to the question whether and how we want to > support native building and - worse - on a really strange > combination of platforms. > The platform - when it comes to compiler and linker, i.e. all pieces that touch the actual code - is pretty standard msvc. All patches submitted against _that_ goal IMO improve portability quite a bit (if you look closer, there were some nonsense calls to posix functions in Windows-only code, where then the mingw libc silently drops stuff - I'd much prefer this to be visible in plain sight). I admit the build system I had to shoehorn that into is weird; then again that can be said about autotools, too ... ;) Cheers, -- Thorsten -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: Digital signature URL: From dkg at fifthhorseman.net Thu Feb 1 16:44:09 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 01 Feb 2018 10:44:09 -0500 Subject: [PATCH libgpg-error] doc: clarify patch submission workflow In-Reply-To: <20180201132407.7791-1-Thorsten.Behrens@CIB.de> References: <20180201132407.7791-1-Thorsten.Behrens@CIB.de> Message-ID: <87607g7m0m.fsf@fifthhorseman.net> On Thu 2018-02-01 14:24:07 +0100, Thorsten Behrens wrote: > Signed-off-by: Thorsten Behrens > --- > doc/HACKING | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 50 insertions(+) This looks like a reasonable update to me. Werner, if you agree with the recommendations there, please merge! --dkg From dkg at fifthhorseman.net Thu Feb 1 16:44:33 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 01 Feb 2018 10:44:33 -0500 Subject: [PATCH gpgme] doc: clarify patch submission workflow In-Reply-To: <20180201132147.7597-1-Thorsten.Behrens@CIB.de> References: <20180201132147.7597-1-Thorsten.Behrens@CIB.de> Message-ID: <87372k7lzy.fsf@fifthhorseman.net> On Thu 2018-02-01 14:21:47 +0100, Thorsten Behrens wrote: > Signed-off-by: Thorsten Behrens > --- > doc/HACKING | 28 ++++++++++++++++++++++++++++ > 1 file changed, 28 insertions(+) This one also looks good to me. --dkg From James.Bottomley at HansenPartnership.com Thu Feb 1 17:13:49 2018 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Thu, 01 Feb 2018 16:13:49 +0000 Subject: DCO signoff for gnupg TPM patches Message-ID: <1517501629.3145.9.camel@HansenPartnership.com> GnuPG Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the GnuPG project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: James Bottomley -------------- 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 dgouttegattat at incenp.org Thu Feb 1 17:20:25 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Thu, 1 Feb 2018 16:20:25 +0000 Subject: [PATCH libgpg-error] doc: clarify patch submission workflow In-Reply-To: <20180201132407.7791-1-Thorsten.Behrens@CIB.de> References: <20180201132407.7791-1-Thorsten.Behrens@CIB.de> Message-ID: Hi, On 02/01/2018 01:24 PM, Thorsten Behrens wrote: > + - send your patches to that list, preferably PGP/MIME signed. ^^^^^^^^^^^^^^^^^^^^^^^^^^ As far as I know, git send-email does not allow to do that. (Or if it does, I never found how to do it--when I looked for that feature, I found nothing else than an a old bug report complaining precisely that it was not supported [1].) It seems strange to ask for "preferably PGP/MIME signed" patches and to suggest a workflow which does not support it. Damien [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534251 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu Feb 1 18:03:12 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 01 Feb 2018 12:03:12 -0500 Subject: [PATCH libgpg-error] doc: clarify patch submission workflow In-Reply-To: References: <20180201132407.7791-1-Thorsten.Behrens@CIB.de> Message-ID: <87fu6k63sf.fsf@fifthhorseman.net> On Thu 2018-02-01 16:20:25 +0000, Damien Goutte-Gattat wrote: > Hi, > > On 02/01/2018 01:24 PM, Thorsten Behrens wrote: >> + - send your patches to that list, preferably PGP/MIME signed. > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > As far as I know, git send-email does not allow to do that. (Or if it > does, I never found how to do it--when I looked for that feature, I > found nothing else than an a old bug report complaining precisely that > it was not supported [1].) > > It seems strange to ask for "preferably PGP/MIME signed" patches and to > suggest a workflow which does not support it. maybe if we state a preference it can be used to encourage bugfixes elsewhere in the stack? it's certainly possible to prefer something that you can't currently have easily. --dkg From tmz at pobox.com Thu Feb 1 17:08:48 2018 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 1 Feb 2018 11:08:48 -0500 Subject: [admin] Sending patches In-Reply-To: <877erxp2il.fsf@wheatstone.g10code.de> References: <877erxp2il.fsf@wheatstone.g10code.de> Message-ID: <20180201160848.GY1427@zaya.teonanacatl.net> Werner Koch wrote: > Hi! > > this is quick note to ask you to always include a tag like [gpgme] or > [gnupg] etc. in the subject when sending a patch. > > This mailing list is used for several projects and it makes the > maintainer task easier if there is no need to guess for which project > the patch is intended. This can be done fairly simply when using git format-patch. The format.subjectPrefix option can be set per repository. For example, if I were working in a clone of gnupg.git, I could use: $ git config format.subjectPrefix 'PATCH/gnupg' and then generated patches would have a subject line like: Subject: [PATCH/gnupg] ... Perhaps that's worth adding to https://git.gnupg.org/ or similar? -- Todd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A fool's brain digests philosophy into folly, science into superstition, and art into pedantry. Hence University education. -- George Bernard Shaw -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From tmz at pobox.com Thu Feb 1 17:42:14 2018 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 1 Feb 2018 11:42:14 -0500 Subject: [PATCH libgpg-error] doc: clarify patch submission workflow In-Reply-To: <20180201132407.7791-1-Thorsten.Behrens@CIB.de> References: <20180201132407.7791-1-Thorsten.Behrens@CIB.de> Message-ID: <20180201164214.GZ1427@zaya.teonanacatl.net> Thorsten Behrens wrote: > +* Sending patches > + > + - submitting patches, and subsequent discussions around them, > + happens via the gnupg-devel at gnupg.org public mailing list > + > + - send your patches to that list, preferably PGP/MIME signed. Make > + sure to include a mention of 'libgpg-error' in the subject line, > + the list is used for several different projects > + > + - if you're working from the git repo, here's a suggested workflow: > + > + - hack hack hack > + > + - commit your changes; group changes into easily-reviewable commit > + units, feel free to submit several patches at once > + > + - e.g. if you want to submit a single patch on top of master, do: > + git send-email --to=gnupg-devel at gnupg.org --annotate -1 > + (please put a mention of libgpg-error into the subjects, > + annotate lets you do that) > + > + - e.g. if you have two commits on top of master, do: > + git send-email --to=gnupg-devel at gnupg.org --annotate --cover-letter -2 > + (that prompts you for a summary mail to precede your actual > + patch mails) I think it would be better to suggest setting the format.subjectPrefix option to make this easier. E.g.: $ git config format.subjectPrefix 'PATCH/libgpg-error' It's generally better to use 'git format-patch --cover-letter ...' to generate and edit the cover letter and be sure it looks good, then use 'git send-email $patch_files'. Using git send-email to directly drive 'git format-patch' makes it far too easy to send out the wrong patch series. The format.subjectPrefix option applies whether you run git format-patch or git send-email and let it call format-patch though. -- Todd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Living your life is a task so difficult, it has never been attempted before. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From tmz at pobox.com Thu Feb 1 21:41:42 2018 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 1 Feb 2018 15:41:42 -0500 Subject: [PATCH libgpg-error] doc: clarify patch submission workflow In-Reply-To: <20180201164214.GZ1427@zaya.teonanacatl.net> References: <20180201132407.7791-1-Thorsten.Behrens@CIB.de> <20180201164214.GZ1427@zaya.teonanacatl.net> Message-ID: <20180201204142.GD1427@zaya.teonanacatl.net> I wrote: > I think it would be better to suggest setting the > format.subjectPrefix option to make this easier. E.g.: > > $ git config format.subjectPrefix 'PATCH/libgpg-error' And here's that suggestion in unified diff format (along with automation of the git send-email --to=... option). Feel free to squash this in with or without attribution. I don't think this warrants a signoff or DCO from me, but I'm happy to provide one if needed. -->8-- diff --git i/doc/HACKING w/doc/HACKING index d379099..9d552b7 100644 --- i/doc/HACKING +++ w/doc/HACKING @@ -57,18 +57,21 @@ - if you're working from the git repo, here's a suggested workflow: + - configure git send-email defaults: + + git config format.subjectPrefix 'PATCH/libgpg-error' + git config sendemail.to gnupg-devel at gnupg.org + - hack hack hack - commit your changes; group changes into easily-reviewable commit units, feel free to submit several patches at once - e.g. if you want to submit a single patch on top of master, do: - git send-email --to=gnupg-devel at gnupg.org --annotate -1 - (please put a mention of libgpg-error into the subjects, - annotate lets you do that) + git send-email --annotate -1 - e.g. if you have two commits on top of master, do: - git send-email --to=gnupg-devel at gnupg.org --annotate --cover-letter -2 + git send-email --annotate --cover-letter -2 (that prompts you for a summary mail to precede your actual patch mails) -- Todd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ You cannot propel yourself forward by patting yourself on the back. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From tmz at pobox.com Thu Feb 1 21:47:02 2018 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 1 Feb 2018 15:47:02 -0500 Subject: [PATCH gpgme] doc: clarify patch submission workflow In-Reply-To: <20180201132147.7597-1-Thorsten.Behrens@CIB.de> References: <20180201132147.7597-1-Thorsten.Behrens@CIB.de> Message-ID: <20180201204702.GE1427@zaya.teonanacatl.net> Thorsten Behrens wrote: > + - send your patches to that list, preferably PGP/MIME signed. Make > + sure to include a mention of 'gpgme' in the subject line, > + the list is used for several different projects > + > + - if you're working from the git repo, here's a suggested workflow: > + > + - hack hack hack > + > + - commit your changes; group changes into easily-reviewable commit > + units, feel free to submit several patches at once > + > + - e.g. if you want to submit a single patch on top of master, do: > + git send-email --to=gnupg-devel at gnupg.org --annotate -1 > + (please put a mention of gpgme into the subjects, > + annotate lets you do that) > + > + - e.g. if you have two commits on top of master, do: > + git send-email --to=gnupg-devel at gnupg.org --annotate --cover-letter -2 > + (that prompts you for a summary mail to precede your actual > + patch mails) > + > + - use --dry-run to test your setup Similar to libgpg-error, we can make it easier for contributors to include a proper subject prefix automatically. Feel free to squash this in with or without attribution. I don't think this warrants a signoff or DCO from me, but I'm happy to provide one if needed. -->8-- diff --git i/doc/HACKING w/doc/HACKING index 3d3a2adf..6eec319d 100644 --- i/doc/HACKING +++ w/doc/HACKING @@ -100,18 +100,21 @@ - if you're working from the git repo, here's a suggested workflow: + - configure git send-email defaults: + + git config format.subjectPrefix 'PATCH/gpgme' + git config sendemail.to gnupg-devel at gnupg.org + - hack hack hack - commit your changes; group changes into easily-reviewable commit units, feel free to submit several patches at once - e.g. if you want to submit a single patch on top of master, do: - git send-email --to=gnupg-devel at gnupg.org --annotate -1 - (please put a mention of gpgme into the subjects, - annotate lets you do that) + git send-email --annotate -1 - e.g. if you have two commits on top of master, do: - git send-email --to=gnupg-devel at gnupg.org --annotate --cover-letter -2 + git send-email --annotate --cover-letter -2 (that prompts you for a summary mail to precede your actual patch mails) -- Todd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ People are crazy and times are strange I'm locked in tight, I'm out of range I used to care, but things have changed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From tmz at pobox.com Thu Feb 1 21:55:48 2018 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 1 Feb 2018 15:55:48 -0500 Subject: [PATCH libgpg-error] doc: clarify patch submission workflow In-Reply-To: <87fu6k63sf.fsf@fifthhorseman.net> References: <20180201132407.7791-1-Thorsten.Behrens@CIB.de> <87fu6k63sf.fsf@fifthhorseman.net> Message-ID: <20180201205548.GF1427@zaya.teonanacatl.net> Daniel Kahn Gillmor wrote: > On Thu 2018-02-01 16:20:25 +0000, Damien Goutte-Gattat wrote: >> On 02/01/2018 01:24 PM, Thorsten Behrens wrote: >>> + - send your patches to that list, preferably PGP/MIME signed. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> As far as I know, git send-email does not allow to do that. (Or if it >> does, I never found how to do it--when I looked for that feature, I >> found nothing else than an a old bug report complaining precisely that >> it was not supported [1].) >> >> It seems strange to ask for "preferably PGP/MIME signed" patches and to >> suggest a workflow which does not support it. > > maybe if we state a preference it can be used to encourage bugfixes > elsewhere in the stack? it's certainly possible to prefer something > that you can't currently have easily. I have my doubts that git send-email will ever directly support PGP/MIME. But if signed patches are desired, there's no reason not use git format-patch to generate a patch (whether a single patch or a series with a cover letter) and then use any decent mail client to send the patch(es). Using git send-email is generally just convenient for folks whose mail clients would otherwise mangle the whitespace, wrap the text, or otherwise bugger the patch content. It's been a while since I've delved deeply into the PGP/MIME specs, but does it ensure that no such whitespace mangling will occur? Obviously, once the message is generated the signature ensures nothing is changed. What I'm not sure of is whether any part of the specification allows or requires any sort of whitespace or other changes. -- Todd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Abandon the search for Truth; settle for a good fantasy. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From Thorsten.Behrens at CIB.de Fri Feb 2 00:32:39 2018 From: Thorsten.Behrens at CIB.de (Thorsten Behrens) Date: Fri, 2 Feb 2018 00:32:39 +0100 Subject: [PATCH libassuan v2] doc: clarify patch submission workflow Message-ID: <20180201233239.23258-1-Thorsten.Behrens@CIB.de> Signed-off-by: Thorsten Behrens Co-authored-by: Todd Zullinger --- doc/HACKING | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/doc/HACKING b/doc/HACKING index 0e32f58..b67651e 100644 --- a/doc/HACKING +++ b/doc/HACKING @@ -108,3 +108,34 @@ grammar fixes." - That's it. From now on you only need to add a "Signed-off-by:" line with your name and mail address to the commit message. It is recommended to send the patches using a PGP/MIME signed mail. + +** Sending patches + + - submitting patches, and subsequent discussions around them, + happens via the gnupg-devel at gnupg.org public mailing list + + - send your patches to that list, preferably PGP/MIME signed. Make + sure to include a mention of 'libassuan' in the subject line, + the list is used for several different projects + + - if you're working from the git repo, here's a suggested workflow: + + - configure git send-email defaults: + + git config format.subjectPrefix 'PATCH libassuan' + git config sendemail.to gnupg-devel at gnupg.org + + - hack hack hack + + - commit your changes; group changes into easily-reviewable commit + units, feel free to submit several patches at once + + - e.g. if you want to submit a single patch on top of master, do: + git send-email --annotate -1 + + - e.g. if you have two commits on top of master, do: + git send-email --annotate --cover-letter -2 + (that prompts you for a summary mail to precede your actual + patch mails) + + - use --dry-run to test your setup -- 2.13.6 From Thorsten.Behrens at CIB.de Fri Feb 2 00:33:50 2018 From: Thorsten.Behrens at CIB.de (Thorsten Behrens) Date: Fri, 2 Feb 2018 00:33:50 +0100 Subject: [PATCH libgpg-error v2] doc: clarify patch submission workflow Message-ID: <20180201233350.23402-1-Thorsten.Behrens@CIB.de> Signed-off-by: Thorsten Behrens Co-authored-by: Todd Zullinger --- doc/HACKING | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) diff --git a/doc/HACKING b/doc/HACKING index e30b2f8..6bb1071 100644 --- a/doc/HACKING +++ b/doc/HACKING @@ -2,6 +2,11 @@ #+TITLE: Various hacking notes #+STARTUP: showall +* How to contribute + + The following stuff explains some basic procedures you need to + follow if you want to contribute code or documentation. + * No more ChangeLog files Do not modify any of the ChangeLog files in Libgpg-error. Starting @@ -23,3 +28,51 @@ in a "real" ChangeLog file, but keep the maximum line length at 72 or smaller, so that the generated ChangeLog lines, each with its leading TAB, will not exceed 80 columns. + +* Commit log keywords + + - GnuPG-bug-id :: Values are comma or space delimited bug numbers + from bug.gnupg.org pertaining to this commit. + - Debian-bug-id :: Same as above but from the Debian bug tracker. + - CVE-id :: CVE id number pertaining to this commit. + - Regression-due-to :: Commit id of the regression fixed by this commit. + - Fixes-commit :: Commit id this commit fixes. + - Reported-by :: Value is a name or mail address of a bug reporte. + - Suggested-by :: Value is a name or mail address of someone how + suggested this change. + - Co-authored-by :: Name or mail address of a co-author + - Some-comments-by :: Name or mail address of the author of + additional comments (commit log or code). + - Proofread-by :: Sometimes used by translation commits. + - Signed-off-by :: Name or mail address of the developer + +* Sending patches + + - submitting patches, and subsequent discussions around them, + happens via the gnupg-devel at gnupg.org public mailing list + + - send your patches to that list, preferably PGP/MIME signed. Make + sure to include a mention of 'libgpg-error' in the subject line, + the list is used for several different projects + + - if you're working from the git repo, here's a suggested workflow: + + - configure git send-email defaults: + + git config format.subjectPrefix 'PATCH libgpg-error' + git config sendemail.to gnupg-devel at gnupg.org + + - hack hack hack + + - commit your changes; group changes into easily-reviewable commit + units, feel free to submit several patches at once + + - e.g. if you want to submit a single patch on top of master, do: + git send-email --annotate -1 + + - e.g. if you have two commits on top of master, do: + git send-email --annotate --cover-letter -2 + (that prompts you for a summary mail to precede your actual + patch mails) + + - use --dry-run to test your setup -- 2.13.6 From Thorsten.Behrens at CIB.de Fri Feb 2 00:34:50 2018 From: Thorsten.Behrens at CIB.de (Thorsten Behrens) Date: Fri, 2 Feb 2018 00:34:50 +0100 Subject: [PATCH gpgme v2] doc: clarify patch submission workflow Message-ID: <20180201233450.23544-1-Thorsten.Behrens@CIB.de> Signed-off-by: Thorsten Behrens Co-authored-by: Todd Zullinger --- doc/HACKING | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/doc/HACKING b/doc/HACKING index 83c0f517..2478f8b3 100644 --- a/doc/HACKING +++ b/doc/HACKING @@ -89,6 +89,37 @@ It is recommended to send the patches using a PGP/MIME signed mail. +** Sending patches + + - submitting patches, and subsequent discussions around them, + happens via the gnupg-devel at gnupg.org public mailing list + + - send your patches to that list, preferably PGP/MIME signed. Make + sure to include a mention of 'gpgme' in the subject line, + the list is used for several different projects + + - if you're working from the git repo, here's a suggested workflow: + + - configure git send-email defaults: + + git config format.subjectPrefix 'PATCH gpgme' + git config sendemail.to gnupg-devel at gnupg.org + + - hack hack hack + + - commit your changes; group changes into easily-reviewable commit + units, feel free to submit several patches at once + + - e.g. if you want to submit a single patch on top of master, do: + git send-email --annotate -1 + + - e.g. if you have two commits on top of master, do: + git send-email --annotate --cover-letter -2 + (that prompts you for a summary mail to precede your actual + patch mails) + + - use --dry-run to test your setup + ** Coding standards Please follow the GNU coding standards. If you are in doubt consult -- 2.13.6 From wk at gnupg.org Fri Feb 2 00:48:57 2018 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Feb 2018 00:48:57 +0100 Subject: DCO signoff for gnupg TPM patches In-Reply-To: <1517501629.3145.9.camel@HansenPartnership.com> (James Bottomley's message of "Thu, 01 Feb 2018 16:13:49 +0000") References: <1517501629.3145.9.camel@HansenPartnership.com> Message-ID: <87o9l81dau.fsf@wheatstone.g10code.de> On Thu, 1 Feb 2018 17:13, James.Bottomley at HansenPartnership.com said: > GnuPG Developer's Certificate of Origin. Version 1.0 > ===================================================== Thanks James. I feel a bit guilty not having answered your original mail. Let's see whether I find time during FOSDEM. 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 James.Bottomley at HansenPartnership.com Fri Feb 2 06:36:42 2018 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Fri, 02 Feb 2018 06:36:42 +0100 Subject: DCO signoff for gnupg TPM patches In-Reply-To: <87o9l81dau.fsf@wheatstone.g10code.de> References: <1517501629.3145.9.camel@HansenPartnership.com> <87o9l81dau.fsf@wheatstone.g10code.de> Message-ID: <1517549802.3222.13.camel@HansenPartnership.com> On Fri, 2018-02-02 at 00:48 +0100, Werner Koch wrote: > On Thu,??1 Feb 2018 17:13, James.Bottomley at HansenPartnership.com > said: > > > > GnuPG Developer's Certificate of Origin.??Version 1.0 > > ===================================================== > > > Thanks James.??I feel a bit guilty not having answered your original > mail.??Let's see whether I find time during FOSDEM. Great, thanks! I'm already in Brussels, and I'll be here until Sunday at around 17:00 (taking the Eurostar to London to visit family then flying back to the USA) if you'd like any non email discussions. Regards, James -------------- 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 Fri Feb 2 18:48:08 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 02 Feb 2018 12:48:08 -0500 Subject: avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG Message-ID: <87y3kb471j.fsf@fifthhorseman.net> Hi GMime and GnuPG developers-- sorry for the cross-posting! coordinating this kind of thing cross-project is tough. I recently learned that default handling of signed S/MIME mail with GnuPG causes an inherent metadata leak about the user's activity: https://dev.gnupg.org/T3348#110132 As a MUA developer, I'd like my MUA to simply handle as much crypto as it can on the user's behalf automatically, correctly and silently, without needing any special configuration or asking the user to make any tough tradeoffs that they might object to. What kinds of tradeoffs are objectionable? Performance tradeoffs are probably OK, since they're user-visible, and can be mitigated by disabling crypto. But metadata leakage by default seems really problematic, because (a) it is invisible to the user, and (b) once done, it cannot be undone. So my question for GMime and GnuPG developers is how a MUA that uses GMime should approach this. Given that GMime relies on GnuPG, and GnuPG basically says "if you process S/MIME mail, you'll leak metadata", what is the best way to instruct GMime to say "handle as much cryptographic mail as you can without leaking metadata"? GMime 3 has greatly simplified its crypto handling interface, and it has moved fully to GPGME on the backend, which i appreciate. However, i think the interface is now so clean that i don't know how to either: * tell GMime to disable crl checks or * tell GMime not to verify S/MIME signatures at all Either of these methods would address the default metadata leakage concern, but the first choice provides more functionality to the user. i note that GPGME offers gpgme_set_offline(), which tells it to avoid talking to the network entirely. Maybe that can be exposed by GMime somehow? i don't think invoking gpgme_set_offline(true) would break other uses of GPGME inside GMime or any other sensible MUA, but if there's a fear that it does, i'd like to hear about it. Note: i'm perfectly happy to allow the user to override this choice if they *want* to leak metadata, but i don't think that my MUA should do that to the user by default. I'm willing to write patches if there is a reasonable plan forward. Any suggestions? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Feb 2 20:24:32 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 02 Feb 2018 14:24:32 -0500 Subject: [gmime-devel] avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG In-Reply-To: <9201448a-83f1-2bf5-14d4-6b862a13e31e@gnome.org> References: <87y3kb471j.fsf@fifthhorseman.net> <9201448a-83f1-2bf5-14d4-6b862a13e31e@gnome.org> Message-ID: <87o9l742kv.fsf@fifthhorseman.net> On Fri 2018-02-02 13:13:32 -0500, Jeffrey Stedfast wrote: >> * tell GMime to disable crl checks > > I'd be willing to add an API to disable CRL checks if there's a way I > can pass that along to gpgme. thanks! >> * tell GMime not to verify S/MIME signatures at all > > Willing to add an API for this as well (although I guess it's not > necessary if an API to disable CRL checks is added?) i would rather not disable signature verification if we can do it without metadata leakage. > Well, I suppose that, like S/MIME signature verification, it would also > disable PGP key-server lookups? ah, right, i should be clearer about the use cases. I'm thinking right now about the use of GMime for *reading* mail. (Maybe we can talk about composing mail separately?) Is there any point during mail reading that you expect GMime to trigger a PGP keyserver lookup? > It might be best if there was a way to disable CRL checks on a per > gpgme_ctx_t basis as opposed to globally, but I can have GMime use the > global option until such an option exists (note: might be racey if you > try and verify signatures on multiple threads). gpgme_set_offline is actually per-gpgme_ctx_t: -- Function: void gpgme_set_offline (gpgme_ctx_t CTX, int YES) Sorry that i omitted that from the shorthand in my earlier message. But how would i use that with GMime? As of GMime 3 i'm in the practice of not not having to handle the GMimeCryptoCtx directly, because Gmime does the Right Thing anyway :) -- i'd like to keep that nice behavior! GMime should consider it as a new value for GMimeVerifyFlags? But i notice that g_mime_multipart_encrypted_decrypt () only takes a GMimeDecryptFlags, and it probably affects this too. I'll send a separate message to gmime-devel about this. > I'll wait for the GnuPG/GPGME devs to comment before making changes to > GMime. your message doesn't appear to have been let through to the gnupg-devel@ mailing list yet [0], so perhaps it's in moderation. --dkg [0] https://lists.gnupg.org/pipermail/gnupg-devel/2018-February/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From fejj at gnome.org Fri Feb 2 19:13:32 2018 From: fejj at gnome.org (Jeffrey Stedfast) Date: Fri, 2 Feb 2018 13:13:32 -0500 Subject: [gmime-devel] avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG In-Reply-To: <87y3kb471j.fsf@fifthhorseman.net> References: <87y3kb471j.fsf@fifthhorseman.net> Message-ID: <9201448a-83f1-2bf5-14d4-6b862a13e31e@gnome.org> Hi Daniel & GnuPG devs, On 2/2/2018 12:48 PM, Daniel Kahn Gillmor wrote: > Hi GMime and GnuPG developers-- > > sorry for the cross-posting! coordinating this kind of thing > cross-project is tough. > > I recently learned that default handling of signed S/MIME mail with > GnuPG causes an inherent metadata leak about the user's activity: > > https://dev.gnupg.org/T3348#110132 > > As a MUA developer, I'd like my MUA to simply handle as much crypto as > it can on the user's behalf automatically, correctly and silently, > without needing any special configuration or asking the user to make any > tough tradeoffs that they might object to. > > What kinds of tradeoffs are objectionable? Performance tradeoffs are > probably OK, since they're user-visible, and can be mitigated by > disabling crypto. But metadata leakage by default seems really > problematic, because (a) it is invisible to the user, and (b) once done, > it cannot be undone. > > So my question for GMime and GnuPG developers is how a MUA that uses > GMime should approach this. Given that GMime relies on GnuPG, and GnuPG > basically says "if you process S/MIME mail, you'll leak metadata", what > is the best way to instruct GMime to say "handle as much cryptographic > mail as you can without leaking metadata"? > > GMime 3 has greatly simplified its crypto handling interface, and it has > moved fully to GPGME on the backend, which i appreciate. However, i > think the interface is now so clean that i don't know how to either: > > * tell GMime to disable crl checks I'd be willing to add an API to disable CRL checks if there's a way I can pass that along to gpgme. > > or > > * tell GMime not to verify S/MIME signatures at all Willing to add an API for this as well (although I guess it's not necessary if an API to disable CRL checks is added?) > > Either of these methods would address the default metadata leakage > concern, but the first choice provides more functionality to the user. > > i note that GPGME offers gpgme_set_offline(), which tells it to avoid > talking to the network entirely. Maybe that can be exposed by GMime > somehow? Absolutely. > > i don't think invoking gpgme_set_offline(true) would break other uses of > GPGME inside GMime or any other sensible MUA, but if there's a fear that > it does, i'd like to hear about it. Well, I suppose that, like S/MIME signature verification, it would also disable PGP key-server lookups? It might be best if there was a way to disable CRL checks on a per gpgme_ctx_t basis as opposed to globally, but I can have GMime use the global option until such an option exists (note: might be racey if you try and verify signatures on multiple threads). I'll wait for the GnuPG/GPGME devs to comment before making changes to GMime. Jeff From wk at gnupg.org Sat Feb 3 01:40:50 2018 From: wk at gnupg.org (Werner Koch) Date: Sat, 03 Feb 2018 01:40:50 +0100 Subject: DCO signoff for gnupg TPM patches In-Reply-To: <1517549802.3222.13.camel@HansenPartnership.com> (James Bottomley's message of "Fri, 02 Feb 2018 06:36:42 +0100") References: <1517501629.3145.9.camel@HansenPartnership.com> <87o9l81dau.fsf@wheatstone.g10code.de> <1517549802.3222.13.camel@HansenPartnership.com> Message-ID: <87o9l6zyzx.fsf@wheatstone.g10code.de> On Fri, 2 Feb 2018 06:36, James.Bottomley at HansenPartnership.com said: R> On Fri, 2018-02-02 at 00:48 +0100, Werner Koch wrote: > Great, thanks! I'm already in Brussels, and I'll be here until Sunday I'll guess that I will be at FODDEM around 10am, if you text me I at +49-157-******* we can schedule a meeting. Hotel Catalonia in St. Gilles, right now. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Sat Feb 3 20:35:08 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 03 Feb 2018 14:35:08 -0500 Subject: [gmime-devel] avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG In-Reply-To: <0FD3E4E1-4C61-44BC-8B67-9996DE9D5DF2@microsoft.com> References: <87y3kb471j.fsf@fifthhorseman.net> <9201448a-83f1-2bf5-14d4-6b862a13e31e@gnome.org> <87o9l742kv.fsf@fifthhorseman.net> <0FD3E4E1-4C61-44BC-8B67-9996DE9D5DF2@microsoft.com> Message-ID: <871si150k3.fsf@fifthhorseman.net> On Sat 2018-02-03 18:48:26 +0000, Jeffrey Stedfast wrote: > I've added code locally to set offline mode but reading the docs: > > https://www.gnupg.org/documentation/manuals/gpgme/Offline-Mode.html > > it suggests that setting offline mode only works for CMS and not > OpenPGP? Can anyone from the GPGME team verify this? If so, I'll drop > the flags that would indicate that this works in OpenPGP mode. hm, it's not just "only CMS" -- it says: Offline mode only affects the keylist mode GPGME_KEYLIST_MODE_VALIDATE and is only relevant to the CMS crypto engine. Offline mode is ignored otherwise. in which case, that might mean that it doesn't affect signature verification at all. :( GnuPG folks -- what is the best way for a user of GPGME to avoid metadata leakage in this scenario as a default configuration? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From jestedfa at microsoft.com Sat Feb 3 19:48:26 2018 From: jestedfa at microsoft.com (Jeffrey Stedfast) Date: Sat, 3 Feb 2018 18:48:26 +0000 Subject: [gmime-devel] avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG In-Reply-To: <87o9l742kv.fsf@fifthhorseman.net> References: <87y3kb471j.fsf@fifthhorseman.net> <9201448a-83f1-2bf5-14d4-6b862a13e31e@gnome.org> <87o9l742kv.fsf@fifthhorseman.net> Message-ID: <0FD3E4E1-4C61-44BC-8B67-9996DE9D5DF2@microsoft.com> I've added code locally to set offline mode but reading the docs: https://www.gnupg.org/documentation/manuals/gpgme/Offline-Mode.html it suggests that setting offline mode only works for CMS and not OpenPGP? Can anyone from the GPGME team verify this? If so, I'll drop the flags that would indicate that this works in OpenPGP mode. Jeff ?On 2/2/18, 2:24 PM, "gmime-devel-list on behalf of Daniel Kahn Gillmor" wrote: On Fri 2018-02-02 13:13:32 -0500, Jeffrey Stedfast wrote: >> * tell GMime to disable crl checks > > I'd be willing to add an API to disable CRL checks if there's a way I > can pass that along to gpgme. thanks! >> * tell GMime not to verify S/MIME signatures at all > > Willing to add an API for this as well (although I guess it's not > necessary if an API to disable CRL checks is added?) i would rather not disable signature verification if we can do it without metadata leakage. > Well, I suppose that, like S/MIME signature verification, it would also > disable PGP key-server lookups? ah, right, i should be clearer about the use cases. I'm thinking right now about the use of GMime for *reading* mail. (Maybe we can talk about composing mail separately?) Is there any point during mail reading that you expect GMime to trigger a PGP keyserver lookup? > It might be best if there was a way to disable CRL checks on a per > gpgme_ctx_t basis as opposed to globally, but I can have GMime use the > global option until such an option exists (note: might be racey if you > try and verify signatures on multiple threads). gpgme_set_offline is actually per-gpgme_ctx_t: -- Function: void gpgme_set_offline (gpgme_ctx_t CTX, int YES) Sorry that i omitted that from the shorthand in my earlier message. But how would i use that with GMime? As of GMime 3 i'm in the practice of not not having to handle the GMimeCryptoCtx directly, because Gmime does the Right Thing anyway :) -- i'd like to keep that nice behavior! GMime should consider it as a new value for GMimeVerifyFlags? But i notice that g_mime_multipart_encrypted_decrypt () only takes a GMimeDecryptFlags, and it probably affects this too. I'll send a separate message to gmime-devel about this. > I'll wait for the GnuPG/GPGME devs to comment before making changes to > GMime. your message doesn't appear to have been let through to the gnupg-devel@ mailing list yet [0], so perhaps it's in moderation. --dkg [0] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnupg.org%2Fpipermail%2Fgnupg-devel%2F2018-February%2F&data=02%7C01%7Cjestedfa%40microsoft.com%7Ca93726fccf3341b635ba08d56a72a2c3%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636531962953290821&sdata=31FiENC95WdhP0le8lNFj%2BMG92pmesnANJic2TFnzLA%3D&reserved=0 From dkg at fifthhorseman.net Sun Feb 4 04:00:40 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 03 Feb 2018 22:00:40 -0500 Subject: [PATCH libgpg-error] doc: clarify patch submission workflow In-Reply-To: <20180201205548.GF1427@zaya.teonanacatl.net> References: <20180201132407.7791-1-Thorsten.Behrens@CIB.de> <87fu6k63sf.fsf@fifthhorseman.net> <20180201205548.GF1427@zaya.teonanacatl.net> Message-ID: <87d11l31d3.fsf@fifthhorseman.net> On Thu 2018-02-01 15:55:48 -0500, Todd Zullinger wrote: > I have my doubts that git send-email will ever directly > support PGP/MIME. But if signed patches are desired, > there's no reason not use git format-patch to generate a > patch (whether a single patch or a series with a cover > letter) and then use any decent mail client to send the > patch(es). you're suggesting a mail client that can take an existing file that contains an RFC822-formatted message, and will let the user sign and send it without this kind of stuff: > Using git send-email is generally just convenient for folks > whose mail clients would otherwise mangle the whitespace, > wrap the text, or otherwise bugger the patch content. i'd like to know which mail clients you use that really make that workflow easy :) > It's been a while since I've delved deeply into the PGP/MIME > specs, but does it ensure that no such whitespace mangling > will occur? Obviously, once the message is generated the > signature ensures nothing is changed. What I'm not sure of > is whether any part of the specification allows or requires > any sort of whitespace or other changes. PGP/MIME will preserve the whitespace. Inline PGP signatures are a whole other kettle of (messed up) fish, and should not be attempted. --dkg From tmz at pobox.com Sun Feb 4 05:55:11 2018 From: tmz at pobox.com (Todd Zullinger) Date: Sat, 3 Feb 2018 23:55:11 -0500 Subject: [PATCH libgpg-error] doc: clarify patch submission workflow In-Reply-To: <87d11l31d3.fsf@fifthhorseman.net> References: <20180201132407.7791-1-Thorsten.Behrens@CIB.de> <87fu6k63sf.fsf@fifthhorseman.net> <20180201205548.GF1427@zaya.teonanacatl.net> <87d11l31d3.fsf@fifthhorseman.net> Message-ID: <20180204045511.GP1427@zaya.teonanacatl.net> Hi Daniel, [Apologies for the relative length of this reply. Brevity is not my strong suite. ;)] Daniel Kahn Gillmor wrote: > On Thu 2018-02-01 15:55:48 -0500, Todd Zullinger wrote: >> I have my doubts that git send-email will ever directly >> support PGP/MIME. But if signed patches are desired, >> there's no reason not use git format-patch to generate a >> patch (whether a single patch or a series with a cover >> letter) and then use any decent mail client to send the >> patch(es). > > you're suggesting a mail client that can take an existing file that > contains an RFC822-formatted message, and will let the user sign and > send it without this kind of stuff: > >> Using git send-email is generally just convenient for folks >> whose mail clients would otherwise mangle the whitespace, >> wrap the text, or otherwise bugger the patch content. > > i'd like to know which mail clients you use that really make that > workflow easy :) Mutt doesn't do too badly here. Receiving a PGP/MIME signed patch can be easily decoded and saved, then applied using git am. It's only a matter of using decode-copy versus copy when saving the patch(es) (or using $pipe_decode for someone piping a patch directly from mutt to git am). That said, my main point is that I don't think it is likely that git send-email will support PGP/MIME natively soon, if ever?. And as such, I think describing a workflow that is not possible in the HACKING file isn't the most friendly thing (essentially what Damien said). It seems better to me to either leave out the ", preferably PGP/MIME signed" bit or describe a workflow for someone reading the HACKING file that can reasonably be followed. What that workflow is depends a bit on how the GnuPG maintainers incorporate patches from the list, which I don't know. > PGP/MIME will preserve the whitespace. Inline PGP signatures are a > whole other kettle of (messed up) fish, and should not be attempted. Teaching most mail clients to save a message without the PGP/MIME is probably trickier than with mutt, but I imagine maintainers and users who have a git workflow based on email use mail clients where this is feasible. If GnuPG wants to use signed patches, that's certainly great. It may be easier to do so using a slightly different workflow, depending on how difficult it is for new contributors to generate PGP/MIME formatted messages from their patches. Attaching messages and then signing them may be easier. Of course, some mail clients won't show the patches "attached" inline, but some mail clients just suck more than others. :) Another option might be to recommend that users generate patches with git format-patch? and then process them using another script which can PGP/MIME sign them. That script could either send the signed patches directly or feed them to git send-email (as far as I know, git send-email won't have trouble with already signed messages, but I haven't tested this). I don't know if there's already a convenient script to create PGP/MIME messages or not. It would be handy to have in many situations, I imagine, and very well may already exist. If so, it should be relatively easy to suggest to users whose mail clients don't make this as easy as mutt (or, I presume gnus). ? If someone wants git send-email to support PGP/MIME signing, they would need to propose patches to git. It would likely need to be done using either Perl or C (and rewriting git send-email in C first) to incur no significant new requirements in git. I say simply this based on my following of the git community over the years (and partly as a distro packager of git who would prefer that a core tool like git send-email avoids growing many more dependencies). ? Recommending git format-patch and then git send-email is better in any case, IMO. Junio has stated a few times on the git list that allowing git send-email to drive git format-patch seems like a bad decision. Most recently, https://public-inbox.org/git/xmqqo9lbt75o.fsf at gitster-ct.c.googlers.com/ -- Todd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Money can't buy happiness, but it sure makes living in misery easier. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Feb 6 02:44:51 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 5 Feb 2018 20:44:51 -0500 Subject: [PINENTRY PATCH] Fix format string errors in fltk pinentry Message-ID: <20180206014451.11167-1-dkg@fifthhorseman.net> if the mesage in question had formatting escape chars, this might be able to cause a crash (or worse) in the pinentry. Gbp-Pq: Name 0003-Fix-format-string-errors-in-fltk-pinentry.patch --- fltk/main.cxx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fltk/main.cxx b/fltk/main.cxx index 8e7e726..5d226ed 100644 --- a/fltk/main.cxx +++ b/fltk/main.cxx @@ -241,12 +241,12 @@ static int fltk_cmd_handler(pinentry_t pe) if (pe->one_button) { fl_ok = ok.c_str(); - fl_message(message); + fl_message("%s", message); result = 1; // OK } else if (pe->notok) { - switch (fl_choice(message, ok.c_str(), cancel.c_str(), pe->notok)) + switch (fl_choice("%s", ok.c_str(), cancel.c_str(), pe->notok, message)) { case 0: result = 1; break; case 2: result = 0; break; @@ -256,7 +256,7 @@ static int fltk_cmd_handler(pinentry_t pe) } else { - switch (fl_choice(message, ok.c_str(), cancel.c_str(), NULL)) + switch (fl_choice("%s", ok.c_str(), cancel.c_str(), NULL, message)) { case 0: result = 1; break; default: -- 2.15.1 From dkg at fifthhorseman.net Tue Feb 6 03:53:30 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 5 Feb 2018 21:53:30 -0500 Subject: [LIBGPG-ERROR PATCH] doc: use compiler flags for yat2m when not cross-built. Message-ID: <20180206025330.12028-1-dkg@fifthhorseman.net> * doc/Makefile.am (yat2m): use standard compiler flags when not cross-building. -- We ship yat2m when not cross-building. This means that yat2m ought to be built with the same flags that other native tools are built with. Signed-off-by: Daniel Kahn Gillmor --- doc/Makefile.am | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/doc/Makefile.am b/doc/Makefile.am index d052283..b82d7bf 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -35,8 +35,13 @@ myman_pages = gpg-error-config.1 man_MANS = $(myman_pages) yat2m: yat2m.c +if CROSS_COMPILING $(CC_FOR_BUILD) -DPACKAGE_VERSION="\"$(PACKAGE_VERSION)\"" \ -o $@ $(srcdir)/yat2m.c +else + $(CC_FOR_BUILD) $(CFLAGS) $(LDFLAGS) $(CPPFLAGS) -DPACKAGE_VERSION="\"$(PACKAGE_VERSION)\"" \ + -o $@ $(srcdir)/yat2m.c +endif yat2m-stamp: $(myman_sources) -- 2.15.1 From wk at gnupg.org Tue Feb 6 18:14:28 2018 From: wk at gnupg.org (Werner Koch) Date: Tue, 06 Feb 2018 18:14:28 +0100 Subject: [LIBGPG-ERROR PATCH] doc: use compiler flags for yat2m when not cross-built. In-Reply-To: <20180206025330.12028-1-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 5 Feb 2018 21:53:30 -0500") References: <20180206025330.12028-1-dkg@fifthhorseman.net> Message-ID: <87r2pyvy4r.fsf@wheatstone.g10code.de> On Tue, 6 Feb 2018 03:53, dkg at fifthhorseman.net said: > We ship yat2m when not cross-building. This means that yat2m ought to > be built with the same flags that other native tools are built with. > yat2m: yat2m.c > +if CROSS_COMPILING > $(CC_FOR_BUILD) -DPACKAGE_VERSION="\"$(PACKAGE_VERSION)\"" \ > -o $@ $(srcdir)/yat2m.c > +else > + $(CC_FOR_BUILD) $(CFLAGS) $(LDFLAGS) $(CPPFLAGS) -DPACKAGE_VERSION="\"$(PACKAGE_VERSION)\"" \ > + -o $@ $(srcdir)/yat2m.c > +endif The last line should be $(COMPILE) -DPACKAGE_VERSION="\"$(PACKAGE_VERSION)\"" \ -o $@ $(srcdir)/yat2m.c so that all flags (in particular AM_CFLAGS) as used as usually. More elegant would be to insert --8<---------------cut here---------------start------------->8--- if CROSS_COMPILING COMPILE_NATIVE_OR_CROSS = $(CC_FOR_BUILD) else COMPILE_NATIVE_OR_CROSS = $(COMPILE) endif --8<---------------cut here---------------end--------------->8--- at the top and use --8<---------------cut here---------------start------------->8--- yat2m: yat2m.c $(COMPILE_NATIVE_OR_CROSS) -DPACKAGE_VERSION="\"$(PACKAGE_VERSION)\"" \ -o $@ $(srcdir)/yat2m.c --8<---------------cut here---------------end--------------->8--- 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 arnaud.fontaine at ssi.gouv.fr Tue Feb 6 17:49:59 2018 From: arnaud.fontaine at ssi.gouv.fr (Arnaud Fontaine) Date: Tue, 6 Feb 2018 17:49:59 +0100 Subject: [PATCH] scd: Improve KDF-DO support Message-ID: <722b4c57-6246-ac1e-5c3c-47609fbb1570@ssi.gouv.fr> Hi, KDF-DO support as been recently introduced in GnuPG, but the implementation provided is not compliant with OpenPGP specifications. The attached patch fixes two issues: - when the KDF-DO algorithm is set to NONE (... 81 01 00 ...), no KDF should be applied which is not the case in the current implementation where KDF is applied as soon as the bit is set in extended capabilities and a DO exists (which is required by the spec) whatever its content (which is not compliant with the spec); - the specification says the KDF-DO is encapsulated in a tag F9 + length object, but the current implementation assumes the F9 tag + length are not present; so the currently used offsets in the DO buffer must be incremented by 2. Cheers, Arnaud Fontaine -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_kdf_do.patch Type: text/x-patch Size: 1842 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Feb 6 18:36:57 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 06 Feb 2018 12:36:57 -0500 Subject: [LIBGPG-ERROR PATCH] doc: use compiler flags for yat2m when not cross-built. In-Reply-To: <87r2pyvy4r.fsf@wheatstone.g10code.de> References: <20180206025330.12028-1-dkg@fifthhorseman.net> <87r2pyvy4r.fsf@wheatstone.g10code.de> Message-ID: <87lgg6xbnq.fsf@fifthhorseman.net> On Tue 2018-02-06 18:14:28 +0100, Werner Koch wrote: > so that all flags (in particular AM_CFLAGS) as used as usually. More > elegant would be [?] Any of these work for me. Feel free to commit the version that you think is the most elegant :) thanks, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From uenobk at gmail.com Wed Feb 7 10:46:54 2018 From: uenobk at gmail.com (Katsuhiro Ueno) Date: Wed, 7 Feb 2018 18:46:54 +0900 Subject: [PATCH gnupg] sm: Fix a wrong key parameter in an exported private key file Message-ID: <1517996814-15153-1-git-send-email-uenobk@gmail.com> * sm/export.c (sexp_to_kparms): Fix the computation of array[6], which must be 'd mod (q-1)' but was 'p mod (q-1)'. -- This bug is not serious but makes some consistency checks fail. For example, 'openssl rsa -check' reports the following error: $ gpgsm --out my.key --export-secret-key-raw 0xXXXXXXXX $ openssl rsa -check -noout -inform DER -in my.key RSA key error: dmq1 not congruent to d --- sm/export.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sm/export.c b/sm/export.c index 29a5ac3..a8c9a4a 100644 --- a/sm/export.c +++ b/sm/export.c @@ -603,7 +603,7 @@ sexp_to_kparms (gcry_sexp_t sexp) array[6] = gcry_mpi_snew (0); /* compute d mod (p-1) */ gcry_mpi_sub_ui (array[6], array[4], 1); - gcry_mpi_mod (array[6], array[3], array[6]); + gcry_mpi_mod (array[6], array[2], array[6]); return array; } -- 2.16.1 From uenobk at gmail.com Wed Feb 7 10:52:37 2018 From: uenobk at gmail.com (Katsuhiro Ueno) Date: Wed, 7 Feb 2018 18:52:37 +0900 Subject: [PATCH gnupg] agent: Avoid appending a '\0' byte to the response of READKEY Message-ID: <1517997157-15341-1-git-send-email-uenobk@gmail.com> * agent/command.c (cmd_readkey): Set pkbuflen to the length of the output without an extra '\0' byte. --- agent/command.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/agent/command.c b/agent/command.c index 7c7e8a4..36a21ae 100644 --- a/agent/command.c +++ b/agent/command.c @@ -1062,7 +1062,8 @@ cmd_readkey (assuan_context_t ctx, char *line) rc = gpg_error_from_syserror (); else { - gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, pkbuf, pkbuflen); + pkbuflen = gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, + pkbuf, pkbuflen); rc = assuan_send_data (ctx, pkbuf, pkbuflen); } } -- 2.16.1 From gniibe at fsij.org Thu Feb 8 01:19:57 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 08 Feb 2018 09:19:57 +0900 Subject: [PATCH] scd: Improve KDF-DO support In-Reply-To: <722b4c57-6246-ac1e-5c3c-47609fbb1570@ssi.gouv.fr> References: <722b4c57-6246-ac1e-5c3c-47609fbb1570@ssi.gouv.fr> Message-ID: <87inb8gwnm.fsf@iwagami.gniibe.org> Hello, Arnaud Fontaine writes: > The attached patch fixes two issues: > - when the KDF-DO algorithm is set to NONE (... 81 01 00 ...), no KDF > should be applied which is not the case in the current implementation > where KDF is applied as soon as the bit is set in extended capabilities > and a DO exists (which is required by the spec) whatever its content > (which is not compliant with the spec); I will apply this part. It's good if you submit this part only, at first. > - the specification says the KDF-DO is encapsulated in a tag F9 + length > object, but the current implementation assumes the F9 tag + length are > not present; so the currently used offsets in the DO buffer must be > incremented by 2. My interpretation is different. It is a constructed DO. For all other constructed DOs, OpenPGPcard responds with the constructed DO's tag+length omitted. For example, 65 or 6E. Is F9 special? -- From arnaud.fontaine at ssi.gouv.fr Thu Feb 8 09:35:41 2018 From: arnaud.fontaine at ssi.gouv.fr (Arnaud Fontaine) Date: Thu, 8 Feb 2018 09:35:41 +0100 Subject: [PATCH] scd: Improve KDF-DO support In-Reply-To: <87inb8gwnm.fsf@iwagami.gniibe.org> References: <722b4c57-6246-ac1e-5c3c-47609fbb1570@ssi.gouv.fr> <87inb8gwnm.fsf@iwagami.gniibe.org> Message-ID: <5dbf4349-ee53-24fb-e471-84c7212a27d7@ssi.gouv.fr> Hello, the specification (section 4.4.1, page 22, in v3.3) says: "Constructed DOs (C, marked yellow) are returned including their tag and length" and in the same section, page 25, F9 (KDF-DO) in marked as a constructed DO, "format C". So, from my understanding of these elements, the KDF-DO must be returned with its tag and length. Cheers -- Arnaud Fontaine Le 08/02/2018 ? 01:19, NIIBE Yutaka a ?crit?: > Hello, > > Arnaud Fontaine writes: >> The attached patch fixes two issues: >> - when the KDF-DO algorithm is set to NONE (... 81 01 00 ...), no KDF >> should be applied which is not the case in the current implementation >> where KDF is applied as soon as the bit is set in extended capabilities >> and a DO exists (which is required by the spec) whatever its content >> (which is not compliant with the spec); > > I will apply this part. It's good if you submit this part only, at first. > >> - the specification says the KDF-DO is encapsulated in a tag F9 + length >> object, but the current implementation assumes the F9 tag + length are >> not present; so the currently used offsets in the DO buffer must be >> incremented by 2. > > My interpretation is different. It is a constructed DO. For all other > constructed DOs, OpenPGPcard responds with the constructed DO's > tag+length omitted. For example, 65 or 6E. Is F9 special? > From gniibe at fsij.org Thu Feb 8 11:43:46 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 08 Feb 2018 19:43:46 +0900 Subject: [PATCH] scd: Improve KDF-DO support In-Reply-To: <5dbf4349-ee53-24fb-e471-84c7212a27d7@ssi.gouv.fr> References: <722b4c57-6246-ac1e-5c3c-47609fbb1570@ssi.gouv.fr> <87inb8gwnm.fsf@iwagami.gniibe.org> <5dbf4349-ee53-24fb-e471-84c7212a27d7@ssi.gouv.fr> Message-ID: <878tc34v8d.fsf@fsij.org> Arnaud Fontaine wrote: > the specification (section 4.4.1, page 22, in v3.3) says: > "Constructed DOs (C, marked yellow) are returned including their tag and > length" > and in the same section, page 25, F9 (KDF-DO) in marked as a constructed > DO, "format C". > > So, from my understanding of these elements, the KDF-DO must be returned > with its tag and length. Well, I have test version of Version 3.3 card from Achim. It doesn't put tag for 65 and 6E, at least. I don't think it supports KDF-DO. In this situation, I think that it's better for GnuPG to allow an implementation of omitting tag, even if it allows violation of the specification. -- From arnaud.fontaine at ssi.gouv.fr Thu Feb 8 13:51:20 2018 From: arnaud.fontaine at ssi.gouv.fr (Arnaud Fontaine) Date: Thu, 8 Feb 2018 13:51:20 +0100 Subject: [PATCH] scd: Improve KDF-DO support In-Reply-To: <878tc34v8d.fsf@fsij.org> References: <722b4c57-6246-ac1e-5c3c-47609fbb1570@ssi.gouv.fr> <87inb8gwnm.fsf@iwagami.gniibe.org> <5dbf4349-ee53-24fb-e471-84c7212a27d7@ssi.gouv.fr> <878tc34v8d.fsf@fsij.org> Message-ID: Le 08/02/2018 ? 11:43, NIIBE Yutaka a ?crit?: > In this situation, I think that it's better for GnuPG to allow an > implementation of omitting tag, even if it allows violation of the > specification. Do you suggest to support both implementations, with and without the tag+length ? Is it OK if I submit a patch that supports both ? From arnaud.fontaine at ssi.gouv.fr Thu Feb 8 14:02:44 2018 From: arnaud.fontaine at ssi.gouv.fr (Arnaud Fontaine) Date: Thu, 8 Feb 2018 14:02:44 +0100 Subject: [PATCH] scd: Improve KDF-DO support In-Reply-To: References: <722b4c57-6246-ac1e-5c3c-47609fbb1570@ssi.gouv.fr> <87inb8gwnm.fsf@iwagami.gniibe.org> <5dbf4349-ee53-24fb-e471-84c7212a27d7@ssi.gouv.fr> <878tc34v8d.fsf@fsij.org> Message-ID: <73fd485a-1613-a598-577f-19cafe8f8efd@ssi.gouv.fr> Here is a patch that deals with both implementations (with and without tag). Le 08/02/2018 ? 13:51, Arnaud Fontaine a ?crit?: > Le 08/02/2018 ? 11:43, NIIBE Yutaka a ?crit?: >> In this situation, I think that it's better for GnuPG to allow an >> implementation of omitting tag, even if it allows violation of the >> specification. > > Do you suggest to support both implementations, with and without the > tag+length ? > Is it OK if I submit a patch that supports both ? > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_kdf_do.patch Type: text/x-patch Size: 2095 bytes Desc: not available URL: From ben at adversary.org Thu Feb 8 18:12:07 2018 From: ben at adversary.org (Ben McGinnes) Date: Fri, 9 Feb 2018 04:12:07 +1100 Subject: [PATCH] doc: Note pinentry-mode for passphrase opts In-Reply-To: <87efmw1oxl.fsf@fifthhorseman.net> References: <1830532.otWbhZNTya@esus> <87d12k6mp0.fsf@fifthhorseman.net> <1660728.9KMfWaAYFe@esus> <87po6j552k.fsf@fifthhorseman.net> <20180110225102.3k4ykstv5v7fqsaq@adversary.org> <87efmw1oxl.fsf@fifthhorseman.net> Message-ID: <20180208171207.nlobbbvlkg5ytnaf@adversary.org> On Thu, Jan 11, 2018 at 08:54:14AM -0500, Daniel Kahn Gillmor wrote: > On Thu 2018-01-11 09:51:02 +1100, Ben McGinnes wrote: > > thanks to Ben and Neal for the feedback, i'm now tracking the > problem in a local toolchain -- I can confirm that i have at least > one set of tools that does verify andre's signature correctly. I > can follow up on list here if folks are interested once i've got a > proper diagnosis. I am a little curious, just in case it's the sort of thing which might crop up in diagnosing other things. >> because I haven't signed or trusted Andre's key, but other than that >> it seemed fine. > > (nitpick: you should never need to "trust" Andre's key to verify > signatures from it! i think you just mean that neither you nor > anyone that you trust has directly certified Andre's key) Correct. One of the other problems with living on Tatooine (Australia) is that, to paraphrase, "if there's a brightest centre of civilisation, I'm on the continent that's farthest from it." So there's a (practical) limit to the extent of direct keysigning which can occur following a face-to-face or other trusted and verified out of band confirmation of identity and key control. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From arnaud.fontaine at ssi.gouv.fr Thu Feb 8 19:03:08 2018 From: arnaud.fontaine at ssi.gouv.fr (Arnaud Fontaine) Date: Thu, 8 Feb 2018 19:03:08 +0100 Subject: [PATCH] scd: Improve KDF-DO support In-Reply-To: References: <722b4c57-6246-ac1e-5c3c-47609fbb1570@ssi.gouv.fr> <87inb8gwnm.fsf@iwagami.gniibe.org> <5dbf4349-ee53-24fb-e471-84c7212a27d7@ssi.gouv.fr> Message-ID: I think adding some examples is a good idea to clarify ambiguous sentences such as the one I have quoted. So no encapsulating tag in the response, only the child ones. Correct ? @Yutaka If this is correct, the following patch is enough to trigger the KDF_ITERSALTED_S2K only when needed. Cheers -- Arnaud Fontaine Le 08/02/2018 ? 18:19, Achim Pietig a ?crit?: > Hi, > > this is a common missunderstandig how data objects are read or written. > > The leading Tag (like 65 or F9) is the the index under what the data object is stored in the card. > This Tag is used to address the content of the DO within commands like Get Data or Put Data in the P1P2 bytes. > The data field or response field only contains the values of these DOs. > In case of a simple DO it is a single value, in case of a constructed DO the child-DOs with Tag/Lenght/Value (TLV). > > "Constructed DOs (C, marked yellow) are returned including their tag and length" means the content of the DO, for constructed DOs a concatenation of all child DOs. > The main Tag (in P1P2) is never used/given/returned in the data field of the commands. > > In the nearest future I will launch an update of the V3.3 specification with examples for all commands (no technical changes, only for better understanding). > > Regards > Achim Pietig > > > Am 08.02.2018 um 09:35 schrieb Arnaud Fontaine: >> Hello, >> >> the specification (section 4.4.1, page 22, in v3.3) says: >> "Constructed DOs (C, marked yellow) are returned including their tag and >> length" >> and in the same section, page 25, F9 (KDF-DO) in marked as a constructed >> DO, "format C". >> >> So, from my understanding of these elements, the KDF-DO must be returned >> with its tag and length. >> >> Cheers >> -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_kdf_do.patch Type: text/x-patch Size: 510 bytes Desc: not available URL: From achim at pietig.com Thu Feb 8 19:50:10 2018 From: achim at pietig.com (Achim Pietig) Date: Thu, 8 Feb 2018 19:50:10 +0100 Subject: [PATCH] scd: Improve KDF-DO support In-Reply-To: References: <722b4c57-6246-ac1e-5c3c-47609fbb1570@ssi.gouv.fr> <87inb8gwnm.fsf@iwagami.gniibe.org> <5dbf4349-ee53-24fb-e471-84c7212a27d7@ssi.gouv.fr> Message-ID: Hi, the actual V3.3 card returns H81, &H01, &H00, &H9000 to a Get Data with P1P2 = 00F9, that means KDF-DO is present, but not used/personalised. Reagrds Achim Am 08.02.2018 um 19:03 schrieb Arnaud Fontaine: > I think adding some examples is a good idea to clarify ambiguous > sentences such as the one I have quoted. > > So no encapsulating tag in the response, only the child ones. Correct ? > > @Yutaka > If this is correct, the following patch is enough to trigger the > KDF_ITERSALTED_S2K only when needed. > > Cheers > From achim at pietig.com Thu Feb 8 18:19:44 2018 From: achim at pietig.com (Achim Pietig) Date: Thu, 8 Feb 2018 18:19:44 +0100 Subject: [PATCH] scd: Improve KDF-DO support In-Reply-To: <5dbf4349-ee53-24fb-e471-84c7212a27d7@ssi.gouv.fr> References: <722b4c57-6246-ac1e-5c3c-47609fbb1570@ssi.gouv.fr> <87inb8gwnm.fsf@iwagami.gniibe.org> <5dbf4349-ee53-24fb-e471-84c7212a27d7@ssi.gouv.fr> Message-ID: Hi, this is a common missunderstandig how data objects are read or written. The leading Tag (like 65 or F9) is the the index under what the data object is stored in the card. This Tag is used to address the content of the DO within commands like Get Data or Put Data in the P1P2 bytes. The data field or response field only contains the values of these DOs. In case of a simple DO it is a single value, in case of a constructed DO the child-DOs with Tag/Lenght/Value (TLV). "Constructed DOs (C, marked yellow) are returned including their tag and length" means the content of the DO, for constructed DOs a concatenation of all child DOs. The main Tag (in P1P2) is never used/given/returned in the data field of the commands. In the nearest future I will launch an update of the V3.3 specification with examples for all commands (no technical changes, only for better understanding). Regards Achim Pietig Am 08.02.2018 um 09:35 schrieb Arnaud Fontaine: > Hello, > > the specification (section 4.4.1, page 22, in v3.3) says: > "Constructed DOs (C, marked yellow) are returned including their tag and > length" > and in the same section, page 25, F9 (KDF-DO) in marked as a constructed > DO, "format C". > > So, from my understanding of these elements, the KDF-DO must be returned > with its tag and length. > > Cheers > From look at my.amazin.horse Sun Feb 11 13:05:49 2018 From: look at my.amazin.horse (Vincent Breitmoser) Date: Sun, 11 Feb 2018 13:05:49 +0100 Subject: cv25519 scalar byte order Message-ID: <20180211120549.GA23215@calamity> Hey folks, I've been working recently on finally getting cv25519 to work in OpenKeychain, and I did achieve an interoperable implementation in the end. But there is a part that doesn't work as I expected from the spec, maybe someone here has an explanation. So, since we already had ECDH working for other curves, I had all the KDF parts in place. I created an encrypted file in GnuPG and built a unit test from that to work against. Switching out the curve operation for X25519 didn't take long - but the test didn't work. I got some intermediate crypto parameters from gnupg, and compared them to my implementation. The difference in numbers happened around X25519 itself: I would give it the same numbers that GnuPG used as input for the operation, but receive a different result and the aes-unwrap failed afterwards. The difference I found was that GnuPG apparently reverses the order of bytes in the scalar before doing the X25519 operation. In its tests, it uses the vectors from RFC 7748 as input for `test_cv(k, u)` function, but the bytes of k are reversed before being handed to the actual implementation: https://github.com/gpg/libgcrypt/blob/master/tests/t-cv25519.c#L146 The input format for the X25519 parameters is defined in 4880-bis as "0x40, followed by the custom format defined by the operation". I'm also fairly sure I didn't similarly reverse the input scalar for EdDSA. So this was quite the curveball for me (haha) while implementing this to spec. I spent some time looking at this, but couldn't find the part of the spec that would require this reversing of bytes, and nobody I asked so far could explain this behavior to me. Is GnuPG behaving weirdly? Or what am I missing? Cheers - V From jussi.kivilinna at iki.fi Sun Feb 11 22:11:49 2018 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Sun, 11 Feb 2018 23:11:49 +0200 Subject: DCO for Jussi Kivilinna Message-ID: <2d8b7014-ff67-1e73-1152-9ff9fb8c10d7@iki.fi> GnuPG Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the GnuPG project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: Jussi Kivilinna -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 671 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Mon Feb 12 10:31:37 2018 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 12 Feb 2018 10:31:37 +0100 Subject: avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG In-Reply-To: <87y3kb471j.fsf@fifthhorseman.net> References: <87y3kb471j.fsf@fifthhorseman.net> Message-ID: <201802121031.41954.bernhard@intevation.de> Hello, Am Freitag 02 Februar 2018 18:48:08 schrieb Daniel Kahn Gillmor: > I recently learned that default handling of signed S/MIME mail with > GnuPG causes an inherent metadata leak about the user's activity: > > ? ? https://dev.gnupg.org/T3348#110132 from briefly reading over the issue I think that "inherent metadata leak" is too broad a term to represent the security pros and cons well enough. Just sending an email or a webpage will also inherently leak meta data for someone listening on the line. So you'll certainly won't disable begin able to send those as well. > As a MUA developer, I'd like my MUA to simply handle as much crypto as > it can on the user's behalf automatically, correctly and silently, > without needing any special configuration or asking the user to make any > tough tradeoffs that they might object to. Users might also object to the higher exposure to revoked certificates and a more surprising behaviour deviating from the CMS standards (which as far as I know mandate checking the validity of certs). It comes down to post some trust into the implementations and the certificate authorities you chose to use. I think we'd do more for users if we educate them about some of the more basic properties. Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From arnaud.fontaine at ssi.gouv.fr Mon Feb 12 10:36:18 2018 From: arnaud.fontaine at ssi.gouv.fr (Arnaud Fontaine) Date: Mon, 12 Feb 2018 10:36:18 +0100 Subject: [PATCH] scd: Improve KDF-DO support In-Reply-To: References: <722b4c57-6246-ac1e-5c3c-47609fbb1570@ssi.gouv.fr> <87inb8gwnm.fsf@iwagami.gniibe.org> <5dbf4349-ee53-24fb-e471-84c7212a27d7@ssi.gouv.fr> Message-ID: Hi, so you (will) have the same problem with the current implementation where KDF_ITERSALTED_S2K is systematically applied when the card supports KDF (bit set in the extended capabilities) and a KDF-DO is present (whatever its content). Cheers -- Arnaud Fontaine Le 08/02/2018 ? 19:50, Achim Pietig a ?crit?: > Hi, > > the actual V3.3 card returns H81, &H01, &H00, &H9000 to a Get Data with P1P2 = 00F9, that means KDF-DO is present, but not used/personalised. > > Reagrds > Achim > > > Am 08.02.2018 um 19:03 schrieb Arnaud Fontaine: >> I think adding some examples is a good idea to clarify ambiguous >> sentences such as the one I have quoted. >> >> So no encapsulating tag in the response, only the child ones. Correct ? >> >> @Yutaka >> If this is correct, the following patch is enough to trigger the >> KDF_ITERSALTED_S2K only when needed. >> >> Cheers >> From achim at pietig.com Mon Feb 12 18:17:54 2018 From: achim at pietig.com (Achim Pietig) Date: Mon, 12 Feb 2018 18:17:54 +0100 Subject: [PATCH] scd: Improve KDF-DO support In-Reply-To: References: <722b4c57-6246-ac1e-5c3c-47609fbb1570@ssi.gouv.fr> <87inb8gwnm.fsf@iwagami.gniibe.org> <5dbf4349-ee53-24fb-e471-84c7212a27d7@ssi.gouv.fr> Message-ID: <032d76ab-81e6-c102-6a1f-39cdf94d11be@pietig.com> Hello Arnaud, as I understand Niibes implementation correctly, the actual definition in the card should work. If the flag for KDF is set in Extended capabilites, the KDF-DO shall be evaluated (is part of application data 6E; if not can be read separately with Tag F9). If all child DOs (F9) are filled with valid data, the KDF-support is installed and the passwords are still set to this format. If the DO is empty (810100 means empty) or not valid, the passwords are in standard format and can be set by any software that can handle that. During changing the passwords to KDF-format, the KDF-DO must be set to a proper value. Reagrds Achim Am 12.02.2018 um 10:36 schrieb Arnaud Fontaine: > Hi, > > so you (will) have the same problem with the current implementation > where KDF_ITERSALTED_S2K is systematically applied when the card > supports KDF (bit set in the extended capabilities) and a KDF-DO is > present (whatever its content). > > Cheers > From Arnaud.Fontaine at ssi.gouv.fr Mon Feb 12 23:17:42 2018 From: Arnaud.Fontaine at ssi.gouv.fr (Fontaine Arnaud) Date: Mon, 12 Feb 2018 22:17:42 +0000 Subject: [PATCH] scd: Improve KDF-DO support Message-ID: <3ce6c4766ab04856a36a06a2cd927d75@ssi.gouv.fr> I think there is a misunderstanding: the current GnuPG implementation is ignoring the content of the KDF-DO, including the algorithm tag even if it is set to NONE. The current (g?t master branche) GnuPG implementation with your card (or mine) is just unusable because it systematically applies a derivation of the PIN entered by the user, even when KDF-DO algorithm is set to NONE, thus producing a "Bas PIN value" error making any operation, including PIN change of course, impossible. I hope it is more clear this way. -- Arnaud Fontaine Le 12 f?vr. 2018 6:18 PM, Achim Pietig a ?crit : Hello Arnaud, as I understand Niibes implementation correctly, the actual definition in the card should work. If the flag for KDF is set in Extended capabilites, the KDF-DO shall be evaluated (is part of application data 6E; if not can be read separately with Tag F9). If all child DOs (F9) are filled with valid data, the KDF-support is installed and the passwords are still set to this format. If the DO is empty (810100 means empty) or not valid, the passwords are in standard format and can be set by any software that can handle that. During changing the passwords to KDF-format, the KDF-DO must be set to a proper value. Reagrds Achim Am 12.02.2018 um 10:36 schrieb Arnaud Fontaine: > Hi, > > so you (will) have the same problem with the current implementation > where KDF_ITERSALTED_S2K is systematically applied when the card > supports KDF (bit set in the extended capabilities) and a KDF-DO is > present (whatever its content). > > Cheers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Tue Feb 13 05:25:46 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 13 Feb 2018 13:25:46 +0900 Subject: [PATCH] scd: Improve KDF-DO support In-Reply-To: <3ce6c4766ab04856a36a06a2cd927d75@ssi.gouv.fr> References: <3ce6c4766ab04856a36a06a2cd927d75@ssi.gouv.fr> Message-ID: <87lgfxy0qd.fsf@iwagami.gniibe.org> Fontaine Arnaud wrote: > I think there is a misunderstanding: the current GnuPG implementation > is ignoring the content of the KDF-DO, including the algorithm tag > even if it is set to NONE. I applied your patch. Thanks. -- From wk at gnupg.org Tue Feb 13 13:51:12 2018 From: wk at gnupg.org (Werner Koch) Date: Tue, 13 Feb 2018 13:51:12 +0100 Subject: cv25519 scalar byte order In-Reply-To: <20180211120549.GA23215@calamity> (Vincent Breitmoser's message of "Sun, 11 Feb 2018 13:05:49 +0100") References: <20180211120549.GA23215@calamity> Message-ID: <87o9ktxdbz.fsf@wheatstone.g10code.de> On Sun, 11 Feb 2018 13:05, look at my.amazin.horse said: > https://github.com/gpg/libgcrypt/blob/master/tests/t-cv25519.c#L146 Pretty please do not reference arbitrary clones of GnuPG software but us the standard place git.gnupg.org (or maybe dev.gnupg.org). It would also be useful to explain you question with a hex dump of the parameters instead of just a verbal description. 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 look at my.amazin.horse Tue Feb 13 23:03:58 2018 From: look at my.amazin.horse (Vincent Breitmoser) Date: Tue, 13 Feb 2018 23:03:58 +0100 Subject: cv25519 scalar byte order In-Reply-To: <87o9ktxdbz.fsf@wheatstone.g10code.de> References: <20180211120549.GA23215@calamity> <87o9ktxdbz.fsf@wheatstone.g10code.de> Message-ID: <20180213220358.GA31022@calamity> Werner Koch(wk at gnupg.org)@Tue, Feb 13, 2018 at 01:51:12PM +0100: > It would also be useful to explain you question with a hex dump of the > parameters instead of just a verbal description. Sure. X25519 Input: k = 45afc2b924ad66c34dd0508f4aac568f8b8b3c154f7ae44104b794c7551dfd88 u = b94121e20db0369d7cbbd8d09372bae2d48d6e990b5f60895f326235e195e134 X25519 Output: bouncycastle and tink = c3843a427995b2031e160409b6b1a29700e6e84ee274283bd754f8f9df212313 GnuPG = 005acc6baccaaf72041b10ca74c24e311804958dc87cda5a1e96073c0b922726 See attached secret key and secret message with those values. This fails to decrypt for me if I use k for the X25519 input (before SP800-56A), but succeeds with reverse(k). While implementing to spec, this was unexpected for me, and it took me quite a while to figure out what GnuPG was doing differently. I also double-checked, for EdDSA the MPI value is not similarly reversed before it is handed as a scalar to the algorithm. - V -------------- next part -------------- A non-text attachment was scrubbed... Name: cv25519-encrypted.asc.gpg Type: application/octet-stream Size: 160 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cv25519-key.sec.asc.gpg Type: application/octet-stream Size: 466 bytes Desc: not available URL: From gniibe at fsij.org Wed Feb 14 03:46:52 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 14 Feb 2018 11:46:52 +0900 Subject: cv25519 scalar byte order In-Reply-To: <20180213220358.GA31022@calamity> References: <20180211120549.GA23215@calamity> <87o9ktxdbz.fsf@wheatstone.g10code.de> <20180213220358.GA31022@calamity> Message-ID: <87r2pop9sz.fsf@iwagami.gniibe.org> Vincent Breitmoser wrote: > See attached secret key and secret message with those values. This fails > to decrypt for me if I use k for the X25519 input (before SP800-56A), > but succeeds with reverse(k). > > While implementing to spec, this was unexpected for me, and it took me > quite a while to figure out what GnuPG was doing differently. I also > double-checked, for EdDSA the MPI value is not similarly reversed before > it is handed as a scalar to the algorithm. Well, I admit that it's confusing, and it would be considered a kind of problem in GnuPG implementation. Let us consider how we can go forward. FWIW, I debug with the following: $ gpg --debug=crypto -a -o /tmp/OUTPUT.asc -a -r -e SOMEFILE $ gpg --debug=crypto,ipc /tmp/OUTPUT.asc I think that there are two things; input handling to encryption/decryption functions and output handling from those functions. The latter is troublesome, I suppose. (1) INPUT handling for ECDH In the libgcrypt API of gcry_pk_encrypt, scalar input is defined as MPI (big-endian order). When GnuPG calls gcry_pk_encrypt, no conversion is done for scalar input; The octet sequence is interpreted as standard MPI (big-endian). # In the test code of X25519 (libgcrypt/tests/t-cv25519.c), the scalar # input K is needed to be converted from little-endian (defined in # X25519) to big-endian, thus, we have reverse_buffer. While gcry_pk_decrypt supports scalar input with the prefix 0x40 for little-endian public key, gcry_pk_encrypt doesn't support scalar input with the prefix 0x40 (yet). I think that this is just a little problem. It is possible for libgcrypt to support the prefix 0x40, so that t-cv25519.c can be less confusion. (2) OUTPUT handling for ECDH Both of gcry_pk_encrypt and gcry_pk_decrypt output the scalar with the prefix 0x40. After the prefix, it's little-endian. In GnuPG (pk_ecdh_encrypt_with_shared_point in gnupg/g10/ecdh.c), For shared secret, result comes with the prefix 0x40 from libgcrypt, then, the octet sequence after 0x40 is used as-is (with no conversion of endian) to the input to KDF function. I think that we have interpretation problem here. In the section 7. Key Derivation Function in RFC 6637, KDF is described referring NIST-SP800-56A and RFC 6090. For the prefix 0x40, I interpret it as "extracting X part from the representation of Z", no change of byte-order. -- From gniibe at fsij.org Wed Feb 14 06:13:32 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 14 Feb 2018 14:13:32 +0900 Subject: cv25519 scalar byte order In-Reply-To: <87r2pop9sz.fsf@iwagami.gniibe.org> References: <20180211120549.GA23215@calamity> <87o9ktxdbz.fsf@wheatstone.g10code.de> <20180213220358.GA31022@calamity> <87r2pop9sz.fsf@iwagami.gniibe.org> Message-ID: <878tbw5f2b.fsf@fsij.org> Hello, Here is an example packet of secret key as an output of GnuPG's --list-packets. ========================== # off=267 ctb=9c tag=7 hlen=2 plen=93 :secret sub key packet: version 4, algo 18, created 1518583322, expires 0 pkey[0]: 0A2B060104019755010501 cv25519 (1.3.6.1.4.1.3029.1.5.1) pkey[1]: 40FD57ED7E6D3490F0BFB4995F281A53648842CDB84DEBA6726DF5BA1994968D23 pkey[2]: 03010807 skey[3]: 5669627AB7427CE223BD94101603978F3F4599AE1A007087A0B3DBBFB67D3278 checksum: 0f5a keyid: 55C6A075A3C82F68 ========================== I wonder if we have difference in the interpretation of secret part (skey[3]). In GnuPG, this part is interpreted as standard MPI representation (big-endian). For better interoperability, we could support the prefix 0x40 for this secret part, I suppose. -- From wk at gnupg.org Wed Feb 14 14:56:47 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 Feb 2018 14:56:47 +0100 Subject: [PATCH gnupg] sm: Fix a wrong key parameter in an exported private key file In-Reply-To: <1517996814-15153-1-git-send-email-uenobk@gmail.com> (Katsuhiro Ueno's message of "Wed, 7 Feb 2018 18:46:54 +0900") References: <1517996814-15153-1-git-send-email-uenobk@gmail.com> Message-ID: <87sha3u128.fsf@wheatstone.g10code.de> On Wed, 7 Feb 2018 10:46, uenobk at gmail.com said: > * sm/export.c (sexp_to_kparms): Fix the computation of array[6], > which must be 'd mod (q-1)' but was 'p mod (q-1)'. Very good catch. Thanks. I added this comment: This bug was introduced with Fixes-commit: 91056b1976bfb7b755e53b1302f4ede2b5cbc05d right at the start of GnuPG 2.1 in July 2010. Before that (in 2.0) we used gpg-protect-tool which got it right. We probably never noticed this because gpgsm, and maybe other tools too, fix things up during import. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Feb 14 17:25:19 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 Feb 2018 17:25:19 +0100 Subject: [PATCH gnupg] agent: Avoid appending a '\0' byte to the response of READKEY In-Reply-To: <1517997157-15341-1-git-send-email-uenobk@gmail.com> (Katsuhiro Ueno's message of "Wed, 7 Feb 2018 18:52:37 +0900") References: <1517997157-15341-1-git-send-email-uenobk@gmail.com> Message-ID: <87inaztu6o.fsf@wheatstone.g10code.de> On Wed, 7 Feb 2018 10:52, uenobk at gmail.com said: > * agent/command.c (cmd_readkey): Set pkbuflen to the length of the output > without an extra '\0' byte. Thanks. If you intend to send more patches, please post a DCO; see doc/HACKING for details. 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 look at my.amazin.horse Thu Feb 15 00:24:11 2018 From: look at my.amazin.horse (Vincent Breitmoser) Date: Thu, 15 Feb 2018 00:24:11 +0100 Subject: cv25519 scalar byte order In-Reply-To: <878tbw5f2b.fsf@fsij.org> References: <20180211120549.GA23215@calamity> <87o9ktxdbz.fsf@wheatstone.g10code.de> <20180213220358.GA31022@calamity> <87r2pop9sz.fsf@iwagami.gniibe.org> <878tbw5f2b.fsf@fsij.org> Message-ID: <20180214232411.GA19521@calamity> > I wonder if we have difference in the interpretation of secret part > (skey[3]). > > In GnuPG, this part is interpreted as standard MPI representation > (big-endian). MPIs are specified as big-endian, but this doesn't really have meaning if they aren't actually interpreted as numbers. RFC7748 specifically defines EdDSA and X25519 over octet-strings: # Although the functions work internally with integers, the inputs and # outputs are 32-byte strings (for X25519) or 56-byte strings (for X448) # and this specification defines their encoding. My expectation was that skey[3] would be passed to the functions as-is, which was matched by GnuPG for EdDSA, but not X25519. As for where to go from here, I don't know. Most importantly, we should make sure the spec can be independently implemented in an interoperable way. :) - V From gniibe at fsij.org Thu Feb 15 08:40:25 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 15 Feb 2018 16:40:25 +0900 Subject: cv25519 scalar byte order In-Reply-To: <20180214232411.GA19521@calamity> References: <20180211120549.GA23215@calamity> <87o9ktxdbz.fsf@wheatstone.g10code.de> <20180213220358.GA31022@calamity> <87r2pop9sz.fsf@iwagami.gniibe.org> <878tbw5f2b.fsf@fsij.org> <20180214232411.GA19521@calamity> Message-ID: <87woze4s5y.fsf@fsij.org> Vincent Breitmoser wrote: > MPIs are specified as big-endian, but this doesn't really have meaning > if they aren't actually interpreted as numbers. RFC7748 specifically > defines EdDSA and X25519 over octet-strings: That would be an interesting claim. Please note that our adoption of ECDH using Curve25519 was done before X25519. In the context of RFC 6637, which defines 18 for ECDH public key algorithm, it is a valid interpretation to handle the secret key field in a way described in the section 9. Encoding of Public and Private Keys. It seems for me that you are implementing OpenPGP ECDH of Curve25519 on top of X25519 function. That's different path. If so, I could understand your claim, but... if it is the case, from my viewpoint, it's more relevant to have new algorithm ID of twenty-something. > My expectation was that skey[3] would be passed to the functions as-is, > which was matched by GnuPG for EdDSA, but not X25519. Since EdDSA has its own algorithm ID, the definition of the field is up to EdDSA. > As for where to go from here, I don't know. Most importantly, we should > make sure the spec can be independently implemented in an interoperable > way. :) Perhaps, refering RFC7749 for Curve25519 is not good if it can result such a confusion? While I don't know how to improve the spec, but it is needed to clarify. -- From look at my.amazin.horse Thu Feb 15 10:54:39 2018 From: look at my.amazin.horse (Vincent Breitmoser) Date: Thu, 15 Feb 2018 10:54:39 +0100 Subject: cv25519 scalar byte order In-Reply-To: <87woze4s5y.fsf@fsij.org> References: <20180211120549.GA23215@calamity> <87o9ktxdbz.fsf@wheatstone.g10code.de> <20180213220358.GA31022@calamity> <87r2pop9sz.fsf@iwagami.gniibe.org> <878tbw5f2b.fsf@fsij.org> <20180214232411.GA19521@calamity> <87woze4s5y.fsf@fsij.org> Message-ID: <20180215095439.GA25284@calamity> Hey gniibe, > Please note that our adoption of ECDH using Curve25519 was done before > X25519. In the context of RFC 6637, which defines 18 for ECDH public > key algorithm, it is a valid interpretation to handle the secret key > field in a way described in the section 9. That actually explains a lot, haha! I was following the reference to RFC7748 from rfc4880bis: https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-04#section-13.1 And given that the public point is encoded with a 0x40 prefix, I assumed that X25519 was used the same way as EdDSA as a type of ECDH. What else would define the "custom point compression" format that is used here, if not X25519? > it's more relevant to have new algorithm ID of twenty-something. That would be a lot simpler both in terms of specification and implementation - just put byte arrays into a well-defined, well-specified and widely used method. Compared to actually dealing with points on curves and their different representations etc. Alas, it's probably too late for that idea to be useful. > Perhaps, refering RFC7749 for Curve25519 is not good if it can result > such a confusion? While I don't know how to improve the spec, but > it is needed to clarify. I'm not sure. If it's valid to "just X25519, then KDF" (and that worked at least for me, modulo reversing the byte array) then I would definitely point that out specifically in the spec, as it greatly simplifies implementation. I had failed implementing cv25519 support using bouncycastle's plain Curve25519 primitives before. Thanks for your input so far, much appreciated! - V From dgouttegattat at incenp.org Mon Feb 19 10:59:46 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Mon, 19 Feb 2018 09:59:46 +0000 Subject: [PATCH gpa] Load the secret keyring before the public one. Message-ID: <20180219095946.5307-1-dgouttegattat@incenp.org> * src/keylist.c (gpa_keylist_init): Forcefully load the secret keyring before attempting to load the public keys. -- Gpa loads the private keyring in a kind of "lazy mode", in that the private keyring is only loaded the first time Gpa needs to lookup a private key. This normally happens during the loading of the public keyring, since for each public key Gpa must lookup in the private keyring to check whether a private counterpart is available. The result is that a Gpg process is spawn to list the secret keys while another Gpg process is still listing the public keys. If the trust model happens to be TOFU or TOFU+PGP, this can cause some problems with regard to the locking of the TOFU database. To avoid that, this patch makes sure the private keyring is actively and synchronously loaded before we fetch the public keys (no more lazy loading). GnuPG-bug-id: 3748 Signed-off-by: Damien Goutte-Gattat --- src/keylist.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/src/keylist.c b/src/keylist.c index 442da08..2c8e7e8 100644 --- a/src/keylist.c +++ b/src/keylist.c @@ -231,7 +231,16 @@ gpa_keylist_init (GTypeInstance *instance, void *class_ptr) } else { - /* Initialize from the global keytable. */ + /* Initialize from the global keytable. + * + * We must forcefully load the secret keytable first to + * prevent concurrent access to the TOFU database. */ + gpa_keytable_force_reload (gpa_keytable_get_secret_instance (), + NULL, (GpaKeyTableEndFunc) gtk_main_quit, + NULL); + gtk_main (); + + /* Now we can load the public keyring. */ gpa_keytable_list_keys (gpa_keytable_get_public_instance(), gpa_keylist_next, gpa_keylist_end, list); } -- 2.14.1 From wk at gnupg.org Mon Feb 19 15:23:10 2018 From: wk at gnupg.org (Werner Koch) Date: Mon, 19 Feb 2018 15:23:10 +0100 Subject: cv25519 scalar byte order In-Reply-To: <878tbw5f2b.fsf@fsij.org> (NIIBE Yutaka's message of "Wed, 14 Feb 2018 14:13:32 +0900") References: <20180211120549.GA23215@calamity> <87o9ktxdbz.fsf@wheatstone.g10code.de> <20180213220358.GA31022@calamity> <87r2pop9sz.fsf@iwagami.gniibe.org> <878tbw5f2b.fsf@fsij.org> Message-ID: <87po51oy7l.fsf@wheatstone.g10code.de> On Wed, 14 Feb 2018 06:13, gniibe at fsij.org said: > I wonder if we have difference in the interpretation of secret part > (skey[3]). > > In GnuPG, this part is interpreted as standard MPI representation > (big-endian). > > For better interoperability, we could support the prefix 0x40 for this > secret part, I suppose. That would be incorrect. The prefix (e.g. 0x40) indicates a _point_ format and not the format of a scalar. Thus skey[3] MAY not have this prefix. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Mon Feb 19 17:24:39 2018 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 19 Feb 2018 08:24:39 -0800 Subject: cv25519 scalar byte order In-Reply-To: <87po51oy7l.fsf@wheatstone.g10code.de> References: <20180211120549.GA23215@calamity> <87o9ktxdbz.fsf@wheatstone.g10code.de> <20180213220358.GA31022@calamity> <87r2pop9sz.fsf@iwagami.gniibe.org> <878tbw5f2b.fsf@fsij.org> <87po51oy7l.fsf@wheatstone.g10code.de> Message-ID: <87bmglkkvs.fsf@fifthhorseman.net> On Mon 2018-02-19 15:23:10 +0100, Werner Koch wrote: > On Wed, 14 Feb 2018 06:13, gniibe at fsij.org said: > >> I wonder if we have difference in the interpretation of secret part >> (skey[3]). >> >> In GnuPG, this part is interpreted as standard MPI representation >> (big-endian). >> >> For better interoperability, we could support the prefix 0x40 for this >> secret part, I suppose. > > That would be incorrect. The prefix (e.g. 0x40) indicates a _point_ > format and not the format of a scalar. Thus skey[3] MAY not have this > prefix. what does this "MAY NOT" mean? if this is an attempt at RFC 2119 language, i don't understand it. Do you mean "MUST NOT" ? What steps are needed to clarify the documentation here so that we can have interoperable implementations? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dgouttegattat at incenp.org Tue Feb 20 16:43:50 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 20 Feb 2018 15:43:50 +0000 Subject: [PATCH gpg] gpg: Avoid assumption on fingerprint size. Message-ID: <20180220154350.15255-1-dgouttegattat@incenp.org> * g10/getkey.c (get_user_id_byfpr): Use the real size of the fingerprint instead of MAX_FINGERPRINT_LEN. -- MAX_FINGERPRINT_LEN was recently changed from 20 to 32, but the get_user_id_byfpr was using this symbol as the actual size of the fingerprint, thus confusing the get_pubkey_byfprint function which does not expect a 32-bytes fingerprint. GnuPG-bug-id: 3801 Signed-off-by: Damien Goutte-Gattat --- g10/getkey.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/g10/getkey.c b/g10/getkey.c index a838c3c61..0ab49f849 100644 --- a/g10/getkey.c +++ b/g10/getkey.c @@ -4243,6 +4243,9 @@ get_user_id_byfpr (ctrl_t ctrl, const byte *fpr, size_t *rn) user_id_db_t r; char *p; int pass = 0; + size_t fpr_len; + + fpr_len = strlen (fpr); /* Try it two times; second pass reads from the database. */ do @@ -4266,7 +4269,7 @@ get_user_id_byfpr (ctrl_t ctrl, const byte *fpr, size_t *rn) } } while (++pass < 2 - && !get_pubkey_byfprint (ctrl, NULL, NULL, fpr, MAX_FINGERPRINT_LEN)); + && !get_pubkey_byfprint (ctrl, NULL, NULL, fpr, fpr_len)); p = xstrdup (user_id_not_found_utf8 ()); *rn = strlen (p); return p; -- 2.14.1 From wk at gnupg.org Tue Feb 20 19:43:25 2018 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Feb 2018 19:43:25 +0100 Subject: [PATCH gpg] gpg: Avoid assumption on fingerprint size. In-Reply-To: <20180220154350.15255-1-dgouttegattat@incenp.org> (Damien Goutte-Gattat's message of "Tue, 20 Feb 2018 15:43:50 +0000") References: <20180220154350.15255-1-dgouttegattat@incenp.org> Message-ID: <87woz7o62a.fsf@wheatstone.g10code.de> On Tue, 20 Feb 2018 16:43, dgouttegattat at incenp.org said: > + size_t fpr_len; > + > + fpr_len = strlen (fpr); That does not work because FPR is binary. Thus the fingerprint may contains '\x0'. I already looked into this and it might be worth to revamp the entire user id caching instead of just fixing the fingerprint thing. In theory the fingerprint should be filled up with zeros to MAX_FINGERPRINT_LEN but that is somewhere missing. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # 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 muelli at cryptobitch.de Tue Feb 20 17:34:14 2018 From: muelli at cryptobitch.de (Tobias Mueller) Date: Tue, 20 Feb 2018 17:34:14 +0100 Subject: [PATCH] python: Fix crash by leaving struct members intact Message-ID: <1519144454.9285.13.camel@cryptobitch.de> * lang/python/setup.py.in: Copy gpgme.h instead of parsing it. -- The python bindings tried to parse deprecated functions out of gpgme.h. This fails for the current gpgme.h in that it removes an entire field in the key sig struct (_obsolete_class). Hence, the fields were off by an int and the bindings accessed struct members via the wrong offset. That caused python program to crash. At least on 32bit platforms, the crash can be easily triggered by accessing key.uids[0].signatures. On 64bit platforms the compiler probably aligns the struct so that the missing 4 bytes are not noticed. With this change, the python bindings will expose all functions that gpgme exposes, including the deprecated ones. Credits go to Justus Winter for debugging and identying the issue. Signed-off-by: Tobias Mueller --- lang/python/setup.py.in | 19 +------------------ 1 file changed, 1 insertion(+), 18 deletions(-) diff --git a/lang/python/setup.py.in b/lang/python/setup.py.in index f9dda20f..2595073f 100755 --- a/lang/python/setup.py.in +++ b/lang/python/setup.py.in @@ -152,25 +152,8 @@ class BuildExtFirstHack(build): 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) - line_break = re.compile(';|\\$|\\x0c|^\s*#|{') - - with open(sink_name, "w") as sink, open(source_name) as source: - text = '' - for line in source: - text += re.sub(' class ', ' _py_obsolete_class ', line) - if line_break.search(line): - if not deprec_func.search(text): - sink.write(text) - text = '' - sink.write(text) + shutil.copy2(source_name, sink_name) def _generate_errors_i(self): From anatoly.borodin at gmail.com Wed Feb 21 09:16:11 2018 From: anatoly.borodin at gmail.com (Anatolii Borodin) Date: Wed, 21 Feb 2018 09:16:11 +0100 Subject: Bug: wrong new signatures count during `gpg --recv` Message-ID: Hi All, every time I run `gpg --recv 6BD9050FD8FC941B43412DCC68B7AB8957548DCD`, it says ``` gpg: key 68B7AB8957548DCD: "Werner Koch (gnupg sig) " 2 new signatures gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: depth: 0 valid: 5 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 5u gpg: next trustdb check due at 2030-01-01 gpg: Total number processed: 1 gpg: new signatures: 2 ``` But there were no 2 signatures in the mean time (3 seconds). These "signatures" are also counted during `gpg --refresh`, which is misleading and a bit annoying. I tried to delete and reimport the key, but the bug stays. Checked in gpg (GnuPG) 2.1.15, Ubuntu Bionic (devel), Ubuntu Artful, etc. PS Sorry if it's a known problem. I tried to google it but couldn't find anything related to it. -- Mit freundlichen Gr??en, Anatolii Borodin From wk at gnupg.org Wed Feb 21 18:06:06 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Feb 2018 18:06:06 +0100 Subject: [admin] Sending patches In-Reply-To: <20180201160848.GY1427@zaya.teonanacatl.net> (Todd Zullinger's message of "Thu, 1 Feb 2018 11:08:48 -0500") References: <877erxp2il.fsf@wheatstone.g10code.de> <20180201160848.GY1427@zaya.teonanacatl.net> Message-ID: <87k1v6jmrl.fsf@wheatstone.g10code.de> On Thu, 1 Feb 2018 17:08, tmz at pobox.com said: > $ git config format.subjectPrefix 'PATCH/gnupg' Good idea. I added this to autogen.sh, so when it is run the first time on a new clone it will add this. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Feb 21 18:28:48 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Feb 2018 18:28:48 +0100 Subject: [PATCH libgpg-error] doc: clarify patch submission workflow In-Reply-To: <20180201204142.GD1427@zaya.teonanacatl.net> (Todd Zullinger's message of "Thu, 1 Feb 2018 15:41:42 -0500") References: <20180201132407.7791-1-Thorsten.Behrens@CIB.de> <20180201164214.GZ1427@zaya.teonanacatl.net> <20180201204142.GD1427@zaya.teonanacatl.net> Message-ID: <877er6gskv.fsf@wheatstone.g10code.de> On Thu, 1 Feb 2018 21:41, tmz at pobox.com said: > And here's that suggestion in unified diff format (along > with automation of the git send-email --to=... option). Thanks. I applied this but also changed autogen.sh to run git config too. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Thu Feb 22 10:13:09 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Feb 2018 10:13:09 +0100 Subject: [admin] Sending patches In-Reply-To: <87k1v6jmrl.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed, 21 Feb 2018 18:06:06 +0100") References: <877erxp2il.fsf@wheatstone.g10code.de> <20180201160848.GY1427@zaya.teonanacatl.net> <87k1v6jmrl.fsf@wheatstone.g10code.de> Message-ID: <87fu5t9yl6.fsf@wheatstone.g10code.de> On Wed, 21 Feb 2018 18:06, wk at gnupg.org said: >> $ git config format.subjectPrefix 'PATCH/gnupg' > > Good idea. I added this to autogen.sh, so when it is run the first time > on a new clone it will add this. BTW, is there a reason why a slash was proposed as delimiter? I changed that to a space because that seems to be easier to parse. However, if it is more common to use a slash, I can chnage that again. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # 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 pierre.labastie at neuf.fr Thu Feb 22 11:23:25 2018 From: pierre.labastie at neuf.fr (Pierre Labastie) Date: Thu, 22 Feb 2018 11:23:25 +0100 Subject: GPGME: tests are built in the lang directory even if --disable-gpg-test is passed to configure Message-ID: <6ea0c3f6-df5d-e5f6-0096-b080f6a6fd85@neuf.fr> Hi, I just subscribed to this list, so let me introduce myself: I am Pierre Labastie, one of the editors of "Beyond linux from Scratch" [1]. We have noticed that in current version (1.10.0) of gpgme, the lang/*/tests programs are unconditionally built, even if --disable-gpg-test is passed to configure. It creates a dependency on gnupg (since the build runs gpg), which is not needed otherwise. I guess a construct similar to the one in top Makefile.am should be in lang/{qt,python}/Makefile.am: if RUN_GPG_TESTS tests = tests else tests = endif and then replace "SUBDIRS= ... tests ..." with "SUBDIRS=... ${tests} ..." Let me know if you need more information, or if I need to submit a bug. I've done some research in the bug tracker to see if this has already been reported, and found nothing. Sorry if it is a duplicate. Regards Pierre [1] http://www.linuxfromscratch.org/blfs/ From tmz at pobox.com Thu Feb 22 16:13:51 2018 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 22 Feb 2018 10:13:51 -0500 Subject: [admin] Sending patches In-Reply-To: <87fu5t9yl6.fsf@wheatstone.g10code.de> References: <877erxp2il.fsf@wheatstone.g10code.de> <20180201160848.GY1427@zaya.teonanacatl.net> <87k1v6jmrl.fsf@wheatstone.g10code.de> <87fu5t9yl6.fsf@wheatstone.g10code.de> Message-ID: <20180222151351.GV27038@zaya.teonanacatl.net> Hi Werner, Werner Koch wrote: > On Wed, 21 Feb 2018 18:06, wk at gnupg.org said: > >>> $ git config format.subjectPrefix 'PATCH/gnupg' >> >> Good idea. I added this to autogen.sh, so when it is run the first time >> on a new clone it will add this. > > BTW, is there a reason why a slash was proposed as delimiter? I changed > that to a space because that seems to be easier to parse. However, if > it is more common to use a slash, I can chnage that again. The / is simply what I used on the last project where we set this. I only have a sample size of 1 or 2, so I don't have any reason to think a space isn't just as widely used as a slash (if not more widely used). :) Thanks, -- Todd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Few things are harder to put up with than a good example. -- Mark Twain (1835-1910) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From wk at gnupg.org Thu Feb 22 16:55:12 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Feb 2018 16:55:12 +0100 Subject: Bug: wrong new signatures count during `gpg --recv` In-Reply-To: (Anatolii Borodin's message of "Wed, 21 Feb 2018 09:16:11 +0100") References: Message-ID: <87h8q981en.fsf@wheatstone.g10code.de> On Wed, 21 Feb 2018 09:16, anatoly.borodin at gmail.com said: > Checked in gpg (GnuPG) 2.1.15, Ubuntu Bionic (devel), Ubuntu Artful, etc. That is a pretty old release and I recall that I fixed the stats some time ago. So your chances that this has been fixed in the next Ubuntu release should be pretty high. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Thu Feb 22 17:27:26 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Feb 2018 17:27:26 +0100 Subject: [Announce] GnuPG 2.2.5 released Message-ID: <878tbl7zwx.fsf@wheatstone.g10code.de> Hello! We are is pleased to announce the availability of a new GnuPG release: version 2.2.5. This is a maintenance release; see below for a list of fixed bugs. 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.2.5 =================================== * gpg: Allow the use of the "cv25519" and "ed25519" short names in addition to the canonical curve names in --batch --gen-key. * gpg: Make sure to print all secret keys with option --list-only and --decrypt. [#3718] * gpg: Fix the use of future-default with --quick-add-key for signing keys. [#3747] * gpg: Select a secret key by checking availability under gpg-agent. [#1967] * gpg: Fix reversed prompt texts for --only-sign-text-ids. [#3787] * gpg,gpgsm: Fix detection of bogus keybox blobs on 32 bit systems. [#3770] * gpgsm: Fix regression since 2.1 in --export-secret-key-raw which got $d mod (q-1)$ wrong. Note that most tools automatically fixup that parameter anyway. * ssh: Fix a regression in getting the client'd PID on *BSD and macOS. * scd: Support the KDF Data Object of the OpenPGP card 3.3. [#3152] * scd: Fix a regression in the internal CCID driver for certain card readers. [#3508] * scd: Fix a problem on NetBSD killing scdaemon on gpg-agent shutdown. [#3778] * dirmngr: Improve returned error description on failure of DNS resolving. [#3756] * wks: Implement command --install-key for gpg-wks-server. * Add option STATIC=1 to the Speedo build system to allow a build with statically linked versions of the core GnuPG libraries. Also use --enable-wks-tools by default by Speedo builds for Unix. Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.5 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.5.tar.bz2 (6430k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.5.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.2.5_20180222.exe (3819k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.5_20180222.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. A new Gpg4win 3.0 installer featuring this version of GnuPG will be available soon. 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.2.5.tar.bz2 you would use this command: gpg --verify gnupg-2.2.5.tar.bz2.sig gnupg-2.2.5.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See 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.2.5.tar.bz2, you run the command like this: sha1sum gnupg-2.2.5.tar.bz2 and check that the output matches the next line: 9dec110397e460b3950943e18f5873a4f277f216 gnupg-2.2.5.tar.bz2 080f801e833c7a9e0441d55cd19d4bdb5bb261f9 gnupg-w32-2.2.5_20180222.exe 0ff74deb747531663b5876788c271c94c20dd605 gnupg-w32-2.2.5_20180222.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. Documentation and Support ========================= 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 reference manual of the system. Separate man pages are included as well but they miss some of the details availabale only in thee manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF 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 to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. 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. Thanks ====== Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project currently employs one full-time developer and one contractor. Both work exclusively on GnuPG and closely related software like Libgcrypt, GPGME, and GPA. We are planning to extend our team again and to help developers to improve integration of crypto in their applications. We have to thank all the people who helped the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good shape and address all the small and larger requests made by our users. Thanks. Happy hacking, Your GnuPG hackers 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 four keys: rsa2048 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 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 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) The keys are available at and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- # Please read: Daniel Ellsberg - The Doomsday Machine # 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: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From o at immerda.ch Sat Feb 24 16:04:57 2018 From: o at immerda.ch (o.) Date: Sat, 24 Feb 2018 16:04:57 +0100 Subject: dirmngr vs. tor gateways In-Reply-To: References: Message-ID: <7043774a-4dfa-c17d-59cb-fe20190d5510@immerda.ch> Hi all, I ran into an issue with with dirmngr and tor. It seems to me, that dirmngr assumes, that the tor daemon is run locally. But, you can also run tor as a gateway (see [0][1][2]). When I try to use dirmngr (gpg 2.2.5) in such a setting with gpg --keyserver hkp://pool.sks-keyservers.net --search-keys xyz I get either (with "use-tor"): dirmngr[7424.6] (it seems Tor is not running) dirmngr[7424.6] command 'KS_SEARCH' failed: Connection refused or (without "use-tor"): dirmngr[7432.6] command 'KS_SEARCH' failed: Server indicated a failure This is not a network issue. I verified on the same machine, that the distro gpg 1.4 works, whereas gpg 2.2.4 has the same issue. I managed to get it to work exactly once, with "use-tor" and "nameserver " (the 500 error is expected, since I actually did search for "xyz"): dirmngr[7543.6] resolve_dns_addr for '144.76.144.117': 'pgp.h-ix.net' [already known] dirmngr[7543.6] error accessing 'http://144.76.144.117:11371/pks/lookup?op=index& options=mr&search=xyz': http status 500 dirmngr[7543.6] command 'KS_SEARCH' failed: No data But that seems extremely brittle, it only worked once. When I try to reproduce now, it fails again with "it seems Tor is not running". I am not exactly sure how dirmngr is supposed to work with tor (and why it needs special handling of tor). So, if you need additional diagnosis, please let me know what I should try. The only way I got it to work reliably, was without "use-tor" and a keyserver specified by ip address, e.g.: gpg --keyserver hkp://176.9.51.79 --search-keys xyz Unfortunately, with this workaround it's neither possible to use hkps (due to cert name mismatch), nor to use .onion keyservers (see OnionAddrRange in "man torsocks.conf" to understand why). In short, there seems to be no good workaround. We should expect a larger group of people to get hit by this problem as soon as a recent enough version of gpg hits the whonix distribution. Best, o. [0] https://www.torproject.org/docs/faq.html.en#ServerClient [1] https://www.whonix.org/wiki/Qubes [2] https://learn.adafruit.com/onion-pi/overview PS: if I specify "use-tor" and then supply an ip, I get: dirmngr[7857.6] resolve_dns_addr failed while checking '176.9.51.79': Connection refused dirmngr[7857.6] can't connect to '176.9.51.79': no IP address for host dirmngr[7857.6] error connecting to 'http://176.9.51.79:11371': Unknown host dirmngr[7857.6] marking host '176.9.51.79' as dead dirmngr[7857.6] host '176.9.51.79' marked as dead but that is probably a different bug. -------------- 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 Feb 26 09:23:11 2018 From: wk at gnupg.org (Werner Koch) Date: Mon, 26 Feb 2018 09:23:11 +0100 Subject: dirmngr vs. tor gateways In-Reply-To: <7043774a-4dfa-c17d-59cb-fe20190d5510@immerda.ch> (o.'s message of "Sat, 24 Feb 2018 16:04:57 +0100") References: <7043774a-4dfa-c17d-59cb-fe20190d5510@immerda.ch> Message-ID: <87vaek40sw.fsf@wheatstone.g10code.de> On Sat, 24 Feb 2018 16:04, o at immerda.ch said: > dirmngr assumes, that the tor daemon is run locally. But, you can also > run tor as a gateway (see [0][1][2]). That is right. Dirmngr (actually Libassuan) always uses 127.0.0.1 and checks whether Tor is running on one of the two standard ports (9050 or 9150 for the Tor browser). There is no way to change the address of the proxy. Of course we could add such a feature but it is not trivial because it complicates the test matrix a lot. > gpg --keyserver hkp://176.9.51.79 --search-keys xyz > > Unfortunately, with this workaround it's neither possible to use hkps > (due to cert name mismatch), nor to use .onion keyservers (see If you want to specify a keyserver, please add it to dirmngr.conf. There you can also add a hkp-cacert option. Support for onion addresses require that Tor runs locally. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dgouttegattat at incenp.org Mon Feb 26 14:17:06 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Mon, 26 Feb 2018 13:17:06 +0000 Subject: [PATCH libgpg-error] doc: clarify patch submission workflow In-Reply-To: <20180204045511.GP1427@zaya.teonanacatl.net> References: <20180201132407.7791-1-Thorsten.Behrens@CIB.de> <87fu6k63sf.fsf@fifthhorseman.net> <20180201205548.GF1427@zaya.teonanacatl.net> <87d11l31d3.fsf@fifthhorseman.net> <20180204045511.GP1427@zaya.teonanacatl.net> Message-ID: Hi GnuPG folks, On 02/04/2018 04:55 AM, Todd Zullinger wrote: > Another option might be to recommend that users generate > patches with git format-patch? and then process them using > another script which can PGP/MIME sign them. > [...] > I don't know if there's already a convenient script to > create PGP/MIME messages or not. Several years ago, I wanted to understand how MIME messages are constructed and I wrote a small program that can take a message body and turn it into a PGP/MIME-signed message. I forgot about this program almost as soon as I finished it. The above discussion reminded me of it. As it turns out, this program could be used for the purpose described by Todd. The program is called fmail and may be found on my homepage [1]. It reads a message (such as one produced by git format-patch) on its standard input and, if called with the -s option, emits a PGP/MIME-signed message on its standard output. The signed message may then be sent with presumably any mail submission agent (I tested with both msmtp and git send-email). With this program, the workflow for a single patch could be the following: $ git format-patch -1 --stdout [other format-patch options] | \ fmail -s | git send-email And for a patch set: $ git format-patch [format-patch options] $ for mail in *.patch ; do fmail -s < $mail > $mail.signed ; done $ git send-email *.signed Note: I am *not* advocating the use of my program to send patches to gnupg-devel (actually I don't even like advertising it here, I am doing it now only because it happens to be relevant to the discussion). My point is mainly that the "another option" proposed by Todd is doable. [1] https://incenp.org/dvlpt/fmail.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From o at immerda.ch Tue Feb 27 20:42:52 2018 From: o at immerda.ch (o.) Date: Tue, 27 Feb 2018 20:42:52 +0100 Subject: dirmngr vs. tor gateways In-Reply-To: <87vaek40sw.fsf@wheatstone.g10code.de> References: <7043774a-4dfa-c17d-59cb-fe20190d5510@immerda.ch> <87vaek40sw.fsf@wheatstone.g10code.de> Message-ID: <8647ef04-9170-6c71-36e6-fb7de3e74b2f@immerda.ch> On 02/26/2018 09:23 AM, Werner Koch wrote: > Dirmngr (actually Libassuan) always uses 127.0.0.1 and > checks whether Tor is running on one of the two standard ports That might be a bit of a problematic assumption, given there is at least one distribution, where this is never true. Especially, if there is no workaround whatsoever. > If you want to specify a keyserver, please add it to dirmngr.conf. The point is, that this does not work. dirmngr name resolution for keyservers fails, if dirmngr connects through a whonix tor gateway. The error message is: command 'KS_SEARCH' failed: Server indicated a failure regardless, if the keyserver is specified through dirmngr.conf or the command line. > There you can also add a hkp-cacert option. That does not help. Due to the above problem, we can only specify keyservers by ip. The ip is most likely not mentioned in the cert. > Support for onion addresses require that Tor runs locally. Is that statement meant for gpg? Because in general, it *is* possible to use .onion addresses with a tor gateway. Best, o. -------------- 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 Wed Feb 28 08:03:37 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 28 Feb 2018 08:03:37 +0100 Subject: dirmngr vs. tor gateways In-Reply-To: <8647ef04-9170-6c71-36e6-fb7de3e74b2f@immerda.ch> (o.'s message of "Tue, 27 Feb 2018 20:42:52 +0100") References: <7043774a-4dfa-c17d-59cb-fe20190d5510@immerda.ch> <87vaek40sw.fsf@wheatstone.g10code.de> <8647ef04-9170-6c71-36e6-fb7de3e74b2f@immerda.ch> Message-ID: <877eqxy4s6.fsf@wheatstone.g10code.de> On Tue, 27 Feb 2018 20:42, o at immerda.ch said: > On 02/26/2018 09:23 AM, Werner Koch wrote: >> Dirmngr (actually Libassuan) always uses 127.0.0.1 and >> checks whether Tor is running on one of the two standard ports > > That might be a bit of a problematic assumption, given there is at least > one distribution, where this is never true. Especially, if there is no > workaround whatsoever. That complain comes a bit late ;-) We have the integrated Tor support for more than 2 years. Just wondering. > The point is, that this does not work. dirmngr name resolution for > keyservers fails, if dirmngr connects through a whonix tor gateway. The > error message is: In this case you need to diable the integrated Tor support: --no-use-tor And you need top make sure that you have a full DNS resolver over Tor. Just looking up AAAA records is not sufficient to use the key server pools. > That does not help. Due to the above problem, we can only specify > keyservers by ip. The ip is most likely not mentioned in the cert. Without proper DNS support PKIX does not work anyway. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # 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 o at immerda.ch Wed Feb 28 16:34:45 2018 From: o at immerda.ch (o.) Date: Wed, 28 Feb 2018 16:34:45 +0100 Subject: dirmngr vs. tor gateways In-Reply-To: <877eqxy4s6.fsf@wheatstone.g10code.de> References: <7043774a-4dfa-c17d-59cb-fe20190d5510@immerda.ch> <87vaek40sw.fsf@wheatstone.g10code.de> <8647ef04-9170-6c71-36e6-fb7de3e74b2f@immerda.ch> <877eqxy4s6.fsf@wheatstone.g10code.de> Message-ID: <07d02087-17d7-71ae-43b2-5b8ec74594ba@immerda.ch> On 02/28/2018 08:03 AM, Werner Koch wrote: > On Tue, 27 Feb 2018 20:42, o at immerda.ch said: >> On 02/26/2018 09:23 AM, Werner Koch wrote: >>> Dirmngr (actually Libassuan) always uses 127.0.0.1 and >>> checks whether Tor is running on one of the two standard ports >> >> That might be a bit of a problematic assumption, given there is at least >> one distribution, where this is never true. Especially, if there is no >> workaround whatsoever. > > That complain comes a bit late ;-) We have the integrated Tor support for > more than 2 years. Just wondering. Well, I guess the problem is that most distributions did not make the switch to gpg2. Whonix is based on debian 8. >> The point is, that this does not work. dirmngr name resolution for >> keyservers fails, if dirmngr connects through a whonix tor gateway. The >> error message is: > > In this case you need to diable the integrated Tor support: --no-use-tor that's what I tried. > And you need top make sure that you have a full DNS resolver over Tor. > Just looking up AAAA records is not sufficient to use the key server pools. I don't think that such a resolver exists for tor at the moment. The ticket seems to still be open [0]. >> That does not help. Due to the above problem, we can only specify >> keyservers by ip. The ip is most likely not mentioned in the cert. > > Without proper DNS support PKIX does not work anyway. ok, I guess I don't see the full picture. But it does work with gpg 1.x, so it should be possible to at least have some fallback mechanism. Best, o. [0] https://trac.torproject.org/projects/tor/ticket/7829 -------------- 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 Wed Feb 28 20:56:16 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 28 Feb 2018 20:56:16 +0100 Subject: dirmngr vs. tor gateways In-Reply-To: <07d02087-17d7-71ae-43b2-5b8ec74594ba@immerda.ch> (o.'s message of "Wed, 28 Feb 2018 16:34:45 +0100") References: <7043774a-4dfa-c17d-59cb-fe20190d5510@immerda.ch> <87vaek40sw.fsf@wheatstone.g10code.de> <8647ef04-9170-6c71-36e6-fb7de3e74b2f@immerda.ch> <877eqxy4s6.fsf@wheatstone.g10code.de> <07d02087-17d7-71ae-43b2-5b8ec74594ba@immerda.ch> Message-ID: <87sh9kq467.fsf@wheatstone.g10code.de> On Wed, 28 Feb 2018 16:34, o at immerda.ch said: > I don't think that such a resolver exists for tor at the moment. The > ticket seems to still be open [0]. Well, dirmngr implements such a resolver its own use. For years I tried to get a similar thing into ADNS but that was rejected by its maintainer. If really needed we could add a public interface to dirmngr's internal resolver. > ok, I guess I don't see the full picture. But it does work with gpg 1.x, > so it should be possible to at least have some fallback mechanism. it works using a couple of tricks. The keyserver helpers of GnuPG-1 have major drawbacks: For example they entirely rely on the system resolver and have no means to detect a non-working keyserver and thus as soon as a keyserver does not respond you need to wait until its TTL runs off so that another keyserver from the pool can be tried. In contrast dirmngr keeps state and does not rely on any upstream round-robin AAAA resource record distribution. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # 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: