From felix.klee at inka.de  Thu Aug  1 03:48:50 2024
From: felix.klee at inka.de (Felix E. Klee)
Date: Thu, 1 Aug 2024 09:48:50 +0800
Subject: ACS APG8201-B2
In-Reply-To: <8734nrtrce.fsf@jumper.gniibe.org>
References: <CA+m_8J0FS=pgZqBwN27eOKDp6TNJ297r+xe-pT3Z=Bp7VuoO3w@mail.gmail.com>
 <CA+m_8J2JS9VfjH6EsHQEr1+UzwMqdRPVRBrBqCRfskzLYVXQUw@mail.gmail.com>
 <87cyn4i8qb.fsf@jacob.g10code.de>
 <CA+m_8J20WnRw0xAij76FLsRv29QS5g-vz8KHHia3qbk=p7OQvg@mail.gmail.com>
 <CA+m_8J270BV+1CX1QgSTra_dGVhG3d0yD2wDzs=4zs1=Qpfs7w@mail.gmail.com>
 <8734nrtrce.fsf@jumper.gniibe.org>
Message-ID: <CA+m_8J3_CF0iMwFDjRCrABQq8nuk77--B5-wRbNp9ST_tHpCUQ@mail.gmail.com>

On Tue, Jul 30, 2024 at 12:51?PM Niibe Yutaka <gniibe at fsij.org> wrote:
> Basically, it's case-by-case thingy when we add new (proprietary)
> hardware support around smartcard + card reader. While we have
> standardized CCID protocol, actually, it depends on each card reader
> plus smartcard combination.

Documentation for the commands is in the reference manual:

https://www.acs.com.hk/download-manual/10212/REF-APG8201-B2-1.00.pdf

I guess someone needs to figure out the right commands and add them to
the code. That someone probably should probably be me, but likely not
any time soon.

> I don't know if it still work for newer Python, but I used to use
> this test program for pinpad input:
>
> https://salsa.debian.org/gnuk-team/gnuk/gnuk/-/blob/master/tool/pinpadtest.py?ref_type=heads

Thanks! It does run, but it times out:

    $ sudo ./pinpadtest.py
    Traceback (most recent call last):
      File "/mnt/c/Users/Felix/Downloads/./pinpadtest.py", line 378, in <module>
        main(who, method, add_a_byte, pinmin, pinmax,
change_by_two_steps, fixed)
      File "/mnt/c/Users/Felix/Downloads/./pinpadtest.py", line 224, in main
        card = Card(add_a_byte, pinmin, pinmax, fixed)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/mnt/c/Users/Felix/Downloads/./pinpadtest.py", line 58, in __init__
        cardservice = cardrequest.waitforcard()
                      ^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/usr/lib/python3/dist-packages/smartcard/CardRequest.py",
line 68, in waitforcard
        return self.pcsccardrequest.waitforcard()
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/usr/lib/python3/dist-packages/smartcard/pcsc/PCSCCardRequest.py",
line 216, in waitforcard
        raise CardRequestTimeoutException()
    smartcard.Exceptions.CardRequestTimeoutException: Time-out during
card request


From Bjorn at xn--rombobjrn-67a.se  Mon Aug  5 20:08:43 2024
From: Bjorn at xn--rombobjrn-67a.se (=?UTF-8?B?QmrDtnJu?= Persson)
Date: Mon, 5 Aug 2024 20:08:43 +0200
Subject: sopv-gpgpv: an implementation of the verification-only subset
 of the Stateless OpenPGP CLI using gpgv as a backend
In-Reply-To: <87o76fw7c5.fsf@fifthhorseman.net>
References: <878qxug03j.fsf@fifthhorseman.net>
 <87h6cgi8ti.fsf@jacob.g10code.de>
 <ZqOqmBzGWAkJu4kQ@teonanacatl.net>
 <87r0bcw5jd.fsf@fifthhorseman.net>
 <ZqfxvewzQddcwP7W@teonanacatl.net>
 <87o76fw7c5.fsf@fifthhorseman.net>
Message-ID: <20240805200844.4666b147@tag.xn--rombobjrn-67a.se>

Daniel Kahn Gillmor via Gnupg-users wrote:
> On Mon 2024-07-29 15:47:09 -0400, Todd Zullinger via Gnupg-users wrote:
> > Using /usr/lib/rpm/redhat/gpgverify -- which is a small
> > shell script wrapper for gpgv -- avoids new dependencies and
> > produces quite readable output which is handy in build logs.  
> 
> is this the source for gpgverify that you're using?
> 
> https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/main/f/gpgverify

That's it, and this is its author speaking.

> This depends explicitly on the return code for gpgv, which is known to
> be brittle.  (it also depends on gpg itself, not just on gpgv, as you
> noted earlier, for the dearmoring)

The gpg2 and gpgv2 commands are both provided by the gnupg2 package,
so they count as a single dependency on the package level.

> For example, if the detached signature contains multiple signatures, and
> gpgv can't verify one of them, it will return a non-zero error code,
> even if it *can* verify the other signature.

It's true that requiring verification of all the signatures is not
always desirable. Allowing all but one to fail is not always right
either. Deciding how many correct signatures should be required is
nontrivial. I doubt any general verification tool can automatically do
the right thing in every case without parameters telling it what's
desired in the specific usecase.

Consider Bitcoin Core as a case study. (Everybody please set aside any
opinions you may have about cryptocurrencies, and focus on the source
code verification.) The Bitcoin Core developers have moved away from a
single release-signing key. They don't want a single central point that
an attacker could compromise. Release tarballs are instead signed by
multiple individuals, each with their own personal key. The set of
signers varies from release to release. Users ? or package maintainers
in the case of packaging in distributions ? aren't required to trust all
the signers. They're expected to choose a few individuals who they deem
trustworthy, and import their keys.

If one downloads a new release of Bitcoin Core, and one signature is
good but none of the others match the tarball, that's almost certainly
a malicious tarball and the one matching signature is made by the
attacker. The situation should be investigated with extreme suspicion.
gpgv would return failure, which is correct in this case. sopv-gpgv
would return OK because one signature could be verified. That's very
bad.

To work around this and return failure in this case, it would be
necessary to write some kind of wrapper around sopv-gpgv ? but a
wrapper around a wrapper would be unnecessary complexity.

If nine out of ten signatures are good, and the tenth is made with an
unknown key, that's not cause for alarm. That tarball should be
considered verified. sopv-gpgv would return OK, which is good in this
case. gpgv would return failure, which is not optimal.

A possible workaround would be to manually remove the signatures by
unknown keys and verify the rest with gpgv. That's doable because the
Bitcoin Core signatures are separately ASCII-armored and then
concatenated into a single signature file. If gpgv says there's no key
for the fifth signature, then delete the fifth ASCII-armored block from
the file. That's not great, but should be workable to a packager with a
basic understanding of signature verification.

Ignoring signatures made with unknown keys, but raising an alarm for any
signature that doesn't match the signed file, would not always be right
either. If there is a group of trusted developers who usually sign every
release, and then one day all but one of the signatures are from unknown
keys, that's also cause for suspicion.

So gpgv has a limitation, and sopv-gpgv has a limitation, but sopv-
gpgv's limitation would be worse for a distribution's security.

> This means every tool that
> depends on gpgverify is going to make it difficult to migrate the
> ecosystem to new cryptographic algorithms.
> 
> The usual approach for that would be to sign the file with both the old
> and new algorithms, and put them both in the detached signature file.
> That way, existing implementations can continue to verify the old
> algorithm, and newer implementations can verify the new one.

I don't remember ever seeing an example of that approach. As far as I
can tell, the usual approach is to have verification tools support both
old and new algorithms. Signers switch keys and signatures to the new
algorithm when they think support for it is sufficiently widespread.
Then support for the old algorithm is removed from tools when almost
nobody uses it anymore.

Bj?rn Persson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signatur
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240805/074d1ccd/attachment.sig>

From jb-gnumlists at wisemo.com  Tue Aug  6 11:32:31 2024
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Tue, 6 Aug 2024 11:32:31 +0200
Subject: sopv-gpgpv: an implementation of the verification-only subset of
 the Stateless OpenPGP CLI using gpgv as a backend
In-Reply-To: <20240805200844.4666b147@tag.xn--rombobjrn-67a.se>
References: <878qxug03j.fsf@fifthhorseman.net>
 <87h6cgi8ti.fsf@jacob.g10code.de> <ZqOqmBzGWAkJu4kQ@teonanacatl.net>
 <87r0bcw5jd.fsf@fifthhorseman.net> <ZqfxvewzQddcwP7W@teonanacatl.net>
 <87o76fw7c5.fsf@fifthhorseman.net>
 <20240805200844.4666b147@tag.xn--rombobjrn-67a.se>
Message-ID: <4131c3c0-ff04-104d-e275-d1b35de35e14@wisemo.com>

On 2024-08-05 20:08, Bj?rn Persson wrote:
> Daniel Kahn Gillmor via Gnupg-users wrote:
>> On Mon 2024-07-29 15:47:09 -0400, Todd Zullinger via Gnupg-users wrote:
>>> Using /usr/lib/rpm/redhat/gpgverify -- which is a small
>>> shell script wrapper for gpgv -- avoids new dependencies and
>>> produces quite readable output which is handy in build logs.
>> is this the source for gpgverify that you're using?
>>
>> https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/main/f/gpgverify
> That's it, and this is its author speaking.
>
>> This depends explicitly on the return code for gpgv, which is known to
>> be brittle.  (it also depends on gpg itself, not just on gpgv, as you
>> noted earlier, for the dearmoring)
> The gpg2 and gpgv2 commands are both provided by the gnupg2 package,
> so they count as a single dependency on the package level.
>
>> For example, if the detached signature contains multiple signatures, and
>> gpgv can't verify one of them, it will return a non-zero error code,
>> even if it *can* verify the other signature.
> It's true that requiring verification of all the signatures is not
> always desirable. Allowing all but one to fail is not always right
> either. Deciding how many correct signatures should be required is
> nontrivial. I doubt any general verification tool can automatically do
> the right thing in every case without parameters telling it what's
> desired in the specific usecase.
>
> Consider Bitcoin Core as a case study. (Everybody please set aside any
> opinions you may have about cryptocurrencies, and focus on the source
> code verification.) The Bitcoin Core developers have moved away from a
> single release-signing key. They don't want a single central point that
> an attacker could compromise. Release tarballs are instead signed by
> multiple individuals, each with their own personal key. The set of
> signers varies from release to release. Users ? or package maintainers
> in the case of packaging in distributions ? aren't required to trust all
> the signers. They're expected to choose a few individuals who they deem
> trustworthy, and import their keys.
>
> If one downloads a new release of Bitcoin Core, and one signature is
> good but none of the others match the tarball, that's almost certainly
> a malicious tarball and the one matching signature is made by the
> attacker. The situation should be investigated with extreme suspicion.
> gpgv would return failure, which is correct in this case. sopv-gpgv
> would return OK because one signature could be verified. That's very
> bad.
>
> To work around this and return failure in this case, it would be
> necessary to write some kind of wrapper around sopv-gpgv ? but a
> wrapper around a wrapper would be unnecessary complexity.
>
> If nine out of ten signatures are good, and the tenth is made with an
> unknown key, that's not cause for alarm. That tarball should be
> considered verified. sopv-gpgv would return OK, which is good in this
> case. gpgv would return failure, which is not optimal.
>
> A possible workaround would be to manually remove the signatures by
> unknown keys and verify the rest with gpgv. That's doable because the
> Bitcoin Core signatures are separately ASCII-armored and then
> concatenated into a single signature file. If gpgv says there's no key
> for the fifth signature, then delete the fifth ASCII-armored block from
> the file. That's not great, but should be workable to a packager with a
> basic understanding of signature verification.
>
> Ignoring signatures made with unknown keys, but raising an alarm for any
> signature that doesn't match the signed file, would not always be right
> either. If there is a group of trusted developers who usually sign every
> release, and then one day all but one of the signatures are from unknown
> keys, that's also cause for suspicion.
>
> So gpgv has a limitation, and sopv-gpgv has a limitation, but sopv-
> gpgv's limitation would be worse for a distribution's security.
>
>> This means every tool that
>> depends on gpgverify is going to make it difficult to migrate the
>> ecosystem to new cryptographic algorithms.
>>
>> The usual approach for that would be to sign the file with both the old
>> and new algorithms, and put them both in the detached signature file.
>> That way, existing implementations can continue to verify the old
>> algorithm, and newer implementations can verify the new one.
> I don't remember ever seeing an example of that approach. As far as I
> can tell, the usual approach is to have verification tools support both
> old and new algorithms. Signers switch keys and signatures to the new
> algorithm when they think support for it is sufficiently widespread.
> Then support for the old algorithm is removed from tools when almost
> nobody uses it anymore.

For issues such as the above, the proper script-friendly solution is to
enhance gpgv itself with command line options to specify the desired
trust requirements.  For the multi-signer scenario above, an option could
be set to

     --must-match-percent 90 --ignore-unknown

, for the case of validating Debian whole-archive signatures that occasionally
contain both the current and future signature as part of a transition to a new
ftp-master signing key, the option could be set to

     --must-match-percent 100 --ignore-unknown --pubring /usr/share/.../current-keys.gpg





Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



From andrewg at andrewg.com  Tue Aug  6 13:28:14 2024
From: andrewg at andrewg.com (andrewg)
Date: Tue, 06 Aug 2024 12:28:14 +0100
Subject: sopv-gpgpv: an implementation of the verification-only subset of
 the Stateless OpenPGP CLI using gpgv as a backend
In-Reply-To: <4131c3c0-ff04-104d-e275-d1b35de35e14@wisemo.com>
References: <878qxug03j.fsf@fifthhorseman.net>
 <87h6cgi8ti.fsf@jacob.g10code.de> <ZqOqmBzGWAkJu4kQ@teonanacatl.net>
 <87r0bcw5jd.fsf@fifthhorseman.net> <ZqfxvewzQddcwP7W@teonanacatl.net>
 <87o76fw7c5.fsf@fifthhorseman.net>
 <20240805200844.4666b147@tag.xn--rombobjrn-67a.se>
 <4131c3c0-ff04-104d-e275-d1b35de35e14@wisemo.com>
Message-ID: <63d645232dd0543f50cfcfb2c5d529a1@andrewg.com>

On 2024-08-06 10:32, Jakob Bohm via Gnupg-users wrote:
> 
> For issues such as the above, the proper script-friendly solution is to
> enhance gpgv itself with command line options to specify the desired
> trust requirements.  For the multi-signer scenario above, an option 
> could
> be set to
> 
>     --must-match-percent 90 --ignore-unknown

I think using percentages rather than absolute values here would be 
dangerous. If this is a percentage of the number of keys in the keyring, 
it would make updating the membership of the keyring a potential DOS 
event. If it is a percentage of the number of signatures on the message, 
an attacker who compromises just one signing key could distribute a 
package signed by just that key, and 100% of attached signatures would 
verify.

A


From andrewg at andrewg.com  Tue Aug  6 13:11:01 2024
From: andrewg at andrewg.com (andrewg)
Date: Tue, 06 Aug 2024 12:11:01 +0100
Subject: sopv-gpgpv: an implementation of the verification-only subset of
 the Stateless OpenPGP CLI using gpgv as a backend
In-Reply-To: <20240805200844.4666b147@tag.xn--rombobjrn-67a.se>
References: <878qxug03j.fsf@fifthhorseman.net>
 <87h6cgi8ti.fsf@jacob.g10code.de> <ZqOqmBzGWAkJu4kQ@teonanacatl.net>
 <87r0bcw5jd.fsf@fifthhorseman.net> <ZqfxvewzQddcwP7W@teonanacatl.net>
 <87o76fw7c5.fsf@fifthhorseman.net>
 <20240805200844.4666b147@tag.xn--rombobjrn-67a.se>
Message-ID: <7e3f2b2fd6ae2db596cb738dc34449f1@andrewg.com>

On 2024-08-05 19:08, Bj?rn Persson wrote:
> Daniel Kahn Gillmor via Gnupg-users wrote:
>> For example, if the detached signature contains multiple signatures, 
>> and
>> gpgv can't verify one of them, it will return a non-zero error code,
>> even if it *can* verify the other signature.
> 
> It's true that requiring verification of all the signatures is not
> always desirable. Allowing all but one to fail is not always right
> either. Deciding how many correct signatures should be required is
> nontrivial. I doubt any general verification tool can automatically do
> the right thing in every case without parameters telling it what's
> desired in the specific usecase.

The easiest way to do this would be to add an option to require N 
verified signatures for success rather than one (which IMO should still 
be the default).

>> The usual approach for that would be to sign the file with both the 
>> old
>> and new algorithms, and put them both in the detached signature file.
>> That way, existing implementations can continue to verify the old
>> algorithm, and newer implementations can verify the new one.
> 
> I don't remember ever seeing an example of that approach. As far as I
> can tell, the usual approach is to have verification tools support both
> old and new algorithms. Signers switch keys and signatures to the new
> algorithm when they think support for it is sufficiently widespread.
> Then support for the old algorithm is removed from tools when almost
> nobody uses it anymore.

The downside of asking signers to guess when support for a signature 
algorithm is "sufficiently widespread" is that it forces them to be 
excessively conservative in what they produce, because the impact of a 
low number of signature failures (and the subsequent complaints) is 
high. The principle of "a broken signature is a missing signature" is 
much more robust and future-proof.

A


From jb-gnumlists at wisemo.com  Tue Aug  6 15:25:28 2024
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Tue, 6 Aug 2024 15:25:28 +0200
Subject: sopv-gpgpv: an implementation of the verification-only subset of
 the Stateless OpenPGP CLI using gpgv as a backend
In-Reply-To: <63d645232dd0543f50cfcfb2c5d529a1@andrewg.com>
References: <878qxug03j.fsf@fifthhorseman.net>
 <87h6cgi8ti.fsf@jacob.g10code.de> <ZqOqmBzGWAkJu4kQ@teonanacatl.net>
 <87r0bcw5jd.fsf@fifthhorseman.net> <ZqfxvewzQddcwP7W@teonanacatl.net>
 <87o76fw7c5.fsf@fifthhorseman.net>
 <20240805200844.4666b147@tag.xn--rombobjrn-67a.se>
 <4131c3c0-ff04-104d-e275-d1b35de35e14@wisemo.com>
 <63d645232dd0543f50cfcfb2c5d529a1@andrewg.com>
Message-ID: <e24b3690-12fd-95eb-542a-6ed72d5d952c@wisemo.com>

On 2024-08-06 13:28, andrewg wrote:
> On 2024-08-06 10:32, Jakob Bohm via Gnupg-users wrote:
>>
>> For issues such as the above, the proper script-friendly solution is to
>> enhance gpgv itself with command line options to specify the desired
>> trust requirements.? For the multi-signer scenario above, an option could
>> be set to
>>
>> ??? --must-match-percent 90 --ignore-unknown
> 
> I think using percentages rather than absolute values here would be 
> dangerous. If this is a percentage of the number of keys in the keyring, 
> it would make updating the membership of the keyring a potential DOS 
> event. If it is a percentage of the number of signatures on the message, 
> an attacker who compromises just one signing key could distribute a 
> package signed by just that key, and 100% of attached signatures would 
> verify.
> 
> A

Intent was percentage of provided signatures whose keys are in the local
pubring, thus verifiable.  Using a percentage without "--ignore-unknown"
would be a percentage of signatures, including any where the public key
isn't in the pubring.

A 3rd option could specify the minimum number of valid signatures no
matter how many are present.  For example:

     --min-ok-sigs 9

would make gpgv reject any file with less than 9 valid signatures, no
matter how many or few invalid signatures are present.  Because this is
an exact min number, it doesn't depend if unknown signatures are ignored
or counted as failures.

Passing these options to the full gpg command would count signatures as
valid only if trusted under the selected trust model, and would offer a
fourth option "--ignore-untrusted" which counts untrusted signers as not
there, thus applying the numeric minimums only to the number of trusted
signatures (includining trusted but invalid signatures).

gpgv trusts all known signatures, so has no use for ignoring untrusted
signatures.

Remember to also implement these options for gpgsm and gpgsmv

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From dkg at fifthhorseman.net  Tue Aug  6 20:01:36 2024
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 06 Aug 2024 14:01:36 -0400
Subject: sopv-gpgpv: an implementation of the verification-only subset
 of the Stateless OpenPGP CLI using gpgv as a backend
In-Reply-To: <20240805200844.4666b147@tag.xn--rombobjrn-67a.se>
References: <878qxug03j.fsf@fifthhorseman.net>
 <87h6cgi8ti.fsf@jacob.g10code.de> <ZqOqmBzGWAkJu4kQ@teonanacatl.net>
 <87r0bcw5jd.fsf@fifthhorseman.net> <ZqfxvewzQddcwP7W@teonanacatl.net>
 <87o76fw7c5.fsf@fifthhorseman.net>
 <20240805200844.4666b147@tag.xn--rombobjrn-67a.se>
Message-ID: <87y159ttrz.fsf@fifthhorseman.net>

On Mon 2024-08-05 20:08:43 +0200, Bj?rn Persson wrote:
> It's true that requiring verification of all the signatures is not
> always desirable. Allowing all but one to fail is not always right
> either. Deciding how many correct signatures should be required is
> nontrivial. I doubt any general verification tool can automatically do
> the right thing in every case without parameters telling it what's
> desired in the specific usecase.

Requiring N signatures to validate is indeed an interesting scenario,
but it is very far from the common scenario.

The common scenario is that there is only one signature available.  You
want to make sure that signature validates.

If a second signature appears, that second signature should not break
the validation unless you have some prearranged knowledge that more than
one signature should be present.  Your Bitcoin example is an unusual
outlier, which i can't speak to because i don't know the full history
there.  I can probably identify one other signing scenario where
everyone involved knows that you should have multiple signatures, but
these are the exceptions, not the rule.

So yes, there is an argument to be made for some (very unusual) cases
where you want at least N-of-M signatures to be validated.

But that amount of complexity, compared to the overwhelming number of
actual use cases that we see simple at-least-one signature verification
used for, is not a great tradeoff.  sopv handles the common base case
correctly, without brittleness.

> So gpgv has a limitation, and sopv-gpgv has a limitation, but sopv-
> gpgv's limitation would be worse for a distribution's security.

I don't think i agree with you, but we seem to be looking at things from
different perspective.  I think you're asking "how can we make a
stronger verification framework that can require redundant signatures?"
while I'm asking "how can we make a stronger verification framework that
lets us deploy cryptographic updates promptly, without coordinating a
flag day?"

But these things aren't mutually exclusive.  For example, you can use
the sopv return code as a baseline (we all agree that we want at least
one valid signature, and should fail if there are none), and then only
accept if you count the distinct lines you care about in the
VERIFICATIONS output if you want to require more than 1 signature.

Or, you could verify the thing multiple times, once against each
verifier you care about, and count up the number of successful
verifications.

Or, if you really want the "sop verify" and "sop inline-verify"
interface to support some sensible "at least N signatures" semantic, feel
free to open a suggestion in the sop issue tracker:

  https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/new

You can get feedback there from multiple implementers, based on what you
propose.

I've toyed with trying to add that semantic in the past myself, but i
never hit on an approach that seemed more convincing than the techniques
i outlined above.  There are some subtle questions that i don't know how
to answer for such a verification requirement by default, like: how do
you want to count "distinct" signatures?  What if there are two
signatures from the same signing-capable subkey?  what if there is one
signature from a signing-capable subkey that is bound to two distinct
primary keys? What if there are two separate signatures, from different
signing-capable subkeys, but they're both attached to the same primary
key?  What if there are valid signatures from two separate primary keys,
each of which have produced a signature, but the certificates for those
primary keys share a user ID?

On the flip side, "at least one signature from this pool of signers must
be valid" is understandable, implementable, unambiguous. And it is
effective for the vast majority of use cases.  That's why sop (and the
sopv subset) uses it as a baseline.

> I don't remember ever seeing an example of that approach.

You haven't seen that approach commonly because it's impossible to
deploy new signatures while tools like gpgv produce a failure when they
encounter an unknown signature.

What I want is an ecosystem where it's possible for the *signer* to
adopt new signature mechanisms as soon as possible (presumably using the
new scheme in parallel with older signing capabilities), and for the
*signer* to decide when to stop making old/weak signatures.  That gives
the verifiers clear motivation to upgrade.  And it also allows any
verifier who is unwilling to rely on older/weaker signatures the chance
to make that switch without having to wait on every other verifier
having upgraded to be able to discover signatures from the new
algorithm.

Brittle verification tools are holding back the ecosystem, and their
brittleness doesn't even bring any concrete benefit to their users.
Let's use a more reasonable interface.

      --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 324 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240806/544fa24a/attachment.sig>

From dkg at fifthhorseman.net  Tue Aug  6 20:49:38 2024
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 06 Aug 2024 14:49:38 -0400
Subject: sopv-gpgpv: an implementation of the verification-only subset
 of the Stateless OpenPGP CLI using gpgv as a backend
In-Reply-To: <87y159ttrz.fsf@fifthhorseman.net>
References: <878qxug03j.fsf@fifthhorseman.net>
 <87h6cgi8ti.fsf@jacob.g10code.de> <ZqOqmBzGWAkJu4kQ@teonanacatl.net>
 <87r0bcw5jd.fsf@fifthhorseman.net> <ZqfxvewzQddcwP7W@teonanacatl.net>
 <87o76fw7c5.fsf@fifthhorseman.net>
 <20240805200844.4666b147@tag.xn--rombobjrn-67a.se>
 <87y159ttrz.fsf@fifthhorseman.net>
Message-ID: <87v80dtrjx.fsf@fifthhorseman.net>

On Tue 2024-08-06 14:01:36 -0400, Daniel Kahn Gillmor via Gnupg-users wrote:
> Or, if you really want the "sop verify" and "sop inline-verify"
> interface to support some sensible "at least N signatures" semantic, feel
> free to open a suggestion in the sop issue tracker:
>
>   https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/new

I've gone ahead and opened an issue to keep track of this, because this
isn't the first time this question has come up about more sophisticated
OpenPGP signature verification for sop:

    https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/104

I'd love to hear feedback there from implementers and from operators of
infrastructure that depend on signature verification.

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

From guru at unixarea.de  Mon Aug 12 14:26:27 2024
From: guru at unixarea.de (Matthias Apitz)
Date: Mon, 12 Aug 2024 14:26:27 +0200
Subject: Using OpenPGP / GnuPG to unlock 'sudo bla bla' or 'sudo -s'
Message-ID: <Zrn/c0o05stN0kpP@pureos>


I use in my Linux Debian mobile L5 an internal OpenPGP card for the
password-store and for outbound SSH/SCP. Is there a way, for example
with a config in /etc/pam.d/.... to used the OpenPGP card for providing
the password to 'sudo xxxx' or 'sudo -s'

Thanks

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

I am not at war with Russia.  ? ?? ???? ? ???????.
Ich bin nicht im Krieg mit Russland.


From andrewg at andrewg.com  Mon Aug 12 14:48:04 2024
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Mon, 12 Aug 2024 13:48:04 +0100
Subject: Using OpenPGP / GnuPG to unlock 'sudo bla bla' or 'sudo -s'
In-Reply-To: <Zrn/c0o05stN0kpP@pureos>
References: <Zrn/c0o05stN0kpP@pureos>
Message-ID: <DD85C1F0-82FF-40C8-9105-643E0FF1C23A@andrewg.com>

You can use pam-auth-ssh-agent with gpg?s ssh-agent emulation. Thisnhas the advantage that it also works over remote ssh connections (with ssh agent forwarding enabled).

Andrew Gallagher

> On 12 Aug 2024, at 13:27, Matthias Apitz <guru at unixarea.de> wrote:
> 
> ?
> I use in my Linux Debian mobile L5 an internal OpenPGP card for the
> password-store and for outbound SSH/SCP. Is there a way, for example
> with a config in /etc/pam.d/.... to used the OpenPGP card for providing
> the password to 'sudo xxxx' or 'sudo -s'
> 
> Thanks
> 
>    matthias
> 
> --
> Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub
> 
> I am not at war with Russia.  ? ?? ???? ? ???????.
> Ich bin nicht im Krieg mit Russland.
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users


From andrewg at andrewg.com  Mon Aug 12 14:50:53 2024
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Mon, 12 Aug 2024 13:50:53 +0100
Subject: Using OpenPGP / GnuPG to unlock 'sudo bla bla' or 'sudo -s'
In-Reply-To: <DD85C1F0-82FF-40C8-9105-643E0FF1C23A@andrewg.com>
References: <DD85C1F0-82FF-40C8-9105-643E0FF1C23A@andrewg.com>
Message-ID: <E1A079AB-F548-465F-8EBC-36EAEC9736B0@andrewg.com>

Sorry, it?s pam-ssh-agent-auth:

https://linux.die.net/man/8/pam_ssh_agent_auth

A

> On 12 Aug 2024, at 13:48, Andrew Gallagher <andrewg at andrewg.com> wrote:
> 
> ?You can use pam-auth-ssh-agent with gpg?s ssh-agent emulation. Thisnhas the advantage that it also works over remote ssh connections (with ssh agent forwarding enabled).
> 
> Andrew Gallagher
> 
>> On 12 Aug 2024, at 13:27, Matthias Apitz <guru at unixarea.de> wrote:
>> 
>> ?
>> I use in my Linux Debian mobile L5 an internal OpenPGP card for the
>> password-store and for outbound SSH/SCP. Is there a way, for example
>> with a config in /etc/pam.d/.... to used the OpenPGP card for providing
>> the password to 'sudo xxxx' or 'sudo -s'
>> 
>> Thanks
>> 
>>   matthias
>> 
>> --
>> Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
>> Public GnuPG key: http://www.unixarea.de/key.pub
>> 
>> I am not at war with Russia.  ? ?? ???? ? ???????.
>> Ich bin nicht im Krieg mit Russland.
>> 
>> _______________________________________________
>> Gnupg-users mailing list
>> Gnupg-users at gnupg.org
>> https://lists.gnupg.org/mailman/listinfo/gnupg-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240812/f765fa56/attachment-0001.html>

From wk at gnupg.org  Mon Aug 12 18:13:43 2024
From: wk at gnupg.org (Werner Koch)
Date: Mon, 12 Aug 2024 18:13:43 +0200
Subject: Using OpenPGP / GnuPG to unlock 'sudo bla bla' or 'sudo -s'
In-Reply-To: <Zrn/c0o05stN0kpP@pureos> (Matthias Apitz's message of "Mon, 12
 Aug 2024 14:26:27 +0200")
References: <Zrn/c0o05stN0kpP@pureos>
Message-ID: <877ccld8i0.fsf@jacob.g10code.de>

On Mon, 12 Aug 2024 14:26, Matthias Apitz said:

> password-store and for outbound SSH/SCP. Is there a way, for example
> with a config in /etc/pam.d/.... to used the OpenPGP card for providing
> the password to 'sudo xxxx' or 'sudo -s'

I thought these days everyone is using

  ssh root at localhost foo --bar baz


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: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240812/f1b0a913/attachment.sig>

From guru at unixarea.de  Mon Aug 12 19:27:19 2024
From: guru at unixarea.de (Matthias Apitz)
Date: Mon, 12 Aug 2024 19:27:19 +0200
Subject: Using OpenPGP / GnuPG to unlock 'sudo bla bla' or 'sudo -s'
In-Reply-To: <877ccld8i0.fsf@jacob.g10code.de>
References: <Zrn/c0o05stN0kpP@pureos>
 <877ccld8i0.fsf@jacob.g10code.de>
Message-ID: <ZrpF9_tMJWsQ7Trb@c720-1400094>

El d?a lunes, agosto 12, 2024 a las 06:13:43p. m. +0200, Werner Koch via Gnupg-users escribi?:

> On Mon, 12 Aug 2024 14:26, Matthias Apitz said:
> 
> > password-store and for outbound SSH/SCP. Is there a way, for example
> > with a config in /etc/pam.d/.... to used the OpenPGP card for providing
> > the password to 'sudo xxxx' or 'sudo -s'
> 
> I thought these days everyone is using
> 
>   ssh root at localhost foo --bar baz


After sudo -s:

cat ~root/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCWjY0QlrPXqw2hj05JeXH4wssx20sq4VvsC4baVocCH8PeDSYcl7Q7p/opEd8CX0WgUaSm8a2GRWxiS9b1m6Q6xzXzzuc6tlfqsulzDCg1a6mV+U7WLQJl9fmyvSMynmVTvkmSdxWJOsG1k2OZS5EKTq4cLfLZCKnl7YvYbdwzEcE7//RC6UX3pATDFOrrrEYbarauEQ1y0Rxj22yIQE0S4Pkut0kDXyJKdDcc1zuKLsjST4+fhm+5Fj6haP8SKibIyPpYqSkeIg0mnEgp8/JHgznK6i8NH/R3507gmHhgER7OMDyPqnp5orHAHqHSeNSfBWmBcWxlelEfa/Y3ZlUex38RQrncYuB7ew+3dAclt7EjQ1Ki4COHmaTueEUaXvYhRG+D2jN672kljs4mOtTQ9nZ68y6gbgRpet5obeSXGPrCMEYvpoz0h00upUwsDgwR/ENm1H1xYWJHL7onVMBKdjER0dKOWhlq7adGm94VjbDJUPxWywSeYjXPNLTGUptbgyku61eUnXcTjusVMQyZHRaDxJZXmB9To9NKUWzUl/AUwn7KocCRCU4JYgNi54fBpbz0LKBJnqa+00AABT5wmVCAmzoQSrcqfruKNOVZrhutwJrR4MifhPaD5MUsFZt4kFJoZrPTEDZiUM4hqINsyeoMZbhw0tMGOuTlvN+79w== openpgp:0x237B4D65

As unpriv user purism:

ssh -vv root at localhost

(PIN of OpenPGP card is asked)

...
debug1: Server accepts key: cardno:00050000CF41 RSA SHA256:DC+r35okkvh99xY7Z3Z5Xb0AMCs5E6hzlYia1QxrY6c agent
Your account has expired; please contact your system administrator.
Connection closed by ::1 port 22

The root account of the L5 is locked for some good reasons.

	matthias
-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

I am not at war with Russia.
? ?? ???? ? ???????.
Ich bin nicht im Krieg mit Russland.


From jhathaway at wikimedia.org  Tue Aug 13 19:08:39 2024
From: jhathaway at wikimedia.org (Jesse Hathaway)
Date: Tue, 13 Aug 2024 12:08:39 -0500
Subject: Unable to change expiration date on primary key
Message-ID: <CAELUtesRkYtPaQ9tvN5LwjfgfvVj1=qg+C67GGP8B0DxPd8Bxg@mail.gmail.com>

I have a key with two subkeys, the two subkeys have no expiration. I am
trying to remove the expiration date on the primary key, but the
suggested commands don't seem to have any effect and more strangely
don't seem to return any error messages or a non-zero exit code. I have
tried using both using the gpg console and the --quick-set-expire
option, but both have no effect. I have also tried extending the
expiration date, but the results are the same:

quick-set

    $ gpg --verbose --with-subkey-fingerprints --list-keys
AB48C7022E543EABE8021D6FB29E1E6371FDBFB6
    gpg: enabled compatibility flags:
    gpg: using pgp trust model
    gpg: checking the trustdb
    gpg: 2 keys processed (2 validity counts cleared)
    gpg: marginals needed: 3  completes needed: 1  trust model: pgp
    gpg: depth: 0  valid:   2  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 2u
    gpg: next trustdb check due at 2030-04-12
    pub   rsa4096 2021-12-10 [C] [expires: 2024-12-10]
          AB48C7022E543EABE8021D6FB29E1E6371FDBFB6
    uid           [ unknown] <jhathaway at wikimedia.org>
    uid           [ unknown] Jesse Hathaway
    sub   rsa4096 2021-12-10 [S]
          68324D0D9D86586CABBF5AA9ABA34714F5533665
    sub   rsa4096 2021-12-10 [E]
          F0A97995C8E8E79AD444BDAF7DE5A2D165656F60

    $ gpg --quick-set-expire AB48C7022E543EABE8021D6FB29E1E6371FDBFB6 0
    $ # no change

gpg console

    $ gpg --edit-key AB48C7022E543EABE8021D6FB29E1E6371FDBFB6
    gpg (GnuPG) 2.4.5; Copyright (C) 2024 g10 Code GmbH
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.

    Secret key is available.

    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
    gpg: next trustdb check due at 2030-04-12
    sec  rsa4096/B29E1E6371FDBFB6
         created: 2021-12-10  expires: 2024-12-10  usage: C
         trust: unknown       validity: unknown
    ssb  rsa4096/ABA34714F5533665
         created: 2021-12-10  expires: never       usage: S
    ssb  rsa4096/7DE5A2D165656F60
         created: 2021-12-10  expires: never       usage: E
    [ unknown] (1). <jhathaway at wikimedia.org>
    [ unknown] (2)  Jesse Hathaway

    gpg> expire
    Changing expiration time for the primary key.
    Please specify how long the key should be valid.
             0 = key does not expire
          <n>  = key expires in n days
          <n>w = key expires in n weeks
          <n>m = key expires in n months
          <n>y = key expires in n years
    Key is valid for? (0)
    Key does not expire at all
    Is this correct? (y/N) y

    sec  rsa4096/B29E1E6371FDBFB6
         created: 2021-12-10  expires: 2024-12-10  usage: C
         trust: unknown       validity: unknown
    ssb  rsa4096/ABA34714F5533665
         created: 2021-12-10  expires: never       usage: S
    ssb  rsa4096/7DE5A2D165656F60
         created: 2021-12-10  expires: never       usage: E
    [ unknown] (1). <jhathaway at wikimedia.org>
    [ unknown] (2)  Jesse Hathaway

    gpg> save
    $ # no change

gpg version

    $ gpg --version
    gpg (GnuPG) 2.4.5
    libgcrypt 1.11.0
    Copyright (C) 2024 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: /home/jhathaway/.gnupg
    Supported algorithms:
    Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
    Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
            CAMELLIA128, CAMELLIA192, CAMELLIA256
    Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
    Compression: Uncompressed, ZIP, ZLIB, BZIP2


From guru at unixarea.de  Wed Aug 14 11:29:32 2024
From: guru at unixarea.de (Matthias Apitz)
Date: Wed, 14 Aug 2024 11:29:32 +0200
Subject: Using OpenPGP / GnuPG to unlock 'sudo bla bla' or 'sudo -s'
In-Reply-To: <E1A079AB-F548-465F-8EBC-36EAEC9736B0@andrewg.com>
References: <DD85C1F0-82FF-40C8-9105-643E0FF1C23A@andrewg.com>
 <E1A079AB-F548-465F-8EBC-36EAEC9736B0@andrewg.com>
Message-ID: <Zrx4/C78S++8A5SS@pureos>

El d?a lunes, agosto 12, 2024 a las 01:50:53 +0100, Andrew Gallagher escribi?:

> Sorry, it?s pam-ssh-agent-auth:
> 
> https://linux.die.net/man/8/pam_ssh_agent_auth

The above page gives as an example entry in the file /etc/pam.d/sudo the
following line:

"auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys"

perhaps to be inserted without the apostrophes.

The actual file is:

purism at pureos:~$ cat /etc/pam.d/sudo
#%PAM-1.0

@include common-auth
@include common-account
@include common-session-noninteractive

Must the new line placed below or above the @include lines?

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

I am not at war with Russia.  ? ?? ???? ? ???????.
Ich bin nicht im Krieg mit Russland.


From andrewg at andrewg.com  Wed Aug 14 16:27:54 2024
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 14 Aug 2024 15:27:54 +0100
Subject: Using OpenPGP / GnuPG to unlock 'sudo bla bla' or 'sudo -s'
In-Reply-To: <Zrx4/C78S++8A5SS@pureos>
References: <DD85C1F0-82FF-40C8-9105-643E0FF1C23A@andrewg.com>
 <E1A079AB-F548-465F-8EBC-36EAEC9736B0@andrewg.com> <Zrx4/C78S++8A5SS@pureos>
Message-ID: <12B559F2-C318-413B-B6E0-B9F0067E17CF@andrewg.com>

On 14 Aug 2024, at 10:29, Matthias Apitz <guru at unixarea.de> wrote:
> 
> The above page gives as an example entry in the file /etc/pam.d/sudo the
> following line:
> 
> "auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys"
> 
> perhaps to be inserted without the apostrophes.
> 
> The actual file is:
> 
> purism at pureos:~$ cat /etc/pam.d/sudo
> #%PAM-1.0
> 
> @include common-auth
> @include common-account
> @include common-session-noninteractive
> 
> Must the new line placed below or above the @include lines?

I recommend neither, actually :-) I use the configuration script below. It expects either APT or YUM to be defined, but you can delete the sections as appropriate for your distro. Editing PAM configuration files by hand is generally not a good idea on modern systems, as they tend to have PAM management toolchains that sit above the raw files, e.g. pam-auth-update for Debian/Ubuntu.

I strongly recommend using `/etc/security/authorized_keys/%u`, which should be owned by root. This prevents a privilege escalation vulnerability where an attacker replaces the user-owned `~/.ssh/authorized_keys` file with one of their own.

```
# Install and configure libpam-ssh-agent-auth

if [[ $APT ]]; then

  apt-get -y install libpam-ssh-agent-auth
  cat > /usr/share/pam-configs/pam-ssh-agent-auth <<EOF
Name: SSH agent authentication
Default: yes
Priority: 258
Auth-Type: Primary
Auth: [success=end default=ignore] pam_ssh_agent_auth.so file=/etc/security/authorized_keys/%u
Auth-Initial: [success=end default=ignore] pam_ssh_agent_auth.so file=/etc/security/authorized_keys/%u
EOF

  pam-auth-update --force

elif [[ $YUM ]]; then

  yum -y --setopt=skip_missing_names_on_install=False install pam_ssh_agent_auth
  if ! grep -q pam_ssh_agent_auth.so /etc/pam.d/system-auth; then
    cat <<EOF >/etc/pam.d/system-auth-ssh-agent
auth sufficient pam_ssh_agent_auth.so file=/etc/security/authorized_keys/%u
auth include system-auth-ac
account include system-auth-ac
password include system-auth-ac
session include system-auth-ac
EOF
    ln -sf system-auth-ssh-agent /etc/pam.d/system-auth
  fi

fi

cat > /etc/sudoers.d/pam-ssh-agent-auth <<EOF
# Older versions of sudo need this to access user ssh-agent
Defaults env_keep += "SSH_AUTH_SOCK"
EOF
```

-------------- 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/20240814/0667c5fa/attachment.sig>

From antomassol at gmail.com  Thu Aug 15 17:15:39 2024
From: antomassol at gmail.com (Toni Mas Soler)
Date: Thu, 15 Aug 2024 17:15:39 +0200
Subject: Unable to change expiration date on primary key
In-Reply-To: <CAELUtesRkYtPaQ9tvN5LwjfgfvVj1=qg+C67GGP8B0DxPd8Bxg@mail.gmail.com>
References: <CAELUtesRkYtPaQ9tvN5LwjfgfvVj1=qg+C67GGP8B0DxPd8Bxg@mail.gmail.com>
Message-ID: <20240815171539.2e41dc70@002>

I use to do by gpg --edit-key command.
Primary key have to be available.



El Tue, 13 Aug 2024 12:08:39 -0500
Jesse Hathaway via Gnupg-users <gnupg-users at gnupg.org> va escriure el
seg?ent:

> I have a key with two subkeys, the two subkeys have no expiration. I
> am trying to remove the expiration date on the primary key, but the
> suggested commands don't seem to have any effect and more strangely
> don't seem to return any error messages or a non-zero exit code. I
> have tried using both using the gpg console and the --quick-set-expire
> option, but both have no effect. I have also tried extending the
> expiration date, but the results are the same:
> 
> quick-set
> 
>     $ gpg --verbose --with-subkey-fingerprints --list-keys
> AB48C7022E543EABE8021D6FB29E1E6371FDBFB6
>     gpg: enabled compatibility flags:
>     gpg: using pgp trust model
>     gpg: checking the trustdb
>     gpg: 2 keys processed (2 validity counts cleared)
>     gpg: marginals needed: 3  completes needed: 1  trust model: pgp
>     gpg: depth: 0  valid:   2  signed:   0  trust: 0-, 0q, 0n, 0m,
> 0f, 2u gpg: next trustdb check due at 2030-04-12
>     pub   rsa4096 2021-12-10 [C] [expires: 2024-12-10]
>           AB48C7022E543EABE8021D6FB29E1E6371FDBFB6
>     uid           [ unknown] <jhathaway at wikimedia.org>
>     uid           [ unknown] Jesse Hathaway
>     sub   rsa4096 2021-12-10 [S]
>           68324D0D9D86586CABBF5AA9ABA34714F5533665
>     sub   rsa4096 2021-12-10 [E]
>           F0A97995C8E8E79AD444BDAF7DE5A2D165656F60
> 
>     $ gpg --quick-set-expire AB48C7022E543EABE8021D6FB29E1E6371FDBFB6
> 0 $ # no change
> 
> gpg console
> 
>     $ gpg --edit-key AB48C7022E543EABE8021D6FB29E1E6371FDBFB6
>     gpg (GnuPG) 2.4.5; Copyright (C) 2024 g10 Code GmbH
>     This is free software: you are free to change and redistribute it.
>     There is NO WARRANTY, to the extent permitted by law.
> 
>     Secret key is available.
> 
>     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 gpg: next trustdb check due at 2030-04-12
>     sec  rsa4096/B29E1E6371FDBFB6
>          created: 2021-12-10  expires: 2024-12-10  usage: C
>          trust: unknown       validity: unknown
>     ssb  rsa4096/ABA34714F5533665
>          created: 2021-12-10  expires: never       usage: S
>     ssb  rsa4096/7DE5A2D165656F60
>          created: 2021-12-10  expires: never       usage: E
>     [ unknown] (1). <jhathaway at wikimedia.org>
>     [ unknown] (2)  Jesse Hathaway
> 
>     gpg> expire  
>     Changing expiration time for the primary key.
>     Please specify how long the key should be valid.
>              0 = key does not expire
>           <n>  = key expires in n days
>           <n>w = key expires in n weeks
>           <n>m = key expires in n months
>           <n>y = key expires in n years
>     Key is valid for? (0)
>     Key does not expire at all
>     Is this correct? (y/N) y
> 
>     sec  rsa4096/B29E1E6371FDBFB6
>          created: 2021-12-10  expires: 2024-12-10  usage: C
>          trust: unknown       validity: unknown
>     ssb  rsa4096/ABA34714F5533665
>          created: 2021-12-10  expires: never       usage: S
>     ssb  rsa4096/7DE5A2D165656F60
>          created: 2021-12-10  expires: never       usage: E
>     [ unknown] (1). <jhathaway at wikimedia.org>
>     [ unknown] (2)  Jesse Hathaway
> 
>     gpg> save  
>     $ # no change
> 
> gpg version
> 
>     $ gpg --version
>     gpg (GnuPG) 2.4.5
>     libgcrypt 1.11.0
>     Copyright (C) 2024 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: /home/jhathaway/.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
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users



From jpalus at fastmail.com  Sat Aug 17 13:49:21 2024
From: jpalus at fastmail.com (Jan Palus)
Date: Sat, 17 Aug 2024 13:49:21 +0200
Subject: ftp down
Message-ID: <054cc9e9-ba4d-46d0-a7a2-0819d1b48029@fastmail.com>

FTP service at ftp.gnupg.org appears to be down for some time. Couldn't 
find any
info about FTP decommissioning so just letting you know about the problem.

Regards,
Jan


From dal at riseup.net  Sun Aug 18 22:18:26 2024
From: dal at riseup.net (Douglas Lucas)
Date: Sun, 18 Aug 2024 20:18:26 +0000
Subject: What files modified by --quick-set-expire ? (pls CC me)
Message-ID: <5320fe4b83f0009bf5df296040352653@riseup.net>

Dear gnupg-users,

When I invoke "$ gpg2 --quick-set-expire" to modify a public key, a sub
key, or a secret key, what file(s) are modified by gpg2? In other words,
by default, what are the public/sub/secret key files that are changed
once a quick extension is invoked?

Please CC me on your answers as I'm not subscribed to the list.

Thanks much,

Douglas


From wk at gnupg.org  Mon Aug 19 11:34:11 2024
From: wk at gnupg.org (Werner Koch)
Date: Mon, 19 Aug 2024 11:34:11 +0200
Subject: ftp down
In-Reply-To: <054cc9e9-ba4d-46d0-a7a2-0819d1b48029@fastmail.com> (Jan Palus
 via Gnupg-users's message of "Sat, 17 Aug 2024 13:49:21 +0200")
References: <054cc9e9-ba4d-46d0-a7a2-0819d1b48029@fastmail.com>
Message-ID: <87ttfgonzg.fsf@jacob.g10code.de>

Hi!

Thanks for mentioning this.

On Sat, 17 Aug 2024 13:49, Jan Palus said:
> FTP service at ftp.gnupg.org appears to be down for some
> time. Couldn't find any
> info about FTP decommissioning so just letting you know about the problem.

I would not considere this a problem but something which we should have
done years ago.  Sorry for not annoucing this but my impression was that
nobody is using ftp anymore since the rush from http to https about 10
years ago.

Mapping ftp.gnupg.org URLs is a easy:

  ftp://ftp.gnupg.org/foo => https://gnupg.org/ftp/foo



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: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240819/b0dba38a/attachment.sig>

From wk at gnupg.org  Mon Aug 19 12:07:09 2024
From: wk at gnupg.org (Werner Koch)
Date: Mon, 19 Aug 2024 12:07:09 +0200
Subject: What files modified by --quick-set-expire ? (pls CC me)
In-Reply-To: <5320fe4b83f0009bf5df296040352653@riseup.net> (Douglas Lucas via
 Gnupg-users's message of "Sun, 18 Aug 2024 20:18:26 +0000")
References: <5320fe4b83f0009bf5df296040352653@riseup.net>
Message-ID: <87o75oomgi.fsf@jacob.g10code.de>

On Sun, 18 Aug 2024 20:18, Douglas Lucas said:

> When I invoke "$ gpg2 --quick-set-expire" to modify a public key, a sub
> key, or a secret key, what file(s) are modified by gpg2? In other words,
> by default, what are the public/sub/secret key files that are changed

There is no definite answer for this because everything in GnuPG's home
directory _may_ be affected.  Probably affected files and directories
with current versions are:

  - pubring.gpg
  - pubring.kbx
  - trustdb.gpg
  - public-keys.d/


Youi need to use for example "gpg --export <userid>" to export and
distribute the public key.


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: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240819/a158f887/attachment.sig>

From dc at genunix.com  Mon Aug 19 18:58:36 2024
From: dc at genunix.com (Dennis Clarke)
Date: Mon, 19 Aug 2024 12:58:36 -0400
Subject: ftp down
In-Reply-To: <87ttfgonzg.fsf@jacob.g10code.de>
References: <054cc9e9-ba4d-46d0-a7a2-0819d1b48029@fastmail.com>
 <87ttfgonzg.fsf@jacob.g10code.de>
Message-ID: <569eaa7f-d372-4220-8c83-deb561f05fd5@genunix.com>

On 8/19/24 05:34, Werner Koch via Gnupg-users wrote:
> Hi!
> 
> Thanks for mentioning this.
> 
> On Sat, 17 Aug 2024 13:49, Jan Palus said:
>> FTP service at ftp.gnupg.org appears to be down for some
>> time. Couldn't find any
>> info about FTP decommissioning so just letting you know about the problem.
> 
> I would not considere this a problem but something which we should have
> done years ago.  Sorry for not annoucing this but my impression was that
> nobody is using ftp anymore since the rush from http to https about 10
> years ago.
> 
> Mapping ftp.gnupg.org URLs is a easy:
> 
>    ftp://ftp.gnupg.org/foo => https://gnupg.org/ftp/foo
> 
> 

re : nobody is using ftp anymore

     Surely you mean gopher ?  FTP and TFTP are much loved.  :)

-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken



From mm at dorfdsl.de  Mon Aug 19 20:59:31 2024
From: mm at dorfdsl.de (Marco Moock)
Date: Mon, 19 Aug 2024 20:59:31 +0200
Subject: ftp down
In-Reply-To: <569eaa7f-d372-4220-8c83-deb561f05fd5@genunix.com>
References: <054cc9e9-ba4d-46d0-a7a2-0819d1b48029@fastmail.com>
 <87ttfgonzg.fsf@jacob.g10code.de>
 <569eaa7f-d372-4220-8c83-deb561f05fd5@genunix.com>
Message-ID: <20240819205931.42d2e1ea@dorfdsl.de>

Am 19.08.2024 um 12:58:36 Uhr schrieb Dennis Clarke via Gnupg-users:

>      Surely you mean gopher ?  FTP and TFTP are much loved.  :)

The amount of gopherholes is also increasing.

-- 
Gru?
Marco

Send unsolicited bulk mail to 1724065116muell at cartoonies.org


From jcb62281 at gmail.com  Tue Aug 20 07:26:56 2024
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Tue, 20 Aug 2024 00:26:56 -0500
Subject: ftp down
In-Reply-To: <87ttfgonzg.fsf@jacob.g10code.de>
References: <054cc9e9-ba4d-46d0-a7a2-0819d1b48029@fastmail.com>
 <87ttfgonzg.fsf@jacob.g10code.de>
Message-ID: <66C42920.2090306@gmail.com>

Werner Koch via Gnupg-users wrote:
> Hi!
>
> Thanks for mentioning this.
>
> On Sat, 17 Aug 2024 13:49, Jan Palus said:
>   
>> FTP service at ftp.gnupg.org appears to be down for some
>> time. Couldn't find any
>> info about FTP decommissioning so just letting you know about the problem.
>>     
>
> I would not considere this a problem but something which we should have
> done years ago.  Sorry for not annoucing this but my impression was that
> nobody is using ftp anymore since the rush from http to https about 10
> years ago.
>
> Mapping ftp.gnupg.org URLs is a easy:
>
>   ftp://ftp.gnupg.org/foo => https://gnupg.org/ftp/foo

Unlike HTTP, FTP is /not/ subject to simple Man-on-the-Side attacks 
(which motivated the rush to HTTPS) because there is no in-protocol 
redirect.  The attack on HTTP depends on winning a race and having the 
client close the connection before the server's legitimate response 
arrives.  (The attacker sends a fake 301 response with "Location:  
http://pwn.me.now/..." and "Connection: close" headers.  The HTTP client 
then closes the connection and the client system sends TCP RST to the 
server when the legitimate response arrives.  The HTTP client the 
processes the redirect and contacts the attacker's server...)  In HTTPS, 
the attack is much harder---the attacker must win a much longer race to 
negotiate a fake TLS session and must hold a plausible certificate.  
(Actual "zero RTT" TLS set-up could make Man-on-the-Side possible 
against HTTPS if the attacker can get a phony certificate---you should 
assume that rogue states and transnational criminal organizations can 
obtain phony certificates from legitimate CAs by coercion or fraud.)  In 
FTP, the control connection must remain open during the transfer and 
there is no way for an attacker's response to redirect the client to a 
malicious server.

There is still a lack of confidentiality, since FTP is almost always run 
in plaintext, but that is not much of a concern when distributing 
publicly available software, especially when the mere fact that user X 
contacted gnupg.org and received N bytes is a good hint of what they 
were doing and possibly even exactly what they downloaded.  (In other 
words, traffic analysis easily breaks confidentiality in this case, even 
for HTTPS.)  For GPG, integrity is assured by signing the distribution 
tarballs directly, and the transport is untrusted anyway.

I would encourage resuming FTP distribution, since I see no plausible 
security benefit to omitting it.


-- Jacob



From wk at gnupg.org  Tue Aug 20 09:07:01 2024
From: wk at gnupg.org (Werner Koch)
Date: Tue, 20 Aug 2024 09:07:01 +0200
Subject: ftp down
In-Reply-To: <66C42920.2090306@gmail.com> (Jacob Bachmeyer via Gnupg-users's
 message of "Tue, 20 Aug 2024 00:26:56 -0500")
References: <054cc9e9-ba4d-46d0-a7a2-0819d1b48029@fastmail.com>
 <87ttfgonzg.fsf@jacob.g10code.de> <66C42920.2090306@gmail.com>
Message-ID: <87frqzoep6.fsf@jacob.g10code.de>

On Tue, 20 Aug 2024 00:26, Jacob Bachmeyer said:

> I would encourage resuming FTP distribution, since I see no plausible
> security benefit to omitting it.

I agree with your arguments.  However, not providing FTP saves us from a
lot of bike shedding discussions ;-)

Another reason why we stopped FTP is that I currently don't anymore
trust the oftpd we are using because it seems I have to maintain it
myself.  Moving to Apache might be an option but that can only be done
when we also move the web server to Apache.  We are still running Boa
instances behind Pound on pretty old hardware.  This needs to be
changed, I know.


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: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240820/0d8e0120/attachment.sig>

From gnupg-users at city17.xyz  Tue Aug 20 10:49:34 2024
From: gnupg-users at city17.xyz (jman)
Date: Tue, 20 Aug 2024 10:49:34 +0200
Subject: ftp down
In-Reply-To: <87frqzoep6.fsf@jacob.g10code.de> (Werner Koch via Gnupg-users's
 message of "Tue, 20 Aug 2024 09:07:01 +0200")
References: <054cc9e9-ba4d-46d0-a7a2-0819d1b48029@fastmail.com>
 <87ttfgonzg.fsf@jacob.g10code.de> <66C42920.2090306@gmail.com>
 <87frqzoep6.fsf@jacob.g10code.de>
Message-ID: <87bk1na89t.fsf@city17.xyz>


Werner Koch via Gnupg-users <gnupg-users at gnupg.org> writes:

> I agree with your arguments.  However, not providing FTP saves us from a
> lot of bike shedding discussions ;-)

All technical considerations aside, would it make it sense to make it official with a short 
announcement, even "a posteriori"?

My reasoning being: if there is one user that took their time to come here and report this, then 
maybe there are others. GnuPG is certainly a very visible project, probably good communication is 
beneficial for both end users and the project itself.

All the best,


From wk at gnupg.org  Tue Aug 20 15:05:10 2024
From: wk at gnupg.org (Werner Koch)
Date: Tue, 20 Aug 2024 15:05:10 +0200
Subject: ftp down
In-Reply-To: <87bk1na89t.fsf@city17.xyz> (jman via Gnupg-users's message of
 "Tue, 20 Aug 2024 10:49:34 +0200")
References: <054cc9e9-ba4d-46d0-a7a2-0819d1b48029@fastmail.com>
 <87ttfgonzg.fsf@jacob.g10code.de> <66C42920.2090306@gmail.com>
 <87frqzoep6.fsf@jacob.g10code.de> <87bk1na89t.fsf@city17.xyz>
Message-ID: <87bk1nny49.fsf@jacob.g10code.de>

On Tue, 20 Aug 2024 10:49, jman said:

> All technical considerations aside, would it make it sense to make it
> official with a short announcement, even "a posteriori"?

I just pushed a short NEWS to the web server frontpage. 

> a very visible project, probably good communication is beneficial for
> both end users and the project itself.

Agreed.


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: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240820/769ce3e6/attachment.sig>

From jcb62281 at gmail.com  Wed Aug 21 02:19:23 2024
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Tue, 20 Aug 2024 19:19:23 -0500
Subject: ftp down
In-Reply-To: <87frqzoep6.fsf@jacob.g10code.de>
References: <054cc9e9-ba4d-46d0-a7a2-0819d1b48029@fastmail.com>	<87ttfgonzg.fsf@jacob.g10code.de>
 <66C42920.2090306@gmail.com> <87frqzoep6.fsf@jacob.g10code.de>
Message-ID: <66C5328B.3090206@gmail.com>

Werner Koch wrote:
> On Tue, 20 Aug 2024 00:26, Jacob Bachmeyer said:
>
>   
>> I would encourage resuming FTP distribution, since I see no plausible
>> security benefit to omitting it.
>>     
>
> I agree with your arguments.  However, not providing FTP saves us from a
> lot of bike shedding discussions ;-)
>   

Like what?  Whether to provide FTP?  ;-)

> Another reason why we stopped FTP is that I currently don't anymore
> trust the oftpd we are using because it seems I have to maintain it
> myself.  Moving to Apache might be an option but that can only be done
> when we also move the web server to Apache.  We are still running Boa
> instances behind Pound on pretty old hardware.  This needs to be
> changed, I know.
>   

Admittedly, I was assuming currently-maintained software on the server.  
(Although FTP is simple enough that I would expect the exploitable bugs 
in *ftpd to have all been fixed by now.)  If you need to disable FTP for 
the time being until new software can be installed on the server, well, 
that is what it is.

I would suggest checking what ftpd Debian ships and using that.


-- Jacob



From wk at gnupg.org  Wed Aug 21 08:47:07 2024
From: wk at gnupg.org (Werner Koch)
Date: Wed, 21 Aug 2024 08:47:07 +0200
Subject: ftp down
In-Reply-To: <66C5328B.3090206@gmail.com> (Jacob Bachmeyer via Gnupg-users's
 message of "Tue, 20 Aug 2024 19:19:23 -0500")
References: <054cc9e9-ba4d-46d0-a7a2-0819d1b48029@fastmail.com>
 <87ttfgonzg.fsf@jacob.g10code.de> <66C42920.2090306@gmail.com>
 <87frqzoep6.fsf@jacob.g10code.de> <66C5328B.3090206@gmail.com>
Message-ID: <87plq2mkyc.fsf@jacob.g10code.de>

On Tue, 20 Aug 2024 19:19, Jacob Bachmeyer said:

> I would suggest checking what ftpd Debian ships and using that.

They don't provide oftpd anymore which is an anonymous only ftpd.  All
others have a way larger attack surface.


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: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240821/73af62e7/attachment.sig>

From jcb62281 at gmail.com  Thu Aug 22 02:09:08 2024
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Wed, 21 Aug 2024 19:09:08 -0500
Subject: ftp down
In-Reply-To: <87plq2mkyc.fsf@jacob.g10code.de>
References: <054cc9e9-ba4d-46d0-a7a2-0819d1b48029@fastmail.com>	<87ttfgonzg.fsf@jacob.g10code.de>
 <66C42920.2090306@gmail.com>	<87frqzoep6.fsf@jacob.g10code.de>
 <66C5328B.3090206@gmail.com> <87plq2mkyc.fsf@jacob.g10code.de>
Message-ID: <66C681A4.2080406@gmail.com>

Werner Koch wrote:
> On Tue, 20 Aug 2024 19:19, Jacob Bachmeyer said:
>
>   
>> I would suggest checking what ftpd Debian ships and using that.
>>     
>
> They don't provide oftpd anymore which is an anonymous only ftpd.  All
> others have a way larger attack surface.

I would be very surprised if whatever they do have cannot be configured 
for anonymous-only.  FTP is both simple and ancient, so I would expect 
all of the longstanding ftpds to be well-hardened by now.


-- Jacob



From janl at langfeldt.net  Thu Aug 22 07:57:00 2024
From: janl at langfeldt.net (Nicolai Langfeldt)
Date: Thu, 22 Aug 2024 07:57:00 +0200
Subject: bugtracker account
Message-ID: <ee0e1596-19e2-4869-874e-c48983cdc7e5@langfeldt.net>

Hi,

I'd like an account on dev.gnupg.org please.

  * Handle one of: janl, niclan, niclangf
  * Display name: Nicolai Langfeldt
  * Email: janl at langfeldt.net

I did try to use the github login that appeared to be available but this 
did not work.

Thanks,

 ? Nicolai Langfeldt

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

From wk at gnupg.org  Thu Aug 22 09:46:15 2024
From: wk at gnupg.org (Werner Koch)
Date: Thu, 22 Aug 2024 09:46:15 +0200
Subject: bugtracker account
In-Reply-To: <ee0e1596-19e2-4869-874e-c48983cdc7e5@langfeldt.net> (Nicolai
 Langfeldt's message of "Thu, 22 Aug 2024 07:57:00 +0200")
References: <ee0e1596-19e2-4869-874e-c48983cdc7e5@langfeldt.net>
Message-ID: <87a5h5m248.fsf@jacob.g10code.de>

Hi,

You should soon receive a confirmation mail.


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: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240822/3d580d47/attachment.sig>

From wk at gnupg.org  Thu Aug 22 09:48:04 2024
From: wk at gnupg.org (Werner Koch)
Date: Thu, 22 Aug 2024 09:48:04 +0200
Subject: ftp down
In-Reply-To: <66C681A4.2080406@gmail.com> (Jacob Bachmeyer via Gnupg-users's
 message of "Wed, 21 Aug 2024 19:09:08 -0500")
References: <054cc9e9-ba4d-46d0-a7a2-0819d1b48029@fastmail.com>
 <87ttfgonzg.fsf@jacob.g10code.de> <66C42920.2090306@gmail.com>
 <87frqzoep6.fsf@jacob.g10code.de> <66C5328B.3090206@gmail.com>
 <87plq2mkyc.fsf@jacob.g10code.de> <66C681A4.2080406@gmail.com>
Message-ID: <875xrtm217.fsf@jacob.g10code.de>

On Wed, 21 Aug 2024 19:09, Jacob Bachmeyer said:

> configured for anonymous-only.  FTP is both simple and ancient, so I

Yes, the protocol is simple but most server implementaions are pretty
complex.  That is why we settled for oftpd nearly decades ago.  And as
we see we are already building a file shed ;-)


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: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240822/87dfdf99/attachment.sig>

From janl at langfeldt.net  Thu Aug 22 10:13:17 2024
From: janl at langfeldt.net (Nicolai Langfeldt)
Date: Thu, 22 Aug 2024 10:13:17 +0200
Subject: bugtracker account
In-Reply-To: <87a5h5m248.fsf@jacob.g10code.de>
References: <ee0e1596-19e2-4869-874e-c48983cdc7e5@langfeldt.net>
 <87a5h5m248.fsf@jacob.g10code.de>
Message-ID: <f2b91e5b-2f6c-4f4c-a001-377f16788c33@langfeldt.net>

Thanks, it arrived before your email!

On 22.08.2024 09:46, Werner Koch wrote:
> Hi,
>
> You should soon receive a confirmation mail.
>
>
> Shalom-Salam,
>
>     Werner
>


From al-gnupg_users at none.at  Thu Aug 22 11:01:28 2024
From: al-gnupg_users at none.at (Alex)
Date: Thu, 22 Aug 2024 11:01:28 +0200
Subject: ftp down
In-Reply-To: <875xrtm217.fsf@jacob.g10code.de>
References: <054cc9e9-ba4d-46d0-a7a2-0819d1b48029@fastmail.com>
 <87ttfgonzg.fsf@jacob.g10code.de> <66C42920.2090306@gmail.com>
 <87frqzoep6.fsf@jacob.g10code.de> <66C5328B.3090206@gmail.com>
 <87plq2mkyc.fsf@jacob.g10code.de> <66C681A4.2080406@gmail.com>
 <875xrtm217.fsf@jacob.g10code.de>
Message-ID: <cc671493-23cc-4e5d-bc01-d93a4c6865f5@none.at>

Hi.

On 2024-08-22 (Do.) 09:48, Werner Koch via Gnupg-users wrote:
> On Wed, 21 Aug 2024 19:09, Jacob Bachmeyer said:
> 
>> configured for anonymous-only.  FTP is both simple and ancient, so I
> 
> Yes, the protocol is simple but most server implementaions are pretty
> complex.  That is why we settled for oftpd nearly decades ago.  And as
> we see we are already building a file shed ;-)

Just FYI.

In case ftp is something which should be still provided maybe twoftpd could be 
an option.

https://packages.debian.org/buster/twoftpd
http://www.untroubled.org/twoftpd/

But it's fully understandable to switch of a daemon because every service 
requires some time and effort.

> Salam-Shalom,
> 
>     Werner

Regards
Alex



From Bjorn at xn--rombobjrn-67a.se  Thu Aug 22 14:01:15 2024
From: Bjorn at xn--rombobjrn-67a.se (=?UTF-8?B?QmrDtnJu?= Persson)
Date: Thu, 22 Aug 2024 14:01:15 +0200
Subject: ftp down
In-Reply-To: <66C42920.2090306@gmail.com>
References: <054cc9e9-ba4d-46d0-a7a2-0819d1b48029@fastmail.com>
 <87ttfgonzg.fsf@jacob.g10code.de> <66C42920.2090306@gmail.com>
Message-ID: <20240822140115.2f59d0c9@tag.xn--rombobjrn-67a.se>

Jacob Bachmeyer via Gnupg-users wrote:
> Unlike HTTP, FTP is /not/ subject to simple Man-on-the-Side attacks 
> (which motivated the rush to HTTPS) because there is no in-protocol 
> redirect.

So FTP isn't vulnerable to that particular attack, and attackers have
to resort to TCP hijacking or DNS poisoning or BGP hijacking or
whatever. Without cryptography there is no security. Anyone who wants
to argue in favor of FTP from a security point of view should at least
argue for FTP over TLS.

And if you want, you can use Wget with --max-redirect=0 to download
tarballs, or Curl which doesn't even follow redirections unless you
give it the --location option.

> you should 
> assume that rogue states and transnational criminal organizations can 
> obtain phony certificates from legitimate CAs by coercion or fraud.

Anyone who can do that probably also has the resources to attack FTP
through one or more of TCP hijacking, DNS poisoning and BGP hijacking.

> For GPG, integrity is assured by signing the distribution 
> tarballs directly, and the transport is untrusted anyway.

Those who already have GPG and the release-signing keys can verify the
next version of GPG that way. To anyone who doesn't already have GPG,
HTTPS is the best integrity protection they will get.

> I would encourage resuming FTP distribution, since I see no plausible 
> security benefit to omitting it.

For the download usecase, I see no plausible benefit to providing FTP
service in addition to HTTPS. A web server plus an FTP server will
always be a larger attack surface than only the web server. I recommend
leaving the FTP server off.

Bj?rn Persson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signatur
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240822/e42d8719/attachment.sig>

From wk at gnupg.org  Thu Aug 22 15:38:16 2024
From: wk at gnupg.org (Werner Koch)
Date: Thu, 22 Aug 2024 15:38:16 +0200
Subject: ftp down
In-Reply-To: <20240822140115.2f59d0c9@tag.xn--rombobjrn-67a.se>
 (=?utf-8?Q?=22Bj=C3=B6rn?=
 Persson"'s message of "Thu, 22 Aug 2024 14:01:15 +0200")
References: <054cc9e9-ba4d-46d0-a7a2-0819d1b48029@fastmail.com>
 <87ttfgonzg.fsf@jacob.g10code.de> <66C42920.2090306@gmail.com>
 <20240822140115.2f59d0c9@tag.xn--rombobjrn-67a.se>
Message-ID: <87msl4d6ev.fsf@jacob.g10code.de>

On Thu, 22 Aug 2024 14:01, Bj?rn Persson said:

> next version of GPG that way. To anyone who doesn't already have GPG,
> HTTPS is the best integrity protection they will get.

Not really.  This does not protect the files on the server.  Only the
.sig and the checksums posted to several places can give you assurance
that the tarball or binary has been produced at a place the
developer/maintainer has under some control.



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: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240822/0b4aa5c1/attachment.sig>

From jcb62281 at gmail.com  Fri Aug 23 02:11:42 2024
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Thu, 22 Aug 2024 19:11:42 -0500
Subject: ftp down
In-Reply-To: <875xrtm217.fsf@jacob.g10code.de>
References: <054cc9e9-ba4d-46d0-a7a2-0819d1b48029@fastmail.com>	<87ttfgonzg.fsf@jacob.g10code.de>
 <66C42920.2090306@gmail.com>	<87frqzoep6.fsf@jacob.g10code.de>
 <66C5328B.3090206@gmail.com>	<87plq2mkyc.fsf@jacob.g10code.de>
 <66C681A4.2080406@gmail.com> <875xrtm217.fsf@jacob.g10code.de>
Message-ID: <66C7D3BE.1090908@gmail.com>

Werner Koch wrote:
> On Wed, 21 Aug 2024 19:09, Jacob Bachmeyer said:
>
>   
>> configured for anonymous-only.  FTP is both simple and ancient, so I
>>     
>
> Yes, the protocol is simple but most server implementaions are pretty
> complex.  That is why we settled for oftpd nearly decades ago.  And as
> we see we are already building a file shed ;-)

Indeed; my point there was that not providing FTP does not necessarily 
avoid discussions about providing FTP.  ;-)

If you provide it, you can have people suggesting turning it off.  If 
you turn it off, you will have people suggesting to turn it back on.  ;-)

(This thread started when a user noticed that it was down, so it was 
being used, if rarely.)


-- Jacob


From jcb62281 at gmail.com  Fri Aug 23 02:12:37 2024
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Thu, 22 Aug 2024 19:12:37 -0500
Subject: ftp down
In-Reply-To: <20240822140115.2f59d0c9@tag.xn--rombobjrn-67a.se>
References: <054cc9e9-ba4d-46d0-a7a2-0819d1b48029@fastmail.com>
 <87ttfgonzg.fsf@jacob.g10code.de> <66C42920.2090306@gmail.com>
 <20240822140115.2f59d0c9@tag.xn--rombobjrn-67a.se>
Message-ID: <66C7D3F5.8060108@gmail.com>

Bj?rn Persson wrote:
> Jacob Bachmeyer via Gnupg-users wrote:
>   
>> Unlike HTTP, FTP is /not/ subject to simple Man-on-the-Side attacks 
>> (which motivated the rush to HTTPS) because there is no in-protocol 
>> redirect.
>>     
>
> So FTP isn't vulnerable to that particular attack,

... which is important because that particular attack (and a 
whistleblower reporting that it had been deployed on a large scale) was 
most of the motivation for the rush to HTTPS.

>  and attackers have
> to resort to TCP hijacking or DNS poisoning or BGP hijacking or
> whatever.

All of which are far more detectable than the simple Man-on-the-Side 
attack.  BGP hijacking and DNS poisoning in particular are likely to 
affect large numbers of users.  That itself can be a deterrent.  
Remember that the threat model here is substituting a backdoored GPG.  
Such an attacker loses if the attack is merely /discovered/.  Each user 
affected increases the risk of discovery.

>  Without cryptography there is no security.

Yes, and the transport by which GPG is delivered is already untrusted, 
thus the signatures on the tarballs and the digests in the release 
announcements.

>  Anyone who wants
> to argue in favor of FTP from a security point of view should at least
> argue for FTP over TLS.
>   

I specifically addressed that TLS is of little or no benefit to the 
distribution of GPG.  It does not even provide privacy as to what was 
downloaded, because passive traffic analysis reveals a connection to the 
GPG distribution server and that N bytes were received, which is likely 
enough information to determine /which/ tarball a client downloaded.

> [...]
>> I would encourage resuming FTP distribution, since I see no plausible 
>> security benefit to omitting it.
>>     
>
> For the download usecase, I see no plausible benefit to providing FTP
> service in addition to HTTPS. A web server plus an FTP server will
> always be a larger attack surface than only the web server. I recommend
> leaving the FTP server off.

FTP is a longstanding and simple protocol; accordingly, FTP servers were 
all hardened long ago.  The incremental risk is slight, compared to the 
complexity of a modern httpd.  Especially if the FTP server can be 
further sandboxed using SELinux or similar, since it should need no 
write access whatsoever:  logs can be sent through syslog if needed or 
simply not kept at all.

I stand by my previous recommendation.


-- Jacob



From ineiev at gnu.org  Fri Aug 23 06:36:35 2024
From: ineiev at gnu.org (Ineiev)
Date: Fri, 23 Aug 2024 04:36:35 +0000
Subject: ftp down
In-Reply-To: <66C7D3F5.8060108@gmail.com>
References: <054cc9e9-ba4d-46d0-a7a2-0819d1b48029@fastmail.com>
 <87ttfgonzg.fsf@jacob.g10code.de> <66C42920.2090306@gmail.com>
 <20240822140115.2f59d0c9@tag.xn--rombobjrn-67a.se>
 <66C7D3F5.8060108@gmail.com>
Message-ID: <ZsgR09spJm3cn81/@manas>

On Thu, Aug 22, 2024 at 07:12:37PM -0500, Jacob Bachmeyer via Gnupg-users wrote:
> > [...]
> > > I would encourage resuming FTP distribution, since I see no
> > > plausible security benefit to omitting it.
> > 
> > For the download usecase, I see no plausible benefit to providing FTP
> > service in addition to HTTPS. A web server plus an FTP server will
> > always be a larger attack surface than only the web server. I recommend
> > leaving the FTP server off.
> 
> FTP is a longstanding and simple protocol; accordingly, FTP servers were all
> hardened long ago.  The incremental risk is slight, compared to the
> complexity of a modern httpd.

At the same time, FTP would provide redundancy.  I don't think HTTPS
failures are absolutely uncommon these days.
-------------- 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/20240823/1e84a604/attachment.sig>

From ineiev at gnu.org  Fri Aug 23 06:27:00 2024
From: ineiev at gnu.org (Ineiev)
Date: Fri, 23 Aug 2024 04:27:00 +0000
Subject: ftp down
In-Reply-To: <20240822140115.2f59d0c9@tag.xn--rombobjrn-67a.se>
References: <054cc9e9-ba4d-46d0-a7a2-0819d1b48029@fastmail.com>
 <87ttfgonzg.fsf@jacob.g10code.de> <66C42920.2090306@gmail.com>
 <20240822140115.2f59d0c9@tag.xn--rombobjrn-67a.se>
Message-ID: <ZsgPlHBXGZiH+rO5@manas>

On Thu, Aug 22, 2024 at 02:01:15PM +0200, Bj?rn Persson wrote:
> 
> Those who already have GPG and the release-signing keys can verify the
> next version of GPG that way. To anyone who doesn't already have GPG,
> HTTPS is the best integrity protection they will get.

Meeting Werner in person may be a better option for some people.
-------------- 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/20240823/290b29fb/attachment.sig>

From jb-gnumlists at wisemo.com  Fri Aug 23 10:45:39 2024
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Fri, 23 Aug 2024 10:45:39 +0200
Subject: ftp down
In-Reply-To: <ZsgPlHBXGZiH+rO5@manas>
References: <054cc9e9-ba4d-46d0-a7a2-0819d1b48029@fastmail.com>
 <87ttfgonzg.fsf@jacob.g10code.de> <66C42920.2090306@gmail.com>
 <20240822140115.2f59d0c9@tag.xn--rombobjrn-67a.se> <ZsgPlHBXGZiH+rO5@manas>
Message-ID: <933d2ea7-763e-bea6-0f9a-646d8429498b@wisemo.com>

On 2024-08-23 06:27, Ineiev via Gnupg-users wrote:
> On Thu, Aug 22, 2024 at 02:01:15PM +0200, Bj?rn Persson wrote:
>> Those who already have GPG and the release-signing keys can verify the
>> next version of GPG that way. To anyone who doesn't already have GPG,
>> HTTPS is the best integrity protection they will get.
> Meeting Werner in person may be a better option for some people.
Which is the major downfall of the PGP/GPG web of trust.? Most end users
never get to meet a member of the cabal that participate in the relevant
key signing parties, especially notin a context where key fingerprints
are shared.?? This means that end users need to rely on published keys
and fingerprints, and in modern days the only widely available place to
read such published fingerprints is on CA-signed HTTPS sites, which
effectively chains the GPG key to the CA that signed the website
certificate.

In contrast, when GPG/PGP was an underground phenomena, it was difficult
to get without knowing someone who knows someone, and public fingerprints
could (if needed) be posted in paper publications such as high
circulation papers like Frankfurter Allgemeine, Times of London or BYTE
Magazine with the assurance that the paper purchased at a Rome newsstand
was from the same physical print run as the ones sold near the developer's
home town (and not an Internet print on demand by a local print shop).



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



From ametzler at bebt.de  Fri Aug 23 13:39:23 2024
From: ametzler at bebt.de (Andreas Metzler)
Date: Fri, 23 Aug 2024 13:39:23 +0200
Subject: ftp down
In-Reply-To: <cc671493-23cc-4e5d-bc01-d93a4c6865f5@none.at>
References: <054cc9e9-ba4d-46d0-a7a2-0819d1b48029@fastmail.com>
 <87ttfgonzg.fsf@jacob.g10code.de> <66C42920.2090306@gmail.com>
 <87frqzoep6.fsf@jacob.g10code.de> <66C5328B.3090206@gmail.com>
 <87plq2mkyc.fsf@jacob.g10code.de> <66C681A4.2080406@gmail.com>
 <875xrtm217.fsf@jacob.g10code.de>
 <cc671493-23cc-4e5d-bc01-d93a4c6865f5@none.at>
Message-ID: <Zsh061vR1pzoCT3r@argenau.bebt.de>

On 2024-08-22 Alex via Gnupg-users <gnupg-users at gnupg.org> wrote:
[...]
> In case ftp is something which should be still provided maybe twoftpd could
> be an option.

> https://packages.debian.org/buster/twoftpd
> http://www.untroubled.org/twoftpd/
[...]

Hello,

Sure, a package removed from Debian about two years ago because of
"unmaintained, dead upstream, plenty of alternatives".

I do not get the whole discussion, surely Werner's and his collagues'
time can spent more productively than managing an ftp server? The
protocol really is not very popular anymore and if one really needs to
use it most mirrors still offer ftp.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From wk at gnupg.org  Fri Aug 23 18:15:56 2024
From: wk at gnupg.org (Werner Koch)
Date: Fri, 23 Aug 2024 18:15:56 +0200
Subject: On the Legacy Encryption Downgrade Attacks against GnuPG
Message-ID: <87ed6fb4g3.fsf@jacob.g10code.de>

Hi!

I have been pointed to the paper
"Legacy Encryption Downgrade Attacks against LibrePGP and CMS" 
at https://eprint.iacr.org/2024/1110.pdf .

I had only the time for brief look at it but it is obviously the final
version of a draft paper I received for commenting last November
"AEAD-to-Legacy-CFB-Encryption Downgrade Attacks on GnuPG AEAD OCB".

The upshot of the paper is that if you disable all protections and get
the target to build an oracle for you you can attack Open/Libre/*/PGP.

The requirement for GPG is to use the strongly deprecated
"--ignore-mdc-error" option which we introduced in the course of the
EFail thing, to still allow the decryption of data created with OpenPGP
software before ~2003.

The other attach option they consider is the attack target provides an
oracle to return decrypted data which has not passed the integrity
check.  Many gpg use cases work with gpg in a pipeline and thus for
obvious reasons the data is firs decrypted and processed and the final
status on whether that data is trustworthy will only be available at the
end of processing in the pipeline.  Either by making use of the AD (MDC
or OCB) or by the status of the signature.  This might not always be
easy to implement but that is how large systems are designed.  It takes
some knowledge to properly process data and it does not matter whether
encryption is involved.

Find below my response to a request from the BSI to comment on the draft
of the paper.  I wrote in German back then and do not have the time to
translate it for you.  Maybe someone else can deepl it.  For a reality
check I can't resist to link to one of Peter's slides [1].


Shalom-Salam,

   Werner


Please recall that my comment below is on a draft of the paper.  I don't
know whether that draft is available somewhere.

--8<---------------cut here---------------start------------->8---
From: Werner Koch [...]
Subject: Re: Sicherheitsschw?che OpenPGP
To: [...]@bsi.bund.de
cc: [...]
Date: Thu, 30 Nov 2023 14:46:11 +0100 (38 weeks, 1 day, 1 hour ago)

Sehr geehrte Damen und Herren,

wir wurden gebeten, Stellung zu einer vermeintlichen Sicherheitsschw?che
in GnuPG und GnuPG VS-Desktop, wie in dem Paper

  Falko Strenzke, Johannes Roth:
  AEAD-to-Legacy-CFB-Encryption Downgrade Attacks on GnuPG AEAD OCB

beschrieben, zu nehmen:

Zusammenfassung: Wir k?nnen hier keine Sicherheitsschw?che erkennen.

Das Paper geht von falschen Voraussetzungen aus da es eine spezielle
Konfiguration der Software ben?tigt: Die Option ?ignore-mdc-error? w?re
hierzu in eine Konfigurationsdatei einzutragen.  Die Dokumentation zu
dieser Option sagt:

  This option changes a MDC integrity protection failure into a warning.
  It is required to decrypt old messages which did not use an MDC.  It
  may also be useful if a message is partially garbled, but it is
  necessary to get as much data as possible out of that garbled message.
  Be aware that a missing or failed MDC can be an indication of an
  attack.  Use with great caution; see also option --rfc2440.

Der MDC (Manipulation Detection Code) ist die seit 20 Jahren benutzte
Form von Authenticated Encryption (AD) in OpenPGP.  Im Zuge des EFail
Papers wurde die bereits damals vorhandene Warnung in eine harte
Fehlermeldung ge?ndert.  Es werden damit keine Dateien mehr gespeichert,
die ohne MDC verschl?sselt wurden.  Im Paper wird auf Seite 14 unter
?Practical attacks on GnuPG? als Voraussetzung lediglich:

  When running the initial query step against a downgraded GnuPG AEAD
  OCB-AES packet using GnuPG 2.2.27 as the decryption oracle, [...]

dies genannt.  Die notwendige Konfigurations?nderung ?ignore-mdc-error?
wird im gesamten Paper nicht erw?hnt.

Auf Seite 6 wird irref?hrend behauptet:

  Table 3 also indicates that both implementations support the
  decryption of SED packets. When decrypting SED packet with GnuPG, the
  following message is output

    gpg: WARNING: message was not integrity protected
    gpg: decryption forced to fail!

  and the file is still decrypted.

Sofern eine Ausgabedatei angegeben wurde, so wird diese in diesem Fall
auch wieder gel?scht.  Ferner, und wesentlich wichtiger, wird auf der
Kommandozeile und auch bei der Verwendung der GPGME Bibliothek ein
Fehlercode zur?ckgegeben.  Die Pr?fung von Fehlerr?ckgabewerten ist eine
essentielle Grundvoraussetzung bei der Verwendung von Software.

Wird ?gpg? (das Kommandozeilentool) in einer Pipeline verwendet, so
speichert es keine Daten in tempor?ren Dateien oder im RAM sondern gibt
diese direkt auf der Standardausgabe aus.  Dies erm?glicht die
Entschl?sselung beliebig gro?er Daten und wird vielfach verwendet.  Dies
enthebt die ?bergeordneten Prozeduren aber nicht von der Pflicht die
Fehlerr?ckgabe am Ende zu pr?fen.

Auf Seite 15 wird als m?gliche ?Countermeasure? Folgendes angegeben:

  A straightforward implementation countermeasure effective for the
  current state of GnuPG AEAD is furthermore to not support the
  deprecated SED de- cryption. However, this countermeasure has the
  drawback that it can only be enforced by the receiving client and for
  the sender of a GnuPG AEAD packet it would remain unknown if the
  receiving client is vulnerable or not.

Hierzu ist zu sagen, da? dies seit 2018 genauso implementiert ist:

  Noteworthy changes in version 2.2.8 (2018-06-08)

  * gpg: Decryption of messages not using the MDC mode will now lead
    to a hard failure even if a legacy cipher algorithm was used.  The
    option --ignore-mdc-error can be used to turn this failure into a
    warning.  Take care: Never use that option unconditionally or
    without a prior warning.

Eine Verwendung von noch ?lteren Versionen mu? nicht ber?cksichtigt
werden, da diese Fehler enthielten, die einen direkten Zugriff auf den
Rechner erlauben w?rden.

Desweiteren ist anzumerken, da? Systeme Tools f?r Offline-Protokolle wie
OpenPGP oder CMS einsetzen, grunds?tzlich vermeiden sollten als Orakel
einsetzbar zu sein.  In automatisierten Systeme ist somit die R?ckgabe
eines Fehler daraufhin zu designen und R?ckgaben m?glichts zeitverz?gert
durchzuf?hren sind um so Angriffe nach dem Bleicherbacherprinzip zu
verhindern.  Eine R?ckgabe gar von fehlerhaft entschl?sselten Daten, wie
in dem Paper angenommen, sollte niemals vorkommen.

Die vorgeschlagene Schl?sselableitung bei der Verwendung des neuen OCB
Modus w?re sicherlich erw?genswert gewesen.  Seit der Vorstellung des
OCB Modus im Herbst 2017 und des Deployments im Fr?hjahr 2018 wurde dies
aber nie als notwendig erachtet.  Erst im Zusammenhang mit der
Spezifizierung eines GCM Modus im ?crypto-refresh? (irgendwann zwischen
Herbst 2021 und Fr?hjahr 2022) wurde eine Schl?sselableitung hierzu
notwendig.  Im ?brigen halte ich die Verwendung von GCM, sowie allgemein
die Proliferation von Algorithmen, f?r eine wesentlich gr??ere
Schwachstelle als den beschriebenen Downgrade Angriff von OCB auf den
Legacy CFB Modus.


Viele Gr??e,

   Werner Koch


p.s.
Als Autor und Maintainer von GnuPG sehe ich keine Notwendigkeit das
beschriebene Paper unter Verschluss zuhalten.  Meine Antwort kann gerne
ver?ffentlich werden.

-- 
g10 Code GmbH        -=- GnuPG.com -=-      AmtsGer. Wuppertal HRB 14459
Bergstr. 3a                                 Gesch?ftsf?hrung Werner Koch
D-40699 Erkrath      https://gnupg.com      USt-Id DE215605608
--8<---------------cut here---------------end--------------->8---


[1]  http://www.cs.auckland.ac.nz/~pgut001/pubs/bollocks.pdf

-- 
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: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240823/5d7e4418/attachment.sig>

From jb-gnumlists at wisemo.com  Tue Aug 27 17:37:03 2024
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Tue, 27 Aug 2024 17:37:03 +0200
Subject: [Feature request] Please make it easier to check success/failure from
 scripts
Message-ID: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com>

Dear GnuPG team,

According to the documentation for the version I have received from 
Debian, scripts that wish to check for success failure of decryption 
and/or signature validation done by invocation of gpg/gpgv/gpgsm, the 
script is currently required to set up a "status-fd", then check the 
status-fd output for a multitude of situation specific strings.? 
Sometimes it is even necessary to check if the expected signing key is 
mentioned in specific ways.

This is highly impractical compared to other scripting of POSIX 
commands.? It would be really nice if a future version of the gnupg 
suite would provide the result via the process exit code directly, 
perhaps with some intermediary values indicating various warning 
conditions such as "valid signature from someone not listed in command 
line option to indicate expected signer" .

I know this because I have a script that uses gpgsm to do pipelined 
check of a large CMS signed system log, which is signed by the server to 
prevent later malicious changes.? gpgsm is used because of its specific 
support for streamed processing.

Your response to the latest fluff paper about supposed "Downgrade 
attacks" emphasizes the importance of doing these checks.

Another, related, feature would be the ability to run the gnupg tools in 
a mode that doesn't talk to any part of the environment, neither the 
gnupg config dir, nor the various helper programs (directory, password 
prompt etc.), but instead acts predicatably based only on the command 
line options.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



From tfasnetamot at emailn.eu  Sat Aug 31 18:29:17 2024
From: tfasnetamot at emailn.eu (T. S.)
Date: Sat, 31 Aug 2024 18:29:17 +0200
Subject: Signing (and Encrypting) Mails with gpg like DKIM
Message-ID: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>

An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240831/8b488c29/attachment.html>