From bernhard at intevation.de Thu Jan 5 15:59:32 2023 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 5 Jan 2023 15:59:32 +0100 Subject: gpgme python bindings (Re: [PATCH gpgme] Fix prerelease Python sdist tarball creation and add PEP517 support) In-Reply-To: <202212011057.35450.bernhard@intevation.de> References: <202212011057.35450.bernhard@intevation.de> Message-ID: <202301051559.45566.bernhard@intevation.de> Hi David, Am Donnerstag 01 Dezember 2022 10:57:28 schrieb Bernhard Reiter: > It would be cool to improve the python binding situation, > even it is just to clarify it more. to explain further [1]: The GnuPG devs support the official GPGME bindings for Python it comes as part of the release tarball, for details see https://wiki.gnupg.org/APIs However the do _not_ (so far) maintain a pypi distribution, thus https://pypi.org/project/gpg/ is outdated. ## History of pypi/gpg It was updated by Justus Winter 2018 who did work as GnuPG dev for g10code until 2017, so he may have started this as GnuPG dev [1]. Ben McGinnes then did some followup work. As far as I remember, there were technical difficulties how the C part could be build with pypi to make sure that distributions with pypi were practical. Since Ben stopped working on it, there is lack of maintainer power. ## How to go forward? Your patch was a reminder to check if the situation can be solved in a better way (maybe because of new ideas or because the situation has improved). That is if there is time, because I or somebody else has it. My first step would be to check the status, who controls the pypi entry and see about your patch, make a plan. And document this in the tracker or the wiki. Best Regards, Bernhard [1] Thanks for asking me this on Mastodon: https://social.tchncs.de/@dvzrv at chaos.social/109637114243091982 -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Fri Jan 6 15:30:31 2023 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 6 Jan 2023 15:30:31 +0100 Subject: Likely IETF WG incompatibility with GnuPG 2.3/2.4 In-Reply-To: References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212191019.05244.bernhard@intevation.de> Message-ID: <202301061530.39144.bernhard@intevation.de> Hi Vincent and list, first I wish a happy new year to you and hope for individual health and general more peace in the world! Am Dienstag 20 Dezember 2022 11:38:51 schrieb Vincent Breitmoser via Gnupg-devel: > > and the WG decision to become incompatible with the previous drafts > > were a big decision for the working group affecting > > OpenPGP users, implementations and the wider ecosystem. > > That is true. And the decision has not been made lightly. I also do not know what is going on. My response mainly aims to explain that the way a question is asked already makes assumptions. And if we want to reach collaboration we need a respectful way of treating each other. > As any WG work, this is a public process: > There has been a lot of discussion, > over a lengthy period of time, with input from many individuals and > projects. > > https://mailarchive.ietf.org/arch/msg/openpgp/PWp3ZcZ_qnDNLhuT-zR7gA2ddeg/ Given the cited charter and way the "design team" works in followup to your post, the design team was a closed process. And according to Werner the design team was in consensus and on a good course, with only details to sort out, until he had to leave it. So we need to find out what was happening in the IETF WG design team (often abbreviated DT) after this. > It's a complex topic and hard to do justice in summary. Thanks for providing a link to the mail archive showing one part of the process that is on public record. After reading a few mails my current understanding is: * There are overlapping (and partly conflicting) drafts, let us call them "koch" and "newdesignteam" * The "newdesignteam" draft is much longer and more complex (at least according to Peter Gutmann and Werner Koch) * The "koch" draft is implemented widely (which was common practice to test the specfication). * Somewhere the closed DT deviated from a consensus that the previous "koch" drafts had in the working group and of the course the DT had in their closed group. > Hence the concrete question here what the plans are for the future of > his concrete project. As you wrote mails to the WG list, you will have seen what Werner already wrote about is a good path forward for the existing implementation RNP and GnuPG: https://mailarchive.ietf.org/arch/msg/openpgp/Ek9SvwdsWJ_j4C7SWVoCSKwfo8Y/ Werner Koch Mon, 10 October 2022 12:20 UTC [..] We deployed things years ago and won't extend that unless there are sound reasons for it. It would be a bit sad if we eventually need to state: "GnuPG implements OpenPGP as specified by RFC-4880 and RFC-6337 plus some extensions described [[here]]". However, our users and their data is more important to us than implementing a newer RFC. https://mailarchive.ietf.org/arch/msg/openpgp/EQC4wCPfwDm-CKLbYLGsOC5hQpE/ Re: [openpgp] a new draft overlapping the WG draft Werner Koch Mon, 10 October 2022 12:34 UTC [about newdesignteam draft] a brief reading shows that it way to complex for an update of OpenPGP. [..] I have not read the new v5 things in detail but I can imagine that we can still change the format. We have been cautious enough to tell people that v5 has not yet been finished. It seems after this, not much has changed on the "newdesignteam" draft. In December Werner wrote: https://lists.gnupg.org/pipermail/gnupg-users/2022-December/066362.html Werner Koch wk at gnupg.org, Fri Dec 16 18:45:58 CET 2022 [..] GnuPG won't follow the likely outcome of the IETF OpenPGP WG because we value our users and feel a responsibility to keep a deployed and sensible moving ecosystem alive and working. So yes, it seems that the outcome of the WG is an incompatibility. And the stated plan of GnuPG seems to not follow the WG outcome, until it changed to be less complex and more towards the early consensus points. (The 10th of October 12:34 mail shows some technicals where both sides seems to be open.) It would be good to have a more official statement from GnuPG and RNP about this. At least I'll go asking. But I also think that others need to dig through the data so we get a summary about the technical issues and the reasoning. And also ask questions about the rational of the remaining closed design team. Best Regards Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From justus at sequoia-pgp.org Fri Jan 6 16:12:20 2023 From: justus at sequoia-pgp.org (Justus Winter) Date: Fri, 06 Jan 2023 16:12:20 +0100 Subject: potential IETF WG incompatibility with GnuPG 2.3 In-Reply-To: <87cz8bwsu3.fsf@europ.lan> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <87fsdanmyp.fsf@wheatstone.g10code.de> <10199374.nUPlyArG6x@daneel> <877cylngev.fsf@wheatstone.g10code.de> <87cz8bwsu3.fsf@europ.lan> Message-ID: <878rifofxn.fsf@europ.lan> (Resent, earlier mail got lost in somewhere in the mail server configuration jungle.) Moin Werner :) Werner Koch via Gnupg-devel writes: > On Wed, 21 Dec 2022 10:30, Ingo Kl?cker said: > >> That's the mailing list of the WG and not the closed one (with open archive) >> used by the DT. For the record, said archive is here: https://mailarchive.ietf.org/arch/browse/openpgp-dt/ I'm not sure why the list has been characterized as closed. It is true that you could not self-subscribe, but everyone was able to post to that list. We did add people to the design team after its inception (Jeffrey), and I'm not aware that anyone was denied access to the design team or the corresponding mailing list. > And lots of video calls not all covered by the minutes. I'm saddened that your trust in the process has been shaken. However, it is not true that there were design team meetings not covered by public notes. In fact, I made a list of every meeting and corresponding notes: https://mailarchive.ietf.org/arch/msg/openpgp/9-WktrFNuZVYZVwlAKl0J56k5Vc/ If you think there were meetings not covered by the notes, I'd be interested to hear which ones you are thinking of. Best, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 519 bytes Desc: not available URL: From ralph at ml.seichter.de Tue Jan 10 00:47:08 2023 From: ralph at ml.seichter.de (Ralph Seichter) Date: Tue, 10 Jan 2023 00:47:08 +0100 Subject: [Announce] GnuPG for OS X 2.4.0 released Message-ID: <87fscjuv7n.fsf@ra.horus-it.com> GnuPG for OS X / macOS release 2.4.0 is now available for download via https://sourceforge.net/p/gpgosx/docu/Download/ . It took me longer than usual to provide this release, because I ran into build problems. I also spent several weeks in hospitals over the last couple of months, and I am still not well today, so I hope you can forgive the delay. ;-) The disk image signature key is available via public keyservers, and it can also be downloaded from https://www.seichter.de/pgp/gpgosx-signing.asc . pub ed25519/FD56297D9833FF7F 2022-07-07 [SC] [expires: 2027-07-06] Key fingerprint = EAB0 FE4F F793 D9E7 028E C8E2 FD56 297D 9833 FF7F uid [ultimate] Ralph Seichter (GnuPG for OS X signing key) GnuPG 2.4.x is installed in /usr/local/gnupg-2.4 instead of the formerly hardcoded directory /usr/local/gnupg-2.2. This enables installing both stable and LTS releases of GnuPG for OS X side by side, for advanced users' needs. The one caveat is that the latest installation will replace existing soft links in /usr/local/{bin,lib}. Please use absolute paths like /usr/local/gnupg-2.2/bin/gpg2 if necessary. Enjoy. -Ralph From andrewg at andrewg.com Tue Jan 10 13:17:59 2023 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 10 Jan 2023 12:17:59 +0000 Subject: Some proposals for future synchronising keyserver development Message-ID: Hi, all. It?s been quiet in keyserver land recently, but I recently published four proposals for how to move forward on the Hockeypuck github blog, and all feedback is welcome: HIP 2: SKS v2 protocol Sync using hashes of self-sig packets rather than hashes of TPKs would mitigate several well-known issues with the SKS protocol. This proposal evolved out of previous discussions around decomposing TPKs into atoms. tl;dr: you don?t have to decompose into atoms, just pretend to the recon protocol that you did. https://github.com/hockeypuck/hockeypuck/wiki/HIP-2:-SKS-v2-protocol HIP 3: Timestamp-aware merge strategy 1pa3pc is a great idea, but it?s still a long way off standardisation and requires updates to all clients. But we don?t need actual attested signatures if keyservers treat the most recent self-sig anywhere on the key as equivalent to an attestation sig, and infer the same behaviour from it. https://github.com/hockeypuck/hockeypuck/wiki/HIP-3:-Timestamp-aware-merge-strategy HIP 4: Third-party revocation sig distribution Both 1pa3pc and HIP 3 above can prevent the distribution of third-party revocation signatures, meaning that a malicious actor could strip third-party revocations from the keyserver copy of his key and pass it off as still certified. Distributing revocations with the _signing_ key rather than the signee avoids this issue. https://github.com/hockeypuck/hockeypuck/wiki/HIP-4:-Third-party-revocation-sig-distribution HIP 5: Reliable personal data deletion using self-signatures Previous proposals for automated deletion of personal information from keyservers have all developed holes under closer scrutiny. Here?s a new attempt using direct key self-sigs and (potentially?) no protocol changes. https://github.com/hockeypuck/hockeypuck/wiki/HIP-5:-Reliable-personal-data-deletion-using-self-signatures Please let me know if you have any questions. Thanks, Andrew. (Crossposted to sks-devel, gnupg-devel and hockeypuck-devel) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From look at my.amazin.horse Wed Jan 11 00:19:45 2023 From: look at my.amazin.horse (Vincent Breitmoser) Date: Wed, 11 Jan 2023 00:19:45 +0100 Subject: Allowing import of pubkeys without User ID In-Reply-To: <202212151108.08889.bernhard@intevation.de> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212130935.30386.bernhard@intevation.de> <7f788796-d49e-3ff0-258b-a99b6568d06b@my.amazin.horse> <202212151108.08889.bernhard@intevation.de> Message-ID: <754c8206-ab13-96bd-20e8-225b83dacdc6@my.amazin.horse> Hey list, quickly noting an observation here that was news to me just now: Werner's rfc4880bis and the working group's crypto-refresh drafts agree that transferable public keys no longer are required to carry a User ID packet: https://www.ietf.org/archive/id/draft-koch-openpgp-2015-rfc4880bis-00.html#section-11.1 https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-06.html#section-11.1.2 So regardless which one of those you believe in, keys.openpgp.org will be compliant with the upcoming spec. Cheers ?- V From bernhard at intevation.de Wed Jan 11 09:16:33 2023 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 11 Jan 2023 09:16:33 +0100 Subject: Allowing import of pubkeys without User ID In-Reply-To: <754c8206-ab13-96bd-20e8-225b83dacdc6@my.amazin.horse> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212151108.08889.bernhard@intevation.de> <754c8206-ab13-96bd-20e8-225b83dacdc6@my.amazin.horse> Message-ID: <202301110916.33893.bernhard@intevation.de> Am Mittwoch 11 Januar 2023 00:19:45 schrieb Vincent Breitmoser via Gnupg-devel: > So regardless which one of those you believe in, I hope it is not a "believe", but we can find good reasons for the best way for OpenPGP users. > keys.openpgp.org will be compliant with the upcoming spec. Are you considering to update the FAQ then? Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu Jan 12 09:33:33 2023 From: wk at gnupg.org (Werner Koch) Date: Thu, 12 Jan 2023 09:33:33 +0100 Subject: Allowing import of pubkeys without User ID In-Reply-To: <754c8206-ab13-96bd-20e8-225b83dacdc6@my.amazin.horse> (Vincent Breitmoser via Gnupg-devel's message of "Wed, 11 Jan 2023 00:19:45 +0100") References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212130935.30386.bernhard@intevation.de> <7f788796-d49e-3ff0-258b-a99b6568d06b@my.amazin.horse> <202212151108.08889.bernhard@intevation.de> <754c8206-ab13-96bd-20e8-225b83dacdc6@my.amazin.horse> Message-ID: <87lem8b19e.fsf@wheatstone.g10code.de> Hi! On Wed, 11 Jan 2023 00:19, Vincent Breitmoser said: > Werner's rfc4880bis and the working group's crypto-refresh drafts > agree that transferable public keys no longer are required to carry > a User ID packet: Thanks for noting. Fix below. Shalom-Salam, Werner commit 64ace7e2c10ef92269073e481c1622b522dc0c9f (HEAD -> refs/heads/master) Author: Werner Koch Date: Thu Jan 12 09:31:19 2023 +0100 Fix composition of public key blocks. In the course of the reformatting actions of the draft a regression against 4880 was not fixed (Zero User ID packets). The reason for introducing zero User ID packets might have been the idea to express that an Attribute packet may be used instead of a User ID. However, that should either be clarified in the comments or left to the implementation. The second fix is to require at least one Signature packet after a User ID and Attribute packet. This was wrong in 2440 and 4880 but is cryptographically required. Modified rfc4880bis.md diff --git a/rfc4880bis.md b/rfc4880bis.md index 038908b..1eaa21a 100644 --- a/rfc4880bis.md +++ b/rfc4880bis.md @@ -4083,14 +4083,14 @@ transferable public key are as follows: - Zero or more revocation signatures - - Zero or more User ID packets + - One or more User ID packets - - After each User ID packet, zero or more Signature packets + - After each User ID packet, one or more Signature packets (certifications and attestation key signatures) - Zero or more User Attribute packets - - After each User Attribute packet, zero or more Signature packets + - After each User Attribute packet, one or more Signature packets (certifications and attestation key signatures) - Zero or more Subkey packets @@ -4106,7 +4106,7 @@ may have more than one email address, and construct a User ID for each one. A transferable public key SHOULD include at least one User ID packet unless storage requirements prohibit this. -Immediately following each User ID packet, there are zero or more +Immediately following each User ID packet, there are one or more Signature packets. Each Signature packet is calculated on the immediately preceding User ID packet and the initial Public-Key packet. The signature serves to certify the corresponding public key @@ -4119,7 +4119,7 @@ certifications over the associated User ID. Within the same section as the User ID packets, there are zero or more User Attribute packets. Like the User ID packets, a User Attribute -packet is followed by zero or more Signature packets calculated on the +packet is followed by one or more Signature packets calculated on the immediately preceding User Attribute packet and the initial Public-Key packet. -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From andrewg at andrewg.com Thu Jan 12 13:24:02 2023 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 12 Jan 2023 12:24:02 +0000 Subject: Allowing import of pubkeys without User ID In-Reply-To: <87lem8b19e.fsf@wheatstone.g10code.de> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212130935.30386.bernhard@intevation.de> <7f788796-d49e-3ff0-258b-a99b6568d06b@my.amazin.horse> <202212151108.08889.bernhard@intevation.de> <754c8206-ab13-96bd-20e8-225b83dacdc6@my.amazin.horse> <87lem8b19e.fsf@wheatstone.g10code.de> Message-ID: <22674744-BFE9-465C-9CC3-AD94961E45C5@andrewg.com> On 12 Jan 2023, at 08:33, Werner Koch via Gnupg-devel wrote: > > - Zero or more Subkey packets > @@ -4106,7 +4106,7 @@ may have more than one email address, and construct a User ID for each > one. A transferable public key SHOULD include at least one User ID > packet unless storage requirements prohibit this. > There is another use case, not previously discussed IIRC, where distributing a TPK without any User ID is desirable. In order to implement RTBF, keyservers must be able to remove personal information from their databases. If a key owner wishes their personal information to be deleted, but this information is attached to a revoked primary key, then removing the entire key from the keyserver will also remove the revocation, which opens a security loophole. It should be possible to still serve the revocation to those people who already have a copy of the full key, without serving the associated personal information to those who do not. Bare revocations may not be sufficent, as these will only be searchable via the primary key fingerprint, whereas keys are often searched for by a subkey fingerprint (e.g. to validate sigs). HIP 5 [1] is an attempt to implement a distributable RTBF declaration using direct revocations, however it requires UID-less TPKs, and may also require multiple direct revocations to be distributed (e.g. a key may be RTBFed *and* compromised). This cannot (IMO) be reliably done using only UIDful TPKs or bare revocations. A [1] https://github.com/hockeypuck/hockeypuck/wiki/HIP-5:-Reliable-personal-data-deletion-using-self-signatures -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From justus at sequoia-pgp.org Thu Jan 12 14:02:50 2023 From: justus at sequoia-pgp.org (Justus Winter) Date: Thu, 12 Jan 2023 14:02:50 +0100 Subject: gpgme python bindings (Re: [PATCH gpgme] Fix prerelease Python sdist tarball creation and add PEP517 support) In-Reply-To: <202301051559.45566.bernhard@intevation.de> References: <202212011057.35450.bernhard@intevation.de> <202301051559.45566.bernhard@intevation.de> Message-ID: <87358foqh1.fsf@europ.lan> Hi Bernhard :) Bernhard Reiter writes: > ## How to go forward? > Your patch was a reminder to check if the situation can be solved in a better > way (maybe because of new ideas or because the situation has improved). > That is if there is time, because I or somebody else has it. > My first step would be to check the status, who controls the pypi entry > and see about your patch, make a plan. And document this in the tracker or the > wiki. I can help with that. I currently "own" the project on PiPI, and am happy to hand that over. Best, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 519 bytes Desc: not available URL: From wk at gnupg.org Thu Jan 12 21:11:34 2023 From: wk at gnupg.org (Werner Koch) Date: Thu, 12 Jan 2023 21:11:34 +0100 Subject: Allowing import of pubkeys without User ID In-Reply-To: <22674744-BFE9-465C-9CC3-AD94961E45C5@andrewg.com> (Andrew Gallagher via Gnupg-devel's message of "Thu, 12 Jan 2023 12:24:02 +0000") References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212130935.30386.bernhard@intevation.de> <7f788796-d49e-3ff0-258b-a99b6568d06b@my.amazin.horse> <202212151108.08889.bernhard@intevation.de> <754c8206-ab13-96bd-20e8-225b83dacdc6@my.amazin.horse> <87lem8b19e.fsf@wheatstone.g10code.de> <22674744-BFE9-465C-9CC3-AD94961E45C5@andrewg.com> Message-ID: <87edrzbjih.fsf@wheatstone.g10code.de> On Thu, 12 Jan 2023 12:24, Andrew Gallagher said: > associated personal information to those who do not. Bare revocations > may not be sufficent, as these will only be searchable via the primary > key fingerprint, whereas keys are often searched for by a subkey > fingerprint (e.g. to validate sigs). That is not a problem because you need to get the primary key anyway before you can use a subkey (because of the subkey binding signature). Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bernhard at intevation.de Fri Jan 13 11:06:51 2023 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 13 Jan 2023 11:06:51 +0100 Subject: python "gpg" on pypi (Re: gpgme python bindings) In-Reply-To: <87358foqh1.fsf@europ.lan> References: <202301051559.45566.bernhard@intevation.de> <87358foqh1.fsf@europ.lan> Message-ID: <202301131106.58055.bernhard@intevation.de> Hi Justus, Am Donnerstag 12 Januar 2023 14:02:50 schrieb Justus Winter: > > My first step would be to check the status, who controls the pypi entry > I can help with that. I currently "own" the project on PiPI, https://pypi.org/project/gpg/ > and am happy to hand that over. thanks, please transfer it to my pypi account: https://pypi.org/user/bernhard/ (You should be able to do this with the interface, when logged in.) I'll will add other GnuPG devs by request of the maintainers. Best, Bernhard ps.: Your pubkey still seems to have id [ unbekannt ] Justus Winter is that still as it should be? -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From justus at sequoia-pgp.org Fri Jan 13 11:40:55 2023 From: justus at sequoia-pgp.org (Justus Winter) Date: Fri, 13 Jan 2023 11:40:55 +0100 Subject: python "gpg" on pypi (Re: gpgme python bindings) In-Reply-To: <202301131106.58055.bernhard@intevation.de> References: <202301051559.45566.bernhard@intevation.de> <87358foqh1.fsf@europ.lan> <202301131106.58055.bernhard@intevation.de> Message-ID: <87zgamn2dk.fsf@europ.lan> Hi Bernhard, Bernhard Reiter writes: > Am Donnerstag 12 Januar 2023 14:02:50 schrieb Justus Winter: >> > My first step would be to check the status, who controls the pypi entry > >> I can help with that. I currently "own" the project on PiPI, > > https://pypi.org/project/gpg/ > >> and am happy to hand that over. > > thanks, please transfer it to my pypi account: > https://pypi.org/user/bernhard/ > (You should be able to do this with the interface, when logged in.) I invited you as the owner. Feel free to remove me to complete the handover. > ps.: Your pubkey still seems to have > id [ unbekannt ] Justus Winter > is that still as it should be? As far as I know I can still receive mails sent to that address. Therefore, if someone wants to contact me securely using that address, they can use my OpenPGP certificate. I think that is as it should be. Best, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 519 bytes Desc: not available URL: From andrewg at andrewg.com Fri Jan 13 12:00:48 2023 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 13 Jan 2023 11:00:48 +0000 Subject: Allowing import of pubkeys without User ID In-Reply-To: <87edrzbjih.fsf@wheatstone.g10code.de> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212130935.30386.bernhard@intevation.de> <7f788796-d49e-3ff0-258b-a99b6568d06b@my.amazin.horse> <202212151108.08889.bernhard@intevation.de> <754c8206-ab13-96bd-20e8-225b83dacdc6@my.amazin.horse> <87lem8b19e.fsf@wheatstone.g10code.de> <22674744-BFE9-465C-9CC3-AD94961E45C5@andrewg.com> <87edrzbjih.fsf@wheatstone.g10code.de> Message-ID: <815D3313-3355-41B7-B64D-B8F10D335549@andrewg.com> On 12 Jan 2023, at 20:11, Werner Koch wrote: > > On Thu, 12 Jan 2023 12:24, Andrew Gallagher said: > >> associated personal information to those who do not. Bare revocations >> may not be sufficent, as these will only be searchable via the primary >> key fingerprint, whereas keys are often searched for by a subkey >> fingerprint (e.g. to validate sigs). > > That is not a problem because you need to get the primary key anyway > before you can use a subkey (because of the subkey binding signature). True, it?s not a security issue - but it is a usability one. ?Key not found? is a temporary error, while ?key revoked? is permanent. These are two quite different failure modes, and it would be best to clearly distinguish them. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From wk at gnupg.org Fri Jan 13 12:50:05 2023 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Jan 2023 12:50:05 +0100 Subject: Allowing import of pubkeys without User ID In-Reply-To: <815D3313-3355-41B7-B64D-B8F10D335549@andrewg.com> (Andrew Gallagher via Gnupg-devel's message of "Fri, 13 Jan 2023 11:00:48 +0000") References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212130935.30386.bernhard@intevation.de> <7f788796-d49e-3ff0-258b-a99b6568d06b@my.amazin.horse> <202212151108.08889.bernhard@intevation.de> <754c8206-ab13-96bd-20e8-225b83dacdc6@my.amazin.horse> <87lem8b19e.fsf@wheatstone.g10code.de> <22674744-BFE9-465C-9CC3-AD94961E45C5@andrewg.com> <87edrzbjih.fsf@wheatstone.g10code.de> <815D3313-3355-41B7-B64D-B8F10D335549@andrewg.com> Message-ID: <87a62mbqmq.fsf@wheatstone.g10code.de> On Fri, 13 Jan 2023 11:00, Andrew Gallagher said: > True, it?s not a security issue - but it is a usability one. ?Key not > found? is a temporary error, while ?key revoked? is permanent. These > are two quite different failure modes, and it would be best to clearly > distinguish them. Sure. But the point here is on how to retrieve a revocation certificate. To do this you first need to have access to the key - without the key there is no need to retrieving a revocation. Without a key you don't know anything about a signature. In fact you could store a standalone revocation certificate on the server and allow accessing it by the included issuer fingerprint. A dedicated keyserver command to do just this might be useful too. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From andrewg at andrewg.com Fri Jan 13 13:15:13 2023 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 13 Jan 2023 12:15:13 +0000 Subject: Allowing import of pubkeys without User ID In-Reply-To: <87a62mbqmq.fsf@wheatstone.g10code.de> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212130935.30386.bernhard@intevation.de> <7f788796-d49e-3ff0-258b-a99b6568d06b@my.amazin.horse> <202212151108.08889.bernhard@intevation.de> <754c8206-ab13-96bd-20e8-225b83dacdc6@my.amazin.horse> <87lem8b19e.fsf@wheatstone.g10code.de> <22674744-BFE9-465C-9CC3-AD94961E45C5@andrewg.com> <87edrzbjih.fsf@wheatstone.g10code.de> <815D3313-3355-41B7-B64D-B8F10D335549@andrewg.com> <87a62mbqmq.fsf@wheatstone.g10code.de> Message-ID: On 13 Jan 2023, at 11:50, Werner Koch wrote: > > On Fri, 13 Jan 2023 11:00, Andrew Gallagher said: > >> True, it?s not a security issue - but it is a usability one. ?Key not >> found? is a temporary error, while ?key revoked? is permanent. These >> are two quite different failure modes, and it would be best to clearly >> distinguish them. > > Sure. But the point here is on how to retrieve a revocation > certificate. To do this you first need to have access to the key - > without the key there is no need to retrieving a revocation. Without a > key you don't know anything about a signature. Correct. But say we?re trying to look up the key for a strange signature, and we have multiple methods to do so (several disjoint keyservers, WKD, LDAP, etc.). If we get a ?key not found? error, that?s just going to encourage us (either manually or via an automated system) to keep trying the other methods. But if we get a ?key revoked? error, then we have a definite answer and can stop looking. The client-side/user behaviour changes depending on the failure mode. > In fact you could store a standalone revocation certificate on the > server and allow accessing it by the included issuer fingerprint. A > dedicated keyserver command to do just this might be useful too. Yes, there are any number of alternative ways to work around it, but none of them are as straightforward and elegant as just... allowing uid-less TPKs. :-) Particularly in the case of synchronising keyservers, where the only canonical metadata is what can be stored in a self-sig, it makes sense to allow self-sigs and their primaries to be distributed regardless of whether they are ?usable? in a client-side sense. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From wk at gnupg.org Fri Jan 13 15:30:00 2023 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Jan 2023 15:30:00 +0100 Subject: Allowing import of pubkeys without User ID In-Reply-To: (Andrew Gallagher via Gnupg-devel's message of "Fri, 13 Jan 2023 12:15:13 +0000") References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212130935.30386.bernhard@intevation.de> <7f788796-d49e-3ff0-258b-a99b6568d06b@my.amazin.horse> <202212151108.08889.bernhard@intevation.de> <754c8206-ab13-96bd-20e8-225b83dacdc6@my.amazin.horse> <87lem8b19e.fsf@wheatstone.g10code.de> <22674744-BFE9-465C-9CC3-AD94961E45C5@andrewg.com> <87edrzbjih.fsf@wheatstone.g10code.de> <815D3313-3355-41B7-B64D-B8F10D335549@andrewg.com> <87a62mbqmq.fsf@wheatstone.g10code.de> Message-ID: <875ydabj87.fsf@wheatstone.g10code.de> On Fri, 13 Jan 2023 12:15, Andrew Gallagher said: > system) to keep trying the other methods. But if we get a ?key > revoked? error, then we have a definite answer and can stop > looking. The client-side/user behaviour changes depending on the You can't stop because you would trust the statement from the keyserver. Which is not what keyservers are made for. Thus even after you get a revoked status from a keyserver you need to fetch the public key and verify the revocation certificate. > a self-sig, it makes sense to allow self-sigs and their primaries to > be distributed regardless of whether they are ?usable? in a > client-side sense. You can do between the keyservers whatever you want. If you want to validate the keyblock you need the user id and need to verify the self-sig before you allow fetching that keyblock (maybe restricted to the requested user id) Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From andrewg at andrewg.com Fri Jan 13 16:13:20 2023 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 13 Jan 2023 15:13:20 +0000 Subject: Allowing import of pubkeys without User ID In-Reply-To: <875ydabj87.fsf@wheatstone.g10code.de> References: <19bd309c-f657-fbc7-162d-140bb8d98db0@my.amazin.horse> <202212130935.30386.bernhard@intevation.de> <7f788796-d49e-3ff0-258b-a99b6568d06b@my.amazin.horse> <202212151108.08889.bernhard@intevation.de> <754c8206-ab13-96bd-20e8-225b83dacdc6@my.amazin.horse> <87lem8b19e.fsf@wheatstone.g10code.de> <22674744-BFE9-465C-9CC3-AD94961E45C5@andrewg.com> <87edrzbjih.fsf@wheatstone.g10code.de> <815D3313-3355-41B7-B64D-B8F10D335549@andrewg.com> <87a62mbqmq.fsf@wheatstone.g10code.de> <875ydabj87.fsf@wheatstone.g10code.de> Message-ID: <611F612D-73DF-4C9B-B7CC-D4BEAC0D85F5@andrewg.com> On 13 Jan 2023, at 14:30, Werner Koch wrote: > > On Fri, 13 Jan 2023 12:15, Andrew Gallagher said: > >> system) to keep trying the other methods. But if we get a ?key >> revoked? error, then we have a definite answer and can stop >> looking. The client-side/user behaviour changes depending on the > > You can't stop because you would trust the statement from the keyserver. > Which is not what keyservers are made for. Thus even after you get a > revoked status from a keyserver you need to fetch the public key and > verify the revocation certificate. This is exactly my proposal. If the keyserver were able to return the key packet(s) and the relevant signature(s), then a client could verify the revocation sig immediately, and stop processing. A UserID is not necessary if the lookup was made for a fingerprint. >> a self-sig, it makes sense to allow self-sigs and their primaries to >> be distributed regardless of whether they are ?usable? in a >> client-side sense. > > You can do between the keyservers whatever you want. If you want to > validate the keyblock you need the user id and need to verify the > self-sig before you allow fetching that keyblock (maybe restricted to > the requested user id) One can validate a direct signature over a primary key without processing any UserIDs. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From bernhard at intevation.de Fri Jan 13 16:24:48 2023 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 13 Jan 2023 16:24:48 +0100 Subject: python "gpg" on pypi (Re: gpgme python bindings) In-Reply-To: <87zgamn2dk.fsf@europ.lan> References: <202301131106.58055.bernhard@intevation.de> <87zgamn2dk.fsf@europ.lan> Message-ID: <202301131624.56789.bernhard@intevation.de> Hi Justus, Am Freitag 13 Januar 2023 11:40:55 schrieb Justus Winter: > > https://pypi.org/project/gpg/ > > thanks, please transfer it to my pypi account: > I invited you as the owner. Feel free to remove me to complete the > handover. thanks! Done! Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu Jan 26 09:42:24 2023 From: wk at gnupg.org (Werner Koch) Date: Thu, 26 Jan 2023 09:42:24 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: <87r0x1gk7n.fsf@josefsson.org> (Simon Josefsson via Gnupg-devel's message of "Thu, 15 Dec 2022 09:11:24 +0100") References: <202212091000.16718.bernhard@intevation.de> <202212121148.03783.bernhard@intevation.de> <202212130944.15657.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> <87r0x1gk7n.fsf@josefsson.org> Message-ID: <878rhp3cwf.fsf@wheatstone.g10code.de> Hi Simon, >>> 1) Use WDK to map ONE email address to ONE public key to use for >>> email. >>> >>> 2) Use WDK to find ALL public keys for an email address. > I'm not familiar with WKS so I don't have an opinion -- it looks like > WKS was tailored towards the use-case 1) above, and I'm not sure a Right. I think that it is in general not a good idea to have several keys for the same mail address. How should a user know which key use for a given mail address to use. A use case would be to help migrating to a new public key algorithm, like we did with ed25519 in the past. In that case having two entirely separate keys for the same mail address makes sense. > WKS-like protocol is useful for the use-case of 2) at all. It is not > important for me at least: I just want to self-publish all trusted keys > for my email address and have a protocol to specify that people should Actually you can do this, but we don't have the tooling to upload such a ket without manual intervention. Here is a test case: I created an rsa1024 test key for dewey at test.gnupg.org, exported it in binary format and then added it to the already existing key for dewey at test.gnupg.org on the server: $ gpg-wks-client --print-wkd-hash dewey at test.gnupg.org 1g8totoxbt4zf6na1sukczp5fiewr1oe dewey at test.gnupg.org $ cat newtestkey.gpg >> \ /var/www/all/test.gnupg.org/htdocs/.well-known/openpgpkey/hu/1g8totoxbt4zf6na1sukczp5fiewr1oe Then on the client you can test this: $ gpg --locate-external-key -v dewey at test.gnupg.org gpg: connection to the dirmngr established gpg: pub ed25519/D19D22B06EE78668 2016-06-28 dewey at test.gnupg.org gpg: key D19D22B06EE78668: public key "dewey at test.gnupg.org" imported gpg: pub rsa1024/5CEC38D7F995FB4E 2023-01-26 dewey at test.gnupg.org gpg: key 5CEC38D7F995FB4E: public key "dewey at test.gnupg.org" imported gpg: Total number processed: 2 gpg: imported: 2 gpg: auto-key-locate found fingerprint 64944BC035493D929EF2A2B9D[..] gpg: automatically retrieved 'dewey at test.gnupg.org' via WKD pub ed25519 2016-06-28 [SC] [expires: 2030-01-01] 64944BC035493D929EF2A2B9D19D22B06EE78668 uid [ unknown] dewey at test.gnupg.org sub cv25519 2016-06-28 [E] [expired: 2018-11-26] sub cv25519 2018-08-28 [E] [expired: 2021-08-27] $ gpg -k dewey at test.gnupg.org pub ed25519 2016-06-28 [SC] [expires: 2030-01-01] 64944BC035493D929EF2A2B9D19D22B06EE78668 uid [ unknown] dewey at test.gnupg.org pub rsa1024 2023-01-26 [SC] [expires: 2025-01-25] 382C8F84FB9FE0F89E61B3045CEC38D7F995FB4E uid [ unknown] dewey at test.gnupg.org sub rsa1024 2023-01-26 [E] Both keys have been retrieved (filtered to have only the requested user id) and the best matching key has been listed. With an implementation w/o support for ed25519 the RSA key would have been listed. So far with the theory and here comes the bug: There is no valid encryption subkey and thus --locate-external-key should indeed list the rsa key. See https://dev.gnupg.org/T6358 . Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bernhard at intevation.de Thu Jan 26 11:04:32 2023 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 26 Jan 2023 11:04:32 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: <878rhp3cwf.fsf@wheatstone.g10code.de> References: <202212091000.16718.bernhard@intevation.de> <87r0x1gk7n.fsf@josefsson.org> <878rhp3cwf.fsf@wheatstone.g10code.de> Message-ID: <202301261104.39194.bernhard@intevation.de> Hi Werner, Am Donnerstag 26 Januar 2023 09:42:24 schrieb Werner Koch via Gnupg-devel: > > I just want to self-publish all trusted keys > > for my email address and have a protocol to specify that people should > > Actually you can do this, but we don't have the tooling to upload such a > ket without manual intervention. Here is a test case: > Then on the client you can test this: > Both keys have been retrieved for my understanding, this technical test case tests something that is outside the specification of https://datatracker.ietf.org/doc/html/draft-koch-openpgp-webkey-service-15#name-key-discovery ? (the current specification, as cited in the start of the discussion) > (filtered to have only the requested user > id) and the best matching key has been listed. With an implementation > w/o support for ed25519 the RSA key would have been listed. > > So far with the theory and here comes the bug: There is no valid > encryption subkey and thus --locate-external-key should indeed list the rsa > key. See https://dev.gnupg.org/T6358 . Looks like an example how distributing two active keys via WKD make it more complicated to implement use case 1). And a for a rollover, just the new public key could be distributed, so I'd say multiple pubkeys are not necessary for the rollover. Regards Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From simon at josefsson.org Thu Jan 26 11:23:49 2023 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 26 Jan 2023 11:23:49 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: <878rhp3cwf.fsf@wheatstone.g10code.de> (Werner Koch via Gnupg-devel's message of "Thu, 26 Jan 2023 09:42:24 +0100") References: <202212091000.16718.bernhard@intevation.de> <202212121148.03783.bernhard@intevation.de> <202212130944.15657.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> <87r0x1gk7n.fsf@josefsson.org> <878rhp3cwf.fsf@wheatstone.g10code.de> Message-ID: <87tu0d7fwq.fsf@josefsson.org> Werner Koch via Gnupg-devel writes: > Hi Simon, > >>>> 1) Use WDK to map ONE email address to ONE public key to use for >>>> email. >>>> >>>> 2) Use WDK to find ALL public keys for an email address. > >> I'm not familiar with WKS so I don't have an opinion -- it looks like >> WKS was tailored towards the use-case 1) above, and I'm not sure a > > Right. I think that it is in general not a good idea to have several > keys for the same mail address. How should a user know which key use > for a given mail address to use. A use case would be to help migrating > to a new public key algorithm, like we did with ed25519 in the past. In > that case having two entirely separate keys for the same mail address > makes sense. I think we can separate the use-cases even further like this: 1) Use WKD to map ONE email address to ONE public key to use for sending email to that address (i.e., encrypt). 2) Use WKD to find ALL public keys for an email address for verifying emails from that address (i.e., verify). These are distinct use-cases and for 1) it is harmful to have more than one key per e-mail address (which one to use?) but for 2) it is important to be able to store more than one key per e-mail address. I don't think we should recommend against doing key rollovers -- forever keys are bad. I don't think changing e-mail address when you change key is realistic either. So we have to live with key rollovers for the same e-mail address. While we could recommend doing hard-stop key rollovers where you revoke the earlier key at the same time you migrate to the new key, I don't think that is a common habit nor am I sure this is even a good idea. Does anyone think we should recommend that? It does have some advantages (clear one-to-one mapping between e-mail address and key), but comes with a high price (flag day). During a key rollover, I think it makes sense to have both the old and new key be valid, for verifying signatures, for some time. Personally, the reason I still have one valid RSA key and one valid Ed25519 key is that I haven't been able to get my Ed25519 into some environments, with reasons ranging from use of really old GnuPG (savannah, now fixed) to key signature requirements (debian), and simple inertia and time to replace trust settings in various systems. When I migrate to some post-quantum-safe algorithm, I expect to do a multi-year key rollover where my current Ed25519 key is still valid as well. It would be good if the WKD supported both use-cases 1) and 2) or that we come up with some other solution for use-case 2) if WKD is intended purely for use-case 1). In fact, I would be happy to migrate to a post-quantum-safe algorithm early if I could keep having my Ed25519 fall-back available in case there is a problem with the new post-quantum-safe algorithm. If it doesn't work well to have two parallel keys, I would delay switching to the new algorithm until use of it has become stable. I didn't switch to Ed25519 until 2019 for this reason, but it would be nice to be able to experiment with new algorithms more easily. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 255 bytes Desc: not available URL: From simon at josefsson.org Fri Jan 27 09:13:15 2023 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 27 Jan 2023 09:13:15 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: <87tu0d7fwq.fsf@josefsson.org> (Simon Josefsson via Gnupg-devel's message of "Thu, 26 Jan 2023 11:23:49 +0100") References: <202212091000.16718.bernhard@intevation.de> <202212121148.03783.bernhard@intevation.de> <202212130944.15657.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> <87r0x1gk7n.fsf@josefsson.org> <878rhp3cwf.fsf@wheatstone.g10code.de> <87tu0d7fwq.fsf@josefsson.org> Message-ID: <87cz7075us.fsf@josefsson.org> Simon Josefsson via Gnupg-devel writes: > I think we can separate the use-cases even further like this: > > 1) Use WKD to map ONE email address to ONE public key to use for > sending email to that address (i.e., encrypt). > > 2) Use WKD to find ALL public keys for an email address for verifying > emails from that address (i.e., verify). Let me modify that again, since my main use-cases really isn't e-mail (where you have the Key ID to search for) but verifying signatures on free software release tarballs, and using the e-mail adress of the publisher as the search field, hence I see these use-cases: 1) Use WKD to map ONE email address to ONE public key to use for sending email to that address (i.e., encrypt). 2) Use WKD to find ALL public keys for an email address for verifying signatures signed by keys owned by that address (i.e., verify). To expand even more to get feedback and suggestions on improving this: my goal is to come up with the best/safest text to write in a software release on how to verify OpenPGP signatures for the tarball. Currently I'm using the text below, which recommends 'gpg --locate-external-key' as the preferred mechanism and normally that uses WKD and will try to refresh the key from the server (otherwise people get old cached keys from local key storage). I like the simplicity and UX of this approach. This mechanism must be able to retrieve all currently valid keys for a particular e-mail address, otherwise people will complain not finding the right key. Second to using the e-mail, maybe retrieving by key id should be preferred because that is more stable. However there aren't really any stable working keyid-based OpenPGP key search engines left, are there? So this method is not reliable. There also were issues with it using only the first 64-bit of the key id, and I'm not sure this is fixed (hence the text below uses only that to not give false sense of security). The --recv-keys parameter behaves different for different GnuPG versions wrt default keyserver and has been somewhat unreliable in the last 5 years or so. It also requires additional configuration, most GnuPG installation doesn't come with a default keyserver URL. Downloading the key from a given https URL is safe. This is likely to be the most reliable method right now, but it feels unsatisfying to me. /Simon Here are the SHA1 and SHA256 checksums: 52908bfc6e0bb6bbb54de4414e92c29fd13906d7 inetutils-2.4.tar.gz dq7gwvCVRyhgDVEJVdaXpOwpMkMY54SEjbYG7jwJ42U inetutils-2.4.tar.gz df64dd4ea0e752a839dd51dd8a6a001c9c7d1e96 inetutils-2.4.tar.xz F4nWsbGlff4qere1M+6fXf2cv1tZuxuzwmEu0I0PaLI inetutils-2.4.tar.xz The SHA256 checksum is base64 encoded, instead of the hexadecimal encoding that most checksum tools default to. Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify inetutils-2.4.tar.gz.sig The signature should match the fingerprint of the following key: pub ed25519 2019-03-20 [SC] B1D2 BD13 75BE CB78 4CF4 F8C4 D73C F638 C53C 06BE uid Simon Josefsson If that command fails because you don't have the required public key, or that public key has expired, try the following commands to retrieve or refresh it, and then rerun the 'gpg --verify' command. gpg --locate-external-key simon at josefsson.org gpg --recv-keys 51722B08FE4745A2 wget -q -O- 'https://savannah.gnu.org/project/release-gpgkeys.php?group=inetutils&download=1' | gpg --import - As a last resort to find the key, you can try the official GNU keyring: wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg gpg --keyring gnu-keyring.gpg --verify inetutils-2.4.tar.gz.sig -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 255 bytes Desc: not available URL: From wk at gnupg.org Fri Jan 27 10:23:48 2023 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Jan 2023 10:23:48 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: <87cz7075us.fsf@josefsson.org> (Simon Josefsson via Gnupg-devel's message of "Fri, 27 Jan 2023 09:13:15 +0100") References: <202212091000.16718.bernhard@intevation.de> <202212121148.03783.bernhard@intevation.de> <202212130944.15657.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> <87r0x1gk7n.fsf@josefsson.org> <878rhp3cwf.fsf@wheatstone.g10code.de> <87tu0d7fwq.fsf@josefsson.org> <87cz7075us.fsf@josefsson.org> Message-ID: <87v8ks1gbf.fsf@wheatstone.g10code.de> Hi! Just a quick note: > Currently I'm using the text below, which recommends 'gpg > --locate-external-key' as the preferred mechanism and normally that uses > WKD and will try to refresh the key from the server (otherwise people > get old cached keys from local key storage). I like the simplicity and You may also include the key in the signature: gpg -sabvu commit --include-key motd.asc and then advise to use gpg --verify --auto-key-import -v motd.asc /etc/motd However, auto-key-import will only import the key if is not yet there. It won't update a key. These options are available since gnupg 2.2.20 FWIW, I recently had to build gcc and I have found no way to validate the key of Jakub. No key signatures available and I have found nowhere a listing of fingerprints - even not on the RedHat site which only lists product keys. If even I am not able to figure this out, how shall we bootstrap our software ecosystem in a somewhat secure way? How does Debian verifies that a gcc update is pristine - private exchange of keys with Jakub? --locate-external-key does not help either because it relies on the very same mechanism we anyway use to download the source (i.e. TLS). Salam-Shalom, Werner p.s. gcc is just one of a myriad of examples; sorry for picking its author -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wiktor at metacode.biz Fri Jan 27 09:40:02 2023 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Fri, 27 Jan 2023 09:40:02 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: <87cz7075us.fsf@josefsson.org> References: <202212091000.16718.bernhard@intevation.de> <202212121148.03783.bernhard@intevation.de> <202212130944.15657.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> <87r0x1gk7n.fsf@josefsson.org> <878rhp3cwf.fsf@wheatstone.g10code.de> <87tu0d7fwq.fsf@josefsson.org> <87cz7075us.fsf@josefsson.org> Message-ID: <9bfe12f1-6b4b-58cc-fc89-298172895b64@metacode.biz> Hi Simon, On 27.01.2023 09:13, Simon Josefsson via Gnupg-devel wrote: > Currently I'm using the text below, which recommends 'gpg > --locate-external-key' as the preferred mechanism and normally that uses > WKD and will try to refresh the key from the server (otherwise people > get old cached keys from local key storage). I like the simplicity and > UX of this approach. This mechanism must be able to retrieve all > currently valid keys for a particular e-mail address, otherwise people > will complain not finding the right key. I don't know if you know but if the signature contains Signer's User ID packet (added with --sender email at example.com option during gpg --sign) then when verifying you can use --auto-key-retrieve and it will use WKD to fetch the key (of course the Signer User ID packet is needed to supply the e-mail at verification time). This makes verification one command instead of two (first get the key then verify). > Second to using the e-mail, maybe retrieving by key id should be > preferred because that is more stable. However there aren't really any > stable working keyid-based OpenPGP key search engines left, are there? > So this method is not reliable. There also were issues with it using > only the first 64-bit of the key id, and I'm not sure this is fixed > (hence the text below uses only that to not give false sense of > security). The --recv-keys parameter behaves different for different > GnuPG versions wrt default keyserver and has been somewhat unreliable in > the last 5 years or so. It also requires additional configuration, most > GnuPG installation doesn't come with a default keyserver URL. There is keys.openpgp.org and it allows fetching keys via subkey fingerprints. Still, since it's technically possible to put multiple keys on WKD IMO the spec should say what to do when there are multiple keys there (e.g. prefer the most recent key, and specify what does it mean for key to be recent). The problem, as described earlier, is only for encryption subkeys and I wouldn't mind if the e-mail client just used all valid available keys (for key rotation) but I think the notion of "one recipient, one key" is ingrained so hard that it's not going to change. Kind regards, Wiktor PS. Sample clearsigned file with the Signer's User ID packet (remove #, you can pipe it to gpg --list-packets): #-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 santa #-----BEGIN PGP SIGNATURE----- iIoEARYIADIWIQTn4rhKNkV76j9DaS3mi+OzEvoz/AUCY9OMZRQcd2lrdG9yQG1l dGFjb2RlLmJpegAKCRDmi+OzEvoz/K6bAQDmxeSoILv1D9wFEPYmEYFiYjKiO5M1 oWh/sJz8o/kjygD9EpihKlBRhKcH/hf1tsAwqE7iomDM98CsSJ6kxTHnFQ0= =RQba #-----END PGP SIGNATURE----- From fweimer at redhat.com Fri Jan 27 13:11:08 2023 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 27 Jan 2023 13:11:08 +0100 Subject: C99 compatibility fixes for gnupg 1 Message-ID: <87y1poxjmr.fsf@oldenburg.str.redhat.com> Is gnupg 1 still being maintained? The configure script needs a few changes to avoid behavioral changes once compilers no longer support implicit function declarations by default. Related to: Thanks, Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg1-configure-c99.patch Type: text/x-patch Size: 1294 bytes Desc: not available URL: From jwilk at jwilk.net Sat Jan 28 23:50:12 2023 From: jwilk at jwilk.net (Jakub Wilk) Date: Sat, 28 Jan 2023 23:50:12 +0100 Subject: WKD: returns only one pubkey (and why) In-Reply-To: <87cz7075us.fsf@josefsson.org> References: <202212091000.16718.bernhard@intevation.de> <202212121148.03783.bernhard@intevation.de> <202212130944.15657.bernhard@intevation.de> <87wn6vbiq6.fsf@josefsson.org> <87r0x1gk7n.fsf@josefsson.org> <878rhp3cwf.fsf@wheatstone.g10code.de> <87tu0d7fwq.fsf@josefsson.org> <87cz7075us.fsf@josefsson.org> Message-ID: <20230128225012.v74tzxb73yfjpjvb@jwilk.net> * Simon Josefsson via Gnupg-devel , 2023-01-27 09:13: > gpg --recv-keys 51722B08FE4745A2 Beware that this may import unrelated keys to your keyring: https://bugs.debian.org/909755 -- Jakub Wilk From wk at gnupg.org Mon Jan 30 16:28:38 2023 From: wk at gnupg.org (Werner Koch) Date: Mon, 30 Jan 2023 16:28:38 +0100 Subject: C99 compatibility fixes for gnupg 1 In-Reply-To: <87y1poxjmr.fsf@oldenburg.str.redhat.com> (Florian Weimer via Gnupg-devel's message of "Fri, 27 Jan 2023 13:11:08 +0100") References: <87y1poxjmr.fsf@oldenburg.str.redhat.com> Message-ID: <87mt6011p5.fsf@wheatstone.g10code.de> On Fri, 27 Jan 2023 13:11, Florian Weimer said: > Is gnupg 1 still being maintained? The configure script needs a few Yes, because it is required to decrypt old mails. > changes to avoid behavioral changes once compilers no longer support > implicit function declarations by default. I know a couple of folks who won't cheer a move t such modern compilers. After all it makes a lot of autoconf tests superfluous. But as along as it is only about prototypes we can easily apply this patch. GnuPG has always demanded C89. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Mon Jan 30 16:47:41 2023 From: wk at gnupg.org (Werner Koch) Date: Mon, 30 Jan 2023 16:47:41 +0100 Subject: C99 compatibility fixes for gnupg 1 In-Reply-To: <87mt6011p5.fsf@wheatstone.g10code.de> (Werner Koch via Gnupg-devel's message of "Mon, 30 Jan 2023 16:28:38 +0100") References: <87y1poxjmr.fsf@oldenburg.str.redhat.com> <87mt6011p5.fsf@wheatstone.g10code.de> Message-ID: <87ilgo10te.fsf@wheatstone.g10code.de> Hi! I applied the patch. However, changing main to void without having a return statement is also prone to errors or warnings, right? Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From fweimer at redhat.com Mon Jan 30 17:18:27 2023 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 30 Jan 2023 17:18:27 +0100 Subject: C99 compatibility fixes for gnupg 1 In-Reply-To: <87ilgo10te.fsf@wheatstone.g10code.de> (Werner Koch's message of "Mon, 30 Jan 2023 16:47:41 +0100") References: <87y1poxjmr.fsf@oldenburg.str.redhat.com> <87mt6011p5.fsf@wheatstone.g10code.de> <87ilgo10te.fsf@wheatstone.g10code.de> Message-ID: <87bkmgxagc.fsf@oldenburg.str.redhat.com> * Werner Koch: > I applied the patch. However, changing main to void without having a > return statement is also prone to errors or warnings, right? I think reaching the } of main has always been specified to return 0 (except for free-standing environments where main isn't special, but this doesn't apply here). And the return type of main does not change whether it is declared explicitly or not. Thanks, Florian From jwilk at jwilk.net Mon Jan 30 17:45:52 2023 From: jwilk at jwilk.net (Jakub Wilk) Date: Mon, 30 Jan 2023 17:45:52 +0100 Subject: C99 compatibility fixes for gnupg 1 In-Reply-To: <87bkmgxagc.fsf@oldenburg.str.redhat.com> References: <87y1poxjmr.fsf@oldenburg.str.redhat.com> <87mt6011p5.fsf@wheatstone.g10code.de> <87ilgo10te.fsf@wheatstone.g10code.de> <87bkmgxagc.fsf@oldenburg.str.redhat.com> Message-ID: <20230130164552.zwf5mdurxumgjvs5@jwilk.net> * Florian Weimer, 2023-01-30 17:18: >* Werner Koch: > >>I applied the patch. However, changing main to void without having a >>return statement is also prone to errors or warnings, right? > >I think reaching the } of main has always been specified to return 0 Only since C99. It wasn't like that in C89: "Reaching the } that terminates a function is equivalent to executing a return statement without an expression." "If the main function executes a return that specifies no value, the termination status returned to the host environment is undefined." -- Jakub Wilk