From johanw at vulcan.xs4all.nl  Mon May  1 01:33:05 2023
From: johanw at vulcan.xs4all.nl (Johan Wevers)
Date: Mon, 1 May 2023 01:33:05 +0200
Subject: ADK's
In-Reply-To: <20230430190142.GA155004@manas>
References: <2199A4D9-31B8-48FD-AD1B-A490E381CB2A@andrewg.com>
 <f606f4f1-0f9b-9d2a-8c47-1d1e7c02f9e5@vulcan.xs4all.nl>
 <20230430190142.GA155004@manas>
Message-ID: <0f41ff95-cab2-313d-476d-cd77c153316f@vulcan.xs4all.nl>

On 2023-04-30 21:01, Ineiev via Gnupg-users wrote:

>> All I want is an option to ignore adk's - and it should not claim
>> anything else than that.
> 
> Can't you remove ADK subkeys from your keyring?

On someone else's key?

-- 
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html


From jcb62281 at gmail.com  Mon May  1 03:19:26 2023
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Sun, 30 Apr 2023 20:19:26 -0500
Subject: ADK's
In-Reply-To: <2de12ab8-b0a0-5c15-5c7a-ea8f241b1ec7@vulcan.xs4all.nl>
References: <f41df85b-c172-c3e0-db6c-1388b9a64216@vulcan.xs4all.nl>
 <8409E3A7-DA83-4EAD-AD7B-E57CC24C5254@andrewg.com>
 <2de12ab8-b0a0-5c15-5c7a-ea8f241b1ec7@vulcan.xs4all.nl>
Message-ID: <644F139E.5010009@gmail.com>

Johan Wevers via Gnupg-users wrote:
> On 2023-04-30 14:58, Andrew Gallagher via Gnupg-users wrote:
>
> [...]
>   
>> The danger of an ?ignore ADK? option is that it gives a false sense of security. It is already possible for an employer to require escrow of the decryption subkeys of their employees - ADK actually makes this process more transparent.
>>     
>
> That might be, but it is nowhere certain that this escrow will happen,
> especially if they roll out adk's. Not providing such an option might be
> a case where the perfect is the enemy of the good: it might not be a
> perfect solution but it can be better than the alternative.
>
> Besides, this is begging for GnuPG forks to arise, and if those forks
> are well implemented remains to be seen.

Maybe the best option here is an "--override-encryption-target 
KEYGRIP/SUBKEYGRIP" option, repeatable to encrypt to multiple specific 
subkeys of the same or different PGP keys, which is why it requires both 
a keygrip and a subkeygrip.  This would also allow encrypting to some 
ADKs while ignoring others and resolve the demands for an "ignore ADK" 
option.

ADKs seem particularly valuable to me as a solution to the "group inbox" 
problem that avoids actually sharing private key material:  simply 
attach encryption subkeys for all recipients to the "group inbox" 
certificate.  This requires publishing new certificates when the 
recipient list changes and discloses the recipient list to some extent, 
but that is the trade-off for end-to-end security in this context.  
Could a "--notify-ADK-encrypt" option that could be placed in the 
configuration file be appropriate to address user concerns about 
possible improper proliferation of ADKs?  Should a notification that an 
ADK was used actually be default?  After all, there are legitimate uses 
for ADKs, but an ADK turning up where not expected could be a strong 
hint that you have a bogus certificate.

I would also note that, for a work email system in an environment where 
there is a legal or quasi-legal requirement (not uncommon in finance) to 
archive messages, simply dropping any incoming message not decryptable 
with the archive ADK as spam would be reasonable.  Since the primary 
concern motivating message archival in this example is deterring insider 
trading, simply not allowing unreadable messages to be delivered 
accomplishes the same objective.


-- Jacob


From mcr at sandelman.ca  Mon May  1 04:53:15 2023
From: mcr at sandelman.ca (Michael Richardson)
Date: Sun, 30 Apr 2023 22:53:15 -0400
Subject: ADK's
In-Reply-To: <644F139E.5010009@gmail.com>
References: <f41df85b-c172-c3e0-db6c-1388b9a64216@vulcan.xs4all.nl>
 <8409E3A7-DA83-4EAD-AD7B-E57CC24C5254@andrewg.com>
 <2de12ab8-b0a0-5c15-5c7a-ea8f241b1ec7@vulcan.xs4all.nl>
 <644F139E.5010009@gmail.com>
Message-ID: <26066.1682909595@localhost>


Jacob Bachmeyer via Gnupg-users <gnupg-users at gnupg.org> wrote:
    > ADKs seem particularly valuable to me as a solution to the "group inbox"
    > problem that avoids actually sharing private key material:  simply
    > attach encryption subkeys for all recipients to the "group inbox"
    > certificate.  This requires publishing new certificates when the
    > recipient list changes and discloses the recipient list to some extent, but
    > that is the trade-off for end-to-end security in this context.  Could a
    > "--notify-ADK-encrypt" option that could be placed in the configuration file
    > be appropriate to address user concerns about possible improper proliferation
    > of ADKs?  Should a notification that an ADK was used actually be default?
    > After all, there are legitimate uses for ADKs, but an ADK turning up where
    > not expected could be a strong hint that you have a bogus certificate.

That would be really useful for security at example.com

I'm unclear if this is a new feature (I think so), and if so what happens if
the sender hasn't upgraded yet?

    > I would also note that, for a work email system in an environment where there
    > is a legal or quasi-legal requirement (not uncommon in finance) to archive
    > messages, simply dropping any incoming message not decryptable with the
    > archive ADK as spam would be reasonable.  Since the primary concern
    > motivating message archival in this example is deterring insider trading,
    > simply not allowing unreadable messages to be delivered accomplishes the same
    > objective.

Yes, reasonable.
OTH, the emails investigating the insider trading by the HR people might need
to avoid the ADK.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 511 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230430/15b0e9fb/attachment.sig>

From jcb62281 at gmail.com  Mon May  1 05:52:10 2023
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Sun, 30 Apr 2023 22:52:10 -0500
Subject: ADK's
In-Reply-To: <26066.1682909595@localhost>
References: <f41df85b-c172-c3e0-db6c-1388b9a64216@vulcan.xs4all.nl>
 <8409E3A7-DA83-4EAD-AD7B-E57CC24C5254@andrewg.com>
 <2de12ab8-b0a0-5c15-5c7a-ea8f241b1ec7@vulcan.xs4all.nl>
 <644F139E.5010009@gmail.com> <26066.1682909595@localhost>
Message-ID: <644F376A.4050504@gmail.com>

Michael Richardson wrote:
> Jacob Bachmeyer via Gnupg-users <gnupg-users at gnupg.org> wrote:
>     > ADKs seem particularly valuable to me as a solution to the "group inbox"
>     > problem that avoids actually sharing private key material:  simply
>     > attach encryption subkeys for all recipients to the "group inbox"
>     > certificate.  This requires publishing new certificates when the
>     > recipient list changes and discloses the recipient list to some extent, but
>     > that is the trade-off for end-to-end security in this context.  Could a
>     > "--notify-ADK-encrypt" option that could be placed in the configuration file
>     > be appropriate to address user concerns about possible improper proliferation
>     > of ADKs?  Should a notification that an ADK was used actually be default?
>     > After all, there are legitimate uses for ADKs, but an ADK turning up where
>     > not expected could be a strong hint that you have a bogus certificate.
>
> That would be really useful for security at example.com
>   

That is an almost prototypical example.  In that case, the "archive" key 
would actually be the main subkey, and the list recipients' personal 
keys would be attached as ADKs.

Another example:  suppose I have multiple hardware tokens and wish to be 
able to use them interchangeably, but also want maximal security with 
this arrangement, so have generated an encryption keypair on each 
token.  I list all of the per-token subkeys as ADKs.  In this case, the 
ADKs really would all be /my/ keys.  Again, I would have to publish a 
new certificate every time my collection of live tokens changes, which 
may or may not leak useful information to an adversary.

> I'm unclear if this is a new feature (I think so), and if so what happens if
> the sender hasn't upgraded yet?
>   

My understanding:  ADKs are new and do not work without support on the 
sender's side.  The ADK is a request to also encrypt any message to the 
subkey to the ADK.  If the sender's software does not understand that 
request, it does not happen.  If the sender rejects that request, either 
by setting an option or by patching their software to ignore the 
request, it does not happen.

My primary reason for arguing to support some way to suppress the use of 
an ADK when encrypting is that, as Johan noted, this is an issue where 
feelings are strong enough to provoke forks, which are likely to simply 
rip out ADK support entirely, thus making its legitimate uses (group 
inboxes, multiple tokens, business-related) unreliable.

>     > I would also note that, for a work email system in an environment where there
>     > is a legal or quasi-legal requirement (not uncommon in finance) to archive
>     > messages, simply dropping any incoming message not decryptable with the
>     > archive ADK as spam would be reasonable.  Since the primary concern
>     > motivating message archival in this example is deterring insider trading,
>     > simply not allowing unreadable messages to be delivered accomplishes the same
>     > objective.
>
> Yes, reasonable.
> OTH, the emails investigating the insider trading by the HR people might need
> to avoid the ADK.

If we are talking about investigating HR malfeasance, those messages 
would not be going to the traders' regular inboxes in the first place.  
You are right that an HR ADK could be a very bad idea in this example, 
since it could allow HR to front-run their own employer.  The expected 
solution would be to give the trading archives only to the audit or 
legal departments, and only after some period of time has passed.  That 
still leaves potential auditor or lawyer malfeasance, but that is an 
existing risk such businesses already handle.


-- Jacob



From mlnl at mailbox.org  Mon May  1 08:28:04 2023
From: mlnl at mailbox.org (mlnl)
Date: Mon, 1 May 2023 08:28:04 +0200
Subject: ADK's
In-Reply-To: <0f41ff95-cab2-313d-476d-cd77c153316f@vulcan.xs4all.nl>
References: <2199A4D9-31B8-48FD-AD1B-A490E381CB2A@andrewg.com>
 <f606f4f1-0f9b-9d2a-8c47-1d1e7c02f9e5@vulcan.xs4all.nl>
 <20230430190142.GA155004@manas>
 <0f41ff95-cab2-313d-476d-cd77c153316f@vulcan.xs4all.nl>
Message-ID: <20230501082804.0bfb4516@localhost>

Hi Johan,

Johan Wevers via Gnupg-users <gnupg-users at gnupg.org> wrote:

>On 2023-04-30 21:01, Ineiev via Gnupg-users wrote:
>
>>> All I want is an option to ignore adk's - and it should not claim
>>> anything else than that.  
>> 
>> Can't you remove ADK subkeys from your keyring?  
>
>On someone else's key?
>

Yes.

1. identify ADK key: [R]/usage: R ("restricted encryption key") and
extract adk's fingerprint
2. gpg --batch --delete-keys adkfp!

after every key import or refresh.

-- 
mlnl

GPG:1FC05426F87FA623


From ineiev at gnu.org  Mon May  1 13:38:51 2023
From: ineiev at gnu.org (Ineiev)
Date: Mon, 1 May 2023 11:38:51 +0000
Subject: ADK's
In-Reply-To: <644F376A.4050504@gmail.com>
References: <f41df85b-c172-c3e0-db6c-1388b9a64216@vulcan.xs4all.nl>
 <8409E3A7-DA83-4EAD-AD7B-E57CC24C5254@andrewg.com>
 <2de12ab8-b0a0-5c15-5c7a-ea8f241b1ec7@vulcan.xs4all.nl>
 <644F139E.5010009@gmail.com> <26066.1682909595@localhost>
 <644F376A.4050504@gmail.com>
Message-ID: <20230501113851.GC13977@manas>

On Sun, Apr 30, 2023 at 10:52:10PM -0500, Jacob Bachmeyer via Gnupg-users wrote:
> 
> That is an almost prototypical example.  In that case, the "archive" key
> would actually be the main subkey, and the list recipients' personal keys
> would be attached as ADKs.
> 
> Another example:  suppose I have multiple hardware tokens and wish to be
> able to use them interchangeably, but also want maximal security with this
> arrangement, so have generated an encryption keypair on each token.  I list
> all of the per-token subkeys as ADKs.  In this case, the ADKs really would
> all be /my/ keys.  Again, I would have to publish a new certificate every
> time my collection of live tokens changes, which may or may not leak useful
> information to an adversary.

It looks like the feature will allow for quite unexpected (if not
unintended) uses.

Another potential use is: I have reasons to believe that the holder
of the key 0123456789ABCDEF controls the email yu at guan.edu, but that
key has no user ID with such email, and I couldn't validate any other
emails in that key. when I'm writing to that email, my MUA will look
for keys with user IDs that match it. now, I generate a key
for yu at guan.edu locally and add 0123456789ABCDEF as an ADK (BTW,
will GnuPG complain if the only encryption-capable subkey is ADK?
can I make all self-signatures local in order to avoid sending
the key to keyservers?)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230501/443eea89/attachment.sig>

From andrewg at andrewg.com  Mon May  1 16:16:12 2023
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Mon, 1 May 2023 15:16:12 +0100
Subject: ADK's
In-Reply-To: <20230501113851.GC13977@manas>
References: <20230501113851.GC13977@manas>
Message-ID: <D0705386-F805-4795-B5BE-C0B00A0C5D85@andrewg.com>

On 1 May 2023, at 12:40, Ineiev via Gnupg-users <gnupg-users at gnupg.org> wrote:
> now, I generate a key
> for yu at guan.edu locally and add 0123456789ABCDEF as an ADK (BTW,
> will GnuPG complain if the only encryption-capable subkey is ADK?

Or you could just use an alias??

A

From tmz at pobox.com  Mon May  1 19:10:15 2023
From: tmz at pobox.com (Todd Zullinger)
Date: Mon, 1 May 2023 13:10:15 -0400
Subject: [Announce] GnuPG 2.4.1 released
In-Reply-To: <87o7n5ziax.fsf@wheatstone.g10code.de>
References: <87mt2s15kn.fsf@wheatstone.g10code.de> <ZEvkkmpbgXUd6oH3@pobox.com>
 <87o7n5ziax.fsf@wheatstone.g10code.de>
Message-ID: <ZE_yd_1GpKC06VTw@pobox.com>

Werner Koch via Gnupg-users wrote:
> On Fri, 28 Apr 2023 11:21, Todd Zullinger said:
> 
>> It seems neither of these files have not made it to the
>> server yet:
> 
> Sorry for that.  I have used a new build machine and obviously forgot
> one of the last steps. Most of the release process is scripted but the
> final upload needs to be done manually (after signing, copying to the
> internal archive, updating the repo, writing announcement and updating
> the web page).
> 
> Fixed after Bernhard called me at home.

Sorry it interrupted your weekend.  Thanks for the new
release and all of your work on GnuPG and OpenPGP. :)

-- 
Todd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230501/c32bee07/attachment.sig>

From mcr at sandelman.ca  Tue May  2 02:20:34 2023
From: mcr at sandelman.ca (Michael Richardson)
Date: Mon, 01 May 2023 20:20:34 -0400
Subject: ADK's
In-Reply-To: <644F376A.4050504@gmail.com>
References: <f41df85b-c172-c3e0-db6c-1388b9a64216@vulcan.xs4all.nl>
 <8409E3A7-DA83-4EAD-AD7B-E57CC24C5254@andrewg.com>
 <2de12ab8-b0a0-5c15-5c7a-ea8f241b1ec7@vulcan.xs4all.nl>
 <644F139E.5010009@gmail.com> <26066.1682909595@localhost>
 <644F376A.4050504@gmail.com>
Message-ID: <4224.1682986834@localhost>


Jacob Bachmeyer <jcb62281 at gmail.com> wrote:
    >> I'm unclear if this is a new feature (I think so), and if so what happens if
    >> the sender hasn't upgraded yet?
    >>

    > My understanding:  ADKs are new and do not work without support on the
    > sender's side.  The ADK is a request to also encrypt any message to the
    > subkey to the ADK.  If the sender's software does not understand that
    > request, it does not happen.  If the sender rejects that request, either
    > by setting an option or by patching their software to ignore the request, it
    > does not happen.

Does it still (by default) encrypt to the main key?

    > My primary reason for arguing to support some way to suppress the use of an
    > ADK when encrypting is that, as Johan noted, this is an issue where feelings
    > are strong enough to provoke forks, which are likely to simply rip out ADK
    > support entirely, thus making its legitimate uses (group inboxes, multiple
    > tokens, business-related) unreliable.

I agree with this view.

    >> > I would also note that, for a work email system in an environment where there
    >> > is a legal or quasi-legal requirement (not uncommon in finance) to archive
    >> > messages, simply dropping any incoming message not decryptable with the
    >> > archive ADK as spam would be reasonable.  Since the primary concern
    >> > motivating message archival in this example is deterring insider trading,
    >> > simply not allowing unreadable messages to be delivered accomplishes the same
    >> > objective.
    >>
    >> Yes, reasonable.
    >> OTH, the emails investigating the insider trading by the HR people might need
    >> to avoid the ADK.

    > If we are talking about investigating HR malfeasance, those messages would
    > not be going to the traders' regular inboxes in the first place.  You are
    > right that an HR ADK could be a very bad idea in this example, since it could
    > allow HR to front-run their own employer.  The expected solution would be to
    > give the trading archives only to the audit or legal departments, and only
    > after some period of time has passed.  That still leaves potential auditor or
    > lawyer malfeasance, but that is an existing risk such businesses already
    > handle.

It's the initial investigation of an irregularity where there could be a problem.
There is also an issue with 2FA and password reset emails: it's something
that may be a vulnerability to archive.  Okay, few are encrypted today, but
we can hope.   Many companies with forced proxis are starting to realize that
they become liable when they store banking login cookies.

Anyway, I think senders need to be made mildly aware that it's occuring, and
I think they should be allowed to pick a specific ADK or suppress them all in
certain circumstances best decided by them.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 511 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230501/a1f57a86/attachment-0001.sig>

From jcb62281 at gmail.com  Tue May  2 04:43:57 2023
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Mon, 01 May 2023 21:43:57 -0500
Subject: ADK's
In-Reply-To: <4224.1682986834@localhost>
References: <f41df85b-c172-c3e0-db6c-1388b9a64216@vulcan.xs4all.nl>
 <8409E3A7-DA83-4EAD-AD7B-E57CC24C5254@andrewg.com>
 <2de12ab8-b0a0-5c15-5c7a-ea8f241b1ec7@vulcan.xs4all.nl>
 <644F139E.5010009@gmail.com> <26066.1682909595@localhost>
 <644F376A.4050504@gmail.com> <4224.1682986834@localhost>
Message-ID: <645078ED.8020000@gmail.com>

Michael Richardson wrote:
> Jacob Bachmeyer <jcb62281 at gmail.com> wrote:
>     >> I'm unclear if this is a new feature (I think so), and if so what happens if
>     >> the sender hasn't upgraded yet?
>     >>
>
>     > My understanding:  ADKs are new and do not work without support on the
>     > sender's side.  The ADK is a request to also encrypt any message to the
>     > subkey to the ADK.  If the sender's software does not understand that
>     > request, it does not happen.  If the sender rejects that request, either
>     > by setting an option or by patching their software to ignore the request, it
>     > does not happen.
>
> Does it still (by default) encrypt to the main key?
>   

My understanding:  Yes, if ADKs are not supported, the message is 
encrypted only for the main key.

> [...]
>
>     >> > I would also note that, for a work email system in an environment where there
>     >> > is a legal or quasi-legal requirement (not uncommon in finance) to archive
>     >> > messages, simply dropping any incoming message not decryptable with the
>     >> > archive ADK as spam would be reasonable.  Since the primary concern
>     >> > motivating message archival in this example is deterring insider trading,
>     >> > simply not allowing unreadable messages to be delivered accomplishes the same
>     >> > objective.
>     >>
>     >> Yes, reasonable.
>     >> OTH, the emails investigating the insider trading by the HR people might need
>     >> to avoid the ADK.
>
>     > If we are talking about investigating HR malfeasance, those messages would
>     > not be going to the traders' regular inboxes in the first place.  You are
>     > right that an HR ADK could be a very bad idea in this example, since it could
>     > allow HR to front-run their own employer.  The expected solution would be to
>     > give the trading archives only to the audit or legal departments, and only
>     > after some period of time has passed.  That still leaves potential auditor or
>     > lawyer malfeasance, but that is an existing risk such businesses already
>     > handle.
>
> It's the initial investigation of an irregularity where there could be a problem.
> There is also an issue with 2FA and password reset emails: it's something
> that may be a vulnerability to archive.  Okay, few are encrypted today, but
> we can hope.   Many companies with forced proxis are starting to realize that
> they become liable when they store banking login cookies.
>   

Really, the banks should be recognizing those networks and denying 
logins.  Perhaps corporate forced proxies should be required to insert 
an additional header reporting that the connection is not actually 
point-to-point encrypted, which banks and other sensitive services could 
use to reject sessions.

The main problem here seems to be a work-life balance issue.  People 
should not be conducting personal business on the company network, and, 
in turn, companies need to understand that personal time outside of work 
is /personal/ /time/ /outside/ /of/ /work/.  I am not sure in which 
direction this first broke down, but it is the root cause of a wide 
variety of problems.

> Anyway, I think senders need to be made mildly aware that it's occuring, and
> I think they should be allowed to pick a specific ADK or suppress them all in
> certain circumstances best decided by them.
>   

I believe that is substantially what I proposed, so at least two of us 
agree.


-- Jacob


From wk at gnupg.org  Tue May  2 08:34:15 2023
From: wk at gnupg.org (Werner Koch)
Date: Tue, 02 May 2023 08:34:15 +0200
Subject: [Announce] GnuPG 2.4.1 released
In-Reply-To: <ZE_yd_1GpKC06VTw@pobox.com> (Todd Zullinger via Gnupg-users's
 message of "Mon, 1 May 2023 13:10:15 -0400")
References: <87mt2s15kn.fsf@wheatstone.g10code.de>
 <ZEvkkmpbgXUd6oH3@pobox.com> <87o7n5ziax.fsf@wheatstone.g10code.de>
 <ZE_yd_1GpKC06VTw@pobox.com>
Message-ID: <878re7z1g8.fsf@wheatstone.g10code.de>

On Mon,  1 May 2023 13:10, Todd Zullinger said:

> Sorry it interrupted your weekend.  Thanks for the new

Actually it was Friday evening and I left the office a bit earlier than
usual.


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230502/bacc4ada/attachment.sig>

From wk at gnupg.org  Tue May  2 08:37:33 2023
From: wk at gnupg.org (Werner Koch)
Date: Tue, 02 May 2023 08:37:33 +0200
Subject: ADK's
In-Reply-To: <8409E3A7-DA83-4EAD-AD7B-E57CC24C5254@andrewg.com> (Andrew
 Gallagher via Gnupg-users's message of "Sun, 30 Apr 2023 13:58:17
 +0100")
References: <f41df85b-c172-c3e0-db6c-1388b9a64216@vulcan.xs4all.nl>
 <8409E3A7-DA83-4EAD-AD7B-E57CC24C5254@andrewg.com>
Message-ID: <874jovz1aq.fsf@wheatstone.g10code.de>

On Sun, 30 Apr 2023 13:58, Andrew Gallagher said:

> The danger of an ?ignore ADK? option is that it gives a false sense of

And not to forget the other important use case: Add an ADK for your own
second device so that you are able to decrypt also on that device -
without the need to keep the pimary key on that device.

BTW, OpenKeychain does something very similar for many years.


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230502/fec44da5/attachment.sig>

From andrewg at andrewg.com  Tue May  2 09:35:08 2023
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Tue, 2 May 2023 08:35:08 +0100
Subject: ADK's
In-Reply-To: <4224.1682986834@localhost>
References: <4224.1682986834@localhost>
Message-ID: <8F05146A-0127-4C88-97B3-F6A16A0B3CF1@andrewg.com>

On 2 May 2023, at 02:18, Michael Richardson <mcr at sandelman.ca> wrote:
> 
> It's the initial investigation of an irregularity where there could be a problem.

These examples are becoming increasingly contrived. If you are investigating fraud by someone who can read all your company emails, don?t discuss it over company email. This is really basic stuff.

> There is also an issue with 2FA and password reset emails: it's something
> that may be a vulnerability to archive. Okay, few are encrypted today, but
> we can hope.

Password reset emails are supposed to be immune to replay attacks.

> Many companies with forced proxis are starting to realize that
> they become liable when they store banking login cookies.

The only way that a company would end up archiving a password reset email encrypted to an ADK would be if an employee was using their work email address for password resets. If using their work email for this purpose is inadvisable, then it is inadvisable regardless of ADKs. 

> Anyway, I think senders need to be made mildly aware that it's occuring, and
> I think they should be allowed to pick a specific ADK or suppress them all in
> certain circumstances best decided by them.

If I add an ADK notation to my key for legitimate reasons that I do not discuss with all my correspondents, on what basis do they decide to second guess it? How is this any different from where I store my private key, whether it is escrowed, whether it has a password etc, which are invisible to the sender and generally none of their business? If you don?t trust how I manage my key, the only reasonable recourse is to avoid using it.

ADK introduces no new considerations that are not also an issue for key escrow, which happens anyway, and has several advantages over escrow, particularly transparency. If however it became common for people to disable encrypting to the ADK, it would simply encourage companies to stop using it and keep using escrow, which doesn?t prevent any of the proposed abuses. 

If you don?t trust your correspondent?s employer, then the only effective course of action is to not use their employer?s email address. Technical measures cannot protect you from opsec problems.

A

From mcr at sandelman.ca  Tue May  2 17:04:33 2023
From: mcr at sandelman.ca (Michael Richardson)
Date: Tue, 02 May 2023 11:04:33 -0400
Subject: ADK's
In-Reply-To: <8F05146A-0127-4C88-97B3-F6A16A0B3CF1@andrewg.com>
References: <4224.1682986834@localhost>
 <8F05146A-0127-4C88-97B3-F6A16A0B3CF1@andrewg.com>
Message-ID: <32705.1683039873@localhost>


Andrew Gallagher <andrewg at andrewg.com> wrote:
    > The only way that a company would end up archiving a password reset
    > email encrypted to an ADK would be if an employee was using their work
    > email address for password resets. If using their work email for this
    > purpose is inadvisable, then it is inadvisable regardless of ADKs.

Like you mean, an employee was using a work email for a work thing, maybe?

    > ADK introduces no new considerations that are not also an issue for key
    > escrow, which happens anyway, and has several advantages over escrow,

I agree.

    > If you don?t trust your correspondent?s employer, then the only
    > effective course of action is to not use their employer?s email
    > address. Technical measures cannot protect you from opsec problems.

I'm asking to be informed so that I can make the decision to do
something else.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 511 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230502/70df558c/attachment.sig>

From ineiev at gnu.org  Thu May  4 07:46:26 2023
From: ineiev at gnu.org (Ineiev)
Date: Thu, 4 May 2023 05:46:26 +0000
Subject: out-of-key UIDs [was: ADK's]
In-Reply-To: <D0705386-F805-4795-B5BE-C0B00A0C5D85@andrewg.com>
References: <20230501113851.GC13977@manas>
 <D0705386-F805-4795-B5BE-C0B00A0C5D85@andrewg.com>
Message-ID: <ZFNGsjD4JZjjVAGO@desdichado>

On Mon, May 01, 2023 at 03:16:12PM +0100, Andrew Gallagher wrote:
> On 1 May 2023, at 12:40, Ineiev via Gnupg-users <gnupg-users at gnupg.org> wrote:
> > now, I generate a key
> > for yu at guan.edu locally and add 0123456789ABCDEF as an ADK (BTW,
> > will GnuPG complain if the only encryption-capable subkey is ADK?
>
> Or you could just use an alias??

I don't think I fully understand what you mean.

$ gpg --group fnord at test.eu=BD9D4DEE7B2FF1CBEF2EE0C4E0ACD3E0CBE7874A --list-keys fnord at test.eu
gpg: error reading key: No public key
$ gpg --list-keys BD9D4DEE7B2FF1CBEF2EE0C4E0ACD3E0CBE7874A | head -n1
pub   rsa2048 2014-10-21 [SC] [expires: 2024-10-17]
$ gpg --version | head -n2
gpg (GnuPG) 2.2.41
libgcrypt 1.8.10
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230504/1022caec/attachment.sig>

From andrewg at andrewg.com  Thu May  4 10:52:54 2023
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Thu, 4 May 2023 09:52:54 +0100
Subject: out-of-key UIDs [was: ADK's]
In-Reply-To: <ZFNGsjD4JZjjVAGO@desdichado>
References: <20230501113851.GC13977@manas>
 <D0705386-F805-4795-B5BE-C0B00A0C5D85@andrewg.com>
 <ZFNGsjD4JZjjVAGO@desdichado>
Message-ID: <8F6EEFCA-59B6-491B-852A-512CF5BCDDDB@andrewg.com>

On 4 May 2023, at 06:46, Ineiev <ineiev at gnu.org> wrote:
> 
> On Mon, May 01, 2023 at 03:16:12PM +0100, Andrew Gallagher wrote:
>> On 1 May 2023, at 12:40, Ineiev via Gnupg-users <gnupg-users at gnupg.org> wrote:
>>> now, I generate a key
>>> for yu at guan.edu locally and add 0123456789ABCDEF as an ADK (BTW,
>>> will GnuPG complain if the only encryption-capable subkey is ADK?
>> 
>> Or you could just use an alias??
> 
> I don't think I fully understand what you mean.
> 
> $ gpg --group fnord at test.eu=BD9D4DEE7B2FF1CBEF2EE0C4E0ACD3E0CBE7874A --list-keys fnord at test.eu
> gpg: error reading key: No public key
> $ gpg --list-keys BD9D4DEE7B2FF1CBEF2EE0C4E0ACD3E0CBE7874A | head -n1
> pub   rsa2048 2014-10-21 [SC] [expires: 2024-10-17]
> $ gpg --version | head -n2
> gpg (GnuPG) 2.2.41
> libgcrypt 1.8.10



?list-keys doesn?t expand groups. Try this instead:


andrewg at serenity % gpg --group fnord at test.eu=BD9D4DEE7B2FF1CBEF2EE0C4E0ACD3E0CBE7874A -r fnord at test.eu -e < /etc/shells > shells.gpg
gpg: 0x40F9B9601900E974: There is no assurance this key belongs to the named user

sub  rsa2048/0x40F9B9601900E974 2014-10-21 Ineiev (fencepost) <ineiev at gnu.org>
 Primary key fingerprint: BD9D 4DEE 7B2F F1CB EF2E  E0C4 E0AC D3E0 CBE7 874A
      Subkey fingerprint: F495 D912 C380 C534 23CD  6B7C 40F9 B960 1900 E974

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N) y
andrewg at serenity % gpg --list-packets shells.gpg
gpg: encrypted with rsa2048 key, ID 0x40F9B9601900E974, created 2014-10-21
      "Ineiev (fencepost) <ineiev at gnu.org>"
gpg: problem with fast path key listing: IPC parameter error - ignored
gpg: public key decryption failed: No secret key
gpg: decryption failed: No secret key
# off=0 ctb=85 tag=1 hlen=3 plen=268
:pubkey enc packet: version 3, algo 1, keyid 40F9B9601900E974
	data: [2047 bits]
# off=271 ctb=d2 tag=18 hlen=2 plen=187 new-ctb
:encrypted data packet:
	length: 187
	mdc_method: 2
andrewg at serenity %

A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230504/806346d2/attachment-0001.sig>

From ineiev at gnu.org  Thu May  4 11:43:56 2023
From: ineiev at gnu.org (Ineiev)
Date: Thu, 4 May 2023 09:43:56 +0000
Subject: out-of-key UIDs [was: ADK's]
In-Reply-To: <8F6EEFCA-59B6-491B-852A-512CF5BCDDDB@andrewg.com>
References: <20230501113851.GC13977@manas>
 <D0705386-F805-4795-B5BE-C0B00A0C5D85@andrewg.com>
 <ZFNGsjD4JZjjVAGO@desdichado>
 <8F6EEFCA-59B6-491B-852A-512CF5BCDDDB@andrewg.com>
Message-ID: <ZFN+XHEcPj4Qzg1h@desdichado>

On Thu, May 04, 2023 at 09:52:54AM +0100, Andrew Gallagher wrote:
> > $ gpg --group fnord at test.eu=BD9D4DEE7B2FF1CBEF2EE0C4E0ACD3E0CBE7874A --list-keys fnord at test.eu
> > gpg: error reading key: No public key
...
> ?list-keys doesn?t expand groups. Try this instead:
> 
> 
> andrewg at serenity % gpg --group fnord at test.eu=BD9D4DEE7B2FF1CBEF2EE0C4E0ACD3E0CBE7874A -r fnord at test.eu -e < /etc/shells > shells.gpg
> gpg: 0x40F9B9601900E974: There is no assurance this key belongs to the named user

I tried something like this with my MUA, I believe that doesn't work:
it first looks for appropriate keys, probably using --list-keys;
in fact, it insists on choosing a single key when multiple ones
are available.

...
> It is NOT certain that the key belongs to the person named
> in the user ID.  If you *really* know what you are doing,
> you may answer the next question with yes.
> 
> Use this key anyway? (y/N) y

This is another issue ADK might handle differently---if gpg skipped
validation of the donor keys (where ADK subkeys come from),
I wouldn't have to certify any UIDs in it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230504/3b59589f/attachment.sig>

From andrewg at andrewg.com  Thu May  4 12:01:36 2023
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Thu, 4 May 2023 11:01:36 +0100
Subject: out-of-key UIDs [was: ADK's]
In-Reply-To: <ZFN+XHEcPj4Qzg1h@desdichado>
References: <20230501113851.GC13977@manas>
 <D0705386-F805-4795-B5BE-C0B00A0C5D85@andrewg.com>
 <ZFNGsjD4JZjjVAGO@desdichado>
 <8F6EEFCA-59B6-491B-852A-512CF5BCDDDB@andrewg.com>
 <ZFN+XHEcPj4Qzg1h@desdichado>
Message-ID: <65178614-13F7-4852-A7A9-CDCA5B4C7450@andrewg.com>

On 4 May 2023, at 10:43, Ineiev <ineiev at gnu.org> wrote:
> 
> On Thu, May 04, 2023 at 09:52:54AM +0100, Andrew Gallagher wrote:
>> 
>> andrewg at serenity % gpg --group fnord at test.eu=BD9D4DEE7B2FF1CBEF2EE0C4E0ACD3E0CBE7874A -r fnord at test.eu -e < /etc/shells > shells.gpg
>> gpg: 0x40F9B9601900E974: There is no assurance this key belongs to the named user
> 
> I tried something like this with my MUA, I believe that doesn't work:
> it first looks for appropriate keys, probably using --list-keys;
> in fact, it insists on choosing a single key when multiple ones
> are available.

Which MUA is this? I know that Thunderbird doesn?t support gnupg?s groups any more, but it has an equivalent inbuilt feature that you can configure separately.

A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230504/15a8d2c5/attachment.sig>

From wk at gnupg.org  Thu May  4 13:01:20 2023
From: wk at gnupg.org (Werner Koch)
Date: Thu, 04 May 2023 13:01:20 +0200
Subject: out-of-key UIDs [was: ADK's]
In-Reply-To: <ZFN+XHEcPj4Qzg1h@desdichado> (Ineiev via Gnupg-users's message
 of "Thu, 4 May 2023 09:43:56 +0000")
References: <20230501113851.GC13977@manas>
 <D0705386-F805-4795-B5BE-C0B00A0C5D85@andrewg.com>
 <ZFNGsjD4JZjjVAGO@desdichado>
 <8F6EEFCA-59B6-491B-852A-512CF5BCDDDB@andrewg.com>
 <ZFN+XHEcPj4Qzg1h@desdichado>
Message-ID: <87y1m4webj.fsf@wheatstone.g10code.de>

On Thu,  4 May 2023 09:43, Ineiev said:

> This is another issue ADK might handle differently---if gpg skipped
> validation of the donor keys (where ADK subkeys come from),

The ADSK shall work very similar to --encrypt-to - that is it is only
used if there is already an encryption key.  That is why it is named
ADS(ub)K(ey) and not just ADK(ey) - the ADSK is always in your keyblock.

In gnupg/g10/pkclist.c:find_and_check_key at line 921 we got the regular
encryption key and add it to our list of keys.  Right after that we scan
that keyblock for an ADSK (i.e. PUBKEY_USAGE_RENC) and add that one too.


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230504/c2463ff2/attachment.sig>

From take at kasaneiro.jp  Thu May  4 15:15:18 2023
From: take at kasaneiro.jp (WATANABE Takeo)
Date: Thu, 04 May 2023 22:15:18 +0900 (JST)
Subject: Error when making "libgcrypt" [rndgetentropy.c ]
Message-ID: <20230504.221518.1450224712191780766.take@kasaneiro.jp>

Dear. GnuPG-Users.

When making "libgcrypt ver1.10.2" and "libgcrypt ver1.8.10",
I got the following error and the compilation could not proceed.
(Output is line-breaked where appropriate.)

---
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g
	 -O2 -fno-delete-null-pointer-checks -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat
	 -Wno-format-y2k -Wformat-security -W -Wextra -Wbad-function-cast -Wwrite-strings
	 -Wdeclaration-after-statement -Wno-missing-field-initializers -Wno-sign-compare -Wpointer-arith
	 -MT rndgetentropy.lo -MD -MP -MF .deps/rndgetentropy.Tpo -c rndgetentropy.c  -fno-common
	 -DPIC -o .libs/rndgetentropy.orndgetentropy.c:98:21:
	       error: call to undeclared function 'getrandom'; ISO C99 and later do not support implicit
	       function declarations [-Wimplicit-function-declaration]
               ret = getrandom (buffer, nbytes, GRND_RANDOM);
	       	       ^
rndgetentropy.c:98:48: error: use of undeclared identifier 'GRND_RANDOM'
              ret = getrandom (buffer, nbytes, GRND_RANDOM);
							      ^
2 errors generated.
make[2]: *** [rndgetentropy.lo] Error 1
make[2]: Leaving directory `/Users/take/Downloads/GnuPG/libgcrypt-1.10.2/random'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/Users/take/Downloads/GnuPG/libgcrypt-1.10.2'
make: *** [all] Error 2
---

Unfortunately I don't know how to make this 'make' passable.

I am very sorry that this is not about "GnuPG".
Could you please advise me how to avoid this error?

My environment is as follows.
Also, ". /configure" output is attached.

OS         :  macOS  13.3.1 (a) / Command Line Tools for Xcode 14.3
Platform :  Darwin (x86_64-apple-darwin22.4.0)

Sincerely yours.
---
WATANABE, Takeo
take at kasaneiro.jp

-------------- next part --------------
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... build-aux/install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking build system type... x86_64-apple-darwin22.4.0
checking host system type... x86_64-apple-darwin22.4.0
checking whether to enable maintainer-specific portions of Makefiles... yes
checking whether make supports nested variables... (cached) yes
checking whether make supports the include directive... yes (GNU style)
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether make sets $(MAKE)... (cached) yes
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking how to run the C preprocessor... gcc -E
checking dependency style of gcc... gcc3
checking for library containing strerror... none required
checking for gawk... (cached) awk
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /Library/Developer/CommandLineTools/usr/bin/ld
checking if the linker (/Library/Developer/CommandLineTools/usr/bin/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/local/bin/nm -B
checking the name lister (/usr/local/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 786432
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-apple-darwin22.4.0 file names to x86_64-apple-darwin22.4.0 format... func_convert_file_noop
checking how to convert x86_64-apple-darwin22.4.0 file names to toolchain format... func_convert_file_noop
checking for /Library/Developer/CommandLineTools/usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/local/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... no
checking if : is a manifest tool... no
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for lipo... lipo
checking for otool... otool
checking for otool64... no
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking for -force_load linker flag... no
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking for gcc option to produce PIC... -fno-common -DPIC
checking if gcc PIC flag -fno-common -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/Library/Developer/CommandLineTools/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin22.4.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for windres... no
checking spawn.h usability... yes
checking spawn.h presence... yes
checking for spawn.h... yes
checking whether byte ordering is bigendian... no
checking size of unsigned short... 2
checking size of unsigned int... 4
checking size of unsigned long... 8
checking size of unsigned long long... 8
checking size of void *... 8
checking for uintptr_t... yes
checking for UINT64_C... yes
checking size of uint64_t... 8
checking which symmetric ciphers to include... arcfour blowfish cast5 des aes twofish serpent rfc2268 seed camellia idea salsa20 gost28147 chacha20 sm4
checking which public-key ciphers to include... dsa elgamal rsa ecc
checking which message digests to include... crc gostr3411-94  md4 md5 rmd160 sha1 sha256 sha512 sha3 tiger whirlpool stribog blake2 sm3
checking which key derivation functions to include... s2k pkdf2 scrypt
checking which random module to use... default
checking whether use of /dev/random is requested... yes
checking whether the experimental random daemon is requested... no
checking whether MPI and cipher assembler modules are requested... yes
checking whether memory guard is requested... no
checking whether to run large data tests... no
checking whether 'soft' HW feature bits are forced on... no
checking whether use of capabilities is requested... no
checking whether a HMAC binary check is requested... no
checking whether jitter entropy support is requested... yes
checking whether padlock support is requested... yes
checking whether AESNI support is requested... yes
checking whether SHAEXT support is requested... yes
checking whether PCLMUL support is requested... yes
checking whether SSE4.1 support is requested... yes
checking whether DRNG support is requested... yes
checking whether AVX support is requested... yes
checking whether AVX2 support is requested... yes
checking whether NEON support is requested... yes
checking whether ARMv8 Crypto Extension support is requested... yes
checking whether PPC crypto support is requested... yes
checking whether a -O flag munging is requested... yes
checking whether a instrumentation (-fprofile, -fsanitize) munging is requested... yes
checking whether to enable AMD64 as(1) feature detection... yes
checking for gpg-error-config... no
checking for gpgrt-config... /usr/local/bin/gpgrt-config
configure: Use gpgrt-config with /usr/local/lib as gpg-error-config
checking for GPG Error - version >= 1.27... yes (1.47)
checking for pthread_create in -lpthread... yes
checking for library containing setsockopt... none required
checking for library containing setsockopt... (cached) none required
checking for unistd.h... (cached) yes
checking sys/auxv.h usability... no
checking sys/auxv.h presence... no
checking for sys/auxv.h... no
checking sys/random.h usability... yes
checking sys/random.h presence... yes
checking for sys/random.h... yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for size_t... yes
checking for pid_t... yes
checking for byte... no
checking for ushort... yes
checking for u16... no
checking for u32... no
checking for u64... no
checking for sys/socket.h... yes
checking for socklen_t... yes
checking for __builtin_bswap32... yes
checking for __builtin_bswap64... yes
checking for __builtin_ctz... yes
checking for __builtin_ctzl... yes
checking for __builtin_clz... yes
checking for __builtin_clzl... yes
checking for __sync_synchronize... yes
checking whether the variable length arrays are supported... yes
checking whether the visibility attribute is supported... no
checking whether the GCC style aligned attribute is supported... yes
checking whether the GCC style packed attribute is supported... yes
checking whether the GCC style may_alias attribute is supported... yes
checking whether 'asm' assembler keyword is supported... yes
checking whether '__asm__' assembler keyword is supported... yes
checking whether inline assembly memory barrier is supported... yes
checking whether GCC assembler is compatible for ARM assembly implementations... no
checking whether GCC assembler is compatible for ARMv8/Aarch64 assembly implementations... no
checking whether GCC assembler supports for CFI directives... no
checking whether GCC assembler supports for ELF directives... no
checking for _ prefix in compiled symbols... yes
checking architecture and mpi assembler functions... x86
checking whether compiler supports 'ms_abi' function attribute... yes
checking whether compiler supports 'sysv_abi' function attribute... yes
checking whether default calling convention is 'ms_abi'... no
checking whether default calling convention is 'sysv_abi'... yes
checking whether GCC inline assembler supports SSSE3 instructions... yes
checking whether GCC inline assembler supports PCLMUL instructions... yes
checking whether GCC inline assembler supports SHA Extensions instructions... yes
checking whether GCC inline assembler supports SSE4.1 instructions... yes
checking whether GCC inline assembler supports AVX instructions... yes
checking whether GCC inline assembler supports AVX2 instructions... yes
checking whether GCC inline assembler supports VAES and VPCLMUL instructions... yes
checking whether GCC inline assembler supports BMI2 instructions... yes
checking whether GCC assembler handles division correctly... no
checking whether GCC assembler handles division correctly with "-Wa,--divide"... no
checking whether GCC assembler is compatible for amd64 assembly implementations... no
checking whether GCC assembler is compatible for Intel syntax assembly implementations... no
checking whether compiler is configured for ARMv6 or newer architecture... n/a
checking whether GCC inline assembler supports NEON instructions... n/a
checking whether GCC inline assembler supports AArch32 Crypto Extension instructions... n/a
checking whether GCC inline assembler supports AArch64 NEON instructions... n/a
checking whether GCC inline assembler supports AArch64 Crypto Extension instructions... n/a
checking whether compiler supports PowerPC AltiVec/VSX intrinsics... n/a
checking whether GCC inline assembler supports PowerPC AltiVec/VSX/crypto instructions... n/a
checking whether GCC inline assembler supports PowerISA 3.00 instructions... n/a
checking whether GCC inline assembler supports zSeries instructions... n/a
checking whether GCC inline assembler supports zSeries vector instructions... n/a
checking for vprintf... yes
checking for _doprnt... no
checking for stpcpy... yes
checking for strcasecmp... yes
checking for strtoul... yes
checking for memmove... yes
checking for stricmp... no
checking for atexit... yes
checking for raise... yes
checking for strerror... yes
checking for rand... yes
checking for mmap... yes
checking for getpagesize... yes
checking for sysconf... yes
checking for waitpid... yes
checking for wait4... yes
checking for gettimeofday... yes
checking for getrusage... yes
checking for gethrtime... no
checking for clock_gettime... yes
checking for syslog... yes
checking for syscall... yes
checking for fcntl... yes
checking for ftruncate... yes
checking for flockfile... yes
checking for getauxval... no
checking for elf_aux_info... no
checking for explicit_bzero... no
checking for explicit_memset... no
checking for getentropy... yes
checking for mlock... yes
checking for sysconf... (cached) yes
checking for getpagesize... (cached) yes
checking whether mlock is broken... no
checking for getpid... yes
checking for clock... yes
checking for random device... yes
configure: checking for cc features
checking if gcc supports -fno-delete-null-pointer-checks... yes
checking if gcc supports -Wno-missing-field-initializers... yes
checking if gcc supports -Wpointer-arith... yes
checking whether non excutable stack support is requested... yes
checking whether assembler supports --noexecstack option... no
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating m4/Makefile
config.status: creating compat/Makefile
config.status: creating mpi/Makefile
config.status: creating cipher/Makefile
config.status: creating random/Makefile
config.status: creating doc/Makefile
config.status: creating src/Makefile
config.status: creating src/gcrypt.h
config.status: creating src/libgcrypt-config
config.status: creating src/libgcrypt.pc
config.status: creating src/versioninfo.rc
config.status: creating tests/Makefile
config.status: creating tests/hashtest-256g
config.status: creating tests/basic-disable-all-hwf
config.status: creating config.h
config.status: linking mpi/amd64/mpih-add1.S to mpi/mpih-add1-asm.S
config.status: linking mpi/amd64/mpih-sub1.S to mpi/mpih-sub1-asm.S
config.status: linking mpi/amd64/mpih-mul1.S to mpi/mpih-mul1-asm.S
config.status: linking mpi/amd64/mpih-mul2.S to mpi/mpih-mul2-asm.S
config.status: linking mpi/amd64/mpih-mul3.S to mpi/mpih-mul3-asm.S
config.status: linking mpi/amd64/mpih-lshift.S to mpi/mpih-lshift-asm.S
config.status: linking mpi/amd64/mpih-rshift.S to mpi/mpih-rshift-asm.S
config.status: linking mpi/amd64/mpi-asm-defs.h to mpi/mpi-asm-defs.h
config.status: executing depfiles commands
config.status: executing libtool commands
config.status: executing gcrypt-conf commands
         
        Libgcrypt v1.10.2 has been configured as follows:
         
        Platform:                  Darwin (x86_64-apple-darwin22.4.0)
        Hardware detection module: libgcrypt_la-hwf-x86
        Enabled cipher algorithms: arcfour blowfish cast5 des aes twofish
                                   serpent rfc2268 seed camellia idea salsa20
                                   gost28147 chacha20 sm4
        Enabled digest algorithms: crc gostr3411-94 md4 md5 rmd160 sha1
                                   sha256 sha512 sha3 tiger whirlpool stribog
                                   blake2 sm3
        Enabled kdf algorithms:    s2k pkdf2 scrypt
        Enabled pubkey algorithms: dsa elgamal rsa ecc
        Random number generator:   default
        Try using jitter entropy:  yes
        Using linux capabilities:  no
        FIPS module version:       
        Try using Padlock crypto:  yes
        Try using AES-NI crypto:   yes
        Try using Intel SHAEXT:    yes
        Try using Intel PCLMUL:    yes
        Try using Intel SSE4.1:    yes
        Try using DRNG (RDRAND):   yes
        Try using Intel AVX:       yes
        Try using Intel AVX2:      yes
        Try using ARM NEON:        n/a
        Try using ARMv8 crypto:    n/a
        Try using PPC crypto:      n/a
         

From take at kasaneiro.jp  Thu May  4 17:31:53 2023
From: take at kasaneiro.jp (WATANABE Takeo)
Date: Fri, 05 May 2023 00:31:53 +0900 (JST)
Subject: About Problem of Error when making "libgcrypt" [rndgetentropy.c ]
Message-ID: <20230505.003153.1079694876199004300.take@kasaneiro.jp>

Dear.  GnuPG-Users ML  members

When making "libgcrypt ver1.10.2" and "libgcrypt ver1.8.10",
I got the following problem of  error and the compilation could not proceed.
(Output is line-breaked where appropriate.)

---
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g
	 -O2 -fno-delete-null-pointer-checks -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat
	 -Wno-format-y2k -Wformat-security -W -Wextra -Wbad-function-cast -Wwrite-strings
	 -Wdeclaration-after-statement -Wno-missing-field-initializers -Wno-sign-compare -Wpointer-arith
	 -MT rndgetentropy.lo -MD -MP -MF .deps/rndgetentropy.Tpo -c rndgetentropy.c  -fno-common
	 -DPIC -o .libs/rndgetentropy.orndgetentropy.c:98:21:
	       error: call to undeclared function 'getrandom'; ISO C99 and later do not support implicit
	       function declarations [-Wimplicit-function-declaration]
               ret = getrandom (buffer, nbytes, GRND_RANDOM);
	       	       ^
rndgetentropy.c:98:48: error: use of undeclared identifier 'GRND_RANDOM'
              ret = getrandom (buffer, nbytes, GRND_RANDOM);
							      ^
2 errors generated.
make[2]: *** [rndgetentropy.lo] Error 1
make[2]: Leaving directory `/Users/take/Downloads/GnuPG/libgcrypt-1.10.2/random'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/Users/take/Downloads/GnuPG/libgcrypt-1.10.2'
make: *** [all] Error 2
---

Unfortunately I don't know how to make this 'make' passable.

Could you please advise how to bypass this error?

My environment is as follows.
Also, ". /configure" output is attached.

OS         :  macOS  13.3.1 (a) / Command Line Tools for Xcode 14.3
Platform :  Darwin (x86_64-apple-darwin22.4.0)

Sincerely yours.
---
WATANABE, Takeo
take at kasaneiro.jp

C
-------------- next part --------------
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... build-aux/install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking build system type... x86_64-apple-darwin22.4.0
checking host system type... x86_64-apple-darwin22.4.0
checking whether to enable maintainer-specific portions of Makefiles... yes
checking whether make supports nested variables... (cached) yes
checking whether make supports the include directive... yes (GNU style)
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether make sets $(MAKE)... (cached) yes
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking how to run the C preprocessor... gcc -E
checking dependency style of gcc... gcc3
checking for library containing strerror... none required
checking for gawk... (cached) awk
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /Library/Developer/CommandLineTools/usr/bin/ld
checking if the linker (/Library/Developer/CommandLineTools/usr/bin/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/local/bin/nm -B
checking the name lister (/usr/local/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 786432
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-apple-darwin22.4.0 file names to x86_64-apple-darwin22.4.0 format... func_convert_file_noop
checking how to convert x86_64-apple-darwin22.4.0 file names to toolchain format... func_convert_file_noop
checking for /Library/Developer/CommandLineTools/usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/local/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... no
checking if : is a manifest tool... no
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for lipo... lipo
checking for otool... otool
checking for otool64... no
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking for -force_load linker flag... no
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking for gcc option to produce PIC... -fno-common -DPIC
checking if gcc PIC flag -fno-common -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/Library/Developer/CommandLineTools/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin22.4.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for windres... no
checking spawn.h usability... yes
checking spawn.h presence... yes
checking for spawn.h... yes
checking whether byte ordering is bigendian... no
checking size of unsigned short... 2
checking size of unsigned int... 4
checking size of unsigned long... 8
checking size of unsigned long long... 8
checking size of void *... 8
checking for uintptr_t... yes
checking for UINT64_C... yes
checking size of uint64_t... 8
checking which symmetric ciphers to include... arcfour blowfish cast5 des aes twofish serpent rfc2268 seed camellia idea salsa20 gost28147 chacha20 sm4
checking which public-key ciphers to include... dsa elgamal rsa ecc
checking which message digests to include... crc gostr3411-94  md4 md5 rmd160 sha1 sha256 sha512 sha3 tiger whirlpool stribog blake2 sm3
checking which key derivation functions to include... s2k pkdf2 scrypt
checking which random module to use... default
checking whether use of /dev/random is requested... yes
checking whether the experimental random daemon is requested... no
checking whether MPI and cipher assembler modules are requested... yes
checking whether memory guard is requested... no
checking whether to run large data tests... no
checking whether 'soft' HW feature bits are forced on... no
checking whether use of capabilities is requested... no
checking whether a HMAC binary check is requested... no
checking whether jitter entropy support is requested... yes
checking whether padlock support is requested... yes
checking whether AESNI support is requested... yes
checking whether SHAEXT support is requested... yes
checking whether PCLMUL support is requested... yes
checking whether SSE4.1 support is requested... yes
checking whether DRNG support is requested... yes
checking whether AVX support is requested... yes
checking whether AVX2 support is requested... yes
checking whether NEON support is requested... yes
checking whether ARMv8 Crypto Extension support is requested... yes
checking whether PPC crypto support is requested... yes
checking whether a -O flag munging is requested... yes
checking whether a instrumentation (-fprofile, -fsanitize) munging is requested... yes
checking whether to enable AMD64 as(1) feature detection... yes
checking for gpg-error-config... no
checking for gpgrt-config... /usr/local/bin/gpgrt-config
configure: Use gpgrt-config with /usr/local/lib as gpg-error-config
checking for GPG Error - version >= 1.27... yes (1.47)
checking for pthread_create in -lpthread... yes
checking for library containing setsockopt... none required
checking for library containing setsockopt... (cached) none required
checking for unistd.h... (cached) yes
checking sys/auxv.h usability... no
checking sys/auxv.h presence... no
checking for sys/auxv.h... no
checking sys/random.h usability... yes
checking sys/random.h presence... yes
checking for sys/random.h... yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for size_t... yes
checking for pid_t... yes
checking for byte... no
checking for ushort... yes
checking for u16... no
checking for u32... no
checking for u64... no
checking for sys/socket.h... yes
checking for socklen_t... yes
checking for __builtin_bswap32... yes
checking for __builtin_bswap64... yes
checking for __builtin_ctz... yes
checking for __builtin_ctzl... yes
checking for __builtin_clz... yes
checking for __builtin_clzl... yes
checking for __sync_synchronize... yes
checking whether the variable length arrays are supported... yes
checking whether the visibility attribute is supported... no
checking whether the GCC style aligned attribute is supported... yes
checking whether the GCC style packed attribute is supported... yes
checking whether the GCC style may_alias attribute is supported... yes
checking whether 'asm' assembler keyword is supported... yes
checking whether '__asm__' assembler keyword is supported... yes
checking whether inline assembly memory barrier is supported... yes
checking whether GCC assembler is compatible for ARM assembly implementations... no
checking whether GCC assembler is compatible for ARMv8/Aarch64 assembly implementations... no
checking whether GCC assembler supports for CFI directives... no
checking whether GCC assembler supports for ELF directives... no
checking for _ prefix in compiled symbols... yes
checking architecture and mpi assembler functions... x86
checking whether compiler supports 'ms_abi' function attribute... yes
checking whether compiler supports 'sysv_abi' function attribute... yes
checking whether default calling convention is 'ms_abi'... no
checking whether default calling convention is 'sysv_abi'... yes
checking whether GCC inline assembler supports SSSE3 instructions... yes
checking whether GCC inline assembler supports PCLMUL instructions... yes
checking whether GCC inline assembler supports SHA Extensions instructions... yes
checking whether GCC inline assembler supports SSE4.1 instructions... yes
checking whether GCC inline assembler supports AVX instructions... yes
checking whether GCC inline assembler supports AVX2 instructions... yes
checking whether GCC inline assembler supports VAES and VPCLMUL instructions... yes
checking whether GCC inline assembler supports BMI2 instructions... yes
checking whether GCC assembler handles division correctly... no
checking whether GCC assembler handles division correctly with "-Wa,--divide"... no
checking whether GCC assembler is compatible for amd64 assembly implementations... no
checking whether GCC assembler is compatible for Intel syntax assembly implementations... no
checking whether compiler is configured for ARMv6 or newer architecture... n/a
checking whether GCC inline assembler supports NEON instructions... n/a
checking whether GCC inline assembler supports AArch32 Crypto Extension instructions... n/a
checking whether GCC inline assembler supports AArch64 NEON instructions... n/a
checking whether GCC inline assembler supports AArch64 Crypto Extension instructions... n/a
checking whether compiler supports PowerPC AltiVec/VSX intrinsics... n/a
checking whether GCC inline assembler supports PowerPC AltiVec/VSX/crypto instructions... n/a
checking whether GCC inline assembler supports PowerISA 3.00 instructions... n/a
checking whether GCC inline assembler supports zSeries instructions... n/a
checking whether GCC inline assembler supports zSeries vector instructions... n/a
checking for vprintf... yes
checking for _doprnt... no
checking for stpcpy... yes
checking for strcasecmp... yes
checking for strtoul... yes
checking for memmove... yes
checking for stricmp... no
checking for atexit... yes
checking for raise... yes
checking for strerror... yes
checking for rand... yes
checking for mmap... yes
checking for getpagesize... yes
checking for sysconf... yes
checking for waitpid... yes
checking for wait4... yes
checking for gettimeofday... yes
checking for getrusage... yes
checking for gethrtime... no
checking for clock_gettime... yes
checking for syslog... yes
checking for syscall... yes
checking for fcntl... yes
checking for ftruncate... yes
checking for flockfile... yes
checking for getauxval... no
checking for elf_aux_info... no
checking for explicit_bzero... no
checking for explicit_memset... no
checking for getentropy... yes
checking for mlock... yes
checking for sysconf... (cached) yes
checking for getpagesize... (cached) yes
checking whether mlock is broken... no
checking for getpid... yes
checking for clock... yes
checking for random device... yes
configure: checking for cc features
checking if gcc supports -fno-delete-null-pointer-checks... yes
checking if gcc supports -Wno-missing-field-initializers... yes
checking if gcc supports -Wpointer-arith... yes
checking whether non excutable stack support is requested... yes
checking whether assembler supports --noexecstack option... no
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating m4/Makefile
config.status: creating compat/Makefile
config.status: creating mpi/Makefile
config.status: creating cipher/Makefile
config.status: creating random/Makefile
config.status: creating doc/Makefile
config.status: creating src/Makefile
config.status: creating src/gcrypt.h
config.status: creating src/libgcrypt-config
config.status: creating src/libgcrypt.pc
config.status: creating src/versioninfo.rc
config.status: creating tests/Makefile
config.status: creating tests/hashtest-256g
config.status: creating tests/basic-disable-all-hwf
config.status: creating config.h
config.status: linking mpi/amd64/mpih-add1.S to mpi/mpih-add1-asm.S
config.status: linking mpi/amd64/mpih-sub1.S to mpi/mpih-sub1-asm.S
config.status: linking mpi/amd64/mpih-mul1.S to mpi/mpih-mul1-asm.S
config.status: linking mpi/amd64/mpih-mul2.S to mpi/mpih-mul2-asm.S
config.status: linking mpi/amd64/mpih-mul3.S to mpi/mpih-mul3-asm.S
config.status: linking mpi/amd64/mpih-lshift.S to mpi/mpih-lshift-asm.S
config.status: linking mpi/amd64/mpih-rshift.S to mpi/mpih-rshift-asm.S
config.status: linking mpi/amd64/mpi-asm-defs.h to mpi/mpi-asm-defs.h
config.status: executing depfiles commands
config.status: executing libtool commands
config.status: executing gcrypt-conf commands
         
        Libgcrypt v1.10.2 has been configured as follows:
         
        Platform:                  Darwin (x86_64-apple-darwin22.4.0)
        Hardware detection module: libgcrypt_la-hwf-x86
        Enabled cipher algorithms: arcfour blowfish cast5 des aes twofish
                                   serpent rfc2268 seed camellia idea salsa20
                                   gost28147 chacha20 sm4
        Enabled digest algorithms: crc gostr3411-94 md4 md5 rmd160 sha1
                                   sha256 sha512 sha3 tiger whirlpool stribog
                                   blake2 sm3
        Enabled kdf algorithms:    s2k pkdf2 scrypt
        Enabled pubkey algorithms: dsa elgamal rsa ecc
        Random number generator:   default
        Try using jitter entropy:  yes
        Using linux capabilities:  no
        FIPS module version:       
        Try using Padlock crypto:  yes
        Try using AES-NI crypto:   yes
        Try using Intel SHAEXT:    yes
        Try using Intel PCLMUL:    yes
        Try using Intel SSE4.1:    yes
        Try using DRNG (RDRAND):   yes
        Try using Intel AVX:       yes
        Try using Intel AVX2:      yes
        Try using ARM NEON:        n/a
        Try using ARMv8 crypto:    n/a
        Try using PPC crypto:      n/a
         

From wk at gnupg.org  Fri May  5 10:45:52 2023
From: wk at gnupg.org (Werner Koch)
Date: Fri, 05 May 2023 10:45:52 +0200
Subject: Error when making "libgcrypt" [rndgetentropy.c ]
In-Reply-To: <20230504.221518.1450224712191780766.take@kasaneiro.jp> (WATANABE
 Takeo's message of "Thu, 04 May 2023 22:15:18 +0900 (JST)")
References: <20230504.221518.1450224712191780766.take@kasaneiro.jp>
Message-ID: <87ednvw4hr.fsf@wheatstone.g10code.de>

Hi!

> rndgetentropy.c:98:48: error: use of undeclared identifier 'GRND_RANDOM'
>               ret = getrandom (buffer, nbytes, GRND_RANDOM);

> OS         :  macOS  13.3.1 (a) / Command Line Tools for Xcode 14.3
> Platform :  Darwin (x86_64-apple-darwin22.4.0)

There is a glitch in 1.10 which affects macOS.  Please see

https://dev.gnupg.org/T6442

which has a patch.  It should also be possible to use

  ./configure --enable-random=linux

which uses the old /dev/random entrop gatherer.


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230505/5af49f17/attachment.sig>

From ineiev at gnu.org  Fri May  5 18:55:24 2023
From: ineiev at gnu.org (Ineiev)
Date: Fri, 5 May 2023 16:55:24 +0000
Subject: out-of-key UIDs [was: ADK's]
In-Reply-To: <65178614-13F7-4852-A7A9-CDCA5B4C7450@andrewg.com>
References: <20230501113851.GC13977@manas>
 <D0705386-F805-4795-B5BE-C0B00A0C5D85@andrewg.com>
 <ZFNGsjD4JZjjVAGO@desdichado>
 <8F6EEFCA-59B6-491B-852A-512CF5BCDDDB@andrewg.com>
 <ZFN+XHEcPj4Qzg1h@desdichado>
 <65178614-13F7-4852-A7A9-CDCA5B4C7450@andrewg.com>
Message-ID: <20230505165524.GB5453@manas>

On Thu, May 04, 2023 at 11:01:36AM +0100, Andrew Gallagher wrote:
> > I tried something like this with my MUA, I believe that doesn't work:
> > it first looks for appropriate keys, probably using --list-keys;
> > in fact, it insists on choosing a single key when multiple ones
> > are available.
> 
> Which MUA is this?

Mutt.


From andrewg at andrewg.com  Fri May  5 19:05:47 2023
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Fri, 5 May 2023 18:05:47 +0100
Subject: out-of-key UIDs [was: ADK's]
In-Reply-To: <20230505165524.GB5453@manas>
References: <20230501113851.GC13977@manas>
 <D0705386-F805-4795-B5BE-C0B00A0C5D85@andrewg.com>
 <ZFNGsjD4JZjjVAGO@desdichado>
 <8F6EEFCA-59B6-491B-852A-512CF5BCDDDB@andrewg.com>
 <ZFN+XHEcPj4Qzg1h@desdichado>
 <65178614-13F7-4852-A7A9-CDCA5B4C7450@andrewg.com>
 <20230505165524.GB5453@manas>
Message-ID: <0116BD62-48FE-4171-9491-81CD4DF25F05@andrewg.com>

On 5 May 2023, at 17:55, Ineiev <ineiev at gnu.org> wrote:
> 
> On Thu, May 04, 2023 at 11:01:36AM +0100, Andrew Gallagher wrote:
>>> I tried something like this with my MUA, I believe that doesn't work:
>>> it first looks for appropriate keys, probably using --list-keys;
>>> in fact, it insists on choosing a single key when multiple ones
>>> are available.
>> 
>> Which MUA is this?
> 
> Mutt.

Ah, I see this has been raised before as a missing feature in [neo]mutt:

https://github.com/neomutt/neomutt/issues/404

A
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230505/09f8f4da/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230505/09f8f4da/attachment-0001.sig>

From take at kasaneiro.jp  Sun May  7 03:17:37 2023
From: take at kasaneiro.jp (WATANABE Takeo)
Date: Sun, 07 May 2023 10:17:37 +0900 (JST)
Subject: Error when making "libgcrypt" [rndgetentropy.c ]
In-Reply-To: <87ednvw4hr.fsf@wheatstone.g10code.de>
References: <20230504.221518.1450224712191780766.take@kasaneiro.jp>
 <87ednvw4hr.fsf@wheatstone.g10code.de>
Message-ID: <20230507.101737.2032287572084591303.take@kasaneiro.jp>

Hi.

on Fri, 05 May 2023 10:45:52 +0200
Werner Koch <wk at gnupg.org> wrote: 

>> rndgetentropy.c:98:48: error: use of undeclared identifier 'GRND_RANDOM'
>>               ret = getrandom (buffer, nbytes, GRND_RANDOM);
> 
>> OS         :  macOS  13.3.1 (a) / Command Line Tools for Xcode 14.3
>> Platform :  Darwin (x86_64-apple-darwin22.4.0)
> 
> There is a glitch in 1.10 which affects macOS.  Please see
> 
> https://dev.gnupg.org/T6442
> 
> which has a patch.  It should also be possible to use
> 
>   ./configure --enable-random=linux
> 
> which uses the old /dev/random entrop gatherer.

I applied the three patches listed on the indicated webpage,
and make went through without any problems.

Thank you very much for your help.

Sincerely yours

---
WATANABE, Takeo
take at kasaneiro.jp


From dimxrss at gmail.com  Tue May  9 16:48:31 2023
From: dimxrss at gmail.com (Dim Xr)
Date: Tue, 9 May 2023 17:48:31 +0300
Subject: GPGME question about ciphertext and plaintext sizes
Message-ID: <CA+geccjoXBObUZorY-edd3xcXOV=LsN8-hhDPt+R6syMZV7eZA@mail.gmail.com>

Hello all,
I'm currently working on a userspace block device driver. I want to add
encryption on it,
and that's how I came across GPGME.

My question is: is there a way to encrypt a plaintext and get a ciphertext
of **exactly** the
same size? Is there any way to have FPE (Format Preserving Encryption) via
GPGME?


>From my research so far, it doesn't seem to exist one. Even symmetric
algorithms are using
metadata on the ciphertext so the size is always bigger than the
corresponding plaintext.

All suggestions are welcome!

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230509/724bf18f/attachment.html>

From wk at gnupg.org  Wed May 10 12:59:07 2023
From: wk at gnupg.org (Werner Koch)
Date: Wed, 10 May 2023 12:59:07 +0200
Subject: GPGME question about ciphertext and plaintext sizes
In-Reply-To: <CA+geccjoXBObUZorY-edd3xcXOV=LsN8-hhDPt+R6syMZV7eZA@mail.gmail.com>
 (Dim Xr via Gnupg-users's message of "Tue, 9 May 2023 17:48:31 +0300")
References: <CA+geccjoXBObUZorY-edd3xcXOV=LsN8-hhDPt+R6syMZV7eZA@mail.gmail.com>
Message-ID: <87ednotptw.fsf@wheatstone.g10code.de>

On Tue,  9 May 2023 17:48, Dim Xr said:

> same size? Is there any way to have FPE (Format Preserving Encryption) via
> GPGME?

No.  GPGME uses the OpenPGP and S/MIME protocols (gpg and gpgsm) and is
not suitable for your task.  You need to use a low level crypto library
for that (e.g. Libgcrypt) and decide which algorithm, mode and
additional information you use.  For example it is possible to create an
IV or nonce from the block number but there are many security pitfalls.
You may want to read some papers about crypto file systems and look at
implementations for Linux and *BSD.

In GnuPG we have a disk encryption tools (g13) but that takes only care
of encrypting the actual symmetric encryption key.  Everything else is
left to dmcrypt.


Shalom-Salam,

   Werner


-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230510/4dbd2503/attachment.sig>

From dimxrss at gmail.com  Wed May 10 13:43:46 2023
From: dimxrss at gmail.com (Dim Xr)
Date: Wed, 10 May 2023 14:43:46 +0300
Subject: GPGME question about ciphertext and plaintext sizes
In-Reply-To: <87ednotptw.fsf@wheatstone.g10code.de>
References: <CA+geccjoXBObUZorY-edd3xcXOV=LsN8-hhDPt+R6syMZV7eZA@mail.gmail.com>
 <87ednotptw.fsf@wheatstone.g10code.de>
Message-ID: <CA+gecch1FbN=CDApESR6XNcV0EtnmG1qwety88GSeYqt2gxgug@mail.gmail.com>

Thank you Werner.

You need to use a low level crypto library
> for that (e.g. Libgcrypt) and decide which algorithm, mode and
> additional information you use.
>

OK I'll check it out. Searching on the mailing list responses I
came across with Libgcrypt again, but I've read that it is quite
low-level library so you have  to be some kind of guru to use it. :-)
I'm far from a security expert, that's why I needed a more
higher level solution for this. But definitely I'll give it a shot.

Do you know if OpenSSL is suitable for this task?

Dim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230510/add6c9d1/attachment.html>

From guillermo13325 at gmail.com  Fri May 12 22:08:04 2023
From: guillermo13325 at gmail.com (Guillermo Montoya Naranjo)
Date: Fri, 12 May 2023 15:08:04 -0500
Subject: "gpg: no valid OpenPGP data found" error when importing public key
 from sks
Message-ID: <CAB2neyZ4SP6xF8xgwiYetXnzERqNa7WyO2sCNUpJ-M7FOq2O9A@mail.gmail.com>

Good afternoon, I have an sks server installed, which synchronizes with
kleopatra, I create a pair of openPGPG keys, which I then publish to the
sks server and it does it successfully, but when I execute the search
option, it throws me the following error, as shown in the image

gpg: no valid OpenPGP data found
gpg: Total amount processed: 0
I have installed Gpg4win 4.1.0 and a sks 1.1.6 server
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230512/099c2d47/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot_1.png
Type: image/png
Size: 7963 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230512/099c2d47/attachment-0001.png>

From andrewg at andrewg.com  Sun May 14 14:41:47 2023
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Sun, 14 May 2023 13:41:47 +0100
Subject: "gpg: no valid OpenPGP data found" error when importing public
 key from sks
In-Reply-To: <CAB2neyZ4SP6xF8xgwiYetXnzERqNa7WyO2sCNUpJ-M7FOq2O9A@mail.gmail.com>
References: <CAB2neyZ4SP6xF8xgwiYetXnzERqNa7WyO2sCNUpJ-M7FOq2O9A@mail.gmail.com>
Message-ID: <9E6B4D58-9263-4982-98AC-59D20D8CAEE4@andrewg.com>

Hi, Guillermo.

You don?t say what sort of keys these are. V4? V5? Elliptic curve? Some recent kinds of keys may not be compatible with SKS. Have you compared with hockeypuck to see if it serves them any differently?

Thanks,
Andrew.

> On 12 May 2023, at 21:08, Guillermo Montoya Naranjo via Gnupg-users <gnupg-users at gnupg.org> wrote:
> 
> Good afternoon, I have an sks server installed, which synchronizes with kleopatra, I create a pair of openPGPG keys, which I then publish to the sks server and it does it successfully, but when I execute the search option, it throws me the following error, as shown in the image
> 
> gpg: no valid OpenPGP data found
> gpg: Total amount processed: 0
> I have installed Gpg4win 4.1.0 and a sks 1.1.6 server
> <Screenshot_1.png>_______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230514/0e2c69c6/attachment.sig>

From wk at gnupg.org  Mon May 15 15:10:35 2023
From: wk at gnupg.org (Werner Koch)
Date: Mon, 15 May 2023 15:10:35 +0200
Subject: GPGME question about ciphertext and plaintext sizes
In-Reply-To: <CA+gecch1FbN=CDApESR6XNcV0EtnmG1qwety88GSeYqt2gxgug@mail.gmail.com>
 (Dim Xr via Gnupg-users's message of "Wed, 10 May 2023 14:43:46
 +0300")
References: <CA+geccjoXBObUZorY-edd3xcXOV=LsN8-hhDPt+R6syMZV7eZA@mail.gmail.com>
 <87ednotptw.fsf@wheatstone.g10code.de>
 <CA+gecch1FbN=CDApESR6XNcV0EtnmG1qwety88GSeYqt2gxgug@mail.gmail.com>
Message-ID: <87fs7xsptg.fsf@wheatstone.g10code.de>

On Wed, 10 May 2023 14:43, Dim Xr said:

> I'm far from a security expert, that's why I needed a more
> higher level solution for this. But definitely I'll give it a shot.

Use DMCrypt under Linux or Veracrypt etc.   Disk encryption is a
complicated matter and you definitley should have some experience in
this area.

> Do you know if OpenSSL is suitable for this task?

The same as Libgcrypt is.


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230515/a441749a/attachment.sig>

From lists at lrose.de  Tue May 16 01:19:28 2023
From: lists at lrose.de (LuKaRo)
Date: Tue, 16 May 2023 01:19:28 +0200
Subject: GPG agent returns subset of keys for SSH
Message-ID: <808145a1-5858-b327-efdb-8620b3fd1d42@lrose.de>

Hi,

I want to use gpg-agent to authenticate to an SSH server via key. This 
has previously worked on this machine when I was using a Nitrokey, now I 
imported the key that was on the Nitrokey locally from a backup, and SSH 
authentication no longer works.

ssh -vvvv server lists these interesting messages:

debug3: ssh_get_authentication_socket_path: path 
'/run/user/1000/gnupg/S.gpg-agent.ssh'
debug2: get_agent_identities: ssh_agent_bind_hostkey: agent refused 
operation
debug1: get_agent_identities: ssh_fetch_identitylist: agent contains no 
identities

However, gpg --list-secret-keys shows this:

sec?? rsa4096 2020-04-07 [SC]
 ????? 94B238AAE6682E5063896F2B7920D03B7AA7CD7B
uid?????????? [ultimate] Lu Ro (New general key) <public at lrose.de>
ssb?? rsa4096 2020-04-07 [E]
ssb?? rsa4096 2020-04-07 [A]

So the authenticate subkey is indeed present.

I executed ssh-add without arguments, and two keys were added from my 
.ssh directory. Now ssh -vvvv shows this:

debug3: ssh_get_authentication_socket_path: path 
'/run/user/1000/gnupg/S.gpg-agent.ssh'
debug2: get_agent_identities: ssh_agent_bind_hostkey: agent refused 
operation
debug1: get_agent_identities: agent returned 2 keys

So communication with the gpg-agent seems to work as well. Any ideas 
what could be the issue?

Thanks in advance,

lukaro



From lists at lrose.de  Tue May 16 01:22:19 2023
From: lists at lrose.de (LuKaRo)
Date: Tue, 16 May 2023 01:22:19 +0200
Subject: Fwd: GPG agent returns subset of keys for SSH
In-Reply-To: <808145a1-5858-b327-efdb-8620b3fd1d42@lrose.de>
References: <808145a1-5858-b327-efdb-8620b3fd1d42@lrose.de>
Message-ID: <3803bede-b26f-5ea7-f89d-6ce74c1cbe14@lrose.de>

Hi,

I want to use gpg-agent to authenticate to an SSH server via key. This 
has previously worked on this machine when I was using a Nitrokey, now I 
imported the key that was on the Nitrokey locally from a backup, and SSH 
authentication no longer works.

ssh -vvvv server lists these interesting messages:

debug3: ssh_get_authentication_socket_path: path 
'/run/user/1000/gnupg/S.gpg-agent.ssh'
debug2: get_agent_identities: ssh_agent_bind_hostkey: agent refused 
operation
debug1: get_agent_identities: ssh_fetch_identitylist: agent contains no 
identities

However, gpg --list-secret-keys shows this:

sec?? rsa4096 2020-04-07 [SC]
 ????? 94B238AAE6682E5063896F2B7920D03B7AA7CD7B
uid?????????? [ultimate] Lu Ro (New general key) <public at lrose.de>
ssb?? rsa4096 2020-04-07 [E]
ssb?? rsa4096 2020-04-07 [A]

So the authenticate subkey is indeed present.

I executed ssh-add without arguments, and two keys were added from my 
.ssh directory. Now ssh -vvvv shows this:

debug3: ssh_get_authentication_socket_path: path 
'/run/user/1000/gnupg/S.gpg-agent.ssh'
debug2: get_agent_identities: ssh_agent_bind_hostkey: agent refused 
operation
debug1: get_agent_identities: agent returned 2 keys

So communication with the gpg-agent seems to work as well. Any ideas 
what could be the issue?

Thanks in advance,

lukaro


From wk at gnupg.org  Tue May 16 16:45:44 2023
From: wk at gnupg.org (Werner Koch)
Date: Tue, 16 May 2023 16:45:44 +0200
Subject: GPG agent returns subset of keys for SSH
In-Reply-To: <808145a1-5858-b327-efdb-8620b3fd1d42@lrose.de> (LuKaRo's message
 of "Tue, 16 May 2023 01:19:28 +0200")
References: <808145a1-5858-b327-efdb-8620b3fd1d42@lrose.de>
Message-ID: <87cz30qqqv.fsf@wheatstone.g10code.de>

On Tue, 16 May 2023 01:19, LuKaRo said:

> '/run/user/1000/gnupg/S.gpg-agent.ssh'
> debug2: get_agent_identities: ssh_agent_bind_hostkey: agent refused
> operation

You should log the other side of the things: Put

log-file /whatever/you/want
verbose
debug ipc

into ~/.gnupg/gpg-agent.conf and "gpgconf --kill gpg-agent".  If you
are not yet running 2.4 (or the older 2.3) you should definitely do so.


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230516/71d48f71/attachment.sig>

From mike at mdsresource.net  Sat May 20 18:20:42 2023
From: mike at mdsresource.net (Mike Schleif)
Date: Sat, 20 May 2023 11:20:42 -0500
Subject: Finally moving from 2.0.22 to 2.2.x or higher
Message-ID: <CACNUArB1g9GyV9QZbvRK+QiLbBRu7HW+ThTyHwLHCZqnHpcicw@mail.gmail.com>

What do we need to know about using our existing keyring, and copious CLIs,
that we use to encrypt, decrypt and administer our legacy GPG?

As previously posted, we are on Centos 7.9.2009, which only supports GPG
v2.0.x.

Until we upgrade Centos later this year, I've been reviewing suggestions on
how to upgrade to 2.2.17 and higher, which we're about to undertake.

How can we "import" our existing keyring into newer GPG?

What else do we need to know, and prepare for, for our production use?

Please, advise. Thank you.

~ Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230520/60a88af0/attachment.html>

From rirelan at gmail.com  Sat May 20 02:38:15 2023
From: rirelan at gmail.com (Robert Irelan)
Date: Fri, 19 May 2023 17:38:15 -0700
Subject: epg-encrypt-string in Emacs seems to be incompatible with GnuPG 2.4.1
 on macOS, 2.4.0 works
Message-ID: <CAJUyYjourONojWUtPo4faLk-EQvY6MPAosbowGRj=TmSA3v40Q@mail.gmail.com>

I'm not sure what info will be most useful for debugging this, but the
`epg-encrypt-string` function seems not to work with GnuPG 2.4.1 on
macOS, while GnuPG 2.4.0 works (both on x86_64, macOS 13.3.1, Macports
used to install both).

This is the command line that seems to hang with 2.4.1:

```
/opt/local/bin/gpg2 --no-tty --status-fd 1 --yes
--enable-progress-filter --command-fd 0 --output
/var/folders/gc/73c5zcp918z9dssx8k1sybh00000gn/T/epg-output2zVC4K
--pinentry-mode ask --decrypt --
/var/folders/gc/73c5zcp918z9dssx8k1sybh00000gn/T/epg-inputMnF1UG
```

No settings in common.conf, gpg-agent.conf, or gpg.conf seem to affect
this hanging command. Let me know what info I can provide to help
debug this further

-- 
Robert Irelan
rirelan at gmail.com


From wk at gnupg.org  Mon May 22 09:56:12 2023
From: wk at gnupg.org (Werner Koch)
Date: Mon, 22 May 2023 09:56:12 +0200
Subject: epg-encrypt-string in Emacs seems to be incompatible with GnuPG
 2.4.1 on macOS, 2.4.0 works
In-Reply-To: <CAJUyYjourONojWUtPo4faLk-EQvY6MPAosbowGRj=TmSA3v40Q@mail.gmail.com>
 (Robert Irelan via Gnupg-users's message of "Fri, 19 May 2023 17:38:15
 -0700")
References: <CAJUyYjourONojWUtPo4faLk-EQvY6MPAosbowGRj=TmSA3v40Q@mail.gmail.com>
Message-ID: <87ilckol43.fsf@wheatstone.g10code.de>

Hi!

On Fri, 19 May 2023 17:38, Robert Irelan said:

> This is the command line that seems to hang with 2.4.1:
>
> ```
> /opt/local/bin/gpg2 --no-tty --status-fd 1 --yes
> --enable-progress-filter --command-fd 0 --output
> /var/folders/gc/73c5zcp918z9dssx8k1sybh00000gn/T/epg-output2zVC4K
> --pinentry-mode ask --decrypt --
> /var/folders/gc/73c5zcp918z9dssx8k1sybh00000gn/T/epg-inputMnF1UG
> ```

Here are two places which do not look correct:

  (defun epg-wait-for-completion (context)
    "Wait until the `epg-gpg-program' process completes."
    (while (eq (process-status (epg-context-process context)) 'run)
      (accept-process-output (epg-context-process context) 1))
    ;; This line is needed to run the process-filter right now.
    (sleep-for 0.1)
  
Sleeping for 100ms looks like an error prone hack.

  (defun epg-start-decrypt (context cipher)
    [...]
    ;; `gpgsm' does not read passphrase from stdin, so waiting is not needed.
    (unless (eq (epg-context-protocol context) 'CMS)
      (epg-wait-for-status context '("BEGIN_DECRYPTION"))))

It is quite possible that BEGIN_DECRYPTION is emitted after the request
for a pinentry. It does not look right to wait for it.  I have not
looked into the EasyPG code for many years despite that I am using it
every day.  The use of --command-fd w/o a state machine (or is there one
for decrypt?) to handle the requests is not a good idea;; using --batch
would be better.

Please also see https://dev.gnupg.org/T6481 which is about a very
similar problem.


Salam-Shalom,

   Werner


-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230522/b2cf656f/attachment.sig>

From robin at nitrokey.com  Tue May 23 09:58:28 2023
From: robin at nitrokey.com (Robin Krahl | Nitrokey)
Date: Tue, 23 May 2023 09:58:28 +0200
Subject: Adding one ADSK to multiple keys
Message-ID: <ce6095c9-2310-c242-ebe9-f5f8e34f3686@nitrokey.com>

Hi,

I want to setup one backup key as an ADSK for multiple keys.  After 
adding the ADSK to the first key, further attempts to add the same ADSK 
to other keys fail with the error message:

     gpg: key "44883766ABE65F20453E6FC046D03490A60D7131" not found: 
Wrong key usage
     gpg: Did you specify the fingerprint of a subkey?

My guess is that the fingerprint is resolved to the ADSK of the first 
key with key usage R instead of the original subkey with key usage SEAR. 
  If I delete the key with the first ADSK and try to add the ADSK to a 
second key, gpg can no longer find the original subkey:

     gpg: key "44883766ABE65F20453E6FC046D03490A60D7131" not found: No 
public key

How can I configure the same subkey as an ADSK for multiple other keys?

Regards,
Robin

Full log:

$ gpg --list-keys --with-subkey-fingerprint 

[keyboxd] 
 

--------- 

pub   rsa2048 2023-05-23 [SCEAR] 
 

       0D040E3B31CD2165952E0B2D2630CA1F4CFEC737
uid           [ultimate] Employee 2 (Department A) <e2 at example.com>
sub   rsa2048 2023-05-23 [SEAR]
       A1EE8DAA2FFA67B2963CF9A44C27B306EF295300

pub   rsa2048 2023-05-23 [SCEAR]
       41CED1E71F2F05362BE79793EEAEB08CFA452DAE
uid           [ultimate] Employee 1 (Department A) <e1 at example.com>
sub   rsa2048 2023-05-23 [SEAR]
       55810101E92C4C4ED311BCA94C3578A761AEB703

pub   rsa2048 2023-05-23 [SCEAR]
       6DF5F1752B66B225853F107AA5D29205F3B6E803
uid           [ultimate] Manager (Department A) <ma at example.com>
sub   rsa2048 2023-05-23 [SEAR]
       44883766ABE65F20453E6FC046D03490A60D7131

$ gpg --quick-add-adsk 41CED1E71F2F05362BE79793EEAEB08CFA452DAE 
44883766ABE65F20453E6FC046D03490A60D7131

$ gpg --quick-add-adsk 0D040E3B31CD2165952E0B2D2630CA1F4CFEC737 
44883766ABE65F20453E6FC046D03490A60D7131
gpg: key "44883766ABE65F20453E6FC046D03490A60D7131" not found: Wrong key 
usage
gpg: Did you specify the fingerprint of a subkey?

$ gpg --list-keys --with-subkey-fingerprint
[keyboxd]
---------
pub   rsa2048 2023-05-23 [SCEAR]
       0D040E3B31CD2165952E0B2D2630CA1F4CFEC737
uid           [ultimate] Employee 2 (Department A) <e2 at example.com>
sub   rsa2048 2023-05-23 [SEAR]
       A1EE8DAA2FFA67B2963CF9A44C27B306EF295300

pub   rsa2048 2023-05-23 [SCEAR]
       41CED1E71F2F05362BE79793EEAEB08CFA452DAE
uid           [ultimate] Employee 1 (Department A) <e1 at example.com>
sub   rsa2048 2023-05-23 [SEAR]
       55810101E92C4C4ED311BCA94C3578A761AEB703
sub   rsa2048 2023-05-23 [R]
       44883766ABE65F20453E6FC046D03490A60D7131

pub   rsa2048 2023-05-23 [SCEAR]
       6DF5F1752B66B225853F107AA5D29205F3B6E803
uid           [ultimate] Manager (Department A) <ma at example.com>
sub   rsa2048 2023-05-23 [SEAR]
       44883766ABE65F20453E6FC046D03490A60D7131

$ gpg --delete-secret-key 41CED1E71F2F05362BE79793EEAEB08CFA452DAE

$ gpg --delete-key 41CED1E71F2F05362BE79793EEAEB08CFA452DAE

$ gpg --list-keys --with-subkey-fingerprint 

gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   2  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 2u
[keyboxd]
---------
pub   rsa2048 2023-05-23 [SCEAR]
       0D040E3B31CD2165952E0B2D2630CA1F4CFEC737
uid           [ultimate] Employee 2 (Department A) <e2 at example.com>
sub   rsa2048 2023-05-23 [SEAR]
       A1EE8DAA2FFA67B2963CF9A44C27B306EF295300

pub   rsa2048 2023-05-23 [SCEAR]
       6DF5F1752B66B225853F107AA5D29205F3B6E803
uid           [ultimate] Manager (Department A) <ma at example.com>
sub   rsa2048 2023-05-23 [SEAR]
       44883766ABE65F20453E6FC046D03490A60D7131

$ gpg --quick-add-adsk 0D040E3B31CD2165952E0B2D2630CA1F4CFEC737 
44883766ABE65F20453E6FC046D03490A60D7131
gpg: key "44883766ABE65F20453E6FC046D03490A60D7131" not found: No public key

$ gpg --version
gpg (GnuPG) 2.4.1
libgcrypt 1.10.2
Copyright (C) 2023 g10 Code GmbH
License GNU GPL-3.0-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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x34F47D2F044B8F17.asc
Type: application/pgp-keys
Size: 1002 bytes
Desc: OpenPGP public key
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230523/cb5aa9ad/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230523/cb5aa9ad/attachment.sig>

From wk at gnupg.org  Tue May 23 15:19:23 2023
From: wk at gnupg.org (Werner Koch)
Date: Tue, 23 May 2023 15:19:23 +0200
Subject: Adding one ADSK to multiple keys
In-Reply-To: <ce6095c9-2310-c242-ebe9-f5f8e34f3686@nitrokey.com> (Robin
 Krahl's message of "Tue, 23 May 2023 09:58:28 +0200")
References: <ce6095c9-2310-c242-ebe9-f5f8e34f3686@nitrokey.com>
Message-ID: <87h6s3mbhg.fsf@wheatstone.g10code.de>

Hi!

thanks for the report.

> My guess is that the fingerprint is resolved to the ADSK of the first
> key with key usage R instead of the original subkey with key usage

Sounds right.  Depends on the structure of the keyring.

Need to develop a fix.  See https://dev.gnupg.org/T6504


Shalom-Salam,

   Werner


-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230523/90f2e260/attachment.sig>

From wk at gnupg.org  Tue May 23 15:25:53 2023
From: wk at gnupg.org (Werner Koch)
Date: Tue, 23 May 2023 15:25:53 +0200
Subject: Finally moving from 2.0.22 to 2.2.x or higher
In-Reply-To: <CACNUArB1g9GyV9QZbvRK+QiLbBRu7HW+ThTyHwLHCZqnHpcicw@mail.gmail.com>
 (Mike Schleif's message of "Sat, 20 May 2023 11:20:42 -0500")
References: <CACNUArB1g9GyV9QZbvRK+QiLbBRu7HW+ThTyHwLHCZqnHpcicw@mail.gmail.com>
Message-ID: <87bkibmb6m.fsf@wheatstone.g10code.de>

On Sat, 20 May 2023 11:20, Mike Schleif said:

> How can we "import" our existing keyring into newer GPG?

You actually don't need to do anything.  gpg auto-migrates the private
keys.  If everything works then for you, you may delete the secring.gpg
which is not anymore used (but better take a backup).  Your private keys
will then be in private-keys-v1.d/ and a file
~/gnupg/.gnupg-v21-migrated shows thathe migration was successful.



Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230523/b81eeccd/attachment.sig>

From bernhard at intevation.de  Thu May 25 18:23:37 2023
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 25 May 2023 18:23:37 +0200
Subject: Mastodon account(s), server search
In-Reply-To: <202212011742.56784.bernhard@intevation.de>
References: <202212011742.56784.bernhard@intevation.de>
Message-ID: <202305251823.44850.bernhard@intevation.de>

Hello,

Am Donnerstag 01 Dezember 2022 17:42:47 schrieb Bernhard Reiter:
> seems to be a good time to start an official Mastodon account
> for GnuPG and related topics like Gpg4win and OpenPGP.

this plan was frozen
 first by the future OpenPGP standards (see gnupg-devel@ from the 26th on).
 secondly by me being unable to work for several weeks

> At least for announcements and some interaction as the interest
> is growing for this decentral platform.

I'm picking it up again and assume ongoing interest.

== Server selection details


>  initial rough requirements:
>  * located in Europe
     (preferred, because many GnuPG / Gpg4win people 
      know the legal environment in the EU better)
>  * can be volunteeringly paid for
>  * some volume / track record to expect a good administration
>  * a moderation and contents policy that allows for respectful
>    exchange, but is liberal in that commercial Free Software
>    topics (and broad other topics) are allowed as well.
>  * (optional) Free Software and privacy friendly organisation

Found more:
 * can take the potential load (https://twitter.com/gnupg as 20k followers)
 * (optional) Tor network access
 * German any English?

The latter is a question if we should make two account, one for Englisch and 
one for German. There are quite a lot of German speaking Gpg4win and GnuPG 
users, it probably is the second largest group after English.

Thanks again for the server suggestions, my current ranking is:
  1. https://mstdn.social 35k account
     Has everything, strong point: Tor access.
     Weak point: no advertising
     I've asked, and it is okay to write about professional
     Free Software products as long as it does not flood the public timeline.
    
  2. infosec.exchange 18k
     Servers rented in Germany, Responsible Person in the US. No Tor.
     No FS preferance.
     Strong point: Infosec community (and moderators from that topic)

  3. fosstodon.org 16k
     No Tor.
     weak point: English post only.
    
All are suitable servers and we could migrate of course.
Maybe I'm looking for a server which is a little bit smaller as a forth 
alternative. (I've gave https://pleroma.social servers a brief look, but I 
haven't found a good match. ;) )

Best Regards
Bernhard

 
     
-- 
https://intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230525/434a5068/attachment-0001.sig>

From hfollmann at itcfollmann.com  Thu May 25 19:15:19 2023
From: hfollmann at itcfollmann.com (Henning Follmann)
Date: Thu, 25 May 2023 13:15:19 -0400
Subject: Mastodon account(s), server search
In-Reply-To: <202305251823.44850.bernhard@intevation.de>
References: <202212011742.56784.bernhard@intevation.de>
 <202305251823.44850.bernhard@intevation.de>
Message-ID: <ZG+Xp4UNeQn3JRzG@Oppenheimer>

On Thu, May 25, 2023 at 06:23:37PM +0200, Bernhard Reiter wrote:
> Hello,
> 
> Am Donnerstag 01 Dezember 2022 17:42:47 schrieb Bernhard Reiter:
> > seems to be a good time to start an official Mastodon account
> > for GnuPG and related topics like Gpg4win and OpenPGP.
> 
> this plan was frozen
>  first by the future OpenPGP standards (see gnupg-devel@ from the 26th on).
>  secondly by me being unable to work for several weeks
> 
> > At least for announcements and some interaction as the interest
> > is growing for this decentral platform.
> 
> I'm picking it up again and assume ongoing interest.
> 
> == Server selection details
> 
> 
> >  initial rough requirements:
> >  * located in Europe
>      (preferred, because many GnuPG / Gpg4win people 
>       know the legal environment in the EU better)
> >  * can be volunteeringly paid for
> >  * some volume / track record to expect a good administration
> >  * a moderation and contents policy that allows for respectful
> >    exchange, but is liberal in that commercial Free Software
> >    topics (and broad other topics) are allowed as well.
> >  * (optional) Free Software and privacy friendly organisation
> 
> Found more:
>  * can take the potential load (https://twitter.com/gnupg as 20k followers)
>  * (optional) Tor network access
>  * German any English?
> 
> The latter is a question if we should make two account, one for Englisch and 
> one for German. There are quite a lot of German speaking Gpg4win and GnuPG 
> users, it probably is the second largest group after English.
> 
> Thanks again for the server suggestions, my current ranking is:
>   1. https://mstdn.social 35k account
>      Has everything, strong point: Tor access.
>      Weak point: no advertising
>      I've asked, and it is okay to write about professional
>      Free Software products as long as it does not flood the public timeline.
>     
>   2. infosec.exchange 18k
>      Servers rented in Germany, Responsible Person in the US. No Tor.
>      No FS preferance.
>      Strong point: Infosec community (and moderators from that topic)
> 
>   3. fosstodon.org 16k
>      No Tor.
>      weak point: English post only.
>     

Well there was also the initial thought of spinning "our own" instance.
I still hold the gnupg.social dns registration and I am still willing 
to pay for it and keeping it current.
I also would chip in time as a assistant administrator. Though I have to
say I do not have any experience in running a mastodon instance.


-H


> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users


-- 
Henning Follmann           | hfollmann at itcfollmann.com



From bernhard at intevation.de  Fri May 26 14:09:29 2023
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 26 May 2023 14:09:29 +0200
Subject: Mastodon account: running a server?
In-Reply-To: <ZG+Xp4UNeQn3JRzG@Oppenheimer>
References: <202212011742.56784.bernhard@intevation.de>
 <202305251823.44850.bernhard@intevation.de> <ZG+Xp4UNeQn3JRzG@Oppenheimer>
Message-ID: <202305261409.30413.bernhard@intevation.de>

Hi Henning,

Am Donnerstag 25 Mai 2023 19:15:19 schrieb Henning Follmann:
> Well there was also the initial thought of spinning "our own" instance.

yes, I did not mention it, because I've answered it back then:
The limitation are administration and moderation time.
For this to work out, at least one more person would need to step up.

My idea is that most GnuPG developers will rather improve something specific 
for GnuPG (or the Free Soft ecosystem around it) than running a fedivese 
server.

> I still hold the gnupg.social dns registration and I am still willing
> to pay for it and keeping it current.
> I also would chip in time as a assistant administrator. Though I have to
> say I do not have any experience in running a mastodon instance.

Thanks for both offers!
If someone else comes up and wants to run the server, it may become a viable 
option. (Though I don't know how GnuPG devs think about using the official 
name.)

If this is considered, why not run a Pleroma backend or one of this line.

Best Regards
Bernhard

-- 
https://intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230526/8af6421a/attachment.sig>