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: <87cyn4i8qb.fsf@jacob.g10code.de> <8734nrtrce.fsf@jumper.gniibe.org> Message-ID: On Tue, Jul 30, 2024 at 12:51?PM Niibe Yutaka 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 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> <87r0bcw5jd.fsf@fifthhorseman.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: 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> <87r0bcw5jd.fsf@fifthhorseman.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> <87r0bcw5jd.fsf@fifthhorseman.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> <87r0bcw5jd.fsf@fifthhorseman.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> <87r0bcw5jd.fsf@fifthhorseman.net> <87o76fw7c5.fsf@fifthhorseman.net> <20240805200844.4666b147@tag.xn--rombobjrn-67a.se> <4131c3c0-ff04-104d-e275-d1b35de35e14@wisemo.com> <63d645232dd0543f50cfcfb2c5d529a1@andrewg.com> Message-ID: 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> <87r0bcw5jd.fsf@fifthhorseman.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: 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> <87r0bcw5jd.fsf@fifthhorseman.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: 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: 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: References: Message-ID: 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 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: References: Message-ID: 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 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 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: 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: (Matthias Apitz's message of "Mon, 12 Aug 2024 14:26:27 +0200") References: 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: 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: <877ccld8i0.fsf@jacob.g10code.de> Message-ID: 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: 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] 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). [ 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 = key expires in n days w = key expires in n weeks m = key expires in n months 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). [ 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 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: References: Message-ID: 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: References: Message-ID: <12B559F2-C318-413B-B6E0-B9F0067E17CF@andrewg.com> On 14 Aug 2024, at 10:29, Matthias Apitz 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 </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 < 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: References: 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 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] > 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). > [ 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 > = key expires in n days > w = key expires in n weeks > m = key expires in n months > 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). > [ 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 > 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: 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 " 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: 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: 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 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: 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: 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: 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: 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: (Nicolai Langfeldt's message of "Thu, 22 Aug 2024 07:57:00 +0200") References: 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: 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: 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: <87a5h5m248.fsf@jacob.g10code.de> Message-ID: 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: 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: 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: 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: 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: 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: 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: 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: 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: <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: 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: On 2024-08-22 Alex via Gnupg-users 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: 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: An HTML attachment was scrubbed... URL: