From dkg at fifthhorseman.net  Sun Dec  2 02:41:12 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 02 Dec 2018 04:41:12 +0300
Subject: [PATCH Libgpg-error] gpg-error.m4: support pkg-config
In-Reply-To: <CAOazyz19XD7CJm_BTO3HgWiGHB8FhtGOrf1yo+-acNCQ-dmVYw@mail.gmail.com>
References: <20181011182720.11991-1-alon.barlev@gmail.com>
 <871s8vptg1.fsf@wheatstone.g10code.de>
 <CAOazyz3F2E0KphGwc41rKFdfhoNxjNW8f8mLoAUyWzhHodCQjg@mail.gmail.com>
 <87efcokjn6.fsf@wheatstone.g10code.de>
 <CAOazyz2Wo62ax_+kn7F+UvJZUnnRavw35bePKZAmPPaKO_gzeg@mail.gmail.com>
 <CAOazyz0Q6m6gbtThu2G8LLyQQ3mnLn_Uexpi+=BxwWKeRUmBQw@mail.gmail.com>
 <8736snt3kn.fsf@fsij.org>
 <CAOazyz3jgK5efBZL1BvFWAGnXRgtr22tRNq3-=WLiGMNk0+JFQ@mail.gmail.com>
 <87d0rqod6v.fsf@fsij.org>
 <CAOazyz1qPw021tq+FNbtLQCQj_oNvDwSnOaPb6=UkByxFLgaNA@mail.gmail.com>
 <CAOazyz19XD7CJm_BTO3HgWiGHB8FhtGOrf1yo+-acNCQ-dmVYw@mail.gmail.com>
Message-ID: <87mupoiu2v.fsf@fifthhorseman.net>

On Sun 2018-11-25 20:45:36 +0200, Alon Bar-Lev wrote:
> I am declaring this thread as MIA [Missing in action].
> I am very sad that we cannot even properly discuss this.

I agree, it's frustrating that this is not happening.  There are many
reasons why pkg-config is common practice across the free software
ecosystem.  It's not perfect, but it's widely understood.  GnuPG's
continued idiosyncracy here makes it harder to work with than it needs
to be.

If the goal is to discourage developers from adopting GnuPG and related
packages, then the status quo is fine.  But if the goal is facilitating
adoption, it would be good to have a clear conversation about strategy
and tactics to do so.

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181202/2dc9f921/attachment.sig>

From gniibe at fsij.org  Sun Dec  2 23:27:29 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 03 Dec 2018 07:27:29 +0900
Subject: [PATCH Libgpg-error] gpg-error.m4: support pkg-config
In-Reply-To: <87mupoiu2v.fsf@fifthhorseman.net>
References: <20181011182720.11991-1-alon.barlev@gmail.com>
 <871s8vptg1.fsf@wheatstone.g10code.de>
 <CAOazyz3F2E0KphGwc41rKFdfhoNxjNW8f8mLoAUyWzhHodCQjg@mail.gmail.com>
 <87efcokjn6.fsf@wheatstone.g10code.de>
 <CAOazyz2Wo62ax_+kn7F+UvJZUnnRavw35bePKZAmPPaKO_gzeg@mail.gmail.com>
 <CAOazyz0Q6m6gbtThu2G8LLyQQ3mnLn_Uexpi+=BxwWKeRUmBQw@mail.gmail.com>
 <8736snt3kn.fsf@fsij.org>
 <CAOazyz3jgK5efBZL1BvFWAGnXRgtr22tRNq3-=WLiGMNk0+JFQ@mail.gmail.com>
 <87d0rqod6v.fsf@fsij.org>
 <CAOazyz1qPw021tq+FNbtLQCQj_oNvDwSnOaPb6=UkByxFLgaNA@mail.gmail.com>
 <CAOazyz19XD7CJm_BTO3HgWiGHB8FhtGOrf1yo+-acNCQ-dmVYw@mail.gmail.com>
 <87mupoiu2v.fsf@fifthhorseman.net>
Message-ID: <87k1krh8dq.fsf@fsij.org>

Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> it would be good to have a clear conversation about strategy and
> tactics to do so.

For pkg-config support, I think that I explained and show our way to do
so, but it seems that my points were not accepted unfortunately.

You can see my changes in GnuPG libraries, in the repo (master).  In
next releases, we will provide .pc files by libgpg-error, npth,
libgcrypt, libassuan, libksba, ntbtls, and gpgme.  Users of those
libraries will be able to use pkg-config if they want.  Say, by using
pkg.m4 for autoconf to generate configure script.

For gpg-error.m4 and other m4 files, we don't have any idea to introduce
pkg-config support in that macro file, because we don't change the build
of GnuPG itself.

I think that use of pkg.m4 is superior, because it supports multiple
modules at once.

I think that there are two different things here; pkg-config support for
users of libraries, and change of GnuPG build.

For the latter, it should be conservative, because GnuPG is important
tool and it should be available earlier in the bootstrap process of
operating system.
-- 


From alon.barlev at gmail.com  Mon Dec  3 00:12:13 2018
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Mon, 3 Dec 2018 01:12:13 +0200
Subject: [PATCH Libgpg-error] gpg-error.m4: support pkg-config
In-Reply-To: <87k1krh8dq.fsf@fsij.org>
References: <20181011182720.11991-1-alon.barlev@gmail.com>
 <871s8vptg1.fsf@wheatstone.g10code.de>
 <CAOazyz3F2E0KphGwc41rKFdfhoNxjNW8f8mLoAUyWzhHodCQjg@mail.gmail.com>
 <87efcokjn6.fsf@wheatstone.g10code.de>
 <CAOazyz2Wo62ax_+kn7F+UvJZUnnRavw35bePKZAmPPaKO_gzeg@mail.gmail.com>
 <CAOazyz0Q6m6gbtThu2G8LLyQQ3mnLn_Uexpi+=BxwWKeRUmBQw@mail.gmail.com>
 <8736snt3kn.fsf@fsij.org>
 <CAOazyz3jgK5efBZL1BvFWAGnXRgtr22tRNq3-=WLiGMNk0+JFQ@mail.gmail.com>
 <87d0rqod6v.fsf@fsij.org>
 <CAOazyz1qPw021tq+FNbtLQCQj_oNvDwSnOaPb6=UkByxFLgaNA@mail.gmail.com>
 <CAOazyz19XD7CJm_BTO3HgWiGHB8FhtGOrf1yo+-acNCQ-dmVYw@mail.gmail.com>
 <87mupoiu2v.fsf@fifthhorseman.net> <87k1krh8dq.fsf@fsij.org>
Message-ID: <CAOazyz0-Ovb_sLk8NUKUDQeLc7203EacgCL4qF6XoDz_6BR5FQ@mail.gmail.com>

On Mon, Dec 3, 2018 at 12:27 AM NIIBE Yutaka <gniibe at fsij.org> wrote:
>
> Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> > it would be good to have a clear conversation about strategy and
> > tactics to do so.
>
> For pkg-config support, I think that I explained and show our way to do
> so, but it seems that my points were not accepted unfortunately.
>
> You can see my changes in GnuPG libraries, in the repo (master).  In
> next releases, we will provide .pc files by libgpg-error, npth,
> libgcrypt, libassuan, libksba, ntbtls, and gpgme.  Users of those
> libraries will be able to use pkg-config if they want.  Say, by using
> pkg.m4 for autoconf to generate configure script.
>
> For gpg-error.m4 and other m4 files, we don't have any idea to introduce
> pkg-config support in that macro file, because we don't change the build
> of GnuPG itself.
>
> I think that use of pkg.m4 is superior, because it supports multiple
> modules at once.
>
> I think that there are two different things here; pkg-config support for
> users of libraries, and change of GnuPG build.
>
> For the latter, it should be conservative, because GnuPG is important
> tool and it should be available earlier in the bootstrap process of
> operating system.

We are discussing here the "change of GnuPG build" to support both
modes, the proprietary config files as default and in addition
pkg-config using pkg.m4 for these who wishes to use pkg-config to
build GnuPG components. This is trivial as I showed in this patch.

Thanks,
Alon


From gniibe at fsij.org  Mon Dec  3 00:23:12 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 03 Dec 2018 08:23:12 +0900
Subject: [PATCH Libgpg-error] gpg-error.m4: support pkg-config
In-Reply-To: <CAOazyz0-Ovb_sLk8NUKUDQeLc7203EacgCL4qF6XoDz_6BR5FQ@mail.gmail.com>
References: <20181011182720.11991-1-alon.barlev@gmail.com>
 <871s8vptg1.fsf@wheatstone.g10code.de>
 <CAOazyz3F2E0KphGwc41rKFdfhoNxjNW8f8mLoAUyWzhHodCQjg@mail.gmail.com>
 <87efcokjn6.fsf@wheatstone.g10code.de>
 <CAOazyz2Wo62ax_+kn7F+UvJZUnnRavw35bePKZAmPPaKO_gzeg@mail.gmail.com>
 <CAOazyz0Q6m6gbtThu2G8LLyQQ3mnLn_Uexpi+=BxwWKeRUmBQw@mail.gmail.com>
 <8736snt3kn.fsf@fsij.org>
 <CAOazyz3jgK5efBZL1BvFWAGnXRgtr22tRNq3-=WLiGMNk0+JFQ@mail.gmail.com>
 <87d0rqod6v.fsf@fsij.org>
 <CAOazyz1qPw021tq+FNbtLQCQj_oNvDwSnOaPb6=UkByxFLgaNA@mail.gmail.com>
 <CAOazyz19XD7CJm_BTO3HgWiGHB8FhtGOrf1yo+-acNCQ-dmVYw@mail.gmail.com>
 <87mupoiu2v.fsf@fifthhorseman.net> <87k1krh8dq.fsf@fsij.org>
 <CAOazyz0-Ovb_sLk8NUKUDQeLc7203EacgCL4qF6XoDz_6BR5FQ@mail.gmail.com>
Message-ID: <87y397jyxr.fsf@fsij.org>

Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> We are discussing here the "change of GnuPG build"

I know, you are.  That resulted "we cannot even properly discuss this."

I explained a larger picture of our improvements.  You ignore.
-- 


From alon.barlev at gmail.com  Mon Dec  3 00:31:21 2018
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Mon, 3 Dec 2018 01:31:21 +0200
Subject: [PATCH Libgpg-error] gpg-error.m4: support pkg-config
In-Reply-To: <87y397jyxr.fsf@fsij.org>
References: <20181011182720.11991-1-alon.barlev@gmail.com>
 <871s8vptg1.fsf@wheatstone.g10code.de>
 <CAOazyz3F2E0KphGwc41rKFdfhoNxjNW8f8mLoAUyWzhHodCQjg@mail.gmail.com>
 <87efcokjn6.fsf@wheatstone.g10code.de>
 <CAOazyz2Wo62ax_+kn7F+UvJZUnnRavw35bePKZAmPPaKO_gzeg@mail.gmail.com>
 <CAOazyz0Q6m6gbtThu2G8LLyQQ3mnLn_Uexpi+=BxwWKeRUmBQw@mail.gmail.com>
 <8736snt3kn.fsf@fsij.org>
 <CAOazyz3jgK5efBZL1BvFWAGnXRgtr22tRNq3-=WLiGMNk0+JFQ@mail.gmail.com>
 <87d0rqod6v.fsf@fsij.org>
 <CAOazyz1qPw021tq+FNbtLQCQj_oNvDwSnOaPb6=UkByxFLgaNA@mail.gmail.com>
 <CAOazyz19XD7CJm_BTO3HgWiGHB8FhtGOrf1yo+-acNCQ-dmVYw@mail.gmail.com>
 <87mupoiu2v.fsf@fifthhorseman.net> <87k1krh8dq.fsf@fsij.org>
 <CAOazyz0-Ovb_sLk8NUKUDQeLc7203EacgCL4qF6XoDz_6BR5FQ@mail.gmail.com>
 <87y397jyxr.fsf@fsij.org>
Message-ID: <CAOazyz2Bd0v6wrBgavQU3yf_rumsLYvHQztUCnEB+j-u-BRfkg@mail.gmail.com>

On Mon, Dec 3, 2018 at 1:23 AM NIIBE Yutaka <gniibe at fsij.org> wrote:
>
> Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> > We are discussing here the "change of GnuPG build"
>
> I know, you are.  That resulted "we cannot even properly discuss this."
>
> I explained a larger picture of our improvements.  You ignore.

Please forgive me if I am ignoring anything. I read again the thread
and yet to understand the larger picture. Maybe I just keep missing
it.

Please explain again why not give an option for downstream to build
gnupg components using pkg-config, this does not take anything from
whoever wishes to continue to use current mode.

Pseudo code per each <library>.m4:

+if enable_pkg_config = yes:
+   use pkg-config via pkg.m4 macro to detect dependency flags
[usually oneliner]
+else:
    use *-config macro to detect dependency flags
+endif

Why does this takes anything from the larger picture?

Thanks!
Alon


From gniibe at fsij.org  Tue Dec  4 01:54:09 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 04 Dec 2018 09:54:09 +0900
Subject: [PATCH Libgpg-error] gpg-error.m4: support pkg-config
In-Reply-To: <CAOazyz2Bd0v6wrBgavQU3yf_rumsLYvHQztUCnEB+j-u-BRfkg@mail.gmail.com>
References: <20181011182720.11991-1-alon.barlev@gmail.com>
 <871s8vptg1.fsf@wheatstone.g10code.de>
 <CAOazyz3F2E0KphGwc41rKFdfhoNxjNW8f8mLoAUyWzhHodCQjg@mail.gmail.com>
 <87efcokjn6.fsf@wheatstone.g10code.de>
 <CAOazyz2Wo62ax_+kn7F+UvJZUnnRavw35bePKZAmPPaKO_gzeg@mail.gmail.com>
 <CAOazyz0Q6m6gbtThu2G8LLyQQ3mnLn_Uexpi+=BxwWKeRUmBQw@mail.gmail.com>
 <8736snt3kn.fsf@fsij.org>
 <CAOazyz3jgK5efBZL1BvFWAGnXRgtr22tRNq3-=WLiGMNk0+JFQ@mail.gmail.com>
 <87d0rqod6v.fsf@fsij.org>
 <CAOazyz1qPw021tq+FNbtLQCQj_oNvDwSnOaPb6=UkByxFLgaNA@mail.gmail.com>
 <CAOazyz19XD7CJm_BTO3HgWiGHB8FhtGOrf1yo+-acNCQ-dmVYw@mail.gmail.com>
 <87mupoiu2v.fsf@fifthhorseman.net> <87k1krh8dq.fsf@fsij.org>
 <CAOazyz0-Ovb_sLk8NUKUDQeLc7203EacgCL4qF6XoDz_6BR5FQ@mail.gmail.com>
 <87y397jyxr.fsf@fsij.org>
 <CAOazyz2Bd0v6wrBgavQU3yf_rumsLYvHQztUCnEB+j-u-BRfkg@mail.gmail.com>
Message-ID: <877egq158u.fsf@fsij.org>

Hello,

Please accept my apologize if tone of my writing sounded too strong.
Perhaps, I (wrongly) recognized that my efforts were disregarded.

IIUC, you haven't try build of current master of GnuPG, with master of
npth, libgpg-error, libassuan, libgcrypt, libksba, and ntbtls, which
introduced .pc files for pkg-config compatibility.  (Well, it is also
introduced to gpgme.)

I should have assumed that.

Let me explain in detail, even if it's TL;TR...

Or it is better to begin with a short answer, changing the order
of answer.

> Pseudo code per each <library>.m4:
>
> +if enable_pkg_config = yes:
> +   use pkg-config via pkg.m4 macro to detect dependency flags
> [usually oneliner]
> +else:
>     use *-config macro to detect dependency flags
> +endif
>
> Why does this takes anything from the larger picture?

It's OK for <library>'s user to do that, but we don't do that for GnuPG
build.

That's because it is not needed; In the current situation, it just
complicates things while adding no benefit.

Please understand that I don't deny your points what to be achieved by
such a change.  It's done already in a different way, other than
introducing use of pkg-config.

			*	*	*

Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> Please explain again why not give an option for downstream to build
> gnupg components using pkg-config, this does not take anything from
> whoever wishes to continue to use current mode.

For pkg-config compatibility, GnuPG libraries (npth, libgpg-error,
libassuan, libgcrypt, libksba, and ntbtls) introduced .pc files.

And we introduced a single script, named gpgrt-config, to handle .pc
files.  This is a kind of cut-down version of pkg-config.

Now, other *-config scripts are only provided for backward
compatibility.  (It is no use for new way of building GnuPG).

I did so, in order to separate static data (which can be described as
pkg-config style) and running script (which tends to easily introduce
peculiar incompatible things).  I believe that by doing so, we can
maintain libraries of GnuPG, as friendly as possible to pkg-config.

Direct benefit of introducing .pc files are for users of those
libraries, they can use pkg-config for their applications (by "[usually
oneliner]" macro of pkg.m4), if they like.  Instead of use of pkg.m4
macro, still, using old <library>.m4 with <library-specific>-config is
supported, and new <library>.m4 with gpgrt-config or
<library-specific>-config is also supported.

However, we don't use pkg-config for GnuPG build itself to configure
GnuPG libraries, while it uses pkg-config for optional external
libraries (sqlite and GnuTLS).  We do so, because GnuPG should be
build-able without pkg-config.  This is important requirement of GnuPG.

Optionally using pkg-config would make sense, if it doesn't add more
complexity for maintenance of GnuPG and if it can provide some benefit.
But... I think that newly introducing optional use of pkg-config for
GnuPG libraries just adds more unnecessary complexity for GnuPG build,
with no benefit.

While we try to keep the compatibility of pkg-config, the behavior of
pkg-config and gpgrt-config may be different, when pkg-config will
change.  When behaviors are different, this should be fixed soonish, but
it may take longer without being noticed.  When it occurs, the impact
for GnuPG build is... bad enough, since GnuPG will be not reproducible
in these two environments; The build with pkg-config (normal build) and
the build with pkg-config wil be different.


Although it's a side effect (I mean, it was not my own purpose
originally), my effort allows better support of GnuPG cross build in
various situations (multiarch in Debian, multilib for
Arch/Fedora/OpenSUSE, and straight cross build for Windows), just like
pkg-config can offer.

Actually, my effort greatly simplifies the situation of GnuPG cross
build, because we only use a single script.

In case of pkg-config, cross build is not supported by the tool itself,
but it is supported by some arrangement of distribution.  For example,
in case of Debian, we have {HOST_ARCH}-pkg-config which links to
/usr/share/pkg-config-crosswrapper.  This is not ideal situation, yet.

In old ways, there were {HOST_ARCH}-<library-specific>-config scripts
for GnuPG (too many!).  Use of pkg-config can improve the situation to
have {HOST_ARCH}-pkg-config only.  Now, there is only a single script of
gpgrt-config.

Speaking about less possibility thing, when/if we will have pkg-config
implementation (re-)written as portable AWK script, in future, we will
be able to use pkg-config directly.  Then, we will be able to throw away
gpgrt-config.
-- 


From alon.barlev at gmail.com  Tue Dec  4 02:46:19 2018
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Tue, 4 Dec 2018 03:46:19 +0200
Subject: [PATCH Libgpg-error] gpg-error.m4: support pkg-config
In-Reply-To: <877egq158u.fsf@fsij.org>
References: <20181011182720.11991-1-alon.barlev@gmail.com>
 <871s8vptg1.fsf@wheatstone.g10code.de>
 <CAOazyz3F2E0KphGwc41rKFdfhoNxjNW8f8mLoAUyWzhHodCQjg@mail.gmail.com>
 <87efcokjn6.fsf@wheatstone.g10code.de>
 <CAOazyz2Wo62ax_+kn7F+UvJZUnnRavw35bePKZAmPPaKO_gzeg@mail.gmail.com>
 <CAOazyz0Q6m6gbtThu2G8LLyQQ3mnLn_Uexpi+=BxwWKeRUmBQw@mail.gmail.com>
 <8736snt3kn.fsf@fsij.org>
 <CAOazyz3jgK5efBZL1BvFWAGnXRgtr22tRNq3-=WLiGMNk0+JFQ@mail.gmail.com>
 <87d0rqod6v.fsf@fsij.org>
 <CAOazyz1qPw021tq+FNbtLQCQj_oNvDwSnOaPb6=UkByxFLgaNA@mail.gmail.com>
 <CAOazyz19XD7CJm_BTO3HgWiGHB8FhtGOrf1yo+-acNCQ-dmVYw@mail.gmail.com>
 <87mupoiu2v.fsf@fifthhorseman.net> <87k1krh8dq.fsf@fsij.org>
 <CAOazyz0-Ovb_sLk8NUKUDQeLc7203EacgCL4qF6XoDz_6BR5FQ@mail.gmail.com>
 <87y397jyxr.fsf@fsij.org>
 <CAOazyz2Bd0v6wrBgavQU3yf_rumsLYvHQztUCnEB+j-u-BRfkg@mail.gmail.com>
 <877egq158u.fsf@fsij.org>
Message-ID: <CAOazyz2dGAhWOAxHJUefeq-U9GffmRLe=R7kpmyomw88D2aCmg@mail.gmail.com>

On Tue, Dec 4, 2018 at 2:54 AM NIIBE Yutaka <gniibe at fsij.org> wrote:
>
> Hello,
>
> Please accept my apologize if tone of my writing sounded too strong.
> Perhaps, I (wrongly) recognized that my efforts were disregarded.

Your efforts are not disregarded and are appreciated, 3rd party
components long waited for having pkg-config support for gnupg
components, now you have provided that, which is the base of taking
this farther into the gnupg build itself.

Based on your detailed description it seems like you do not understand
that us, downstream maintainers, and us, developers, need to cope with
a complex proprietary build system. I truly understand your point of
view, however, the larger picture is that we have many packages to
maintain in different scenarios and combinations, and gnupg build
system just make it harder to create a solution with no actual
functional benefit other than saying the pkg-config is not the idle
solution out there.

You truly believe that the build system of gnupg was simplified with
recent effort and you are probably right... however, this is not
enough when looking at the greater picture as it requires special
attention and does not comply with the best practices of build system
that we have worked so hard to reach.

Any proprietary build system, as simple as you may believe it is
introduce additional complexity in the grand plan. In this discussion,
I am not interested in taking anything from you, we can continue to
build and maintain gnupg packages without pkg-config, however, I would
like you to allow the option for downstream and developers who wishes
to use pkg-config to do so, this is a trivial effort to maintain now
that you provide pkg-config metadata.

Once again, I would like to see gnupg build system make both of us
happy, by default use your best/simplest/efficient build system, and
in addition provide pkg-config alternative for users who wishes to use
this method. It is trivial to support that, as I've shown in this
patch.

Regardless of using pkg-config, in this thread I also showed you that
your usage of config script is incorrect as:
1. AC_CHECK_TOOL should be use to check platform specific tools.
2. The config scripts must be prefixed with ${HOST}
3. The config scripts should have their own target directory, probably
outside of ${ROOT} as executing anything from ${ROOT} is incompatible
with cross-compile.

Let's summarize what I understand so far:

1. You should use the method of detecting and installing config
scripts to comply with autoconf patterns, this applies to the current
proprietary solution.

2. You did not answer the request of supporting both options of using
the gpgrt-config as default and allow people to use pkg-config if they
like, this will solve many of the problem other people are
experiencing and allow downstream maintainer to have predictable build
behavior if they so choose.

Thanks,
Alon


From wk at gnupg.org  Tue Dec  4 08:27:37 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 04 Dec 2018 08:27:37 +0100
Subject: [PATCH Libgpg-error] gpg-error.m4: support pkg-config
In-Reply-To: <CAOazyz2Bd0v6wrBgavQU3yf_rumsLYvHQztUCnEB+j-u-BRfkg@mail.gmail.com>
 (Alon Bar-Lev's message of "Mon, 3 Dec 2018 01:31:21 +0200")
References: <20181011182720.11991-1-alon.barlev@gmail.com>
 <871s8vptg1.fsf@wheatstone.g10code.de>
 <CAOazyz3F2E0KphGwc41rKFdfhoNxjNW8f8mLoAUyWzhHodCQjg@mail.gmail.com>
 <87efcokjn6.fsf@wheatstone.g10code.de>
 <CAOazyz2Wo62ax_+kn7F+UvJZUnnRavw35bePKZAmPPaKO_gzeg@mail.gmail.com>
 <CAOazyz0Q6m6gbtThu2G8LLyQQ3mnLn_Uexpi+=BxwWKeRUmBQw@mail.gmail.com>
 <8736snt3kn.fsf@fsij.org>
 <CAOazyz3jgK5efBZL1BvFWAGnXRgtr22tRNq3-=WLiGMNk0+JFQ@mail.gmail.com>
 <87d0rqod6v.fsf@fsij.org>
 <CAOazyz1qPw021tq+FNbtLQCQj_oNvDwSnOaPb6=UkByxFLgaNA@mail.gmail.com>
 <CAOazyz19XD7CJm_BTO3HgWiGHB8FhtGOrf1yo+-acNCQ-dmVYw@mail.gmail.com>
 <87mupoiu2v.fsf@fifthhorseman.net> <87k1krh8dq.fsf@fsij.org>
 <CAOazyz0-Ovb_sLk8NUKUDQeLc7203EacgCL4qF6XoDz_6BR5FQ@mail.gmail.com>
 <87y397jyxr.fsf@fsij.org>
 <CAOazyz2Bd0v6wrBgavQU3yf_rumsLYvHQztUCnEB+j-u-BRfkg@mail.gmail.com>
Message-ID: <87efaxhhue.fsf@wheatstone.g10code.de>

On Mon,  3 Dec 2018 00:31, alon.barlev at gmail.com said:

> Please explain again why not give an option for downstream to build
> gnupg components using pkg-config, this does not take anything from
> whoever wishes to continue to use current mode.

Because supporting two build systems is a PITA and costs us too much.

The changes Gniibe did to support pgk-config for users of our libraries
were already expensive enough and it is not justified to burn more money
with that.  In particular because we and not you need to maintain such a
duplicated build systems.

After the next round of releases we can expect quite some extra work due
to these changes anyway.  We will take this trouble and thus pretty
please stop complaining about that not being sufficient.  There are much
more important things to do than to willy-nilly change an established
build system.


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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181204/e60ff6ac/attachment.sig>

From alon.barlev at gmail.com  Tue Dec  4 21:54:22 2018
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Tue, 4 Dec 2018 22:54:22 +0200
Subject: [PATCH Libgpg-error] gpg-error.m4: support pkg-config
In-Reply-To: <87efaxhhue.fsf@wheatstone.g10code.de>
References: <20181011182720.11991-1-alon.barlev@gmail.com>
 <871s8vptg1.fsf@wheatstone.g10code.de>
 <CAOazyz3F2E0KphGwc41rKFdfhoNxjNW8f8mLoAUyWzhHodCQjg@mail.gmail.com>
 <87efcokjn6.fsf@wheatstone.g10code.de>
 <CAOazyz2Wo62ax_+kn7F+UvJZUnnRavw35bePKZAmPPaKO_gzeg@mail.gmail.com>
 <CAOazyz0Q6m6gbtThu2G8LLyQQ3mnLn_Uexpi+=BxwWKeRUmBQw@mail.gmail.com>
 <8736snt3kn.fsf@fsij.org>
 <CAOazyz3jgK5efBZL1BvFWAGnXRgtr22tRNq3-=WLiGMNk0+JFQ@mail.gmail.com>
 <87d0rqod6v.fsf@fsij.org>
 <CAOazyz1qPw021tq+FNbtLQCQj_oNvDwSnOaPb6=UkByxFLgaNA@mail.gmail.com>
 <CAOazyz19XD7CJm_BTO3HgWiGHB8FhtGOrf1yo+-acNCQ-dmVYw@mail.gmail.com>
 <87mupoiu2v.fsf@fifthhorseman.net> <87k1krh8dq.fsf@fsij.org>
 <CAOazyz0-Ovb_sLk8NUKUDQeLc7203EacgCL4qF6XoDz_6BR5FQ@mail.gmail.com>
 <87y397jyxr.fsf@fsij.org>
 <CAOazyz2Bd0v6wrBgavQU3yf_rumsLYvHQztUCnEB+j-u-BRfkg@mail.gmail.com>
 <87efaxhhue.fsf@wheatstone.g10code.de>
Message-ID: <CAOazyz2NDOmXyB4t-mGF=rfcsYOJOiSb+2TvvX-fXGF5xyLwAg@mail.gmail.com>

On Tue, Dec 4, 2018 at 9:30 AM Werner Koch <wk at gnupg.org> wrote:
>
> On Mon,  3 Dec 2018 00:31, alon.barlev at gmail.com said:
>
> > Please explain again why not give an option for downstream to build
> > gnupg components using pkg-config, this does not take anything from
> > whoever wishes to continue to use current mode.
>

<snip>

> After the next round of releases we can expect quite some extra work due
> to these changes anyway.  We will take this trouble and thus pretty
> please stop complaining about that not being sufficient.  There are much
> more important things to do than to willy-nilly change an established
> build system.

Hello Werner,
Once again you ignore that even the current build system does not
comply with autoconf standards and should be fixed.
This was not required if you support pkg-config as we could have an
option, but if you insist not supporting pkg-config at least work to
fix the existing build to properly support multilib and cross compile.
Thanks,
Alon


From dirk.gottschalk1980 at googlemail.com  Tue Dec  4 22:57:15 2018
From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk)
Date: Tue, 04 Dec 2018 22:57:15 +0100
Subject: [PATCH Libgpg-error] gpg-error.m4: support pkg-config
In-Reply-To: <CAOazyz2NDOmXyB4t-mGF=rfcsYOJOiSb+2TvvX-fXGF5xyLwAg@mail.gmail.com>
References: <20181011182720.11991-1-alon.barlev@gmail.com>
 <871s8vptg1.fsf@wheatstone.g10code.de>
 <CAOazyz3F2E0KphGwc41rKFdfhoNxjNW8f8mLoAUyWzhHodCQjg@mail.gmail.com>
 <87efcokjn6.fsf@wheatstone.g10code.de>
 <CAOazyz2Wo62ax_+kn7F+UvJZUnnRavw35bePKZAmPPaKO_gzeg@mail.gmail.com>
 <CAOazyz0Q6m6gbtThu2G8LLyQQ3mnLn_Uexpi+=BxwWKeRUmBQw@mail.gmail.com>
 <8736snt3kn.fsf@fsij.org>
 <CAOazyz3jgK5efBZL1BvFWAGnXRgtr22tRNq3-=WLiGMNk0+JFQ@mail.gmail.com>
 <87d0rqod6v.fsf@fsij.org>
 <CAOazyz1qPw021tq+FNbtLQCQj_oNvDwSnOaPb6=UkByxFLgaNA@mail.gmail.com>
 <CAOazyz19XD7CJm_BTO3HgWiGHB8FhtGOrf1yo+-acNCQ-dmVYw@mail.gmail.com>
 <87mupoiu2v.fsf@fifthhorseman.net> <87k1krh8dq.fsf@fsij.org>
 <CAOazyz0-Ovb_sLk8NUKUDQeLc7203EacgCL4qF6XoDz_6BR5FQ@mail.gmail.com>
 <87y397jyxr.fsf@fsij.org>
 <CAOazyz2Bd0v6wrBgavQU3yf_rumsLYvHQztUCnEB+j-u-BRfkg@mail.gmail.com>
 <87efaxhhue.fsf@wheatstone.g10code.de>
 <CAOazyz2NDOmXyB4t-mGF=rfcsYOJOiSb+2TvvX-fXGF5xyLwAg@mail.gmail.com>
Message-ID: <b66bb3224667155e03f2dc5fff2dfee8dbc010b4.camel@googlemail.com>

Hello Alon.

Am Dienstag, den 04.12.2018, 22:54 +0200 schrieb Alon Bar-Lev:
> On Tue, Dec 4, 2018 at 9:30 AM Werner Koch <wk at gnupg.org> wrote:
> > On Mon,  3 Dec 2018 00:31, alon.barlev at gmail.com said:
> > 
> > > Please explain again why not give an option for downstream to
> > > build
> > > gnupg components using pkg-config, this does not take anything
> > > from
> > > whoever wishes to continue to use current mode.

> <snip>

> > After the next round of releases we can expect quite some extra
> > work due
> > to these changes anyway.  We will take this trouble and thus pretty
> > please stop complaining about that not being sufficient.  There are
> > much
> > more important things to do than to willy-nilly change an
> > established
> > build system.

> Hello Werner,
> Once again you ignore that even the current build system does not
> comply with autoconf standards and should be fixed.
> This was not required if you support pkg-config as we could have an
> option, but if you insist not supporting pkg-config at least work to
> fix the existing build to properly support multilib and cross
> compile.

I don't see your problem at all. Most libraries for GPG, at least the
packages of Fedora, which I use, support pkg-config to link them, the
.pc files are available and usable. GPG itself is not a library so
there is no need for a .pc file.

I have no problem building the actual git snapshot of GPG only with the
installed libraries and header files from the system. So, what are you
complaining about? The .pc files which are not available in your case?
Write them, if you want to link the libs with pkg-config for
configuration.

There is really no need of changing the build system at all. And yes,
it is autoconf. The scripts are a little complicated to read, but it is
autoconf, for sure, with some "extras".

I, as a developer of software which uses GPG(me) and some of the
underlying libraries directly, have never had any real problem with the
actual build system.

Regards,
Dirk

PS: Thank you, Werner and the whole team, for your good work. And no
bugs, please. Pest patrol is really expensive. :D


-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen, Germany

GPG: DDCB AF8E 0132 AA54 20AB  B864 4081 0B18 1ED8 E838
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac




From gniibe at fsij.org  Wed Dec  5 02:10:40 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 05 Dec 2018 10:10:40 +0900
Subject: [PATCH Libgpg-error] gpg-error.m4: support pkg-config
In-Reply-To: <CAOazyz2dGAhWOAxHJUefeq-U9GffmRLe=R7kpmyomw88D2aCmg@mail.gmail.com>
References: <20181011182720.11991-1-alon.barlev@gmail.com>
 <871s8vptg1.fsf@wheatstone.g10code.de>
 <CAOazyz3F2E0KphGwc41rKFdfhoNxjNW8f8mLoAUyWzhHodCQjg@mail.gmail.com>
 <87efcokjn6.fsf@wheatstone.g10code.de>
 <CAOazyz2Wo62ax_+kn7F+UvJZUnnRavw35bePKZAmPPaKO_gzeg@mail.gmail.com>
 <CAOazyz0Q6m6gbtThu2G8LLyQQ3mnLn_Uexpi+=BxwWKeRUmBQw@mail.gmail.com>
 <8736snt3kn.fsf@fsij.org>
 <CAOazyz3jgK5efBZL1BvFWAGnXRgtr22tRNq3-=WLiGMNk0+JFQ@mail.gmail.com>
 <87d0rqod6v.fsf@fsij.org>
 <CAOazyz1qPw021tq+FNbtLQCQj_oNvDwSnOaPb6=UkByxFLgaNA@mail.gmail.com>
 <CAOazyz19XD7CJm_BTO3HgWiGHB8FhtGOrf1yo+-acNCQ-dmVYw@mail.gmail.com>
 <87mupoiu2v.fsf@fifthhorseman.net> <87k1krh8dq.fsf@fsij.org>
 <CAOazyz0-Ovb_sLk8NUKUDQeLc7203EacgCL4qF6XoDz_6BR5FQ@mail.gmail.com>
 <87y397jyxr.fsf@fsij.org>
 <CAOazyz2Bd0v6wrBgavQU3yf_rumsLYvHQztUCnEB+j-u-BRfkg@mail.gmail.com>
 <877egq158u.fsf@fsij.org>
 <CAOazyz2dGAhWOAxHJUefeq-U9GffmRLe=R7kpmyomw88D2aCmg@mail.gmail.com>
Message-ID: <87bm60lqwf.fsf@iwagami.gniibe.org>

Hello,

I think that I should explain from my viewpoint, not as an answer.

So, I'm writing this message for people who build GnuPG.  As an
appendix, I will write an answer to reply, but that's not important
part.


Here we go.

In master branch, we did major improvement to introduce new method,
keeping old method.  We are sorry to say that we don't accept further
change of old method.  We keep old method unchanged (as bad as is).
Please use new method for new features.


(1) We introduce .pc files for GnuPG libraries (npth, libgpg-error,
libgcrypt, libassuan, libksba, and ntbtls) and for GPGME.  


(2) We introduce new gpgrt-config script which is a portable script to
use .pc file for each ${HOST}.  Since it supports all ${HOST} by a
single script, there will be no ${HOST}-gpgrt-config scripts, like
pkg-config (or <library-specific>-config) does in distribution
arrangement.


(3) We introduce new method which uses gpgrt-config script by updated
<library-specific>.m4.  It's up to library users to prefer this m4 with
gpgrt-config, or to prefer pkg.m4 with pkg-config.

Still updated <library-specific>.m4 keeps old method of using
<library-specific>-config script (possibly wrong for some use cases, I
know), but we intentionally keep it for backward compatibility.


(4) For use of updated <library-specific>.m4 for new GnuPG libraries
which come with .pc files, since gpgrt-config script can be used, any
<library-specific>-config script (including
${HOST}-<library-specific>-config scripts) are not needed any more.
Obviously, for use of pkg.m4, <library-specific>-config script is no
need.

Distributions are suggested not to install <library-specific>-config, if
all software will be updated to use updated <library-specific>.m4, or
pkg.m4.

We keep distributing <library-specific>-config for a while, since old
<library-specific>.m4 can be supported.


(5) GnuPG build uses new <library-specific>.m4 with gpgrt-config.  It
does require only a single gpgrt-config for all ${HOST}s for cross
build.  No ${HOST}-gpgrt-config, no <library-specific>-config,
no ${HOST}-<library-specific>-config are required.

With .pc files which are handled by single gpgrt-config script, GnuPG
build has been improved, supporting many cross build cases (multiarch,
multilib in Arch/Fedora/OpenSUSE style, mingw for Windows).

No need of SYSROOT environment variable, no need of
--with-<library-specific>-prefix argument for configure, just run
simple configure with relevant --host=${HOST} (and --libdir for
multiarch).

Please test and enjoy new improvement, and please report problems
of new features.

		*	*	*
An appendix:

Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> Regardless of using pkg-config, in this thread I also showed you that
> your usage of config script is incorrect as:
> 1. AC_CHECK_TOOL should be use to check platform specific tools.
> 2. The config scripts must be prefixed with ${HOST}

This claim is only valid to old code, not correct any more.

In new method, <library-specific>-config was gone, gpgrt-config is only
a single script which is portable, and we don't have
${HOST}-gpgrt-config script.  So, AC_CHECK_PROG is enough.

> 3. The config scripts should have their own target directory, probably
> outside of ${ROOT} as executing anything from ${ROOT} is incompatible
> with cross-compile.

I think that you meant SYSROOT environment variable support.  I know
it's a peculiar method (and possibly strange and wrong in some use
cases).  It's only for specific cross build for Windows.  We don't touch
this existing method.  New users don't need to use this old method.

> 1. You should use the method of detecting and installing config
> scripts to comply with autoconf patterns, this applies to the current
> proprietary solution.

I understand your claim (and partly share your frustrations), which was
valid for old method.

It is somehow compilicated, but we also support old (in some cases,
wrong way) of detecting <library-specific>-config script, to support
existing build and existing software.  We are conservative about that,
we don't have any idea to "fix" this part to comply "correct" autoconf
patterns.

And it is true that we still use gpgrt-config script for GnuPG build
(instead of pkg-config), but this is a single script with no ${HOST}
variants.

> 2. You did not answer the request of supporting both options of using
> the gpgrt-config as default and allow people to use pkg-config if they
> like, this will solve many of the problem other people are
> experiencing and allow downstream maintainer to have predictable build
> behavior if they so choose.

I have explained the reason why GnuPG build never use pkg-config for its
detection of GnuPG libraries.  It's no need, no benefit, but comes with
possible risk.

Nevertheless, many of problems were solved in new method, just like
pkg-config can be achieved.

It's unfortunate, for some people, it hasn't achieved to the status of
complete victory (of using pkg-config for all) yet.  Please don't
complain about that.  As I suggested, when pkg-config will be evolved to
meet GnuPG build requirement, situation will be able to be improved.
Let's see, but, it's not now.
-- 


From dkg at fifthhorseman.net  Wed Dec  5 01:57:56 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 05 Dec 2018 03:57:56 +0300
Subject: [GPGME PATCH] python: simplify Context.decrypt()
In-Reply-To: <20181128062525.5649-1-dkg@fifthhorseman.net>
References: <20181128062525.5649-1-dkg@fifthhorseman.net>
Message-ID: <87o9a0lrhn.fsf@fifthhorseman.net>

On Wed 2018-11-28 01:25:25 -0500, Daniel Kahn Gillmor wrote:
> In the course of trying to address https://dev.gnupg.org/T4271, i
> discovered that gpg.Context.decrypt() has a bit of superfluous code.
> This changeset is intended to simplify the code without making any
> functional changes.

this is now a part of the branch dkg/fix-T4271 on dev.gnupg.org, which
resolves issue T4271 completely, including adjusting the test suite to
catch it when something like this happens again.

it's a clarification/restructuring of the Context.decrypt() function, so
i'd appreciate review/oversight on the patches in that branch though.
Ben, can i get you take a look at it? and either merge it or tell me
what's wrong?  I need to get this fixed in debian soon, because it's
breaking other packages.

Regards,

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181205/3c940d7b/attachment.sig>

From alon.barlev at gmail.com  Wed Dec  5 12:35:30 2018
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Wed, 5 Dec 2018 13:35:30 +0200
Subject: [PATCH Libgpg-error] gpg-error.m4: support pkg-config
In-Reply-To: <b66bb3224667155e03f2dc5fff2dfee8dbc010b4.camel@googlemail.com>
References: <20181011182720.11991-1-alon.barlev@gmail.com>
 <871s8vptg1.fsf@wheatstone.g10code.de>
 <CAOazyz3F2E0KphGwc41rKFdfhoNxjNW8f8mLoAUyWzhHodCQjg@mail.gmail.com>
 <87efcokjn6.fsf@wheatstone.g10code.de>
 <CAOazyz2Wo62ax_+kn7F+UvJZUnnRavw35bePKZAmPPaKO_gzeg@mail.gmail.com>
 <CAOazyz0Q6m6gbtThu2G8LLyQQ3mnLn_Uexpi+=BxwWKeRUmBQw@mail.gmail.com>
 <8736snt3kn.fsf@fsij.org>
 <CAOazyz3jgK5efBZL1BvFWAGnXRgtr22tRNq3-=WLiGMNk0+JFQ@mail.gmail.com>
 <87d0rqod6v.fsf@fsij.org>
 <CAOazyz1qPw021tq+FNbtLQCQj_oNvDwSnOaPb6=UkByxFLgaNA@mail.gmail.com>
 <CAOazyz19XD7CJm_BTO3HgWiGHB8FhtGOrf1yo+-acNCQ-dmVYw@mail.gmail.com>
 <87mupoiu2v.fsf@fifthhorseman.net> <87k1krh8dq.fsf@fsij.org>
 <CAOazyz0-Ovb_sLk8NUKUDQeLc7203EacgCL4qF6XoDz_6BR5FQ@mail.gmail.com>
 <87y397jyxr.fsf@fsij.org>
 <CAOazyz2Bd0v6wrBgavQU3yf_rumsLYvHQztUCnEB+j-u-BRfkg@mail.gmail.com>
 <87efaxhhue.fsf@wheatstone.g10code.de>
 <CAOazyz2NDOmXyB4t-mGF=rfcsYOJOiSb+2TvvX-fXGF5xyLwAg@mail.gmail.com>
 <b66bb3224667155e03f2dc5fff2dfee8dbc010b4.camel@googlemail.com>
Message-ID: <CAOazyz2e1XM2OnUTVm_d3j5Udcr_gQj8P34d3TfApH58joKuCg@mail.gmail.com>

On Tue, Dec 4, 2018 at 11:57 PM Dirk Gottschalk
<dirk.gottschalk1980 at googlemail.com> wrote:
>
> Hello Alon.
>
> Am Dienstag, den 04.12.2018, 22:54 +0200 schrieb Alon Bar-Lev:
> > On Tue, Dec 4, 2018 at 9:30 AM Werner Koch <wk at gnupg.org> wrote:
> > > On Mon,  3 Dec 2018 00:31, alon.barlev at gmail.com said:
> > >
> > > > Please explain again why not give an option for downstream to
> > > > build
> > > > gnupg components using pkg-config, this does not take anything
> > > > from
> > > > whoever wishes to continue to use current mode.
>
> I have no problem building the actual git snapshot of GPG only with the
> installed libraries and header files from the system. So, what are you
> complaining about? The .pc files which are not available in your case?
> Write them, if you want to link the libs with pkg-config for
> configuration.
>
> There is really no need of changing the build system at all. And yes,
> it is autoconf. The scripts are a little complicated to read, but it is
> autoconf, for sure, with some "extras".

Just to make sure we are on the same page...
Have you tried cross compile a complete solution of libraries? Have
you tried cross-compile + multilib setup?
If you have, how many tweaks have you needed in order to make this work?

Thanks!
Alon


From alon.barlev at gmail.com  Wed Dec  5 15:49:08 2018
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Wed, 5 Dec 2018 16:49:08 +0200
Subject: [PATCH Libgpg-error] gpg-error.m4: support pkg-config
In-Reply-To: <e428aff2-14f5-6bf5-2390-f0ba03f676af@digitalbrains.com>
References: <20181011182720.11991-1-alon.barlev@gmail.com>
 <87efcokjn6.fsf@wheatstone.g10code.de>
 <CAOazyz2Wo62ax_+kn7F+UvJZUnnRavw35bePKZAmPPaKO_gzeg@mail.gmail.com>
 <CAOazyz0Q6m6gbtThu2G8LLyQQ3mnLn_Uexpi+=BxwWKeRUmBQw@mail.gmail.com>
 <8736snt3kn.fsf@fsij.org>
 <CAOazyz3jgK5efBZL1BvFWAGnXRgtr22tRNq3-=WLiGMNk0+JFQ@mail.gmail.com>
 <87d0rqod6v.fsf@fsij.org>
 <CAOazyz1qPw021tq+FNbtLQCQj_oNvDwSnOaPb6=UkByxFLgaNA@mail.gmail.com>
 <CAOazyz19XD7CJm_BTO3HgWiGHB8FhtGOrf1yo+-acNCQ-dmVYw@mail.gmail.com>
 <87mupoiu2v.fsf@fifthhorseman.net> <87k1krh8dq.fsf@fsij.org>
 <CAOazyz0-Ovb_sLk8NUKUDQeLc7203EacgCL4qF6XoDz_6BR5FQ@mail.gmail.com>
 <87y397jyxr.fsf@fsij.org>
 <CAOazyz2Bd0v6wrBgavQU3yf_rumsLYvHQztUCnEB+j-u-BRfkg@mail.gmail.com>
 <87efaxhhue.fsf@wheatstone.g10code.de>
 <CAOazyz2NDOmXyB4t-mGF=rfcsYOJOiSb+2TvvX-fXGF5xyLwAg@mail.gmail.com>
 <b66bb3224667155e03f2dc5fff2dfee8dbc010b4.camel@googlemail.com>
 <CAOazyz2e1XM2OnUTVm_d3j5Udcr_gQj8P34d3TfApH58joKuCg@mail.gmail.com>
 <e428aff2-14f5-6bf5-2390-f0ba03f676af@digitalbrains.com>
Message-ID: <CAOazyz0Od5ufeRaFPzoY+taGtQNYSjZuPgQtCmE_4Q8-ozyhaA@mail.gmail.com>

On Wed, Dec 5, 2018 at 4:31 PM Peter Lebbing <peter at digitalbrains.com> wrote:
>
> On 05/12/2018 12:35, Alon Bar-Lev wrote:
> > If you have, how many tweaks have you needed in order to make this
> > work?
>
> It sounds like /you/ have tried it. If it's not too much work, can you
> give an indication of the tweaks /you/ needed to build the current
> master branch?

It is only a matter of cost shift from single upstream to multiple
people and downstream. You can look at the Gentoo packages to see the
current tweaks, which are not working for all cases. We will see what
it takes to support cross-compile in the next versions. I hope the
cross compile and multilib (apart and together) will be tested and
supported before release.

I fully understand the response I got. No reason to continue this thread.


From peter at digitalbrains.com  Wed Dec  5 15:31:06 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 5 Dec 2018 15:31:06 +0100
Subject: [PATCH Libgpg-error] gpg-error.m4: support pkg-config
In-Reply-To: <CAOazyz2e1XM2OnUTVm_d3j5Udcr_gQj8P34d3TfApH58joKuCg@mail.gmail.com>
References: <20181011182720.11991-1-alon.barlev@gmail.com>
 <87efcokjn6.fsf@wheatstone.g10code.de>
 <CAOazyz2Wo62ax_+kn7F+UvJZUnnRavw35bePKZAmPPaKO_gzeg@mail.gmail.com>
 <CAOazyz0Q6m6gbtThu2G8LLyQQ3mnLn_Uexpi+=BxwWKeRUmBQw@mail.gmail.com>
 <8736snt3kn.fsf@fsij.org>
 <CAOazyz3jgK5efBZL1BvFWAGnXRgtr22tRNq3-=WLiGMNk0+JFQ@mail.gmail.com>
 <87d0rqod6v.fsf@fsij.org>
 <CAOazyz1qPw021tq+FNbtLQCQj_oNvDwSnOaPb6=UkByxFLgaNA@mail.gmail.com>
 <CAOazyz19XD7CJm_BTO3HgWiGHB8FhtGOrf1yo+-acNCQ-dmVYw@mail.gmail.com>
 <87mupoiu2v.fsf@fifthhorseman.net> <87k1krh8dq.fsf@fsij.org>
 <CAOazyz0-Ovb_sLk8NUKUDQeLc7203EacgCL4qF6XoDz_6BR5FQ@mail.gmail.com>
 <87y397jyxr.fsf@fsij.org>
 <CAOazyz2Bd0v6wrBgavQU3yf_rumsLYvHQztUCnEB+j-u-BRfkg@mail.gmail.com>
 <87efaxhhue.fsf@wheatstone.g10code.de>
 <CAOazyz2NDOmXyB4t-mGF=rfcsYOJOiSb+2TvvX-fXGF5xyLwAg@mail.gmail.com>
 <b66bb3224667155e03f2dc5fff2dfee8dbc010b4.camel@googlemail.com>
 <CAOazyz2e1XM2OnUTVm_d3j5Udcr_gQj8P34d3TfApH58joKuCg@mail.gmail.com>
Message-ID: <e428aff2-14f5-6bf5-2390-f0ba03f676af@digitalbrains.com>

On 05/12/2018 12:35, Alon Bar-Lev wrote:
> If you have, how many tweaks have you needed in order to make this
> work?

It sounds like /you/ have tried it. If it's not too much work, can you
give an indication of the tweaks /you/ needed to build the current
master branch?

I know nothing of the subject at hand, but so far, from this
conversation I can distill that you think the build system should never
invoke anything in SYSROOT, whereas Werner thinks that is okay so long
as the things invoked are architecture-independent scripts such as a
Bash script.

And that you think GnuPG should follow best practices of various tools.

Furthermore, you are of the opinion it is trivial to do whereas Werner
uses the phrases "PITA" and "burning money".

However, the first two things are matters of differing points of view,
not directly things that actually mean something needs to be tweaked
before it actually works. And the difference of opinion on triviality
suggests you are not exactly talking about the same changes, or the
impact is misunderstood.

Finally, Gniibe seems to indicate that there are no tweaks needed at all
in all situations he considers in his mails. Which begs the question at
the top: which tweaks do you need to build current master succesfully?

Maybe my from-the-sideline observation can nudge the conversation into
more concrete matter? If not, feel free to disregard this.

Hoping that helps,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181205/72cffe75/attachment-0001.sig>

From dirk.gottschalk1980 at googlemail.com  Thu Dec  6 23:52:33 2018
From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk)
Date: Thu, 06 Dec 2018 23:52:33 +0100
Subject: [PATCH Libgpg-error] gpg-error.m4: support pkg-config
In-Reply-To: <CAOazyz2e1XM2OnUTVm_d3j5Udcr_gQj8P34d3TfApH58joKuCg@mail.gmail.com>
References: <20181011182720.11991-1-alon.barlev@gmail.com>
 <871s8vptg1.fsf@wheatstone.g10code.de>
 <CAOazyz3F2E0KphGwc41rKFdfhoNxjNW8f8mLoAUyWzhHodCQjg@mail.gmail.com>
 <87efcokjn6.fsf@wheatstone.g10code.de>
 <CAOazyz2Wo62ax_+kn7F+UvJZUnnRavw35bePKZAmPPaKO_gzeg@mail.gmail.com>
 <CAOazyz0Q6m6gbtThu2G8LLyQQ3mnLn_Uexpi+=BxwWKeRUmBQw@mail.gmail.com>
 <8736snt3kn.fsf@fsij.org>
 <CAOazyz3jgK5efBZL1BvFWAGnXRgtr22tRNq3-=WLiGMNk0+JFQ@mail.gmail.com>
 <87d0rqod6v.fsf@fsij.org>
 <CAOazyz1qPw021tq+FNbtLQCQj_oNvDwSnOaPb6=UkByxFLgaNA@mail.gmail.com>
 <CAOazyz19XD7CJm_BTO3HgWiGHB8FhtGOrf1yo+-acNCQ-dmVYw@mail.gmail.com>
 <87mupoiu2v.fsf@fifthhorseman.net> <87k1krh8dq.fsf@fsij.org>
 <CAOazyz0-Ovb_sLk8NUKUDQeLc7203EacgCL4qF6XoDz_6BR5FQ@mail.gmail.com>
 <87y397jyxr.fsf@fsij.org>
 <CAOazyz2Bd0v6wrBgavQU3yf_rumsLYvHQztUCnEB+j-u-BRfkg@mail.gmail.com>
 <87efaxhhue.fsf@wheatstone.g10code.de>
 <CAOazyz2NDOmXyB4t-mGF=rfcsYOJOiSb+2TvvX-fXGF5xyLwAg@mail.gmail.com>
 <b66bb3224667155e03f2dc5fff2dfee8dbc010b4.camel@googlemail.com>
 <CAOazyz2e1XM2OnUTVm_d3j5Udcr_gQj8P34d3TfApH58joKuCg@mail.gmail.com>
Message-ID: <1433ef08cb67d6c6db2591c83a4b593ea2f633db.camel@googlemail.com>

Hello Alon.

Am Mittwoch, den 05.12.2018, 13:35 +0200 schrieb Alon Bar-Lev:
> On Tue, Dec 4, 2018 at 11:57 PM Dirk Gottschalk
> <dirk.gottschalk1980 at googlemail.com> wrote:
> > Hello Alon.

> > Am Dienstag, den 04.12.2018, 22:54 +0200 schrieb Alon Bar-Lev:
> > > On Tue, Dec 4, 2018 at 9:30 AM Werner Koch <wk at gnupg.org> wrote:
> > > > On Mon,  3 Dec 2018 00:31, alon.barlev at gmail.com said:
> > > > 
> > > > > Please explain again why not give an option for downstream to
> > > > > build gnupg components using pkg-config, this does not take
> > > > > anything from whoever wishes to continue to use current mode.

> > I have no problem building the actual git snapshot of GPG only with
> > the installed libraries and header files from the system. So, what
> > are you complaining about? The .pc files which are not available in
> > your case?
> > Write them, if you want to link the libs with pkg-config for
> > configuration.

> > There is really no need of changing the build system at all. And
> > yes, it is autoconf. The scripts are a little complicated to read,
> > but it is autoconf, for sure, with some "extras".

> Just to make sure we are on the same page...
> Have you tried cross compile a complete solution of libraries? Have
> you tried cross-compile + multilib setup?

I compiled the libs for GnuPG on several platforms without any
problems. Usually I have the Systems which I compile for at least in a
virtual machine, so there is no need for cross compiling. But it should
work if the environment ist set up correctly, that I am sure of. There
is no program out there which cross compiles without any changes that
have to be made. On my fedora machine there are, for example, some
wrapper scripts if you want to cross compile for mingw which set up the
environment for configure, cmake and various other build systems.


> If you have, how many tweaks have you needed in order to make this
> work?

Even my own programs which are completely made with Autotools and
pkg-config need some tweaks if I want to cross compile them for
Windows, for example.

That's the reason why I prefer to compile on the target platform, this
makes life much easier. ^^

Regards,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen, Germany

GPG: DDCB AF8E 0132 AA54 20AB  B864 4081 0B18 1ED8 E838
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181206/5b82a86d/attachment.sig>

From gniibe at fsij.org  Fri Dec  7 01:56:38 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 07 Dec 2018 09:56:38 +0900
Subject: [PATCH Libgpg-error] gpg-error.m4: support pkg-config
In-Reply-To: <1433ef08cb67d6c6db2591c83a4b593ea2f633db.camel@googlemail.com>
References: <20181011182720.11991-1-alon.barlev@gmail.com>
 <871s8vptg1.fsf@wheatstone.g10code.de>
 <CAOazyz3F2E0KphGwc41rKFdfhoNxjNW8f8mLoAUyWzhHodCQjg@mail.gmail.com>
 <87efcokjn6.fsf@wheatstone.g10code.de>
 <CAOazyz2Wo62ax_+kn7F+UvJZUnnRavw35bePKZAmPPaKO_gzeg@mail.gmail.com>
 <CAOazyz0Q6m6gbtThu2G8LLyQQ3mnLn_Uexpi+=BxwWKeRUmBQw@mail.gmail.com>
 <8736snt3kn.fsf@fsij.org>
 <CAOazyz3jgK5efBZL1BvFWAGnXRgtr22tRNq3-=WLiGMNk0+JFQ@mail.gmail.com>
 <87d0rqod6v.fsf@fsij.org>
 <CAOazyz1qPw021tq+FNbtLQCQj_oNvDwSnOaPb6=UkByxFLgaNA@mail.gmail.com>
 <CAOazyz19XD7CJm_BTO3HgWiGHB8FhtGOrf1yo+-acNCQ-dmVYw@mail.gmail.com>
 <87mupoiu2v.fsf@fifthhorseman.net> <87k1krh8dq.fsf@fsij.org>
 <CAOazyz0-Ovb_sLk8NUKUDQeLc7203EacgCL4qF6XoDz_6BR5FQ@mail.gmail.com>
 <87y397jyxr.fsf@fsij.org>
 <CAOazyz2Bd0v6wrBgavQU3yf_rumsLYvHQztUCnEB+j-u-BRfkg@mail.gmail.com>
 <87efaxhhue.fsf@wheatstone.g10code.de>
 <CAOazyz2NDOmXyB4t-mGF=rfcsYOJOiSb+2TvvX-fXGF5xyLwAg@mail.gmail.com>
 <b66bb3224667155e03f2dc5fff2dfee8dbc010b4.camel@googlemail.com>
 <CAOazyz2e1XM2OnUTVm_d3j5Udcr_gQj8P34d3TfApH58joKuCg@mail.gmail.com>
 <1433ef08cb67d6c6db2591c83a4b593ea2f633db.camel@googlemail.com>
Message-ID: <87pnuew3w9.fsf@iwagami.gniibe.org>

Hello,

Dirk Gottschalk <dirk.gottschalk1980 at googlemail.com> wrote:
> On my fedora machine there are, for example, some
> wrapper scripts if you want to cross compile for mingw which set up the
> environment for configure, cmake and various other build systems.

Right.

The questions are: how such a setup can be maintained, possibly cleanly.

Released versions of (old) GnuPG and GnuPG libraries require tweaks
which is GnuPG specific, by --with-<library-specific>-config options or
SYSROOT environment variable.  From viewpoint of the current best
practice of cross build, I think, both could be considered not ideal,
because it is application specific, and the method uses command for
cross-target under cross-target directory, only works in a specific
use case, etc.

And... cross build is common these days.  That's because mainly, it's
common that a system supports both of 32-bit and 64-bit environments.
Speaking about GNU systems, there are two different flavors, multiarch
support and multilib support.  For example, the former uses
/lib/i386-linux-gnu and /lib/x86_64-linux-gnu, the latter uses /lib and
/lib64.

New version of GnuPG and GnuPG libraries, which is currently in master
branch, introduces new method, by a single script named gpgrt-config.
By this script, for building GnuPG, we don't need any application
specific tweaks any more.  We can just supply --host=${HOST} to
configure invocation, which perfectly follows the current best practice
of cross build, I suppose.

It is unfortunate that we can't use pkg-config directly to achieve this
(yet).  It still has an application specific script, that is,
gpgrt-config.  But, no special tweak is required, because it is a script
which can be shared for all cross-targets, and it follows pkg-config
methodology (of using .pc files and its environment vars).

Perhaps, our changes are somewhat confusing.  While we introduce new
method, we keep old method as well.  So, old tweaks can still be valid
for both of old GnuPG and new GnuPG.  And old tweaks by existing
software which use GnuPG libraries are still valid with new GnuPG
libraries.

I'm sorry to say that we don't accept further changes for old method in
GnuPG libraries.  They keep staying there to keep supporting existing
software.  Please use new method instead, for improving cross-build,
or use pkg-config directly.

I'm sorry if our .pc files brought an illusion like... the perfect
victory of pkg-config for GnuPG build.  No, it's never our purpose, at
all.

I wish that our improvement makes cross-build easier for others, just
like it makes easier for us.


Happy Hacking,
-- 


From wk at gnupg.org  Fri Dec  7 17:36:38 2018
From: wk at gnupg.org (Werner Koch)
Date: Fri, 07 Dec 2018 17:36:38 +0100
Subject: Libgpg-error 1.33 released
Message-ID: <87efat70q1.fsf@wheatstone.g10code.de>

Hi!

I just released libgpg-error 1.33.  This is a helper library for all
GnuPG related software.  Noteworthy changes are:

 * New unified config script gpgrt-config which can now be used by all
   GnuPG related packages.

 * Support for ARC and arm64ilp32.

 * The log functions now sanitize strings printed with the "%s" format
   specifier.  All control characters are C-escaped in the output.
   Users of that function may want to remove their own escaping to
   avoid doubling of backslashes.

 * New fprintf style function to apply a custom filter for string
   arguments.

 * New function to compare version strings.

 * Interface changes relative to the 1.28 release:
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 gpgrt_cmp_version               New.
 gpgrt_string_filter_t           New.
 gpgrt_fprintf_sf                New.
 gpgrt_fprintf_sf_unlocked       New.
 gpgrt_ftruncate                 New but limited functionality.
 gpgrt_w32_override_locale       New.

 Please see https://dev.gnupg.org/T4205 in case of problems.



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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181207/9c7d1d40/attachment.sig>

From bogorodskiy at gmail.com  Sun Dec  9 10:08:21 2018
From: bogorodskiy at gmail.com (Roman Bogorodskiy)
Date: Sun,  9 Dec 2018 13:08:21 +0400
Subject: [PATCH libgpg-error] gpgrt-config: escape expr(1) operands
Message-ID: <20181209090821.86084-1-bogorodskiy@gmail.com>

With FreeBSD's expr(1), gpgrt-config prints the following:

$ PKG_CONFIG_LIBDIR=src ./src/gpgrt-config --libs
expr: illegal option -- L
expr: usage: expr [-e] expression

-L -lgpg-error
$

This happens because FreeBSD expr(1) makes no lexical distinction
between arguments which may be operators and arguments which
may be operands. [1]

To fix that, parenthesize values that could start with "-", as
suggested in the man page.

1: https://www.freebsd.org/cgi/man.cgi?query=expr&sektion=&n=1
---
 src/gpgrt-config | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Note: there are similar invocations of expr(1) in gpgrt-config which
potentially could cause the same problem. However, I didn't touch those
because wasn't able to trigger these errors.

diff --git a/src/gpgrt-config b/src/gpgrt-config
index 3a76869..23b5ac7 100755
--- a/src/gpgrt-config
+++ b/src/gpgrt-config
@@ -404,7 +404,7 @@ sysroot () {
 	    _result="$_result${_result:+ }$_opt"
 	    shift
 	    _result="$_result $PKG_CONFIG_SYSROOT_DIR$1"
-	elif expr "$1" : "^$_opt" >/dev/null; then
+	elif expr "\( $1 \)" : "^$_opt" >/dev/null; then
 	    _result="$_result${_result:+ }$_opt$PKG_CONFIG_SYSROOT_DIR$(expr "$1" : "^$_opt\(.*\)")"
 	else
 	    _result="$_result${_result:+ }$1"
-- 
2.19.1



From gniibe at fsij.org  Mon Dec 10 01:12:09 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 10 Dec 2018 09:12:09 +0900
Subject: [PATCH libgpg-error] gpgrt-config: escape expr(1) operands
In-Reply-To: <20181209090821.86084-1-bogorodskiy@gmail.com>
References: <20181209090821.86084-1-bogorodskiy@gmail.com>
Message-ID: <8736r6utnq.fsf@iwagami.gniibe.org>

Roman Bogorodskiy <bogorodskiy at gmail.com> wrote:
> With FreeBSD's expr(1), gpgrt-config prints the following:
[...]
> This happens because FreeBSD expr(1) makes no lexical distinction
> between arguments which may be operators and arguments which
> may be operands. [1]
>
> To fix that, parenthesize values that could start with "-", as
> suggested in the man page.

Thank you.

> --- a/src/gpgrt-config
> +++ b/src/gpgrt-config
> @@ -404,7 +404,7 @@ sysroot () {
>  	    _result="$_result${_result:+ }$_opt"
>  	    shift
>  	    _result="$_result $PKG_CONFIG_SYSROOT_DIR$1"
> -	elif expr "$1" : "^$_opt" >/dev/null; then
> +	elif expr "\( $1 \)" : "^$_opt" >/dev/null; then

Here, the expression is to match string of $1 against $_opt.  IIUC,
while this fix indeed escapes $1, I'm afraid it changes the semantics.

I fix it in a different way, by adding "x" to the expression.  I also
fix another portability problem of expr.
-- 


From tomi.leppanen at jolla.com  Mon Dec 10 15:50:03 2018
From: tomi.leppanen at jolla.com (=?UTF-8?q?Tomi=20Lepp=C3=A4nen?=)
Date: Mon, 10 Dec 2018 16:50:03 +0200
Subject: [PATCH 0/1] Allow Busybox find
Message-ID: <20181210145004.5612-1-tomi.leppanen@jolla.com>

This adds a patch that changes addgnupghome script to use POSIX compatible
arguments for find. Busybox doesn't support the GNU extensions it used to use
and we at Mer would like to support Busybox as well.

Tomi Lepp?nen (1):
  scripts: Use POSIX compatible arguments for find

 tools/addgnupghome | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.19.2



From tomi.leppanen at jolla.com  Mon Dec 10 15:50:04 2018
From: tomi.leppanen at jolla.com (=?UTF-8?q?Tomi=20Lepp=C3=A4nen?=)
Date: Mon, 10 Dec 2018 16:50:04 +0200
Subject: [PATCH 1/1] scripts: Use POSIX compatible arguments for find
In-Reply-To: <20181210145004.5612-1-tomi.leppanen@jolla.com>
References: <20181210145004.5612-1-tomi.leppanen@jolla.com>
Message-ID: <20181210145004.5612-2-tomi.leppanen@jolla.com>

Some versions of find do not support -or or -not arguments but use -o
and ! arguments instead.

Signed-off-by: Tomi Lepp?nen <tomi.leppanen at jolla.com>
---
 tools/addgnupghome | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/addgnupghome b/tools/addgnupghome
index e13c3cd01..718b2226c 100755
--- a/tools/addgnupghome
+++ b/tools/addgnupghome
@@ -107,7 +107,7 @@ if [ ! -d /etc/skel/.gnupg ]; then
     exit 1
 fi
 cd "/etc/skel/.gnupg" || (error "error cd-ing to \`/etc/skel/.gnupg'"; exit 1)
-filelist=$(find . \( -type f -or -type d \) -not -name '*~' -not -name . -print)
+filelist=$(find . \( -type f -o -type d \) '!' -name '*~' '!' -name . -print)
 
 
 if ! umask 0077 ; then
-- 
2.19.2



From tomi.leppanen at jolla.com  Mon Dec 10 17:13:16 2018
From: tomi.leppanen at jolla.com (=?UTF-8?Q?Tomi_Lepp=c3=a4nen?=)
Date: Mon, 10 Dec 2018 18:13:16 +0200
Subject: [PATCH 0/1] Allow Busybox find
In-Reply-To: <20181210145004.5612-1-tomi.leppanen@jolla.com>
References: <20181210145004.5612-1-tomi.leppanen@jolla.com>
Message-ID: <c29d982a-2111-1638-3e4e-79db43e99ed7@jolla.com>

Btw, this patch is from gnupg2 packaging in mer-core for which I made it 
some time ago:
https://git.merproject.org/mer-core/iproute/blob/f8210f68c9b31c8390df617bace5a7aa650b0032/rpm/iproute2-use-busybox-compatible-arguments-for-find.patch

Mentioning this in case it's somehow important.

Tomi Lepp?nen kirjoitti 10.12.2018 klo 16.50:
> This adds a patch that changes addgnupghome script to use POSIX compatible
> arguments for find. Busybox doesn't support the GNU extensions it used to use
> and we at Mer would like to support Busybox as well.
>
> Tomi Lepp?nen (1):
>    scripts: Use POSIX compatible arguments for find
>
>   tools/addgnupghome | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>


From Alistair.Francis at wdc.com  Mon Dec 10 18:34:29 2018
From: Alistair.Francis at wdc.com (Alistair Francis)
Date: Mon, 10 Dec 2018 17:34:29 +0000
Subject: [PATCH Libgpg-error] syscfg: Add a riscv32 architecture
Message-ID: <20181210173421.26907-1-alistair.francis@wdc.com>

* src/syscfg/lock-obj-pub.riscv32-unknown-linux-gnu.h: New.
* src/Makefile.am (lock_obj_pub): Add it.

Signed-off-by: Alistair Francis <alistair.francis at wdc.com>
Signed-off-by: pino-kim <sungwon.pino at gmail.com>
---
 src/Makefile.am                               |  1 +
 .../lock-obj-pub.riscv32-unknown-linux-gnu.h  | 23 +++++++++++++++++++
 2 files changed, 24 insertions(+)
 create mode 100644 src/syscfg/lock-obj-pub.riscv32-unknown-linux-gnu.h

diff --git a/src/Makefile.am b/src/Makefile.am
index 8e6683f..ce1b882 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -67,6 +67,7 @@ lock_obj_pub = \
 	syscfg/lock-obj-pub.powerpc64le-unknown-linux-gnu.h \
 	syscfg/lock-obj-pub.powerpc-unknown-linux-gnuspe.h  \
 	syscfg/lock-obj-pub.riscv64-unknown-linux-gnu.h     \
+	syscfg/lock-obj-pub.riscv32-unknown-linux-gnu.h     \
         syscfg/lock-obj-pub.s390x-unknown-linux-gnu.h       \
         syscfg/lock-obj-pub.sh3-unknown-linux-gnu.h         \
         syscfg/lock-obj-pub.sh4-unknown-linux-gnu.h         \
diff --git a/src/syscfg/lock-obj-pub.riscv32-unknown-linux-gnu.h b/src/syscfg/lock-obj-pub.riscv32-unknown-linux-gnu.h
new file mode 100644
index 0000000..b5bdaf5
--- /dev/null
+++ b/src/syscfg/lock-obj-pub.riscv32-unknown-linux-gnu.h
@@ -0,0 +1,23 @@
+## lock-obj-pub.riscv32-unknown-linux-gnu.h
+## File created by gen-posix-lock-obj - DO NOT EDIT
+## To be included by mkheader into gpg-error.h
+
+typedef struct
+{
+  long _vers;
+  union {
+    volatile char _priv[24];
+    long _x_align;
+    long *_xp_align;
+  } u;
+} gpgrt_lock_t;
+
+#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \
+                                    0,0,0,0,0,0,0,0, \
+                                    0,0,0,0,0,0,0,0}}}
+##
+## Local Variables:
+## mode: c
+## buffer-read-only: t
+## End:
+##
-- 
2.19.1



From gniibe at fsij.org  Tue Dec 11 06:01:37 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 11 Dec 2018 14:01:37 +0900
Subject: [PATCH Libgpg-error] syscfg: Add a riscv32 architecture
In-Reply-To: <20181210173421.26907-1-alistair.francis@wdc.com>
References: <20181210173421.26907-1-alistair.francis@wdc.com>
Message-ID: <87k1kgejwu.fsf@iwagami.gniibe.org>

Alistair Francis <Alistair.Francis at wdc.com> wrote:
> * src/syscfg/lock-obj-pub.riscv32-unknown-linux-gnu.h: New.
> * src/Makefile.am (lock_obj_pub): Add it.

Thanks.  Applied.
-- 


From wk at gnupg.org  Tue Dec 11 08:47:52 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 11 Dec 2018 08:47:52 +0100
Subject: [PATCH 0/1] Allow Busybox find
In-Reply-To: <20181210145004.5612-1-tomi.leppanen@jolla.com> ("Tomi
 =?utf-8?Q?Lepp=C3=A4nen=22's?= message of "Mon, 10 Dec 2018 16:50:03
 +0200")
References: <20181210145004.5612-1-tomi.leppanen@jolla.com>
Message-ID: <87k1kgijx3.fsf@wheatstone.g10code.de>

On Mon, 10 Dec 2018 15:50, tomi.leppanen at jolla.com said:
> This adds a patch that changes addgnupghome script to use POSIX compatible
> arguments for find. Busybox doesn't support the GNU extensions it used to use
> and we at Mer would like to support Busybox as well.

Thanks.  Applied to master and 2.2.  I was not aware that that tools was
actually in use and, yes, we should walsy make sure that things are
POSIX compliant.

Salam-Shalom,

   Werner


p.s.
Is there a chance that the next Sailfish release will have 2.2?

-- 
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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181211/f6814379/attachment.sig>

From Alistair.Francis at wdc.com  Tue Dec 11 18:43:05 2018
From: Alistair.Francis at wdc.com (Alistair Francis)
Date: Tue, 11 Dec 2018 17:43:05 +0000
Subject: [PATCH Libgpg-error] syscfg: Add a riscv32 architecture
In-Reply-To: <87k1kgejwu.fsf@iwagami.gniibe.org>
References: <20181210173421.26907-1-alistair.francis@wdc.com>
 <87k1kgejwu.fsf@iwagami.gniibe.org>
Message-ID: <1029407712356ec3acca63f6151c1124207adc75.camel@wdc.com>

On Tue, 2018-12-11 at 14:01 +0900, NIIBE Yutaka wrote:
> Alistair Francis <Alistair.Francis at wdc.com> wrote:
> > * src/syscfg/lock-obj-pub.riscv32-unknown-linux-gnu.h: New.
> > * src/Makefile.am (lock_obj_pub): Add it.
> 
> Thanks.  Applied.

Thanks! It looks like we just missed the 1.33 release. Do you have an
idea when the 1.34 release will be out?

Alistair


From wk at gnupg.org  Fri Dec 14 16:00:14 2018
From: wk at gnupg.org (Werner Koch)
Date: Fri, 14 Dec 2018 16:00:14 +0100
Subject: [Announce] GnuPG 2.2.12 released
Message-ID: <8736r0dugx.fsf@wheatstone.g10code.de>

Hello!

We are pleased to announce the availability of a new GnuPG release:
version 2.2.12.  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.12
====================================

  * tools: New commands --install-key and --remove-key for
    gpg-wks-client.  This allows to prepare a Web Key Directory on a
    local file system for later upload to a web server.

  * gpg: New --list-option "show-only-fpr-mbox".  This makes the use
    of the new gpg-wks-client --install-key command easier on Windows.

  * gpg: Improve processing speed when --skip-verify is used.

  * gpg: Fix a bug where a LF was accidentally written to the console.

  * gpg: --card-status now shwos whether a card has the new KDF
    feature enabled.

  * agent: New runtime option --s2k-calibration=MSEC.  New configure
    option --with-agent-s2k-calibration=MSEC.
    [https://dev.gnupg.org/T3399]

  * dirmngr: Try another keyserver from the pool on receiving a 502,
    503, or 504 error.  [https://dev.gnupg.org/T4175]

  * dirmngr: Avoid possible CSRF attacks via http redirects.  A HTTP
    query will not anymore follow a 3xx redirect unless the Location
    header gives the same host.  If the host is different only the
    host and port is taken from the Location header and the original
    path and query parts are kept.

  * dirmngr: New command FLUSHCRL to flush all CRLS from disk and
    memory.  [https://dev.gnupg.org/T3967]

  * New simplified Chinese translation (zh_CN).

  Release-info: https://dev.gnupg.org/T4289


Getting the Software
====================

Please follow the instructions found at <https://gnupg.org/download/> or
read on:

GnuPG 2.2.12 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
<https://gnupg.org/download/mirrors.html>.  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.12.tar.bz2 (6525k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.12.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.12_20181214.exe (3965k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.12_20181214.exe.sig

The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix.


Checking the Integrity
======================

In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:

 * If you already have a version of GnuPG installed, you can simply
   verify the supplied signature.  For example to verify the signature
   of the file gnupg-2.2.12.tar.bz2 you would use this command:

     gpg --verify gnupg-2.2.12.tar.bz2.sig gnupg-2.2.12.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.12.tar.bz2, you run the command like this:

     sha1sum gnupg-2.2.12.tar.bz2

   and check that the output matches the next line:

2aeccc35ea8034306ff7a1072b84abbaa79619c3  gnupg-2.2.12.tar.bz2
304785d6db3d490265f8638ec3fb7340050b58bd  gnupg-w32-2.2.12_20181214.tar.xz
8efed66ebfe68bae3069f7d1724c8b4b9de0b00b  gnupg-w32-2.2.12_20181214.exe


Internationalization
====================

This version of GnuPG has support for 26 languages with Chinese
(traditional and simplified), 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.

In case of build problems specific to this release please first check
https://dev.gnupg.org/T4289 for updated information.

Please consult the archive of the gnupg-users mailing list before
reporting a bug: <https://gnupg.org/documentation/mailing-lists.html>.
We suggest to send bug reports for a new release to this list in favor
of filing a bug at <https://bugs.gnupg.org>.  If you need commercial
support check out <https://gnupg.org/service.html>.

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 two
contractors.  All work exclusively on GnuPG and closely related software
like Libgcrypt and GPGME.

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) <dshaw 'at' jabberwocky.com>

  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) <gniibe 'at' fsij.org>

  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 <https://gnupg.org/signature_key.html> and
in any recently released GnuPG tarball in the file g10/distsigkey.gpg .
Note that this mail has been signed by a different key.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181214/24bb1c5b/attachment-0001.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From fsantiago at deviltracks.net  Sat Dec 15 22:18:30 2018
From: fsantiago at deviltracks.net (=?utf-8?q?fsantiago=40deviltracks=2Enet?=)
Date: Sat, 15 Dec 2018 16:18:30 -0500
Subject: Setting up =?utf-8?q?wks=2F?= error parsing submission email
Message-ID: <1bf7-5c156f80-3-329e9540@84984237>


Hi,

I?m setting up (or trying to) wks on my email server, which is Ubuntu 18.04 using postfix / dovecot with procmail. I think I?m close but keep getting an error in my procmail output when I test it from another machine using the command line client test noted in the GnuPG docs. The 2nd machine is also Ubuntu but using its stock gpg (older rev as you can see in the log output below). The email server has been setup with the current gpg as noted in the instructions:
?
gpg-wks-server: gpg: public key is 79080E479BBBDB96
gpg-wks-server: gpg: WARNING: server 'gpg-agent' is older than us (2.2.4 < 2.2.9)
gpg-wks-server: gpg: Note: Outdated servers may lack important security fixes.
gpg-wks-server: gpg: Note: Use the command "gpgconf --kill all" to restart them.
gpg-wks-server: gpg: using subkey 79080E479BBBDB96 instead of primary key 2FEB4BBFE6F2B8FD
gpg-wks-server: gpg: public key is FAD6496868B818DD
gpg-wks-server: gpg: encrypted with RSA key, ID FAD6496868B818DD
gpg-wks-server: gpg: using subkey 79080E479BBBDB96 instead of primary key 2FEB4BBFE6F2B8FD
gpg-wks-server: gpg: encrypted with 3072-bit RSA key, ID 79080E479BBBDB96, created 2018-12-14
gpg-wks-server: gpg: ??????"key-submission at deviltracks.net"
gpg-wks-server: gpg: AES256 encrypted data
gpg-wks-server: gpg: uncompressing failed: Unknown compression algorithm
gpg-wks-server: error running '/home/webkey/bin/gpg': exit status 2
gpg-wks-server: decryption failed: General error
gpg-wks-server: draft version 2 requested
gpg-wks-server: parsing decrypted message
gpg-wks-server: no suitable data found in the message
gpg-wks-server: command failed: No data

i followed the GnuPG wikis / doc webpages?for this setup. I can?t get past this last error. Any ideas? Thanks.?

- Fabian S.
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181215/f0b95f81/attachment.html>

From patrick at enigmail.net  Sun Dec 16 11:40:30 2018
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Sun, 16 Dec 2018 11:40:30 +0100
Subject: Web Key Directory - HTTP Redirect?
Message-ID: <8f1b963f-0546-e726-1f52-9213bde1db72@enigmail.net>

When a client does Key Discovery using the Web Key Directory, should it
follow HTTP Redirects (HTTP Status 302) or is that not foreseen?



-Patrick

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181216/58b7543c/attachment.sig>

From wiktor at metacode.biz  Mon Dec 17 21:09:34 2018
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Mon, 17 Dec 2018 21:09:34 +0100
Subject: Web Key Directory - HTTP Redirect?
In-Reply-To: <8f1b963f-0546-e726-1f52-9213bde1db72@enigmail.net>
References: <8f1b963f-0546-e726-1f52-9213bde1db72@enigmail.net>
Message-ID: <b1913155-237d-9cfb-8568-040c59b418f2@metacode.biz>

On 16.12.2018 11:40, Patrick Brunschwig wrote:
> When a client does Key Discovery using the Web Key Directory, should it
> follow HTTP Redirects (HTTP Status 302) or is that not foreseen?

Hi Patrick, I've asked that question some time ago [0] and the answer was
"redirects should be followed".

[0]: https://lists.gt.net/gnupg/devel/83924#83924

There are some restrictions implemented recently for the Location header:
https://dev.gnupg.org/rGfa1b1eaa4241ff3f0634c8bdf8591cbc7c464144

This page gives more details:
https://www.sektioneins.de/en/advisories/advisory-012018-gnupg-wkd.html

(as a side note it's interesting because this "CRSF" in GnuPG would not send any
cookies and the attack described in the advisory shows rather an issue with the
receiving app, not GnuPG... but that's a side note...)

Kind regards,
Wiktor

-- 
https://metacode.biz/@wiktor


From dkg at fifthhorseman.net  Mon Dec 17 20:56:48 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 17 Dec 2018 14:56:48 -0500
Subject: Setting up wks/ error parsing submission email
In-Reply-To: <1bf7-5c156f80-3-329e9540@84984237>
References: <1bf7-5c156f80-3-329e9540@84984237>
Message-ID: <87bm5kylj3.fsf@fifthhorseman.net>

On Sat 2018-12-15 16:18:30 -0500, fsantiago at deviltracks.net wrote:

> I?m setting up (or trying to) wks on my email server, which is Ubuntu
> 18.04 using postfix / dovecot with procmail. I think I?m close but
> keep getting an error in my procmail output when I test it from
> another machine using the command line client test noted in the GnuPG
> docs. The 2nd machine is also Ubuntu but using its stock gpg (older
> rev as you can see in the log output below). The email server has been
> setup with the current gpg as noted in the instructions:

It looks to me like you're mixing versions of gpg -- one is the stock
version shipping in ubuntu, and the other is some slightly-more-recent
(but not fully current) locally-built copy (the one in
/home/webkey/bin/gpg).

have you tried just installing the gpg-wks-server package directly in
ubuntu, rather than trying to build your own local copy?

> gpg-wks-server: gpg: uncompressing failed: Unknown compression algorithm
> gpg-wks-server: error running '/home/webkey/bin/gpg': exit status 2

this looks like your self-built copy of gpg doesn't enable the expected
compression algorithm.

can you compare the output of:

    gpg --version | grep ^Compression:

against:

    /home/webkey/bin/gpg --version | grep ^Compression:

?

that might help to understand some of what's going on at least.

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181217/56e8fe7e/attachment-0001.sig>

From wk at gnupg.org  Tue Dec 18 08:09:10 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 18 Dec 2018 08:09:10 +0100
Subject: Web Key Directory - HTTP Redirect?
In-Reply-To: <b1913155-237d-9cfb-8568-040c59b418f2@metacode.biz> (Wiktor
 Kwapisiewicz via Gnupg-devel's message of "Mon, 17 Dec 2018 21:09:34
 +0100")
References: <8f1b963f-0546-e726-1f52-9213bde1db72@enigmail.net>
 <b1913155-237d-9cfb-8568-040c59b418f2@metacode.biz>
Message-ID: <87ftuv9uqx.fsf@wheatstone.g10code.de>

On Mon, 17 Dec 2018 21:09, gnupg-devel at gnupg.org said:

> There are some restrictions implemented recently for the Location header:
> https://dev.gnupg.org/rGfa1b1eaa4241ff3f0634c8bdf8591cbc7c464144

Which are: If the host part of the new URL is identical to the original
one the entire new URL is used.  If the host part differs only the new
host part is used and the path and query parameters of the original URL
are kept.

It might be possible to relax this insofar that certain transformations
of the path parameter are still allowed; in particular to allow a
redirection from say,

  https://example.org/.well-known/openpgpkey/FOO 

to

  https://openpgpkey.example.org/.well-known/openpgpkey/examample.org/FOO 

  (different host and path but a well-known path structure)

to it easier to migrate to the new advanced scheme.  But this adds some
complexity and will not cover all cases.  I have doubts that this makes
sense.

> (as a side note it's interesting because this "CRSF" in GnuPG would not send any
> cookies and the attack described in the advisory shows rather an issue with the
> receiving app, not GnuPG... but that's a side note...)

The example they give is that in the internal network you have an server
which controls, say, a chemical plant.  That server has only IP based
authentication and allows to open all kind of valves just be a HTTP
request.  Someone inside of example.org sends a mail to an outsider and
the MUA automatically encrypts to that outsider.  In the course of that
a http request is sent to the outsider's domain and that replies with a
302 and a malicious Location header.  bang.  A bit far-fetched, but we
better inhibit this.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181218/49eef6bc/attachment.sig>

From wk at gnupg.org  Tue Dec 18 08:13:38 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 18 Dec 2018 08:13:38 +0100
Subject: Setting up wks/ error parsing submission email
In-Reply-To: <87bm5kylj3.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message
 of "Mon, 17 Dec 2018 14:56:48 -0500")
References: <1bf7-5c156f80-3-329e9540@84984237>
 <87bm5kylj3.fsf@fifthhorseman.net>
Message-ID: <87bm5j9ujh.fsf@wheatstone.g10code.de>

On Mon, 17 Dec 2018 20:56, dkg at fifthhorseman.net said:

> this looks like your self-built copy of gpg doesn't enable the expected
> compression algorithm.

Indeed.  We can easily make this more robust by disabling compression -
the data is anyway small.  Different compression algorithms are pretty
common because these are implemented by external libraries - in contrast
to the cipher algos which are from Libgcrypt and that library is always
required.


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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181218/172ddede/attachment.sig>

From wk at gnupg.org  Tue Dec 18 09:15:29 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 18 Dec 2018 09:15:29 +0100
Subject: [PATCH Libgpg-error] syscfg: Add a riscv32 architecture
In-Reply-To: <1029407712356ec3acca63f6151c1124207adc75.camel@wdc.com>
 (Alistair Francis's message of "Tue, 11 Dec 2018 17:43:05 +0000")
References: <20181210173421.26907-1-alistair.francis@wdc.com>
 <87k1kgejwu.fsf@iwagami.gniibe.org>
 <1029407712356ec3acca63f6151c1124207adc75.camel@wdc.com>
Message-ID: <877eg79roe.fsf@wheatstone.g10code.de>

On Tue, 11 Dec 2018 18:43, Alistair.Francis at wdc.com said:

> Thanks! It looks like we just missed the 1.33 release. Do you have an
> idea when the 1.34 release will be out?

We can do a new release in early January.  Ist that okay for you?


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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181218/62b45cfa/attachment.sig>

From wiktor at metacode.biz  Tue Dec 18 10:03:50 2018
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Tue, 18 Dec 2018 10:03:50 +0100
Subject: Web Key Directory - HTTP Redirect?
In-Reply-To: <87ftuv9uqx.fsf@wheatstone.g10code.de>
References: <8f1b963f-0546-e726-1f52-9213bde1db72@enigmail.net>
 <b1913155-237d-9cfb-8568-040c59b418f2@metacode.biz>
 <87ftuv9uqx.fsf@wheatstone.g10code.de>
Message-ID: <0eb8defc-bb85-cdf1-9f82-9fafce2146b7@metacode.biz>

On 18.12.2018 08:09, Werner Koch wrote:
> The example they give is that in the internal network you have an server
> which controls, say, a chemical plant.  That server has only IP based
> authentication and allows to open all kind of valves just be a HTTP
> request.  Someone inside of example.org sends a mail to an outsider and
> the MUA automatically encrypts to that outsider.  In the course of that
> a http request is sent to the outsider's domain and that replies with a
> 302 and a malicious Location header.  bang.  A bit far-fetched, but we
> better inhibit this.

Yes, agreed, especially that the change doesn't break common redirects (like
bare domain to "www" subdomain etc.)

Still the "has only IP based authentication" problem strikes me as extremely
easy to mount anyway without GnuPG e.g. by embedding <img
src="http://internal/launch-nukes?confirm=yes"> in a webpage or in an e-mail.

Thanks for taking the time to explain the attack!

Kind regards,
Wiktor

-- 
https://metacode.biz/@wiktor


From fsantiago at deviltracks.net  Tue Dec 18 23:38:12 2018
From: fsantiago at deviltracks.net (Fabian A. Santiago)
Date: Tue, 18 Dec 2018 17:38:12 -0500
Subject: Setting up wks/ error parsing submission email
In-Reply-To: <87bm5kylj3.fsf@fifthhorseman.net>
References: <1bf7-5c156f80-3-329e9540@84984237>
 <87bm5kylj3.fsf@fifthhorseman.net>
Message-ID: <2431a6bdc67f18f81a8394a47ac425a1@deviltracks.net>

On 2018-12-17 14:56, Daniel Kahn Gillmor wrote:
> On Sat 2018-12-15 16:18:30 -0500, fsantiago at deviltracks.net wrote:
> 
>> I?m setting up (or trying to) wks on my email server, which is Ubuntu
>> 18.04 using postfix / dovecot with procmail. I think I?m close but
>> keep getting an error in my procmail output when I test it from
>> another machine using the command line client test noted in the GnuPG
>> docs. The 2nd machine is also Ubuntu but using its stock gpg (older
>> rev as you can see in the log output below). The email server has been
>> setup with the current gpg as noted in the instructions:
> 
> It looks to me like you're mixing versions of gpg -- one is the stock
> version shipping in ubuntu, and the other is some slightly-more-recent
> (but not fully current) locally-built copy (the one in
> /home/webkey/bin/gpg).
> 
> have you tried just installing the gpg-wks-server package directly in
> ubuntu, rather than trying to build your own local copy?
> 
>> gpg-wks-server: gpg: uncompressing failed: Unknown compression 
>> algorithm
>> gpg-wks-server: error running '/home/webkey/bin/gpg': exit status 2
> 
> this looks like your self-built copy of gpg doesn't enable the expected
> compression algorithm.
> 
> can you compare the output of:
> 
>     gpg --version | grep ^Compression:
> 
> against:
> 
>     /home/webkey/bin/gpg --version | grep ^Compression:
> 
> ?
> 
> that might help to understand some of what's going on at least.
> 
>      --dkg

that's probably it:

root at mail:~# gpg --version | grep ^Compression:
Compression: Uncompressed, ZIP, ZLIB, BZIP2
root at mail:~# /home/webkey/bin/gpg --version | grep ^Compression:
Compression: Uncompressed


so this was produced following the online instructions for setting up 
WKS (as far as building your own current gpg). should i not do that? or 
what can i do to enable or disable compression? Thanks for your help.

-- 
--

Thanks,

Fabian S.

OpenPGP:  0xE05BF5EEFDD6549DAD3EDF64AE4E3D03B4F2DF29


From wk at gnupg.org  Wed Dec 19 09:40:40 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 19 Dec 2018 09:40:40 +0100
Subject: Setting up wks/ error parsing submission email
In-Reply-To: <2431a6bdc67f18f81a8394a47ac425a1@deviltracks.net> (Fabian
 A. Santiago's message of "Tue, 18 Dec 2018 17:38:12 -0500")
References: <1bf7-5c156f80-3-329e9540@84984237>
 <87bm5kylj3.fsf@fifthhorseman.net>
 <2431a6bdc67f18f81a8394a47ac425a1@deviltracks.net>
Message-ID: <87k1k5rjsn.fsf@wheatstone.g10code.de>

On Tue, 18 Dec 2018 23:38, fsantiago at deviltracks.net said:

> so this was produced following the online instructions for setting up
> WKS (as far as building your own current gpg). should i not do that?
> or what can i do to enable or disable compression? Thanks for your

The configure scripts detects whether the required libs are available and
depending on this includes support for these compression algorithms.  IF
you created the encryption key for the server using that very version
everything should be fine.  It might be easiest to simply create a new
key using the version w/o the compression support.

Or you build again but first install the packages /zlibg1-dev/ and
/libbz2-dev/.  If you build using the speedo Makefile copies of those
libearies should have been downloaded and used during the speedo build
process.


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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181219/431b1877/attachment.sig>

From fsantiago at deviltracks.net  Wed Dec 19 14:49:42 2018
From: fsantiago at deviltracks.net (Fabian A. Santiago)
Date: Wed, 19 Dec 2018 08:49:42 -0500
Subject: Setting up wks/ error parsing submission email
In-Reply-To: <87k1k5rjsn.fsf@wheatstone.g10code.de>
References: <1bf7-5c156f80-3-329e9540@84984237>
 <87bm5kylj3.fsf@fifthhorseman.net>
 <2431a6bdc67f18f81a8394a47ac425a1@deviltracks.net>
 <87k1k5rjsn.fsf@wheatstone.g10code.de>
Message-ID: <a228d3e54e5cbc291543576efebf1e41@deviltracks.net>

On 2018-12-19 03:40, Werner Koch wrote:
> On Tue, 18 Dec 2018 23:38, fsantiago at deviltracks.net said:
> 
>> so this was produced following the online instructions for setting up
>> WKS (as far as building your own current gpg). should i not do that?
>> or what can i do to enable or disable compression? Thanks for your
> 
> The configure scripts detects whether the required libs are available 
> and
> depending on this includes support for these compression algorithms.  
> IF
> you created the encryption key for the server using that very version
> everything should be fine.  It might be easiest to simply create a new
> key using the version w/o the compression support.
> 
> Or you build again but first install the packages /zlibg1-dev/ and
> /libbz2-dev/.  If you build using the speedo Makefile copies of those
> libearies should have been downloaded and used during the speedo build
> process.
> 
> 
> Salam-Shalom,
> 
>    Werner

i did use speedo....so?


-- 
--

Thanks,

Fabian S.

OpenPGP:  0xE05BF5EEFDD6549DAD3EDF64AE4E3D03B4F2DF29


From fsantiago at deviltracks.net  Wed Dec 19 16:29:01 2018
From: fsantiago at deviltracks.net (Fabian A. Santiago)
Date: Wed, 19 Dec 2018 10:29:01 -0500
Subject: Setting up wks/ error parsing submission email
In-Reply-To: <a228d3e54e5cbc291543576efebf1e41@deviltracks.net>
References: <1bf7-5c156f80-3-329e9540@84984237>
 <87bm5kylj3.fsf@fifthhorseman.net>
 <2431a6bdc67f18f81a8394a47ac425a1@deviltracks.net>
 <87k1k5rjsn.fsf@wheatstone.g10code.de>
 <a228d3e54e5cbc291543576efebf1e41@deviltracks.net>
Message-ID: <1c9dc7701b48f22757d7040c6a796497@deviltracks.net>

On 2018-12-19 08:49, Fabian A. Santiago wrote:
> On 2018-12-19 03:40, Werner Koch wrote:
>> On Tue, 18 Dec 2018 23:38, fsantiago at deviltracks.net said:
>> 
>>> so this was produced following the online instructions for setting up
>>> WKS (as far as building your own current gpg). should i not do that?
>>> or what can i do to enable or disable compression? Thanks for your
>> 
>> The configure scripts detects whether the required libs are available 
>> and
>> depending on this includes support for these compression algorithms.  
>> IF
>> you created the encryption key for the server using that very version
>> everything should be fine.  It might be easiest to simply create a new
>> key using the version w/o the compression support.
>> 
>> Or you build again but first install the packages /zlibg1-dev/ and
>> /libbz2-dev/.  If you build using the speedo Makefile copies of those
>> libearies should have been downloaded and used during the speedo build
>> process.
>> 
>> 
>> Salam-Shalom,
>> 
>>    Werner
> 
> i did use speedo....so?

ok, so i edited my procmailrc file to use the system's own version of 
gpg-wks-server and now it parses the test email but is awaiting a 
confirmation and since i tested it from the command line and with an 
invalid address I'm not sure how to give it the confirmation it seeks. i 
did receive it's confirmation email to my catchall inbox but unsure 
where to go from here to continue testing it without simply using a 
legitimate key and email client. how do i pass it the confirmation it 
seeks via command line? Thanks.
-- 
--

Thanks,

Fabian S.

OpenPGP:  0xE05BF5EEFDD6549DAD3EDF64AE4E3D03B4F2DF29


From fsantiago at deviltracks.net  Wed Dec 19 20:55:47 2018
From: fsantiago at deviltracks.net (Fabian A. Santiago)
Date: Wed, 19 Dec 2018 14:55:47 -0500
Subject: Setting up wks/ error parsing submission email
In-Reply-To: <1c9dc7701b48f22757d7040c6a796497@deviltracks.net>
References: <1bf7-5c156f80-3-329e9540@84984237>
 <87bm5kylj3.fsf@fifthhorseman.net>
 <2431a6bdc67f18f81a8394a47ac425a1@deviltracks.net>
 <87k1k5rjsn.fsf@wheatstone.g10code.de>
 <a228d3e54e5cbc291543576efebf1e41@deviltracks.net>
 <1c9dc7701b48f22757d7040c6a796497@deviltracks.net>
Message-ID: <39441660d2f385e841d3c8b837c63cb9@deviltracks.net>

On 2018-12-19 10:29, Fabian A. Santiago wrote:
> On 2018-12-19 08:49, Fabian A. Santiago wrote:
>> On 2018-12-19 03:40, Werner Koch wrote:
>>> On Tue, 18 Dec 2018 23:38, fsantiago at deviltracks.net said:
>>> 
>>>> so this was produced following the online instructions for setting 
>>>> up
>>>> WKS (as far as building your own current gpg). should i not do that?
>>>> or what can i do to enable or disable compression? Thanks for your
>>> 
>>> The configure scripts detects whether the required libs are available 
>>> and
>>> depending on this includes support for these compression algorithms.  
>>> IF
>>> you created the encryption key for the server using that very version
>>> everything should be fine.  It might be easiest to simply create a 
>>> new
>>> key using the version w/o the compression support.
>>> 
>>> Or you build again but first install the packages /zlibg1-dev/ and
>>> /libbz2-dev/.  If you build using the speedo Makefile copies of those
>>> libearies should have been downloaded and used during the speedo 
>>> build
>>> process.
>>> 
>>> 
>>> Salam-Shalom,
>>> 
>>>    Werner
>> 
>> i did use speedo....so?
> 
> ok, so i edited my procmailrc file to use the system's own version of
> gpg-wks-server and now it parses the test email but is awaiting a
> confirmation and since i tested it from the command line and with an
> invalid address I'm not sure how to give it the confirmation it seeks.
> i did receive it's confirmation email to my catchall inbox but unsure
> where to go from here to continue testing it without simply using a
> legitimate key and email client. how do i pass it the confirmation it
> seeks via command line? Thanks.

so i've switched to using the gnupg built into my system and can get as 
far as receiving the confirmation email as previously stated. when i use 
the command line client to process this confirmation (I think, unless 
i've misunderstood something), i get:

root at deviltracks:~# /usr/lib/gnupg/gpg-wks-client --receive --send < 
sample2.txt
gpg-wks-client: t2body for level 0
gpg-wks-client: t2body for level 1
gpg-wks-client: t2body for level 2
gpg-wks-client: t2body for level 2
gpg-wks-client: new 'application/vnd.gnupg.wks' message part
gpg-wks-client: t2body for level 1
gpg-wks-client: gpg: Signature made Wed Dec 19 14:52:36 2018 EST
gpg-wks-client: gpg:                using RSA key 
A6E176009FC6EBE8537D4FB72FEB4BBFE6F2B8FD
gpg-wks-client: gpg:                issuer 
"key-submission at deviltracks.net"
gpg-wks-client: gpg: Good signature from 
"key-submission at deviltracks.net" [unknown]
gpg-wks-client: gpg: WARNING: Using untrusted key!
gpg-wks-client: DBG: Fixme: Verification result is not used
gpg-wks-client: wkd data found
gpg-wks-client: draft version 2 requested
gpg-wks-client: gpg: decryption failed: No secret key
gpg-wks-client: error running '/usr/bin/gpg': exit status 2
gpg-wks-client: decryption failed: General error
gpg-wks-client: decryption failed: General error
gpg-wks-client: processing mail failed: General error

I feel like i must likely be doing something wrong but i'm unsure where 
to go from here. thanks for your help everyone.

-- 
--

Thanks,

Fabian S.

OpenPGP:  0xE05BF5EEFDD6549DAD3EDF64AE4E3D03B4F2DF29


From dkg at fifthhorseman.net  Thu Dec 20 00:29:56 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 19 Dec 2018 18:29:56 -0500
Subject: Setting up wks/ error parsing submission email
In-Reply-To: <2431a6bdc67f18f81a8394a47ac425a1@deviltracks.net>
References: <1bf7-5c156f80-3-329e9540@84984237>
 <87bm5kylj3.fsf@fifthhorseman.net>
 <2431a6bdc67f18f81a8394a47ac425a1@deviltracks.net>
Message-ID: <87k1k5xfgr.fsf@fifthhorseman.net>

On Tue 2018-12-18 17:38:12 -0500, Fabian A. Santiago wrote:
> so this was produced following the online instructions for setting up 
> WKS (as far as building your own current gpg). should i not do that? or 
> what can i do to enable or disable compression? Thanks for your help.

unless you have a plan in place for maintaining and upgrading your own
GnuPG installation, i recommend sticking with your distro's version of
GnuPG.  it is a non-trivial amount of work.  (full disclaimer, i'm one
of the people who works on maintaining GnuPG in debian)

   --dkg


From fsantiago at deviltracks.net  Thu Dec 20 15:47:30 2018
From: fsantiago at deviltracks.net (Fabian A. Santiago)
Date: Thu, 20 Dec 2018 09:47:30 -0500
Subject: Setting up wks/ error parsing submission email
In-Reply-To: <87k1k5xfgr.fsf@fifthhorseman.net>
References: <1bf7-5c156f80-3-329e9540@84984237>
 <87bm5kylj3.fsf@fifthhorseman.net>
 <2431a6bdc67f18f81a8394a47ac425a1@deviltracks.net>
 <87k1k5xfgr.fsf@fifthhorseman.net>
Message-ID: <b01f0e35fe30f1d53b04ae64f28ea870@deviltracks.net>

On 2018-12-19 18:29, Daniel Kahn Gillmor wrote:
> On Tue 2018-12-18 17:38:12 -0500, Fabian A. Santiago wrote:
>> so this was produced following the online instructions for setting up
>> WKS (as far as building your own current gpg). should i not do that? 
>> or
>> what can i do to enable or disable compression? Thanks for your help.
> 
> unless you have a plan in place for maintaining and upgrading your own
> GnuPG installation, i recommend sticking with your distro's version of
> GnuPG.  it is a non-trivial amount of work.  (full disclaimer, i'm one
> of the people who works on maintaining GnuPG in debian)
> 
>    --dkg

alright, so as i think i stated before, i'm currently stuck here:

/usr/lib/gnupg/gpg-wks-client --receive --send < sample2.txt
gpg-wks-client: t2body for level 0
gpg-wks-client: t2body for level 1
gpg-wks-client: t2body for level 2
gpg-wks-client: t2body for level 2
gpg-wks-client: new 'application/vnd.gnupg.wks' message part
gpg-wks-client: t2body for level 1
gpg-wks-client: gpg: Signature made Thu Dec 20 09:41:21 2018 EST
gpg-wks-client: gpg:                using RSA key 
672DC8471CEA6025761161FE05C53C82C753F2B6
gpg-wks-client: gpg:                issuer 
"key-submission at deviltracks.net"
gpg-wks-client: gpg: Good signature from 
"key-submission at deviltracks.net" [unknown]
gpg-wks-client: gpg: WARNING: Using untrusted key!
gpg-wks-client: DBG: Fixme: Verification result is not used
gpg-wks-client: wkd data found
gpg-wks-client: draft version 2 requested
gpg-wks-client: gpg: decryption failed: No secret key
gpg-wks-client: error running '/usr/bin/gpg': exit status 2
gpg-wks-client: decryption failed: General error
gpg-wks-client: decryption failed: General error
gpg-wks-client: processing mail failed: General error

this is me trying to feed in the email confirmation via command line to 
the client. no secret key? and I've now since reverted to using my 
distro's default gpg version. thanks.

-- 
--

Thanks,

Fabian S.

OpenPGP:  0xE05BF5EEFDD6549DAD3EDF64AE4E3D03B4F2DF29


From dkg at fifthhorseman.net  Thu Dec 20 20:36:53 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 20 Dec 2018 14:36:53 -0500
Subject: Setting up wks/ error parsing submission email
In-Reply-To: <b01f0e35fe30f1d53b04ae64f28ea870@deviltracks.net>
References: <1bf7-5c156f80-3-329e9540@84984237>
 <87bm5kylj3.fsf@fifthhorseman.net>
 <2431a6bdc67f18f81a8394a47ac425a1@deviltracks.net>
 <87k1k5xfgr.fsf@fifthhorseman.net>
 <b01f0e35fe30f1d53b04ae64f28ea870@deviltracks.net>
Message-ID: <87woo4vvl6.fsf@fifthhorseman.net>

On Thu 2018-12-20 09:47:30 -0500, Fabian A. Santiago wrote:
> /usr/lib/gnupg/gpg-wks-client --receive --send < sample2.txt
> gpg-wks-client: t2body for level 0
> gpg-wks-client: t2body for level 1
> gpg-wks-client: t2body for level 2
> gpg-wks-client: t2body for level 2
> gpg-wks-client: new 'application/vnd.gnupg.wks' message part
> gpg-wks-client: t2body for level 1
> gpg-wks-client: gpg: Signature made Thu Dec 20 09:41:21 2018 EST
> gpg-wks-client: gpg:                using RSA key  672DC8471CEA6025761161FE05C53C82C753F2B6
> gpg-wks-client: gpg:                issuer "key-submission at deviltracks.net"
> gpg-wks-client: gpg: Good signature from "key-submission at deviltracks.net" [unknown]
> gpg-wks-client: gpg: WARNING: Using untrusted key!
> gpg-wks-client: DBG: Fixme: Verification result is not used
> gpg-wks-client: wkd data found
> gpg-wks-client: draft version 2 requested
> gpg-wks-client: gpg: decryption failed: No secret key
> gpg-wks-client: error running '/usr/bin/gpg': exit status 2
> gpg-wks-client: decryption failed: General error
> gpg-wks-client: decryption failed: General error
> gpg-wks-client: processing mail failed: General error
>
> this is me trying to feed in the email confirmation via command line to 
> the client. no secret key? and I've now since reverted to using my 
> distro's default gpg version. thanks.

Can you report more info about sample2.txt, or share it here?  I would
want to know what its internal structure looks like, if possible, and to
know whether the key(s?) that its inner part is encrypted to are keys
that you have listed when you run gpg --list-secret-keys .

Also, what version is your local gpg where you're running
gpg-wks-client?  Is it possible that you're mixing gpg 2.1.x and gpg
1.4.x on your local system?

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181220/62a94ab4/attachment-0001.sig>

From fsantiago at deviltracks.net  Thu Dec 20 20:58:33 2018
From: fsantiago at deviltracks.net (Fabian A. Santiago)
Date: Thu, 20 Dec 2018 14:58:33 -0500
Subject: Setting up wks/ error parsing submission email
In-Reply-To: <87woo4vvl6.fsf@fifthhorseman.net>
References: <1bf7-5c156f80-3-329e9540@84984237>
 <87bm5kylj3.fsf@fifthhorseman.net>
 <2431a6bdc67f18f81a8394a47ac425a1@deviltracks.net>
 <87k1k5xfgr.fsf@fifthhorseman.net>
 <b01f0e35fe30f1d53b04ae64f28ea870@deviltracks.net>
 <87woo4vvl6.fsf@fifthhorseman.net>
Message-ID: <83952c9925c5bbe7d29ed2fc4ed13706@deviltracks.net>

On 2018-12-20 14:36, Daniel Kahn Gillmor wrote:
> On Thu 2018-12-20 09:47:30 -0500, Fabian A. Santiago wrote:
>> /usr/lib/gnupg/gpg-wks-client --receive --send < sample2.txt
>> gpg-wks-client: t2body for level 0
>> gpg-wks-client: t2body for level 1
>> gpg-wks-client: t2body for level 2
>> gpg-wks-client: t2body for level 2
>> gpg-wks-client: new 'application/vnd.gnupg.wks' message part
>> gpg-wks-client: t2body for level 1
>> gpg-wks-client: gpg: Signature made Thu Dec 20 09:41:21 2018 EST
>> gpg-wks-client: gpg:                using RSA key  
>> 672DC8471CEA6025761161FE05C53C82C753F2B6
>> gpg-wks-client: gpg:                issuer 
>> "key-submission at deviltracks.net"
>> gpg-wks-client: gpg: Good signature from 
>> "key-submission at deviltracks.net" [unknown]
>> gpg-wks-client: gpg: WARNING: Using untrusted key!
>> gpg-wks-client: DBG: Fixme: Verification result is not used
>> gpg-wks-client: wkd data found
>> gpg-wks-client: draft version 2 requested
>> gpg-wks-client: gpg: decryption failed: No secret key
>> gpg-wks-client: error running '/usr/bin/gpg': exit status 2
>> gpg-wks-client: decryption failed: General error
>> gpg-wks-client: decryption failed: General error
>> gpg-wks-client: processing mail failed: General error
>> 
>> this is me trying to feed in the email confirmation via command line 
>> to
>> the client. no secret key? and I've now since reverted to using my
>> distro's default gpg version. thanks.
> 
> Can you report more info about sample2.txt, or share it here?  I would
> want to know what its internal structure looks like, if possible, and 
> to
> know whether the key(s?) that its inner part is encrypted to are keys
> that you have listed when you run gpg --list-secret-keys .
> 
> Also, what version is your local gpg where you're running
> gpg-wks-client?  Is it possible that you're mixing gpg 2.1.x and gpg
> 1.4.x on your local system?
> 
>         --dkg

sure,

gpg --version:

gpg (GnuPG) 2.2.4
libgcrypt 1.8.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /root/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
         CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

***

root at mail:~# /usr/lib/gnupg/gpg-wks-client --version
gpg-wks-client (GnuPG) 2.2.4
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

***

and see my attached sample.txt (which is the confirmation email received 
when submitting a new key).
-- 
--

Thanks,

Fabian S.

OpenPGP:  0xE05BF5EEFDD6549DAD3EDF64AE4E3D03B4F2DF29
-------------- next part --------------
An embedded message was scrubbed...
From: key-submission at deviltracks.net
Subject: Confirm your key publication
Date: Thu, 20 Dec 2018 14:41:21 +0000
Size: 3569
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181220/92d2f39a/attachment.mht>

From dkg at fifthhorseman.net  Thu Dec 20 21:08:13 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 20 Dec 2018 15:08:13 -0500
Subject: Setting up wks/ error parsing submission email
In-Reply-To: <83952c9925c5bbe7d29ed2fc4ed13706@deviltracks.net>
References: <1bf7-5c156f80-3-329e9540@84984237>
 <87bm5kylj3.fsf@fifthhorseman.net>
 <2431a6bdc67f18f81a8394a47ac425a1@deviltracks.net>
 <87k1k5xfgr.fsf@fifthhorseman.net>
 <b01f0e35fe30f1d53b04ae64f28ea870@deviltracks.net>
 <87woo4vvl6.fsf@fifthhorseman.net>
 <83952c9925c5bbe7d29ed2fc4ed13706@deviltracks.net>
Message-ID: <87o99gvu4y.fsf@fifthhorseman.net>

On Thu 2018-12-20 14:58:33 -0500, Fabian A. Santiago wrote:
> gpg --version:
>
> gpg (GnuPG) 2.2.4
 [?]
>
> Home: /root/.gnupg

This looks like you're running it as root.

> root at mail:~# /usr/lib/gnupg/gpg-wks-client --version
> gpg-wks-client (GnuPG) 2.2.4
> Copyright (C) 2017 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> <https://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> ***
>
> and see my attached sample.txt (which is the confirmation email received 
> when submitting a new key).

thanks!  that shows that the message is encrypted to the public key with
keyid 0xFAD6496868B818DD.  are you running gpg-wks-client as root as
well?  does root control the secret key for this e-mail address
test123 at deviltracks.net?

what is the output of:

    gpg --list-secret-keys 0xFAD6496868B818DD

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181220/c2cc3b7c/attachment.sig>

From fsantiago at deviltracks.net  Thu Dec 20 21:38:04 2018
From: fsantiago at deviltracks.net (Fabian A. Santiago)
Date: Thu, 20 Dec 2018 15:38:04 -0500
Subject: Setting up wks/ error parsing submission email
In-Reply-To: <87o99gvu4y.fsf@fifthhorseman.net>
References: <1bf7-5c156f80-3-329e9540@84984237>
 <87bm5kylj3.fsf@fifthhorseman.net>
 <2431a6bdc67f18f81a8394a47ac425a1@deviltracks.net>
 <87k1k5xfgr.fsf@fifthhorseman.net>
 <b01f0e35fe30f1d53b04ae64f28ea870@deviltracks.net>
 <87woo4vvl6.fsf@fifthhorseman.net>
 <83952c9925c5bbe7d29ed2fc4ed13706@deviltracks.net>
 <87o99gvu4y.fsf@fifthhorseman.net>
Message-ID: <d72d68d25e3fdbacc3ec118114342927@deviltracks.net>

On 2018-12-20 15:08, Daniel Kahn Gillmor wrote:
> On Thu 2018-12-20 14:58:33 -0500, Fabian A. Santiago wrote:
>> gpg --version:
>> 
>> gpg (GnuPG) 2.2.4
>  [?]
>> 
>> Home: /root/.gnupg
> 
> This looks like you're running it as root.
> 
>> root at mail:~# /usr/lib/gnupg/gpg-wks-client --version
>> gpg-wks-client (GnuPG) 2.2.4
>> Copyright (C) 2017 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> <https://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
>> 
>> ***
>> 
>> and see my attached sample.txt (which is the confirmation email 
>> received
>> when submitting a new key).
> 
> thanks!  that shows that the message is encrypted to the public key 
> with
> keyid 0xFAD6496868B818DD.  are you running gpg-wks-client as root as
> well?  does root control the secret key for this e-mail address
> test123 at deviltracks.net?
> 
> what is the output of:
> 
>     gpg --list-secret-keys 0xFAD6496868B818DD
> 
>         --dkg

output of your requested command:

sec   rsa3072 2018-12-14 [SC] [expires: 2020-12-13]
       89CFCD21743DBDD5EB5ABC973879E79EC3420092
uid           [ultimate] test123 <test123 at deviltracks.net>
ssb   rsa3072 2018-12-14 [E] [expires: 2020-12-13]


yes i am (running as root). this is from the "client" PC submitting the 
key itself. on the email server side this is all being processed as a 
local user / not root.

-- 
--

Thanks,

Fabian S.

OpenPGP:  0xE05BF5EEFDD6549DAD3EDF64AE4E3D03B4F2DF29


From dkg at fifthhorseman.net  Thu Dec 20 22:19:57 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 20 Dec 2018 16:19:57 -0500
Subject: Setting up wks/ error parsing submission email
In-Reply-To: <d72d68d25e3fdbacc3ec118114342927@deviltracks.net>
References: <1bf7-5c156f80-3-329e9540@84984237>
 <87bm5kylj3.fsf@fifthhorseman.net>
 <2431a6bdc67f18f81a8394a47ac425a1@deviltracks.net>
 <87k1k5xfgr.fsf@fifthhorseman.net>
 <b01f0e35fe30f1d53b04ae64f28ea870@deviltracks.net>
 <87woo4vvl6.fsf@fifthhorseman.net>
 <83952c9925c5bbe7d29ed2fc4ed13706@deviltracks.net>
 <87o99gvu4y.fsf@fifthhorseman.net>
 <d72d68d25e3fdbacc3ec118114342927@deviltracks.net>
Message-ID: <87d0pvx5du.fsf@fifthhorseman.net>

On Thu 2018-12-20 15:38:04 -0500, Fabian A. Santiago wrote:
> On 2018-12-20 15:08, Daniel Kahn Gillmor wrote:
>> what is the output of:
>> 
>>     gpg --list-secret-keys 0xFAD6496868B818DD
>
> output of your requested command:
>
> sec   rsa3072 2018-12-14 [SC] [expires: 2020-12-13]
>        89CFCD21743DBDD5EB5ABC973879E79EC3420092
> uid           [ultimate] test123 <test123 at deviltracks.net>
> ssb   rsa3072 2018-12-14 [E] [expires: 2020-12-13]
>
>
> yes i am (running as root). this is from the "client" PC submitting the 
> key itself. on the email server side this is all being processed as a 
> local user / not root.

It's a little bit odd for the root user to be running a local e-mail
account.  i'm fine to continue debugging like this, but i would
generally advise you to only check (and interact with) mail from a
non-root account.

I'm perplexed.  I don't know how to square that with your earlier report
of:

    /usr/lib/gnupg/gpg-wks-client --receive --send < sample2.txt
    gpg-wks-client: t2body for level 0
    gpg-wks-client: t2body for level 1
    gpg-wks-client: t2body for level 2
    gpg-wks-client: t2body for level 2
    gpg-wks-client: new 'application/vnd.gnupg.wks' message part
    gpg-wks-client: t2body for level 1
    gpg-wks-client: gpg: Signature made Thu Dec 20 09:41:21 2018 EST
    gpg-wks-client: gpg:                using RSA key 672DC8471CEA6025761161FE05C53C82C753F2B6
    gpg-wks-client: gpg:                issuer "key-submission at deviltracks.net"
    gpg-wks-client: gpg: Good signature from "key-submission at deviltracks.net" [unknown]
    gpg-wks-client: gpg: WARNING: Using untrusted key!
    gpg-wks-client: DBG: Fixme: Verification result is not used
    gpg-wks-client: wkd data found
    gpg-wks-client: draft version 2 requested
    gpg-wks-client: gpg: decryption failed: No secret key
    gpg-wks-client: error running '/usr/bin/gpg': exit status 2
    gpg-wks-client: decryption failed: General error
    gpg-wks-client: decryption failed: General error
    gpg-wks-client: processing mail failed: General error

Can you try to extract text from the application/vnd.gnupg.wks part of
sample2.txt -- starting at the "BEGIN PGP MESSAGE" line and going
through the "END PGP MESSAGE" line (inclusive!) -- and save it to a file
ciphertext.wks ?  Then do:

    gpg --output cleartext.wks --decrypt ciphertext.wks

does that work?  If not, are there specific errors?  full transcripts
(including the commands run, shell prompts, error messages, etc) are
always helpful.

Sorry to not have any clearer answers for you immediately.

If you're up for giving me an account on the system i can try to
replicate the problem you're describing and see whether i can make it
happen myself.  Feel free to mail me offlist about credentials if that's
the case.

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181220/12b5f0f7/attachment.sig>

From fsantiago at deviltracks.net  Thu Dec 20 22:35:43 2018
From: fsantiago at deviltracks.net (Fabian A. Santiago)
Date: Thu, 20 Dec 2018 16:35:43 -0500
Subject: Setting up wks/ error parsing submission email
In-Reply-To: <87d0pvx5du.fsf@fifthhorseman.net>
References: <1bf7-5c156f80-3-329e9540@84984237>
 <87bm5kylj3.fsf@fifthhorseman.net>
 <2431a6bdc67f18f81a8394a47ac425a1@deviltracks.net>
 <87k1k5xfgr.fsf@fifthhorseman.net>
 <b01f0e35fe30f1d53b04ae64f28ea870@deviltracks.net>
 <87woo4vvl6.fsf@fifthhorseman.net>
 <83952c9925c5bbe7d29ed2fc4ed13706@deviltracks.net>
 <87o99gvu4y.fsf@fifthhorseman.net>
 <d72d68d25e3fdbacc3ec118114342927@deviltracks.net>
 <87d0pvx5du.fsf@fifthhorseman.net>
Message-ID: <72f70f2f3f18eb908be624b766b1a91d@deviltracks.net>

On 2018-12-20 16:19, Daniel Kahn Gillmor wrote:
> On Thu 2018-12-20 15:38:04 -0500, Fabian A. Santiago wrote:
>> On 2018-12-20 15:08, Daniel Kahn Gillmor wrote:
>>> what is the output of:
>>> 
>>>     gpg --list-secret-keys 0xFAD6496868B818DD
>> 
>> output of your requested command:
>> 
>> sec   rsa3072 2018-12-14 [SC] [expires: 2020-12-13]
>>        89CFCD21743DBDD5EB5ABC973879E79EC3420092
>> uid           [ultimate] test123 <test123 at deviltracks.net>
>> ssb   rsa3072 2018-12-14 [E] [expires: 2020-12-13]
>> 
>> 
>> yes i am (running as root). this is from the "client" PC submitting 
>> the
>> key itself. on the email server side this is all being processed as a
>> local user / not root.
> 
> It's a little bit odd for the root user to be running a local e-mail
> account.  i'm fine to continue debugging like this, but i would
> generally advise you to only check (and interact with) mail from a
> non-root account.
> 
> I'm perplexed.  I don't know how to square that with your earlier 
> report
> of:
> 
>     /usr/lib/gnupg/gpg-wks-client --receive --send < sample2.txt
>     gpg-wks-client: t2body for level 0
>     gpg-wks-client: t2body for level 1
>     gpg-wks-client: t2body for level 2
>     gpg-wks-client: t2body for level 2
>     gpg-wks-client: new 'application/vnd.gnupg.wks' message part
>     gpg-wks-client: t2body for level 1
>     gpg-wks-client: gpg: Signature made Thu Dec 20 09:41:21 2018 EST
>     gpg-wks-client: gpg:                using RSA key
> 672DC8471CEA6025761161FE05C53C82C753F2B6
>     gpg-wks-client: gpg:                issuer 
> "key-submission at deviltracks.net"
>     gpg-wks-client: gpg: Good signature from
> "key-submission at deviltracks.net" [unknown]
>     gpg-wks-client: gpg: WARNING: Using untrusted key!
>     gpg-wks-client: DBG: Fixme: Verification result is not used
>     gpg-wks-client: wkd data found
>     gpg-wks-client: draft version 2 requested
>     gpg-wks-client: gpg: decryption failed: No secret key
>     gpg-wks-client: error running '/usr/bin/gpg': exit status 2
>     gpg-wks-client: decryption failed: General error
>     gpg-wks-client: decryption failed: General error
>     gpg-wks-client: processing mail failed: General error
> 
> Can you try to extract text from the application/vnd.gnupg.wks part of
> sample2.txt -- starting at the "BEGIN PGP MESSAGE" line and going
> through the "END PGP MESSAGE" line (inclusive!) -- and save it to a 
> file
> ciphertext.wks ?  Then do:
> 
>     gpg --output cleartext.wks --decrypt ciphertext.wks
> 
> does that work?  If not, are there specific errors?  full transcripts
> (including the commands run, shell prompts, error messages, etc) are
> always helpful.
> 
> Sorry to not have any clearer answers for you immediately.
> 
> If you're up for giving me an account on the system i can try to
> replicate the problem you're describing and see whether i can make it
> happen myself.  Feel free to mail me offlist about credentials if 
> that's
> the case.
> 
>         --dkg

here you go:

root at deviltracks:~# /usr/lib/gnupg/gpg-wks-client --receive --send < 
pgp_snippet.txt
gpg-wks-client: t2body for level 0
gpg-wks-client: processing mail failed: Unexpected message


that doesn't seem to work when i cut out just the pgp message portion. 
also see attached snippet file.

i understand about the root thing. in production root isn't used.

as for you having an account, would you be needing it on the test 
"client", email server, or both? i will contact you later after i'm off 
my day job and we can set something up if you wish. i should also state 
this is by no means critical. i'm just experimenting for my own personal 
use. so any help is greatly appreciated and i don't really mind how long 
it takes.

-- 
--

Thanks,

Fabian S.

OpenPGP:  0xE05BF5EEFDD6549DAD3EDF64AE4E3D03B4F2DF29
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp_snippet.txt
Type: application/pgp
Size: 921 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181220/259392d9/attachment-0001.bin>

From dkg at fifthhorseman.net  Thu Dec 20 22:42:40 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 20 Dec 2018 16:42:40 -0500
Subject: Setting up wks/ error parsing submission email
In-Reply-To: <72f70f2f3f18eb908be624b766b1a91d@deviltracks.net>
References: <1bf7-5c156f80-3-329e9540@84984237>
 <87bm5kylj3.fsf@fifthhorseman.net>
 <2431a6bdc67f18f81a8394a47ac425a1@deviltracks.net>
 <87k1k5xfgr.fsf@fifthhorseman.net>
 <b01f0e35fe30f1d53b04ae64f28ea870@deviltracks.net>
 <87woo4vvl6.fsf@fifthhorseman.net>
 <83952c9925c5bbe7d29ed2fc4ed13706@deviltracks.net>
 <87o99gvu4y.fsf@fifthhorseman.net>
 <d72d68d25e3fdbacc3ec118114342927@deviltracks.net>
 <87d0pvx5du.fsf@fifthhorseman.net>
 <72f70f2f3f18eb908be624b766b1a91d@deviltracks.net>
Message-ID: <87a7kzx4bz.fsf@fifthhorseman.net>

On Thu 2018-12-20 16:35:43 -0500, Fabian A. Santiago wrote:
> On 2018-12-20 16:19, Daniel Kahn Gillmor wrote:
>> save it to a file ciphertext.wks ?  Then do:
>> 
>>     gpg --output cleartext.wks --decrypt ciphertext.wks
 [?]
> here you go:
>
> root at deviltracks:~# /usr/lib/gnupg/gpg-wks-client --receive --send < 
> pgp_snippet.txt
> gpg-wks-client: t2body for level 0
> gpg-wks-client: processing mail failed: Unexpected message

this isn't the command i was trying to ask you to run.  can you try the
original suggestion?

> as for you having an account, would you be needing it on the test 
> "client", email server, or both? i will contact you later after i'm off 
> my day job and we can set something up if you wish. i should also state 
> this is by no means critical. i'm just experimenting for my own personal 
> use. so any help is greatly appreciated and i don't really mind how long 
> it takes.

It would just be an e-mail account on that mailserver.  if you've gotten
the gpg-wks-server side of things sorted, then i ought to be able to use
the tools from my side to register a key.

your work in debugging this publicly will likely help other people who
stumble into whatever this problem is in the future and end up reading
the archives.  so thanks for your persistence!

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181220/7bd8d6c3/attachment.sig>

From fsantiago at deviltracks.net  Thu Dec 20 22:47:46 2018
From: fsantiago at deviltracks.net (Fabian A. Santiago)
Date: Thu, 20 Dec 2018 16:47:46 -0500
Subject: Setting up wks/ error parsing submission email
In-Reply-To: <87a7kzx4bz.fsf@fifthhorseman.net>
References: <1bf7-5c156f80-3-329e9540@84984237>
 <87bm5kylj3.fsf@fifthhorseman.net>
 <2431a6bdc67f18f81a8394a47ac425a1@deviltracks.net>
 <87k1k5xfgr.fsf@fifthhorseman.net>
 <b01f0e35fe30f1d53b04ae64f28ea870@deviltracks.net>
 <87woo4vvl6.fsf@fifthhorseman.net>
 <83952c9925c5bbe7d29ed2fc4ed13706@deviltracks.net>
 <87o99gvu4y.fsf@fifthhorseman.net>
 <d72d68d25e3fdbacc3ec118114342927@deviltracks.net>
 <87d0pvx5du.fsf@fifthhorseman.net>
 <72f70f2f3f18eb908be624b766b1a91d@deviltracks.net>
 <87a7kzx4bz.fsf@fifthhorseman.net>
Message-ID: <9b3a841cc0244a087b970aaa6064f9fb@deviltracks.net>

On 2018-12-20 16:42, Daniel Kahn Gillmor wrote:
> On Thu 2018-12-20 16:35:43 -0500, Fabian A. Santiago wrote:
>> On 2018-12-20 16:19, Daniel Kahn Gillmor wrote:
>>> save it to a file ciphertext.wks ?  Then do:
>>> 
>>>     gpg --output cleartext.wks --decrypt ciphertext.wks
>  [?]
>> here you go:
>> 
>> root at deviltracks:~# /usr/lib/gnupg/gpg-wks-client --receive --send <
>> pgp_snippet.txt
>> gpg-wks-client: t2body for level 0
>> gpg-wks-client: processing mail failed: Unexpected message
> 
> this isn't the command i was trying to ask you to run.  can you try the
> original suggestion?
> 
>> as for you having an account, would you be needing it on the test
>> "client", email server, or both? i will contact you later after i'm 
>> off
>> my day job and we can set something up if you wish. i should also 
>> state
>> this is by no means critical. i'm just experimenting for my own 
>> personal
>> use. so any help is greatly appreciated and i don't really mind how 
>> long
>> it takes.
> 
> It would just be an e-mail account on that mailserver.  if you've 
> gotten
> the gpg-wks-server side of things sorted, then i ought to be able to 
> use
> the tools from my side to register a key.
> 
> your work in debugging this publicly will likely help other people who
> stumble into whatever this problem is in the future and end up reading
> the archives.  so thanks for your persistence!
> 
>     --dkg
my apologies, i can be a bit of a tool sometimes. here you are:

root at deviltracks:~# gpg --output clear_snippet.txt --decrypt 
pgp_snippet.txt
gpg: encrypted with 3072-bit RSA key, ID FAD6496868B818DD, created 
2018-12-14
       "test123 <test123 at deviltracks.net>"

and the clear text is:

root at deviltracks:~# cat clear_snippet.txt
type: confirmation-request
sender: key-submission at deviltracks.net
address: test123 at deviltracks.net
fingerprint: 89CFCD21743DBDD5EB5ABC973879E79EC3420092
nonce: <redacted>

-- 
--

Thanks,

Fabian S.

OpenPGP:  0xE05BF5EEFDD6549DAD3EDF64AE4E3D03B4F2DF29


From dkg at fifthhorseman.net  Thu Dec 20 23:32:23 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 20 Dec 2018 17:32:23 -0500
Subject: Setting up wks/ error parsing submission email
In-Reply-To: <9b3a841cc0244a087b970aaa6064f9fb@deviltracks.net>
References: <1bf7-5c156f80-3-329e9540@84984237>
 <87bm5kylj3.fsf@fifthhorseman.net>
 <2431a6bdc67f18f81a8394a47ac425a1@deviltracks.net>
 <87k1k5xfgr.fsf@fifthhorseman.net>
 <b01f0e35fe30f1d53b04ae64f28ea870@deviltracks.net>
 <87woo4vvl6.fsf@fifthhorseman.net>
 <83952c9925c5bbe7d29ed2fc4ed13706@deviltracks.net>
 <87o99gvu4y.fsf@fifthhorseman.net>
 <d72d68d25e3fdbacc3ec118114342927@deviltracks.net>
 <87d0pvx5du.fsf@fifthhorseman.net>
 <72f70f2f3f18eb908be624b766b1a91d@deviltracks.net>
 <87a7kzx4bz.fsf@fifthhorseman.net>
 <9b3a841cc0244a087b970aaa6064f9fb@deviltracks.net>
Message-ID: <877eg3x214.fsf@fifthhorseman.net>

On Thu 2018-12-20 16:47:46 -0500, Fabian A. Santiago wrote:
> root at deviltracks:~# gpg --output clear_snippet.txt --decrypt  pgp_snippet.txt
> gpg: encrypted with 3072-bit RSA key, ID FAD6496868B818DD, created 2018-12-14
>        "test123 <test123 at deviltracks.net>"
>
> and the clear text is:
>
> root at deviltracks:~# cat clear_snippet.txt
> type: confirmation-request
> sender: key-submission at deviltracks.net
> address: test123 at deviltracks.net
> fingerprint: 89CFCD21743DBDD5EB5ABC973879E79EC3420092
> nonce: <redacted>

OK, so gpg is working fine, and the relevant secret key is available.
that's good!

But (i think) it narrows down the problem to your implemetation of
gpg-wks-client.

Perhaps Werner or someone more well-versed in WKD can weigh in here?
Without access to an environment to replicate the problem, i'm at a bit
of a dead end.

   --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181220/8cc5edd6/attachment.sig>

From smueller at chronox.de  Fri Dec 21 12:39:25 2018
From: smueller at chronox.de (Stephan Mueller)
Date: Fri, 21 Dec 2018 12:39:25 +0100
Subject: [RFC] Add group support to key management commands
Message-ID: <45455542.It0E639E8f@tauon.chronox.de>

Hi,

I am using KDE's kmail and rely heavily on the GPG group feature to encrypt 
emails to groups. The GPG support in kmail seems to have changed recently such 
that group support seems to be non-functional at this point.

After strace'ing kmail a bit, I found that the following command is executed 
to search for the recipient key.

gpg2 --batch --no-sk-comments --charset utf8 --enable-progress-filter --exit-
on-status-write-error --with-colons --list-keys -- <RECIPIENT>

When the recipient is a GPG group, this command is empty.

May I ask whether it is considered appropriate to add group support to this 
mechanism so that when recipient is a group, the command returns all members?

The attached patch would do that (note, the patch is for discussion - it does 
not link at the moment, because pkclist.c is not in libcommon.a. But if you 
manually copy the functions from pkclist.c to getkey.c, you see that the patch 
works).

Ciao
Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: expand_groups_list_keys.diff
Type: text/x-patch
Size: 2860 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181221/0d5357c0/attachment.bin>

From wk at gnupg.org  Fri Dec 21 14:23:39 2018
From: wk at gnupg.org (Werner Koch)
Date: Fri, 21 Dec 2018 14:23:39 +0100
Subject: Setting up wks/ error parsing submission email
In-Reply-To: <b01f0e35fe30f1d53b04ae64f28ea870@deviltracks.net> (Fabian
 A. Santiago's message of "Thu, 20 Dec 2018 09:47:30 -0500")
References: <1bf7-5c156f80-3-329e9540@84984237>
 <87bm5kylj3.fsf@fifthhorseman.net>
 <2431a6bdc67f18f81a8394a47ac425a1@deviltracks.net>
 <87k1k5xfgr.fsf@fifthhorseman.net>
 <b01f0e35fe30f1d53b04ae64f28ea870@deviltracks.net>
Message-ID: <87o99fm2sk.fsf@wheatstone.g10code.de>

On Thu, 20 Dec 2018 15:47, fsantiago at deviltracks.net said:

> /usr/lib/gnupg/gpg-wks-client --receive --send < sample2.txt

> gpg-wks-client: draft version 2 requested
> gpg-wks-client: gpg: decryption failed: No secret key
> gpg-wks-client: error running '/usr/bin/gpg': exit status 2
> gpg-wks-client: decryption failed: General error

Can you please add 

  --verbose --debug crypto

to the invocation.  This shows diagnostics from gpg and is better than
the General Error.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181221/b715fb50/attachment.sig>

From fsantiago at deviltracks.net  Fri Dec 21 15:18:00 2018
From: fsantiago at deviltracks.net (Fabian A. Santiago)
Date: Fri, 21 Dec 2018 09:18:00 -0500
Subject: Setting up wks/ error parsing submission email
In-Reply-To: <87o99fm2sk.fsf@wheatstone.g10code.de>
References: <1bf7-5c156f80-3-329e9540@84984237>
 <87bm5kylj3.fsf@fifthhorseman.net>
 <2431a6bdc67f18f81a8394a47ac425a1@deviltracks.net>
 <87k1k5xfgr.fsf@fifthhorseman.net>
 <b01f0e35fe30f1d53b04ae64f28ea870@deviltracks.net>
 <87o99fm2sk.fsf@wheatstone.g10code.de>
Message-ID: <bbf546c96eaeaec19b502162efba7942@deviltracks.net>

On 2018-12-21 08:23, Werner Koch wrote:
> On Thu, 20 Dec 2018 15:47, fsantiago at deviltracks.net said:
> 
>> /usr/lib/gnupg/gpg-wks-client --receive --send < sample2.txt
> 
>> gpg-wks-client: draft version 2 requested
>> gpg-wks-client: gpg: decryption failed: No secret key
>> gpg-wks-client: error running '/usr/bin/gpg': exit status 2
>> gpg-wks-client: decryption failed: General error
> 
> Can you please add
> 
>   --verbose --debug crypto
> 
> to the invocation.  This shows diagnostics from gpg and is better than
> the General Error.
> 
> 
> Shalom-Salam,
> 
>    Werner

ok,

here is your requested debug output:

webkey at mail:/var/vmail/procmail$ /usr/lib/gnupg/gpg-wks-client --verbose 
--debug crypto --receive --send < sample2.txt
gpg-wks-client: t2body for level 0
gpg-wks-client: t2body for level 1
gpg-wks-client: t2body for level 2
gpg-wks-client: t2body for level 2
gpg-wks-client: new 'application/vnd.gnupg.wks' message part
gpg-wks-client: t2body for level 1
gpg-wks-client: DBG: gpg status: NEWSIG key-submission at deviltracks.net
gpg-wks-client: gpg: Signature made Thu Dec 20 09:41:21 2018 EST
gpg-wks-client: gpg:                using RSA key 
672DC8471CEA6025761161FE05C53C82C753F2B6
gpg-wks-client: gpg:                issuer 
"key-submission at deviltracks.net"
gpg-wks-client: DBG: gpg status: KEY_CONSIDERED 
672DC8471CEA6025761161FE05C53C82C753F2B6 0
gpg-wks-client: DBG: gpg status: SIG_ID ofQS0AUZIFSt31WutH8lEdQ75Yk 
2018-12-20 1545316881
gpg-wks-client: DBG: gpg status: KEY_CONSIDERED 
672DC8471CEA6025761161FE05C53C82C753F2B6 0
gpg-wks-client: DBG: gpg status: GOODSIG 05C53C82C753F2B6 
key-submission at deviltracks.net
gpg-wks-client: gpg: Good signature from 
"key-submission at deviltracks.net" [unknown]
gpg-wks-client: DBG: gpg status: VALIDSIG 
672DC8471CEA6025761161FE05C53C82C753F2B6 2018-12-20 1545316881 0 4 0 1 
10 00 672DC8471CEA6025761161FE05C53C82C753F2B6
gpg-wks-client: gpg: WARNING: Using untrusted key!
gpg-wks-client: gpg: binary signature, digest algorithm SHA512, key 
algorithm rsa3072
gpg-wks-client: DBG: gpg status: VERIFICATION_COMPLIANCE_MODE 23
gpg-wks-client: DBG: Fixme: Verification result is not used
gpg-wks-client: wkd data found
gpg-wks-client: draft version 2 requested
gpg-wks-client: DBG: gpg status: ENC_TO FAD6496868B818DD 1 0
gpg-wks-client: gpg: encrypted with RSA key, ID FAD6496868B818DD
gpg-wks-client: DBG: gpg status: NO_SECKEY FAD6496868B818DD
gpg-wks-client: DBG: gpg status: BEGIN_DECRYPTION
gpg-wks-client: DBG: gpg status: DECRYPTION_FAILED
gpg-wks-client: gpg: decryption failed: No secret key
gpg-wks-client: DBG: gpg status: END_DECRYPTION
gpg-wks-client: error running '/usr/bin/gpg': exit status 2
gpg-wks-client: decryption failed: General error
gpg-wks-client: decryption failed: General error
gpg-wks-client: processing mail failed: General error


that key id mentioned as missing, "FAD6496868B818DD", is that of my 
test123 address from my client testbed. i would have assumed it would be 
encrypted to the key-submission address' key. am i wrong? is it so that 
i could also read the message in my sent folder so it's encrypted to 
both of us? i'm just thinking aloud. let me know what you think. thanks.
-- 
--

Thanks,

Fabian S.

OpenPGP:  0xE05BF5EEFDD6549DAD3EDF64AE4E3D03B4F2DF29


From uri at mit.edu  Fri Dec 21 15:18:23 2018
From: uri at mit.edu (Uri Blumenthal)
Date: Fri, 21 Dec 2018 14:18:23 +0000
Subject: [RFC] Add group support to key management commands
In-Reply-To: <45455542.It0E639E8f@tauon.chronox.de>
References: <45455542.It0E639E8f@tauon.chronox.de>
Message-ID: <B808644D-A7FD-4D8C-A648-039D7B4470B1@mit.edu>

I support this idea.

Sent from my test iPhone

> On Dec 21, 2018, at 07:50, Stephan Mueller <smueller at chronox.de> wrote:
> 
> Hi,
> 
> I am using KDE's kmail and rely heavily on the GPG group feature to encrypt 
> emails to groups. The GPG support in kmail seems to have changed recently such 
> that group support seems to be non-functional at this point.
> 
> After strace'ing kmail a bit, I found that the following command is executed 
> to search for the recipient key.
> 
> gpg2 --batch --no-sk-comments --charset utf8 --enable-progress-filter --exit-
> on-status-write-error --with-colons --list-keys -- <RECIPIENT>
> 
> When the recipient is a GPG group, this command is empty.
> 
> May I ask whether it is considered appropriate to add group support to this 
> mechanism so that when recipient is a group, the command returns all members?
> 
> The attached patch would do that (note, the patch is for discussion - it does 
> not link at the moment, because pkclist.c is not in libcommon.a. But if you 
> manually copy the functions from pkclist.c to getkey.c, you see that the patch 
> works).
> 
> Ciao
> Stephan
> <expand_groups_list_keys.diff>
> _______________________________________________
> 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: smime.p7s
Type: application/pkcs7-signature
Size: 2894 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181221/5c1a2b3d/attachment.bin>

From wk at gnupg.org  Sun Dec 23 11:59:21 2018
From: wk at gnupg.org (Werner Koch)
Date: Sun, 23 Dec 2018 11:59:21 +0100
Subject: Setting up wks/ error parsing submission email
In-Reply-To: <bbf546c96eaeaec19b502162efba7942@deviltracks.net> (Fabian
 A. Santiago's message of "Fri, 21 Dec 2018 09:18:00 -0500")
References: <1bf7-5c156f80-3-329e9540@84984237>
 <87bm5kylj3.fsf@fifthhorseman.net>
 <2431a6bdc67f18f81a8394a47ac425a1@deviltracks.net>
 <87k1k5xfgr.fsf@fifthhorseman.net>
 <b01f0e35fe30f1d53b04ae64f28ea870@deviltracks.net>
 <87o99fm2sk.fsf@wheatstone.g10code.de>
 <bbf546c96eaeaec19b502162efba7942@deviltracks.net>
Message-ID: <8736qomrue.fsf@wheatstone.g10code.de>

On Fri, 21 Dec 2018 15:18, fsantiago at deviltracks.net said:

> webkey at mail:/var/vmail/procmail$ /usr/lib/gnupg/gpg-wks-client
> --verbose --debug crypto --receive --send < sample2.txt

> gpg-wks-client: gpg: Good signature from
> "key-submission at deviltracks.net" [unknown]

The signature from the server.  The server signs the confirmation
request to allow the client to detect malicious requests before annoying
the user with a request to decrypt the challenge.  All good here.

> gpg-wks-client: DBG: gpg status: ENC_TO FAD6496868B818DD 1 0
> gpg-wks-client: gpg: encrypted with RSA key, ID FAD6496868B818DD

The encrypted challenge.  The client must be able to decrypt this to
confirm the publication requests he sent.

> gpg-wks-client: DBG: gpg status: NO_SECKEY FAD6496868B818DD

But for whatever reason the client does now own that private key.

> gpg-wks-client: error running '/usr/bin/gpg': exit status 2

Sure that this is the same gpg version you used to create the challenge?

> that key id mentioned as missing, "FAD6496868B818DD", is that of my
> test123 address from my client testbed. i would have assumed it would
> be encrypted to the key-submission address' key. am i wrong? is it so

No.  You encrypt your publication request to the submission address
key.  This is not required for the protocol but we want to encrypt as much
traffic as possible.

The server then encrypts to the key you want to have published.

> that i could also read the message in my sent folder so it's encrypted
> to both of us? i'm just thinking aloud. let me know what you

The server does not need to decrypt its own challenge again.


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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181223/e99901f7/attachment.sig>

From fsantiago at deviltracks.net  Wed Dec 26 16:12:44 2018
From: fsantiago at deviltracks.net (Fabian A. Santiago)
Date: Wed, 26 Dec 2018 10:12:44 -0500
Subject: Setting up wks/ error parsing submission email
In-Reply-To: <8736qomrue.fsf@wheatstone.g10code.de>
References: <1bf7-5c156f80-3-329e9540@84984237>
 <87bm5kylj3.fsf@fifthhorseman.net>
 <2431a6bdc67f18f81a8394a47ac425a1@deviltracks.net>
 <87k1k5xfgr.fsf@fifthhorseman.net>
 <b01f0e35fe30f1d53b04ae64f28ea870@deviltracks.net>
 <87o99fm2sk.fsf@wheatstone.g10code.de>
 <bbf546c96eaeaec19b502162efba7942@deviltracks.net>
 <8736qomrue.fsf@wheatstone.g10code.de>
Message-ID: <05682fa2f7c9d58311bf1ef05f1c7e0d@deviltracks.net>

On 2018-12-23 05:59, Werner Koch wrote:
> On Fri, 21 Dec 2018 15:18, fsantiago at deviltracks.net said:
> 
>> webkey at mail:/var/vmail/procmail$ /usr/lib/gnupg/gpg-wks-client
>> --verbose --debug crypto --receive --send < sample2.txt
> 
>> gpg-wks-client: gpg: Good signature from
>> "key-submission at deviltracks.net" [unknown]
> 
> The signature from the server.  The server signs the confirmation
> request to allow the client to detect malicious requests before 
> annoying
> the user with a request to decrypt the challenge.  All good here.
> 
>> gpg-wks-client: DBG: gpg status: ENC_TO FAD6496868B818DD 1 0
>> gpg-wks-client: gpg: encrypted with RSA key, ID FAD6496868B818DD
> 
> The encrypted challenge.  The client must be able to decrypt this to
> confirm the publication requests he sent.
> 
>> gpg-wks-client: DBG: gpg status: NO_SECKEY FAD6496868B818DD
> 
> But for whatever reason the client does now own that private key.
> 
>> gpg-wks-client: error running '/usr/bin/gpg': exit status 2
> 
> Sure that this is the same gpg version you used to create the 
> challenge?
> 
>> that key id mentioned as missing, "FAD6496868B818DD", is that of my
>> test123 address from my client testbed. i would have assumed it would
>> be encrypted to the key-submission address' key. am i wrong? is it so
> 
> No.  You encrypt your publication request to the submission address
> key.  This is not required for the protocol but we want to encrypt as 
> much
> traffic as possible.
> 
> The server then encrypts to the key you want to have published.
> 
>> that i could also read the message in my sent folder so it's encrypted
>> to both of us? i'm just thinking aloud. let me know what you
> 
> The server does not need to decrypt its own challenge again.
> 
> 
> Shalom-Salam,
> 
>    Werner

yes, confirmed same gpg version between both ends. thanks for the 
explanation.

-- 
--

Thanks,

Fabian S.

OpenPGP:  0xE05BF5EEFDD6549DAD3EDF64AE4E3D03B4F2DF29


From jeroen at berkeley.edu  Sat Dec 29 15:01:59 2018
From: jeroen at berkeley.edu (Jeroen Ooms)
Date: Sat, 29 Dec 2018 15:01:59 +0100
Subject: gpgme_op_delete() does not work with gpg 2.x
Message-ID: <CABFfbXsXcMJ=P8n8_XKk=DCuxd2iNvHi54R8KusgEPAjZOfV8w@mail.gmail.com>

A user of the R bindings has reported (and I have confirmed) that
deleting secret keys in gpgme does not work with gnupg2. We call (on
an existing key):

  gpgme_op_delete(ctx, key, 1)

This returns success if the key exists, and when we are running with
GnuPG 1.4 the key is deleted. However when running gpg2 it returns
success but the key is still there.

Downstream issue: https://github.com/jeroen/gpg/issues/3


From bts at square-r00t.net  Sat Dec 29 17:01:19 2018
From: bts at square-r00t.net (brent s.)
Date: Sat, 29 Dec 2018 11:01:19 -0500
Subject: gpgme_op_delete() does not work with gpg 2.x
In-Reply-To: <CABFfbXsXcMJ=P8n8_XKk=DCuxd2iNvHi54R8KusgEPAjZOfV8w@mail.gmail.com>
References: <CABFfbXsXcMJ=P8n8_XKk=DCuxd2iNvHi54R8KusgEPAjZOfV8w@mail.gmail.com>
Message-ID: <d992f33e-fdac-5067-32cb-383078f716b6@square-r00t.net>

On 12/29/18 9:01 AM, Jeroen Ooms wrote:
> A user of the R bindings has reported (and I have confirmed) that
> deleting secret keys in gpgme does not work with gnupg2. We call (on
> an existing key):
> 
>   gpgme_op_delete(ctx, key, 1)
> 
> This returns success if the key exists, and when we are running with
> GnuPG 1.4 the key is deleted. However when running gpg2 it returns
> success but the key is still there.
> 
> Downstream issue: https://github.com/jeroen/gpg/issues/3
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> 

I'm not sure how much this will help you, but deleting a private key
works in the Python bindings if I use the abstracted method but not the
direct gpgme method (see attached POC).

Haven't taken a look at the R bindings; is there a similar
context-specific method there?

-- 
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testdelete.py
Type: text/x-python
Size: 1873 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181229/4d87e186/attachment-0001.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181229/4d87e186/attachment-0001.sig>

From wiktor at metacode.biz  Sat Dec 29 20:22:54 2018
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Sat, 29 Dec 2018 20:22:54 +0100
Subject: Exporting SSH keys from OpenPGP Authentication keys programatically
 (gpgme)
Message-ID: <15d4748b-2be1-a3cd-bd03-66a42ca0998e@metacode.biz>

Hello all,

Is it possible to export SSH keys from OpenPGP Authentication keys
programmatically with gpgme?

I'm looking for an equivalent of "gpg --export-ssh" and did some preliminary
research but the exporting keys documentation [0] doesn't list anything related
to SSH.

[0]: https://www.gnupg.org/documentation/manuals/gpgme/Exporting-Keys.html

Thank you in advance!

Kind regards,
Wiktor

-- 
https://metacode.biz/@wiktor


From wk at gnupg.org  Sun Dec 30 11:27:01 2018
From: wk at gnupg.org (Werner Koch)
Date: Sun, 30 Dec 2018 11:27:01 +0100
Subject: Exporting SSH keys from OpenPGP Authentication keys
 programatically (gpgme)
In-Reply-To: <15d4748b-2be1-a3cd-bd03-66a42ca0998e@metacode.biz> (Wiktor
 Kwapisiewicz via Gnupg-devel's message of "Sat, 29 Dec 2018 20:22:54
 +0100")
References: <15d4748b-2be1-a3cd-bd03-66a42ca0998e@metacode.biz>
Message-ID: <87tvivia2y.fsf@wheatstone.g10code.de>

On Sat, 29 Dec 2018 20:22, gnupg-devel at gnupg.org said:

> I'm looking for an equivalent of "gpg --export-ssh" and did some preliminary
> research but the exporting keys documentation [0] doesn't list

This is not supported.  Do you think this could be a common use case?


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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181230/fd475d36/attachment.sig>

From dirk.gottschalk1980 at googlemail.com  Sun Dec 30 18:05:54 2018
From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk)
Date: Sun, 30 Dec 2018 18:05:54 +0100
Subject: Exporting SSH keys from OpenPGP Authentication keys
 programatically (gpgme)
In-Reply-To: <87tvivia2y.fsf@wheatstone.g10code.de>
References: <15d4748b-2be1-a3cd-bd03-66a42ca0998e@metacode.biz>
 <87tvivia2y.fsf@wheatstone.g10code.de>
Message-ID: <640b070e7652fb6c8b55f9513bfb5aa01411ff8d.camel@googlemail.com>

Hello.

Am Sonntag, den 30.12.2018, 11:27 +0100 schrieb Werner Koch:
> On Sat, 29 Dec 2018 20:22, gnupg-devel at gnupg.org said:

> > I'm looking for an equivalent of "gpg --export-ssh" and did some
> > preliminary
> > research but the exporting keys documentation [0] doesn't list

> This is not supported.  Do you think this could be a common use case?

Excuse my dumb question, but, what would be the benefit of this?

AFAIK, there is no way of using X.509 Certs from GPGsm for SSH,
especially when the private KEys are on an OpenPGP-Card.

Correct me if I'm wrong, please.

Regards,
Dirk


-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen, Germany

GPG: DDCB AF8E 0132 AA54 20AB  B864 4081 0B18 1ED8 E838
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181230/dd9a7443/attachment.sig>

From wiktor at metacode.biz  Sun Dec 30 20:29:06 2018
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Sun, 30 Dec 2018 20:29:06 +0100
Subject: Exporting SSH keys from OpenPGP Authentication keys
 programatically (gpgme)
In-Reply-To: <640b070e7652fb6c8b55f9513bfb5aa01411ff8d.camel@googlemail.com>
References: <15d4748b-2be1-a3cd-bd03-66a42ca0998e@metacode.biz>
 <87tvivia2y.fsf@wheatstone.g10code.de>
 <640b070e7652fb6c8b55f9513bfb5aa01411ff8d.camel@googlemail.com>
Message-ID: <303014d3-077b-56e6-2e70-4a3626fd16e5@metacode.biz>

Hi Werner, Dirk,

>> This is not supported.  Do you think this could be a common use case?

I don't know if this is "common" enough but I'm planning to write an integration
that would automatically add user's keys (OpenPGP, SSH) to GitLab when a new
e-mail is added through Web Key Directory [0]. As far as I've seen they use
GpgME for key management so if it was possible I'd like to keep the same style.

[0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/48751

> Excuse my dumb question, but, what would be the benefit of this?
> 
> AFAIK, there is no way of using X.509 Certs from GPGsm for SSH,
> especially when the private KEys are on an OpenPGP-Card.

This is not about using X.509 but OpenPGP Authentication subkeys. GPG Agent acts
as SSH Agent. Check this out, for example (no affiliation, just first hit on a
search engine for "gpg ssh"):

https://www.esev.com/blog/post/2015-01-pgp-ssh-key-on-yubikey-neo/

(Yes, I know SSH can use X.509 certs but this isn't it).

Kind regards,
Wiktor

-- 
https://metacode.biz/@wiktor