From konstantin at linuxfoundation.org Sun Sep 1 01:21:55 2024 From: konstantin at linuxfoundation.org (Konstantin Ryabitsev) Date: Sat, 31 Aug 2024 19:21:55 -0400 Subject: Signing (and Encrypting) Mails with gpg like DKIM In-Reply-To: References: Message-ID: <20240831-practical-gray-mackerel-ed137d@lemur> On Sat, Aug 31, 2024 at 06:29:17PM GMT, T. S. wrote: The same thought did occur to me, which is why the patch attestation process used by many in the kernel development community uses DKIM-like signatures: https://github.com/mricon/patatt However, this is limited to signing -- I don't believe this mechanism can be extended to message encryption. -K From mm at dorfdsl.de Sun Sep 1 06:47:25 2024 From: mm at dorfdsl.de (Marco Moock) Date: Sun, 1 Sep 2024 06:47:25 +0200 Subject: Signing (and Encrypting) Mails with gpg like DKIM In-Reply-To: References: Message-ID: <20240901064725.4659b93c@zbook> Am Sat, 31 Aug 2024 18:29:17 +0200 schrieb "T. S." : > Is somethings similar available for GPG/PGP? I don't know about such an implementation, but if you want to create one, everybody can publish RFCs at IETF, so feel free to create such a technology. If you want something unofficial, use the X- headers. From stuartl at longlandclan.id.au Sun Sep 1 06:46:58 2024 From: stuartl at longlandclan.id.au (Stuart Longland) Date: Sun, 1 Sep 2024 14:46:58 +1000 Subject: Signing (and Encrypting) Mails with gpg like DKIM In-Reply-To: References: Message-ID: <6df9205d-045c-411e-be2d-e6532fd6cf49@longlandclan.id.au> On 1/9/24 02:29, T. S. wrote: > after looking into DKIM details, I started searching, why the same procedure > cannot be used for gpg? DKIM signs emails that are sent server-to-server. It does not perform encryption of the email (that is done by the sending server sending the `STARTTLS` SMTP command and the pair negotiating a cipher). Crucially, DKIM does not: 1. end-to-end digitally sign the email, the email is not signed until it is transmitted by your mail server, malicious code (or users) on the server can still manipulate it before sending. 2. perform any encryption, DKIM is about verifying sender *identity* (the I). "Sender" being the server, not you the user. Emails may be passed between servers via TLS, but the messages themselves will be stored clear-text at each hop. For end-to-end encryption/signing, you need to apply this before your outgoing SMTP server receives it? that's where S/MIME and OpenPGP come in. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. From mm at dorfdsl.de Sun Sep 1 07:42:25 2024 From: mm at dorfdsl.de (Marco Moock) Date: Sun, 1 Sep 2024 07:42:25 +0200 Subject: Signing (and Encrypting) Mails with gpg like DKIM In-Reply-To: <6df9205d-045c-411e-be2d-e6532fd6cf49@longlandclan.id.au> References: <6df9205d-045c-411e-be2d-e6532fd6cf49@longlandclan.id.au> Message-ID: <20240901074225.2cc2e28f@dorfdsl.de> Am 01.09.2024 um 14:46:58 Uhr schrieb Stuart Longland via Gnupg-users: > 1. end-to-end digitally sign the email, the email is not signed until > it is transmitted by your mail server, malicious code (or users) on > the server can still manipulate it before sending. It would be possible to sign DKIM at the MUA, but this is not common. With the selectors, each user could have its own selector and private key. -- kind regards Marco From stuartl at longlandclan.id.au Sun Sep 1 07:51:57 2024 From: stuartl at longlandclan.id.au (Stuart Longland) Date: Sun, 1 Sep 2024 15:51:57 +1000 Subject: Signing (and Encrypting) Mails with gpg like DKIM In-Reply-To: <20240901074225.2cc2e28f@dorfdsl.de> References: <6df9205d-045c-411e-be2d-e6532fd6cf49@longlandclan.id.au> <20240901074225.2cc2e28f@dorfdsl.de> Message-ID: <41e19c78-20ad-47df-b607-fc63bf7b3718@longlandclan.id.au> On 1/9/24 15:42, Marco Moock wrote: > It would be possible to sign DKIM at the MUA, but this is not common. > > With the selectors, each user could have its own selector and private > key. Given the public key is published in DNS records, could you imagine the hot mess that'd create for domains with lots of users? Either lots of DNS records, or lots of users sharing the same private key. Neither is a good look. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. From mm at dorfdsl.de Sun Sep 1 07:55:26 2024 From: mm at dorfdsl.de (Marco Moock) Date: Sun, 1 Sep 2024 07:55:26 +0200 Subject: Signing (and Encrypting) Mails with gpg like DKIM In-Reply-To: <41e19c78-20ad-47df-b607-fc63bf7b3718@longlandclan.id.au> References: <6df9205d-045c-411e-be2d-e6532fd6cf49@longlandclan.id.au> <20240901074225.2cc2e28f@dorfdsl.de> <41e19c78-20ad-47df-b607-fc63bf7b3718@longlandclan.id.au> Message-ID: <20240901075526.13a1add7@dorfdsl.de> Am 01.09.2024 um 15:51:57 Uhr schrieb Stuart Longland: > Given the public key is published in DNS records, could you imagine > the hot mess that'd create for domains with lots of users? Either > lots of DNS records, or lots of users sharing the same private key. Is there a limit for DNS records? I don't see a problem here, especially if they are provisioned in an automatic way. -- Gru? Marco From stuartl at longlandclan.id.au Sun Sep 1 08:17:59 2024 From: stuartl at longlandclan.id.au (Stuart Longland) Date: Sun, 1 Sep 2024 16:17:59 +1000 Subject: Signing (and Encrypting) Mails with gpg like DKIM In-Reply-To: <20240901075526.13a1add7@dorfdsl.de> References: <6df9205d-045c-411e-be2d-e6532fd6cf49@longlandclan.id.au> <20240901074225.2cc2e28f@dorfdsl.de> <41e19c78-20ad-47df-b607-fc63bf7b3718@longlandclan.id.au> <20240901075526.13a1add7@dorfdsl.de> Message-ID: <1da1b417-04c7-4d5b-bd12-b90b730c3573@longlandclan.id.au> [Re-send with correct from: address? apologies to the moderators for the noise] On 1/9/24 15:55, Marco Moock via Gnupg-users wrote: > Is there a limit for DNS records? In theory, probably not. In practice, most definitely, especially if you don't "own" the DNS server. > I don't see a problem here, especially if they are provisioned in an > automatic way. Again, not everyone has that luxury. There exist many web hosting providers whose only means of updating DNS is a crummy web application. CheaperDomains for example does this, and allows just 4 TXT records. https://community.cloudflare.com/t/dns-record-limit/169997 suggests a limit of 1000 records for CloudFlare for example (and its import instructions limit the zone file to 256KiB). -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. From hfollmann at itcfollmann.com Sun Sep 1 10:07:19 2024 From: hfollmann at itcfollmann.com (Henning Follmann) Date: Sun, 1 Sep 2024 04:07:19 -0400 Subject: Signing (and Encrypting) Mails with gpg like DKIM In-Reply-To: <1da1b417-04c7-4d5b-bd12-b90b730c3573@longlandclan.id.au> References: <1da1b417-04c7-4d5b-bd12-b90b730c3573@longlandclan.id.au> Message-ID: <271E02CF-5198-4523-A6BA-5A4639B10C3F@itcfollmann.com> > On Sep 1, 2024, at 02:18, Stuart Longland via Gnupg-users wrote: > > ?[Re-send with correct from: address? apologies to the moderators for the noise] > >> On 1/9/24 15:55, Marco Moock via Gnupg-users wrote: >> Is there a limit for DNS records? > > In theory, probably not. In practice, most definitely, especially if you don't "own" the DNS server. > >> I don't see a problem here, especially if they are provisioned in an >> automatic way. > > Again, not everyone has that luxury. There exist many web hosting providers whose only means of updating DNS is a crummy web application. CheaperDomains for example does this, and allows just 4 TXT records. > > https://community.cloudflare.com/t/dns-record-limit/169997 suggests a limit of 1000 records for CloudFlare for example (and its import instructions limit the zone file to 256KiB). > -- > And on top of that you need the unprotected private key for each user. That is probably a bad idea. -H From andrewg at andrewg.com Sun Sep 1 12:24:40 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 1 Sep 2024 11:24:40 +0100 Subject: Signing (and Encrypting) Mails with gpg like DKIM In-Reply-To: References: Message-ID: On 31 Aug 2024, at 23:35, T. S. wrote: > > Hello, > > after looking into DKIM details, I started searching, why the same procedure cannot be used for gpg? > With gpg a lot of people from get confused, when they receive signed mails either because of the -----BEGIN PGP SIGNED MESSAGE----- strings, or because the unknown attachments in MIME message. > > When now looking to DKIM, this looks much more advanced. There is a Header in the mail, containing the signature all details to the signature and information about header items included in the signature: > Is somethings similar available for GPG/PGP? > > Currently I found nothing, but I expect that this could help for much better acceptance for signed mails. Receivers, who don't know anything about gpg getting not confused, as the Header is totally invisible. > With such an implementation I would start again sending all my mails automatically signed, as I have not longer to answer questions about my weird looking mails. You?re essentially talking about defining a new cleartext signing mechanism, so that people using PGP-unaware mail clients can remain blissfully unaware, while also allowing for a graceful upgrade to signed mail for those who can. Unfortunately, history has taught us that any cleartext sent over email *will* be mangled, and this will break the signature. MTAs are in general really bad at preserving the content of email messages. The only reliable way we know of to protect your signed plaintext is to encode it in something more robust, such as base64. Even then, if it is encoded as a base64 MIME part, MTAs have been known to mangle the MIME headers, which breaks the signature. And if you don?t sign over the MIME headers, your email is dangerously malleable (see efail). So for the foreseeable future at least, it seems you can have trustworthy signed emails or you can have backwards-compatible cleartext signing, but not both. A -------------- next part -------------- An HTML attachment was scrubbed... URL: From mm at dorfdsl.de Mon Sep 2 06:49:37 2024 From: mm at dorfdsl.de (Marco Moock) Date: Mon, 2 Sep 2024 06:49:37 +0200 Subject: Signing (and Encrypting) Mails with gpg like DKIM In-Reply-To: References: Message-ID: <20240902064937.43bfc02b@zbook> Am Sat, 31 Aug 2024 18:29:17 +0200 schrieb "T. S." : > If someone could provide me with information, if such header > implementations are already somewhere discussed, I would be glad. I've now seen an implementation for signing control messages for Usenet: ftp://ftp.isc.org/usenet/control/hispagatos/hispagatos.hacking.exploits.gz MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="signcontrol" Content-Transfer-Encoding: 8bit X-PGP-Sig: GnuPG_v2 Subject,Control,Message-ID,Date,Injection-Date,From iQHIBAABCAAyFiEE/G5Aphyycx8BqrxkqP6aHcFxsyAFAmbRFmYUHG5ld3NAaGlz cGFnYXRvcy5vcmcACgkQqP6aHcFxsyDlYAwAuEZAjR7V/k9e73rkONzMAS24HWeQ 6l5hraveKcUQKpvWu3BxQ5iVn2rxEixbHqsUi7CTXHThYGc85s0veqCTROE8AVC2 11fSd0sQVz/1Gq2/Us/Dk3E6yttGEnJhBGsftQ/+BnTyhZ7Nr2iPUtBgZ8/B21B6 Se9e0DJUozyFO/dLjSrd73aoMNW0p3Ay+jqvA0zO01lhrSkVRoqRggyIbZYRSiWX UkajMq5LglfVbWDhnT59p6D4tJBtVCYfDxBVMNN21ERFPy19pVhxgjjBgqf5OKZi Xu0dfruQcLDGhVuVH71gDc0TWC5gYzNKM46hZndPWrpx+IyAWJ/RwK2fsBNzNOpF Fc7RGKbKx7xdMX8ICHcSKxJzjBAYWw032ybWejodTl6C2ytqnDBbvrCMueZpoN1I NtWdPDflgapCtSL66I6JEV/HeaPVE8ZX5W2TRLPP67uTzfrmU03y2AW0VKQC77gb 0F5Uxka7ThKOv64WgQcukidfaWBmeA3nGw49 =tU9d From wk at gnupg.org Mon Sep 2 09:00:53 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 02 Sep 2024 09:00:53 +0200 Subject: Signing (and Encrypting) Mails with gpg like DKIM In-Reply-To: (T. S.'s message of "Sat, 31 Aug 2024 18:29:17 +0200") References: Message-ID: <87wmju7d5m.fsf@jacob.g10code.de> On Sat, 31 Aug 2024 18:29, T. S. said: > either because of the -----BEGIN PGP SIGNED MESSAGE----- strings, or because > the unknown attachments in MIME message. Don't use those legacy inline PGP encryption. Use PGP/MIME, a 28 year old standard (RFC-2015). You should give that unnamed attachment a name, for example Content-Type: application/pgp-signature; name="openpgp-digital-signature.asc" which clearly shows what kind of attachment this is. > When now looking to DKIM, this looks much more advanced. There is a Header in > the mail, containing the signature all details to the signature and You may want to go back to the year ~2000 when DKIM was first presented at the IETF in Paris. It was then a quick hack from the sendmail authors and it took only a few hours until an attack on this was found. DKIM also broke with the long standing rule of being able to work in a pipeline (iirc, this is called an online algo these days). Instead of doing all that DKIM stuff it would have been easier to directly use S/MIME or PGP/MIME and include copies of important headers in a signed attachment. But well, attachments are ugly for some people. 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 jb-gnumlists at wisemo.com Wed Sep 4 14:33:28 2024 From: jb-gnumlists at wisemo.com (Jakob Bohm) Date: Wed, 4 Sep 2024 14:33:28 +0200 Subject: Signing (and Encrypting) Mails with gpg like DKIM In-Reply-To: <271E02CF-5198-4523-A6BA-5A4639B10C3F@itcfollmann.com> References: <1da1b417-04c7-4d5b-bd12-b90b730c3573@longlandclan.id.au> <271E02CF-5198-4523-A6BA-5A4639B10C3F@itcfollmann.com> Message-ID: <8601fff5-27bb-8e3f-d1ef-0f249d1de5db@wisemo.com> On 2024-09-01 10:07, Henning Follmann wrote: > >> On Sep 1, 2024, at 02:18, Stuart Longland via Gnupg-users wrote: >> >> ?[Re-send with correct from: address? apologies to the moderators for the noise] >> >>> On 1/9/24 15:55, Marco Moock via Gnupg-users wrote: >>> Is there a limit for DNS records? >> In theory, probably not. In practice, most definitely, especially if you don't "own" the DNS server. >> >>> I don't see a problem here, especially if they are provisioned in an >>> automatic way. >> Again, not everyone has that luxury. There exist many web hosting providers whose only means of updating DNS is a crummy web application. CheaperDomains for example does this, and allows just 4 TXT records. >> >> https://community.cloudflare.com/t/dns-record-limit/169997 suggests a limit of 1000 records for CloudFlare for example (and its import instructions limit the zone file to 256KiB). >> -- >> > And on top of that you need the unprotected private key for each user. > That is probably a bad idea. Not anymore than for any other signing.? In particular, only automated server-side signing would need (somewhat) unprotected key access. Signing in the MUA asdiscussed above could protect the key in a GPG card, but is entirely hypotheticaland antithetical to the idea of DKIM. 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 jb-gnumlists at wisemo.com Wed Sep 4 14:41:38 2024 From: jb-gnumlists at wisemo.com (Jakob Bohm) Date: Wed, 4 Sep 2024 14:41:38 +0200 Subject: Signing (and Encrypting) Mails with gpg like DKIM In-Reply-To: <87wmju7d5m.fsf@jacob.g10code.de> References: <87wmju7d5m.fsf@jacob.g10code.de> Message-ID: On 2024-09-02 09:00, Werner Koch via Gnupg-users wrote: > On Sat, 31 Aug 2024 18:29, T. S. said: > >> either because of the -----BEGIN PGP SIGNED MESSAGE----- strings, or because >> the unknown attachments in MIME message. > Don't use those legacy inline PGP encryption. Use PGP/MIME, a 28 year > old standard (RFC-2015). You should give that unnamed attachment a > name, for example > > Content-Type: application/pgp-signature; > name="openpgp-digital-signature.asc" > > which clearly shows what kind of attachment this is. > >> When now looking to DKIM, this looks much more advanced. There is a Header in >> the mail, containing the signature all details to the signature and > You may want to go back to the year ~2000 when DKIM was > first presented at the IETF in Paris. It was then a quick hack from the > sendmail authors and it took only a few hours until an attack on this > was found. DKIM also broke with the long standing rule of being able to > work in a pipeline (iirc, this is called an online algo these days). > Instead of doing all that DKIM stuff it would have been easier to > directly use S/MIME or PGP/MIME and include copies of important headers > in a signed attachment. But well, attachments are ugly for some people. > Using S/MIME for server to server protection would involve heavy mangling of mail bodies, unlike the header-only placement of DKIM signatures.? It is true that DKIM generation and validation needs the entire mail in some kind of storage, such as the mail spool of a resend-capable MTA, which is a key reliability requirement for non-spam mail servers anyway. As a mail admin I see a lot of buggy 3rd party mail servers built by rather large companies, but the traditional line mangling so common before MIME seems a thing of the past, while Base64 encoding mail bodies has become the realm of buggy software and/or spam (I happen to use such a buggy big name SMTP library for mailing webshop receipts etc.) 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 Wed Sep 4 15:05:28 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 4 Sep 2024 14:05:28 +0100 Subject: Signing (and Encrypting) Mails with gpg like DKIM In-Reply-To: References: <87wmju7d5m.fsf@jacob.g10code.de> Message-ID: On 4 Sep 2024, at 13:41, Jakob Bohm via Gnupg-users wrote: > > As a mail admin I see a lot of buggy 3rd party mail servers built by rather > large companies, but the traditional line mangling so common before MIME > seems a thing of the past, As I mentioned already in an (accidental) off-list message to the OP, I have one regular correspondent who sees my signatures as broken if I send email from my laptop, because some as yet unknown MTA on the path between us is normalising a double newline into a single newline between the MIME headers of the inner multipart and the inner MIME plaintext part. I?m sure I?m not the only person to experience this. A -------------- 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 dkg at fifthhorseman.net Thu Sep 5 17:04:23 2024 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 05 Sep 2024 11:04:23 -0400 Subject: Signing Mails with OpenPGP like DKIM [was: gpg like DKIM] In-Reply-To: References: <87wmju7d5m.fsf@jacob.g10code.de> Message-ID: <87jzfqw39k.fsf@fifthhorseman.net> On Wed 2024-09-04 14:05:28 +0100, Andrew Gallagher via Gnupg-users wrote: > As I mentioned already in an (accidental) off-list message to the OP, > I have one regular correspondent who sees my signatures as broken if I > send email from my laptop, because some as yet unknown MTA on the path > between us is normalising a double newline into a single newline > between the MIME headers of the inner multipart and the inner MIME > plaintext part. I?m sure I?m not the only person to experience this. I think that's me! We should really try to debug that further at some point, Andrew, but not at the risk of distracting from or delaying any of the many other projects we're collaborating on at the moment ? Back to the topic at hand: it seems like there are several orthogonal questions that are being discussed in this thread, and it would be best to tease them apart if anyone wants to make progress. I *do* think progress is achievable here and might be worthwhile on at least some of these ideas, but it would happen on a matter of years, not months. Let's break out the distinct things that people might want from "using OpenPGP like DKIM" ? Who is doing the DKIM signing? DKIM signatures are typically done by the server (the MTA), but this thread includes some discussion about them being done by the user (the MUA). The *recipient* of course, can't tell whether the DKIM signing key is held by the MUA or the MTA, so this doesn't really give the recipient any clear end-to-end assurances. I'm personally not that interested in the idea of giving DKIM signing keys to end users, but this is one possible project. ? Doing something DKIM-like, but for encryption: i don't think this is a coherent goal. DKIM is signatures-only, and trying to repurpose it for encryption doesn't make sense. ? Putting end-user OpenPGP certificates in the DNS: this one is already done! See RFC 7929 (https://datatracker.ietf.org/doc/html/rfc7929) ? Creating a new structure for signed-only mail that would be capable of improving on (and at some point supplanting) PGP/MIME multipart/signed: This is where i think it gets interesting. If you want to pursue this, i'd recommend identifying the specific flaws of PGP/MIME multipart/signed that you want to ameleiorate, and the tradeoffs that you're willing to accept to fix them. You probably want to find a proper venue for discussion (e.g. The IETF OpenPGP or LAMPS or perhaps MAILMAINT lists). I would avoid trying to mix this mechanism into encrypted+signed mail, as we already have standards for doing that safely that don't have the drawbacks that multipart/signed has. I think you could specify such a mechanism relatively quickly if you make use of existing DKIM message canonicalization rules and header structure (but without calling it "DKIM") and replacing the DKIM signature blob with a base64-encoded binary OpenPGP signature object. You'd want to make sure that all of the headers applied by the sending MUA are included in the signature, so that you don't cause a regression from draft-ietf-lamps-header-protection mechanisms. And you'd need to recruit a few MUA developers who would be willing to verify signatures structured in this way, and to be capable of producing them. And finally, you'd need to think about the UX concerns: should the end user be responsible for selecting which kind of signed-only message to produce? I don't think that's a reasonable question to ask of end users, who just want to send mail. Do you need a signalling/negotiation mechanism so that MUAs can automatically choose the "best" signing format for any given outbound message? Or can you frame the tradeoffs such that a MUA can at some point just unilaterally choose to emit the new format and be confident that their signed-only messages will be acceptable? Such a deployment would probably be helped along by leaning into recommendation (common to both DKIM and to draft-ietf-lamps-e2e-mail-guidance) that a message with a broken signature be presented in no more scary a form than a message with no signature whatsoever. If you're interested in doing this kind of work but have never done interoperable standardization before, i'd be happy to give you some pointers and help nudge this along where i can. This has been on my list of things to clean up in the ecosystem for a while, and it just needs someone to drive it forward. --dkg PS for the record, i think there is one major concern about PGP/MIME multipart/signed: for users of MUAs that don't understand PGP/MIME, the signature shows up as a mystery attachment. I can't tell you the number of times that i get a response from a colleague that says "i can't open your attachment, please re-send". That happens often enough that i deliberately do not sign mail unless i know the recipient won't do that. That means i don't sign most of my mail, which means i can't expect anyone to expect that all my mail will be signed. If a mechanism like this was available, and especially if it didn't automatically cause warnings on the receiving end when the signature failed to validate, i'd use it to sign *all* of my cleartext mail. Once i am comfortable signing all of my cleartext mail, i would be happy to start opting into something like https://datatracker.ietf.org/doc/draft-dkg-lamps-expect-signed-mail/ This is a multi-stage process to get to the point where at least some people can have robust e2e cryptographic authenticity protections for their mail, but i think the work described above would be a great start. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 324 bytes Desc: not available URL: From wk at gnupg.org Fri Sep 6 11:26:30 2024 From: wk at gnupg.org (Werner Koch) Date: Fri, 06 Sep 2024 11:26:30 +0200 Subject: [Feature request] Please make it easier to check success/failure from scripts In-Reply-To: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com> (Jakob Bohm via Gnupg-users's message of "Tue, 27 Aug 2024 17:37:03 +0200") References: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com> Message-ID: <87wmjpb0ah.fsf@jacob.g10code.de> Hi! On Tue, 27 Aug 2024 17:37, Jakob Bohm said: > 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. Right. That is because there are a lot of use cases for signatures which required different handling depending on the signature (e.g. time created) and meta data from the key. For OpenPGP we wrote gpgv to handle one common task; which was originally Debian package signing. Only recently we added --assert-signer to gpg which actually can replace gpgv. The plan is to add a few other --assert options for example to check the time the signature was made. > 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. Cool. I didn't expected that someone really has this use case. But it makes sense. See T7286: Add --assert-signer also to gpgsm. > 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. That is too hard to implement. We have keys, trust models, ownertrust, and compliance modes which is quite some data. For this it is better to use a separate GNUPGHOME. The --assert-signer requires a fingerprint or the list of fingerprints and thus the import of the to-be-tested keys prior to running a verification. It might be possible to combine the import and the verification and even make the imported keys ephemeral so that they don't clutter the keyring. However, some file system write access will be required unless we can find a way to keep the keys in a memory only database. A RAM based file system and ephemeral storage of keys would be an easier solution. 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 Fri Sep 6 14:00:53 2024 From: wk at gnupg.org (Werner Koch) Date: Fri, 06 Sep 2024 14:00:53 +0200 Subject: Signing Mails with OpenPGP like DKIM In-Reply-To: <87jzfqw39k.fsf@fifthhorseman.net> (Daniel Kahn Gillmor via Gnupg-users's message of "Thu, 05 Sep 2024 11:04:23 -0400") References: <87wmju7d5m.fsf@jacob.g10code.de> <87jzfqw39k.fsf@fifthhorseman.net> Message-ID: <87seudat56.fsf_-_@jacob.g10code.de> On Thu, 5 Sep 2024 11:04, Daniel Kahn Gillmor said: > PS for the record, i think there is one major concern about PGP/MIME > multipart/signed: for users of MUAs that don't understand PGP/MIME, > the signature shows up as a mystery attachment. I can't tell you the See GpgOL: Add filenames for PGP/MIME parts https://dev.gnupg.org/T4258 on how to solve that. Complaints about strange attachments dropped to nearly zero after we deployed that change 5 years ago. 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 dkg at fifthhorseman.net Fri Sep 6 16:00:09 2024 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 06 Sep 2024 10:00:09 -0400 Subject: Signing Mails with OpenPGP like DKIM In-Reply-To: <87seudat56.fsf_-_@jacob.g10code.de> References: <87wmju7d5m.fsf@jacob.g10code.de> <87jzfqw39k.fsf@fifthhorseman.net> <87seudat56.fsf_-_@jacob.g10code.de> Message-ID: <877cbox4pi.fsf@fifthhorseman.net> On Fri 2024-09-06 14:00:53 +0200, Werner Koch wrote: > See > GpgOL: Add filenames for PGP/MIME parts > https://dev.gnupg.org/T4258 > > on how to solve that. Complaints about strange attachments dropped to > nearly zero after we deployed that change 5 years ago. This is a great idea, and certainly an improvement over an unnamed MIME part. That said, i suspect you have a more technical userbase than the pool of people i correspond with. Receiving an uninterpretable attachment named "openpgp-digital-signature.asc" or "smime.p7s" would get me responses like "what's an .asc file?" or "I don't know how to open a .p7s file!" or "what does openpgp-digital-signature have to do with [subject of message]?" The less visible the signature is for people who can't use it, the better. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 324 bytes Desc: not available URL: From wk at gnupg.org Fri Sep 6 18:10:54 2024 From: wk at gnupg.org (Werner Koch) Date: Fri, 06 Sep 2024 18:10:54 +0200 Subject: Signing Mails with OpenPGP like DKIM In-Reply-To: <877cbox4pi.fsf@fifthhorseman.net> (Daniel Kahn Gillmor via Gnupg-users's message of "Fri, 06 Sep 2024 10:00:09 -0400") References: <87wmju7d5m.fsf@jacob.g10code.de> <87jzfqw39k.fsf@fifthhorseman.net> <87seudat56.fsf_-_@jacob.g10code.de> <877cbox4pi.fsf@fifthhorseman.net> Message-ID: <87o750bw4x.fsf@jacob.g10code.de> On Fri, 6 Sep 2024 10:00, Daniel Kahn Gillmor said: > part. That said, i suspect you have a more technical userbase than the > pool of people i correspond with. ROFL -- 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 steffen at sdaoden.eu Fri Sep 6 21:17:36 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 06 Sep 2024 21:17:36 +0200 Subject: Signing Mails with OpenPGP like DKIM In-Reply-To: <87o750bw4x.fsf@jacob.g10code.de> References: <87wmju7d5m.fsf@jacob.g10code.de> <87jzfqw39k.fsf@fifthhorseman.net> <87seudat56.fsf_-_@jacob.g10code.de> <877cbox4pi.fsf@fifthhorseman.net> <87o750bw4x.fsf@jacob.g10code.de> Message-ID: <20240906191736.7MrPzlzy@steffen%sdaoden.eu> Werner Koch via Gnupg-users wrote in <87o750bw4x.fsf at jacob.g10code.de>: |On Fri, 6 Sep 2024 10:00, Daniel Kahn Gillmor said: | |> part. That said, i suspect you have a more technical userbase than the |> pool of people i correspond with. | |ROFL There is btw also Content-Description:. (Depends on the mailer if it is used it seems (superficial knowledge), but especially so if filename is set as is in the patch.) (I think of all this rather as a more political issue, anyway.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From harish.chandrasekar16 at gmail.com Sat Sep 7 19:52:34 2024 From: harish.chandrasekar16 at gmail.com (Harish Chandrasekar) Date: Sat, 7 Sep 2024 23:22:34 +0530 Subject: PGP Linux OS Upgrade Issue Message-ID: Hi, Recently our servers were migrated from Linux REHL 7 to 9. We have PGP encryption/decryption done as part of our apps using java which runs the gpg command . The issue is after upgradation we have installed gnupg 2 2.3 v and pinentry 1.1 but 1st time when the script runs popup of passphrase is displayed .(manually checked by running command in terminal since we were reciving timout when run through application). How to stop this pop up since passphrase is already part of the command. gpg --homedir ~/.gnupg/ --batch --yes --no--tty --receipient --passphrase --output --decrypt --value Googled and found couple of suggestions to add loopback entry in pgp.conf and pgp-agent.conf. So have created files under .gngpg and made entries as well.Restarted the deamon. Nothing worked. I would highly appreciate if anyone can help on this issue? Regards, C.Harish -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Mon Sep 9 05:47:38 2024 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 08 Sep 2024 23:47:38 -0400 Subject: [Feature request] Please make it easier to check success/failure from scripts In-Reply-To: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com> References: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com> Message-ID: <87wmjlv679.fsf@fifthhorseman.net> On Tue 2024-08-27 17:37:03 +0200, Jakob Bohm via Gnupg-users wrote: > 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. Given this request for statelessness, You might be interested in the "stateless openpgp command line interface", or "sop", which is designed in many ways for the types of operations you're talking about: https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/ (disclaimer: I've been shepherding the specification, but there are a half-dozen high quality implementations in the wild and several more in incubation) For signature verification specifically, the "sopv" verification-only subset is intended specifically to integrate well with other POSIX commands. A sopv implementation that wraps gpgv and handles all the status-fd checking as documented is also available at: https://gitlab.com/dkg/sopv-gpgv I see that you're using S/MIME and/or CMS (i.e. gpgsm) instead of the OpenPGP equivalents, and i don't know that anyone has produced something comparable for S/MIME or CMS, unfortunately. But the rough shape of the problem space is the same. I'd be very surprised if you couldn't move your administrative tooling over to using OpenPGP and making it work successfully with any of the available sop implementations. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 324 bytes Desc: not available URL: From wk at gnupg.org Mon Sep 9 15:13:07 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 09 Sep 2024 15:13:07 +0200 Subject: [admin] This is a GnuPG related ML In-Reply-To: <87wmjlv679.fsf@fifthhorseman.net> (Daniel Kahn Gillmor via Gnupg-users's message of "Sun, 08 Sep 2024 23:47:38 -0400") References: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com> <87wmjlv679.fsf@fifthhorseman.net> Message-ID: <877cblas2k.fsf_-_@jacob.g10code.de> Hi! Just a short reminder that this mailing list's topic is GnuPG. Advertisement for other applications, like a Python wrapper around a long standing command line API (going all the way back to pgp 2), is thus off-topic. It feels more like a SEO strategy than as helpful information. Please don't confuse users; search engines already deliver too much misinformation on best gpg practices. 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 andrewg at andrewg.com Wed Sep 11 10:18:02 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 11 Sep 2024 09:18:02 +0100 Subject: Signing Mails with OpenPGP like DKIM [was: gpg like DKIM] In-Reply-To: <87jzfqw39k.fsf@fifthhorseman.net> References: <87wmju7d5m.fsf@jacob.g10code.de> <87jzfqw39k.fsf@fifthhorseman.net> Message-ID: On 5 Sep 2024, at 16:04, Daniel Kahn Gillmor wrote: > > PS for the record, i think there is one major concern about PGP/MIME > multipart/signed: for users of MUAs that don't understand PGP/MIME, > the signature shows up as a mystery attachment. I can't tell you the > number of times that i get a response from a colleague that says "i > can't open your attachment, please re-send". That happens often > enough that i deliberately do not sign mail unless i know the > recipient won't do that. That means i don't sign most of my mail, I?ve been signing all my email (from my laptop anyway) for twenty years, and the last time I had complaints about mystery attachments was in the early 2000s. That said, there are a lot of automated systems (e.g. bug trackers) that treat the attachment as a file that needs to be recorded for posterity, e.g. attaching it to a ticket on every emailed comment/reply (although this also applies to HTML email signature footers, which is more annoying). So I do think that moving from an attachment-based cleartext format to a header-based one has some advantages. A -------------- 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 wk at gnupg.org Thu Sep 12 14:02:41 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 12 Sep 2024 14:02:41 +0200 Subject: [Announce] GnuPG 2.5.1 released Message-ID: <87wmjh6pwe.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.5.1. This release is the second of a series of public testing releases eventually leading to a new stable version 2.6. The main features in the 2.6 series are improvements for 64 bit Windows and the introduction of a PQC encryption algorithm. The 2.6 series will not differ a lot from 2.4 because the majority of changes are internal to make use of newer features from the supporting libraries. What is GnuPG ============= The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.5.1 (2024-09-12) ================================================ [compared to version 2.5.0] * gpg: The support for composite Kyber+ECC public key algorithms does now use the final FIPS-203 and LibrePGP specifications. The experimental keys from 2.5.0 are no longer supported. [T6815] * gpg: New commands --add-recipients and --change-recipients. [T1825] * gpg: New option --proc-all-sigs. [T7261] * gpg: Fix a regression in 2.5.0 in gpgme's tests. [T7195] * gpg: Make --no-literal work again for -c and --store. [T5852] * gpg: Improve detection of input data read errors. [T6528] * gpg: Fix getting key by IPGP record (rfc-4398). [T7288] * gpgsm: New option --assert-signer. [T7286] * gpgsm: More improvements to PKCS#12 parsing to cope with latest IVBB changes. [T7213] * agent: Fix KEYTOCARD command when used with a loopback pinentry. [T7283] * gpg-mail-tube: Make sure GNUPGHOME is set in vsd mode. New option --as-attach. [rG4511997e9e1b] * Now uses the process spawn API from libgpg-error. [T7192,T7194] * Removed the --enable-gpg-is-gpg2 configure time option. [rG2125f228d36c] * Die Windows version will now be build for 64-Bit Windows and with the corresponding changes to the installation directory and Registry keys. Release-info: https://dev.gnupg.org/T7191 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG may be downloaded from one of the GnuPG mirror sites or direct from its primary file server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.1.tar.bz2 (7936k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.1.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.1_20240912.exe (5449k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.1_20240912.exe.sig Note that these Windows binaries are exceptionally not AuthentiCode signed and not well tested. The source used to build this Windows installer is available at https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.1_20240912.tar.xz (16M) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.1_20240912.tar.xz.sig This Windows source tarball may also be used to download all required libraries at once to build a Unix version on any modern system. See the included README but replace the make target "native" by "this-native". Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.5.1.tar.bz2 you would use this command: gpg --verify gnupg-2.5.1.tar.bz2.sig gnupg-2.5.1.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.5.1.tar.bz2, you run the command like this: sha1sum gnupg-2.5.1.tar.bz2 and check that the output matches the next line: 1336f00a6d9ff9806a2187bb06e8faf59391b5a2 gnupg-2.5.1.tar.bz2 4237371dbe5ebafaa015da2f3681f466b65c9742 gnupg-w32-2.5.1_20240912.tar.xz 772dda3a41f7cafd07cad66340fa17becc77687d gnupg-w32-2.5.1_20240912.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, Japanese, Norwegian, Polish, Russian, Turkish, and Ukrainian being almost completely translated. Documentation and Support ========================= The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details available only in the manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. https://wiki.gnupg.org has user contributed information around GnuPG and relate software. In case of build problems specific to this release please first check https://dev.gnupg.org/T7191 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html. We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html. If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and has mostly been financed by donations. Several full-time employed developers and contractors are working exclusively on GnuPG and closely related software like Libgcrypt, GPGME, Kleopatra and Gpg4win. Fortunately, and this is still not common with free software, we have established a way of financing the development while keeping all our software free and freely available for everyone. Our model is similar to the way RedHat manages RHEL and Fedora: Except for the actual binary of the MSI installer for Windows and client specific configuration files, all the software is available under the GNU GPL and other Open Source licenses. Thus customers may even build and distribute their own version of the software as long as they do not use our trademarks GnuPG Desktop? or GnuPG VS-Desktop?. We like to thank all the nice people who are helping the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, or helped with donations. *Thank you all* Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users at gnupg.org mailing list. List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa3072 2017-03-17 [expires: 2027-03-15] 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) ed25519 2020-08-24 [expires: 2030-06-30] 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) ed25519 2021-05-19 [expires: 2027-04-04] AC8E 115B F73E 2D8D 47FA 9908 E98E 9B2D 19C6 C8BD Niibe Yutaka (GnuPG Release Key) brainpoolP256r1 2021-10-15 [expires: 2029-12-31] 02F3 8DFF 731F F97C B039 A1DA 549E 695E 905B A208 GnuPG.com (Release Signing Key 2021) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Arguing that you don't care about the right to privacy because you have nothing to hide is no different from saying you don't care about free speech because you have nothing to say. - Edward Snowden -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From alx at kernel.org Thu Sep 12 13:28:37 2024 From: alx at kernel.org (Alejandro Colomar) Date: Thu, 12 Sep 2024 13:28:37 +0200 Subject: Text (non-binary) keyring format Message-ID: Hi, I have my ~/.gnupg keyring under git source control, which helps creating and updating backups, and also having a history of the changes. I find that having the contents in binary format is odd, and think it would be much better if it was all stored in text files. I would be able to understand the diffs, and if a failure happens before a backup, I'd probably be able to at least diff(1) the contents of the keyring and recover something. Would you consider developing a new format for the keyring, where stuff is divided in small text files, just like most Unix stuff? Have a lovely day! Alex -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From steffen at sdaoden.eu Thu Sep 12 23:00:08 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 12 Sep 2024 23:00:08 +0200 Subject: Text (non-binary) keyring format In-Reply-To: References: Message-ID: <20240912210008.k4szuwdl@steffen%sdaoden.eu> Alejandro Colomar via Gnupg-users wrote in : |I have my ~/.gnupg keyring under git source control, which helps |creating and updating backups, and also having a history of the changes. |I find that having the contents in binary format is odd, and think it |would be much better if it was all stored in text files. I would be |able to understand the diffs, and if a failure happens before a backup, |I'd probably be able to at least diff(1) the contents of the keyring and |recover something. I do that too. (In fact i even have three different PGP directories, ehem, all 1.4 still, i am sorry, but these are pgp-nosecrets.git (no secring, only public key), pgp.git (mutilated private key, for creating signatures, but which cannot be exported or whatever, and has its own specific password; thanks again for this great idea and fantastic possibility!), and ~/sic/pgp.git (there it is).) |Would you consider developing a new format for the keyring, where stuff |is divided in small text files, just like most Unix stuff? And how about using a LMDB database. Seriously, i also hate it, but even more seriously, how about exporting at times stuff via "--list-keys/--list-sigs --with- colons --verbose", and then further process the output if you want? Ie hop from ^pub to ^pub, use "--list-key ID" and then even "--armor --export ID". --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From ralph at ml.seichter.de Fri Sep 13 02:22:06 2024 From: ralph at ml.seichter.de (Ralph Seichter) Date: Fri, 13 Sep 2024 02:22:06 +0200 Subject: Text (non-binary) keyring format In-Reply-To: References: Message-ID: <87ttekpfm9.fsf@ra.horus-it.com> * Alejandro Colomar via Gnupg-users: > I have my ~/.gnupg keyring under git source control, which helps > creating and updating backups, and also having a history of the > changes. I find that having the contents in binary format is odd, and > think it would be much better if it was all stored in text files. I have my GnuPG keyrings and config under version control as well. However, I think that the key material does not really lend itself to text-based inspection with something like 'diff', in contrast to config files. For recovery, I have sometimes accessed historic keyrings, but only as a whole. and then exported a certain key, to be re-imported into my newer keyring. I don't see myself accessing some part of a keyring without using the GnuPG binary, so I wonder what tanglibe benefit a text-based storage format would bring to the table? -Ralph From wk at gnupg.org Fri Sep 13 13:39:08 2024 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Sep 2024 13:39:08 +0200 Subject: Text (non-binary) keyring format In-Reply-To: (Alejandro Colomar via Gnupg-users's message of "Thu, 12 Sep 2024 13:28:37 +0200") References: Message-ID: <87seu37pgj.fsf@jacob.g10code.de> Hi! On Thu, 12 Sep 2024 13:28, Alejandro Colomar said: > I have my ~/.gnupg keyring under git source control, which helps > creating and updating backups, and also having a history of the changes. That is not a good idea because the key database (pubring.gpg, pubring.kbx, or keyboxd DB) are a binary format which also stores meta data which is only used by gnupg itself and not part of an official API (e.g. the signature cache). Thus if you want to put something under version control, it is better to do this with exported files. You may use "--export-option backup" so that you get all the internal infos and also non-exportable signed signatures ("--export-option export-local-sigs" would be sufficient here. Although I really like text files, it will be somewhat hard to diff them because any property update of a key also requires a new signature and that give a lot of diff overhead. This is similar to Libreoffice's fodt format - in theory a way to diff things but in practice it is useless. We actually moved to an SQL database to speed up things. If you have hundreds of keys with thousands of key signatures it is very helpful to have indices; it really speeds up things. OpenPGP keys do not allow a rollback by design. For documentation writing a (sorted) key listing to a file might thus be more useful than plain text files. 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 Fri Sep 13 16:42:04 2024 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Sep 2024 16:42:04 +0200 Subject: [Feature request] Please make it easier to check success/failure from scripts In-Reply-To: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com> (Jakob Bohm via Gnupg-users's message of "Tue, 27 Aug 2024 17:37:03 +0200") References: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com> Message-ID: <87ed5n62f7.fsf@jacob.g10code.de> Hi! GnuPG 2.5.1 has the option --assert-signer and 2.4.6 will have this option as well: --assert-signer fpr_or_file This option checks whether at least one valid signature on a file has been made with the specified key. The key is either specified as a fingerprint or a file listing fingerprints. The fingerprint must be given or listed in compact format (no colons or spaces in between). As of now only SHA-1 fingerprints are allowed. This option can be given multiple times and each fingerprint is checked against the sign? ing key as well as the corresponding primary key. If fpr_or_file specifies a file, empty lines are ignored as well as all lines start? ing with a hash sign. With this option gpgsm is guaranteed to return with an exit code of 0 if and only if a signature has been encoun? tered, is valid, and the key matches one of the fingerprints given by this option. Tarcked as https://dev.gnupg.org/T7286 Hope that helps a bit. 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 alx at kernel.org Fri Sep 13 14:02:54 2024 From: alx at kernel.org (Alejandro Colomar) Date: Fri, 13 Sep 2024 14:02:54 +0200 Subject: Text (non-binary) keyring format In-Reply-To: <87seu37pgj.fsf@jacob.g10code.de> References: <87seu37pgj.fsf@jacob.g10code.de> Message-ID: Hi Werner, On Fri, Sep 13, 2024 at 01:39:08PM GMT, Werner Koch wrote: > Hi! > > On Thu, 12 Sep 2024 13:28, Alejandro Colomar said: > > > I have my ~/.gnupg keyring under git source control, which helps > > creating and updating backups, and also having a history of the changes. > > That is not a good idea because the key database (pubring.gpg, > pubring.kbx, or keyboxd DB) are a binary format which also stores meta > data which is only used by gnupg itself and not part of an official > API (e.g. the signature cache). Maybe you could split the pubring as a directory with many files, have most of them as text files, and a few that need to be binary could be kept as binary. > Thus if you want to put something under version control, it is better to > do this with exported files. You may use "--export-option backup" so > that you get all the internal infos and also non-exportable signed > signatures ("--export-option export-local-sigs" would be sufficient > here. I prefer having the actual keyring under version control, although will consider that option. > Although I really like text files, it will be somewhat hard to diff them > because any property update of a key also requires a new signature and > that give a lot of diff overhead. If we had one text file per contact (just like we have now one text file per private key under `~/.gnupg/private-keys-v1.d`), I wouldn't mind the diff for the contact to look like an entire (or almost entire) rewrite of the contact. That's already better than "Binary files a/pubring.kbx and b/pubring.kbx differ". > This is similar to Libreoffice's fodt > format - in theory a way to diff things but in practice it is useless. > > We actually moved to an SQL database to speed up things. If you have > hundreds of keys with thousands of key signatures it is very helpful to > have indices; it really speeds up things. > > OpenPGP keys do not allow a rollback by design. For documentation > writing a (sorted) key listing to a file might thus be more useful than > plain text files. I don't use git to be able to roll back, but rather to know at which state a backup is. For example, I gave a backup to a family member last time I saw him, and I know that backup is N commits behind my current keyring. > > > > Shalom-Salam, > > Werner Have a lovely day! Alex -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tmz at pobox.com Sat Sep 14 00:56:18 2024 From: tmz at pobox.com (Todd Zullinger) Date: Fri, 13 Sep 2024 18:56:18 -0400 Subject: Text (non-binary) keyring format In-Reply-To: References: <87seu37pgj.fsf@jacob.g10code.de> Message-ID: Alejandro Colomar via Gnupg-users wrote: > I don't use git to be able to roll back, but rather to know at which > state a backup is. For example, I gave a backup to a family member last > time I saw him, and I know that backup is N commits behind my current > keyring. As a random idea (which you may have already had), you could include the output of a keyring listing along with the commit. Putting that data in git notes is an option if you don't want the commit message to be too large. While that doesn't improve the diff between things, it does make it easier to know the state of the keyring at each commit. For diffing, you could also use a script to dump the keyring (via git show or whatever) and pipe it to gpg to list. That could make comparing the revisions a little easier. I've thought about doing some similar to track a collection of binary music files -- but have never gotten around to doing it. :) -- Todd -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From ralph at ml.seichter.de Sat Sep 14 01:20:37 2024 From: ralph at ml.seichter.de (Ralph Seichter) Date: Sat, 14 Sep 2024 01:20:37 +0200 Subject: Text (non-binary) keyring format In-Reply-To: References: <87seu37pgj.fsf@jacob.g10code.de> Message-ID: <87jzffqgxm.fsf@ra.horus-it.com> * Alejandro Colomar via Gnupg-users: > I don't use git to be able to roll back, but rather to know at which > state a backup is. For example, I gave a backup to a family member last > time I saw him, and I know that backup is N commits behind my current > keyring. Looks like none of this depends on the keyring being stored in a binary or textual format, does it? Even knowing only the date of having passed on a backup would be enough to figure out the commits made after handing over the backup. Then there are commit comments, tags, branchs... Maybe think of the process of creating and handing over a backup like a software release? In any case, as far as I am concerned, the increased performance of using a binary keyring in daily GnuPG use far outweighs any perceived convenience of a text-based format, especially when that text-based format can be easily generated using the "gpg" binary. Note that I am saying that as a true fan of text-based formats myself. -Ralph From dkg at fifthhorseman.net Tue Sep 10 19:40:45 2024 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 10 Sep 2024 13:40:45 -0400 Subject: [admin] This is a GnuPG related ML In-Reply-To: <877cblas2k.fsf_-_@jacob.g10code.de> References: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com> <87wmjlv679.fsf@fifthhorseman.net> <877cblas2k.fsf_-_@jacob.g10code.de> Message-ID: <87jzfjl84i.fsf@fifthhorseman.net> On Mon 2024-09-09 15:13:07 +0200, Werner Koch via Gnupg-users wrote: > Advertisement for other applications, like a Python wrapper around a > long standing command line API (going all the way back to pgp 2), is > thus off-topic. Jakob specifically asked how he could use GnuPG while relying on the return code. I pointed to some tooling that is designed to do that specifically, not to avoid the use of GnuPG. In particular, the command line API for GnuPG tools is itself quite idiosyncratic, as "long standing" CLIs tend to be. > It feels more like a SEO strategy than as helpful information. Please > don't confuse users; search engines already deliver too much > misinformation on best gpg practices. I agree that there is a lot of misinformation in the wild about how to "best" use gpg. I think if the GnuPG interface lent itself to the type of straightforward system integration like Jakob was asking for, there would probably be fewer workarounds, not-quite-complete shell scripts, or ambitious-yet-flawed guidance floating around about the project. Tooling that deliberately transforms GnuPG's idiosyncratic interface into a simpler, easier-to-integrate DWIM syntax/semantics is intended as a contribution to the GnuPG project, so that people who want to rely on GnuPG can do so safely. Sorry if it didn't read that way from the outset. All the best, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 324 bytes Desc: not available URL: From jb-gnumlists at wisemo.com Mon Sep 16 12:47:35 2024 From: jb-gnumlists at wisemo.com (Jakob Bohm) Date: Mon, 16 Sep 2024 12:47:35 +0200 Subject: [Feature request] Please make it easier to check success/failure from scripts In-Reply-To: <87ed5n62f7.fsf@jacob.g10code.de> References: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com> <87ed5n62f7.fsf@jacob.g10code.de> Message-ID: <72ed0b77-c138-6f24-7f1d-9d0c0c31bf65@wisemo.com> On 2024-09-13 16:42, Werner Koch wrote: > Hi! > > GnuPG 2.5.1 has the option --assert-signer and 2.4.6 will have this > option as well: > > --assert-signer fpr_or_file > > This option checks whether at least one valid signature on a file > has been made with the specified key. The key is either specified > as a fingerprint or a file listing fingerprints. The fingerprint > must be given or listed in compact format (no colons or spaces in > between). As of now only SHA-1 fingerprints are allowed. This > option can be given multiple times and each fingerprint is checked > against the sign? ing key as well as the corresponding primary key. > If fpr_or_file specifies a file, empty lines are ignored as well as > all lines start? ing with a hash sign. With this option gpgsm is > guaranteed to return with an exit code of 0 if and only if a > signature has been encoun? tered, is valid, and the key matches one > of the fingerprints given by this option. > > > Tarcked as https://dev.gnupg.org/T7286 > > Hope that helps a bit. > > This is a very partial solution, and only for bleeding edge Gnupg . It might be usable when combined with scripting that identifies the hash of the DER certificate expected, but still at the (security, stability and performance) cost of still invoking ?gyptian bureaucracy of GPG specific versions of the overall X.509 infrastructure in the OS (typically based on derivatives of old SSLeay code or Microsoft CryptoAPI 1.x) . 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 jb-gnumlists at wisemo.com Mon Sep 16 14:06:03 2024 From: jb-gnumlists at wisemo.com (Jakob Bohm) Date: Mon, 16 Sep 2024 14:06:03 +0200 Subject: Text (non-binary) keyring format In-Reply-To: <87seu37pgj.fsf@jacob.g10code.de> References: <87seu37pgj.fsf@jacob.g10code.de> Message-ID: <4dce2525-8e92-e628-c1c9-4be2446adaf4@wisemo.com> On 2024-09-13 13:39, Werner Koch via Gnupg-users wrote: > Hi! > > On Thu, 12 Sep 2024 13:28, Alejandro Colomar said: > >> I have my ~/.gnupg keyring under git source control, which helps >> creating and updating backups, and also having a history of the changes. > We actually moved to an SQL database to speed up things. If you have > hundreds of keys with thousands of key signatures it is very helpful to > have indices; it really speeds up things. This isn't the first time GnuPG prematurely optimized pubring access. Years ago, I noticed that the certificate validation cache prematurely optimized when the problem was a linear search of the pubring itself, not the cryptographic validation.? Obvious solution at the time would have been to keep a hash table of file offsets for key fingerprints . 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 wk at gnupg.org Tue Sep 17 10:21:27 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Sep 2024 10:21:27 +0200 Subject: Text (non-binary) keyring format In-Reply-To: <4dce2525-8e92-e628-c1c9-4be2446adaf4@wisemo.com> (Jakob Bohm via Gnupg-users's message of "Mon, 16 Sep 2024 14:06:03 +0200") References: <87seu37pgj.fsf@jacob.g10code.de> <4dce2525-8e92-e628-c1c9-4be2446adaf4@wisemo.com> Message-ID: <8734ly4rnc.fsf@jacob.g10code.de> On Mon, 16 Sep 2024 14:06, Jakob Bohm said: > not the cryptographic validation.? Obvious solution at the time would > have been to keep a hash table of file offsets for key fingerprints . Which conflicted with the demand for having several keyring; actually we once had experimental support for a hash table. But because some sites insisted on using several keyrings this did not worked very well. With the keyboxd we finally started to drop support for several keyrings. Due to the ubiquity and maturity of SQLite keyboxd does not anymore use a custom database but relies on SQLite. 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 nils.schween at mpi-hd.mpg.de Tue Sep 17 21:49:55 2024 From: nils.schween at mpi-hd.mpg.de (Nils Schween) Date: Tue, 17 Sep 2024 21:49:55 +0200 Subject: Error: Bad length of salt (32) for AES when importing a p12 certificate Message-ID: <87msk6ukkc.fsf@mpi-hd.mpg.de> Dear gpg community, I had difficulties to import a p12 certificiate with gpgsm --import cert.p12 I got the following error message: gpgsm: bad length of salt (32) for AES gpgsm: parse_shrouded_key_bag(shrouded_key_bag.pkcs5PBES2-params): lvl=16 (tlv_expect_octet_string): Success - Invalid length gpgsm: parse_bag_data(data.oid): lvl=16 (tlv_expect_octet_string): Success - Invalid length gpgsm: p12_parse(bag.data): @6724 lvl=16 tlv_expect_octet_string: Success - Invalid length gpgsm: error parsing or decrypting the PKCS#12 file gpgsm: total number processed: 4 gpgsm: unchanged: 4 I searched the internet and I found the following bug report https://dev.gnupg.org/T6757#182217 I checked with the lenght of the salt in my certificate with the command command openssl pkcs12 -info -nokeys -noout -in smime_eyJpZCI6MzYzNTkwMSwidHlwZSI6IlNNSU1FIn0_.p12 The output was MAC: sha256, Iteration 20000 MAC length: 32, salt length: 64 In agreement with the error message and along the lines of the mentioned bug report I changed the following lines in the sm/minip12.c : static int parse_bag_encrypted_data (struct p12_parse_ctx_s *ctx, tlv_parser_t tlv) { gpg_error_t err = 0; const char *where; const unsigned char *oid; size_t oidlen; const unsigned char *data; size_t datalen; int intval; - char salt[32]; + char salt[64]; static gpg_error_t parse_shrouded_key_bag (struct p12_parse_ctx_s *ctx, tlv_parser_t tlv) { gpg_error_t err = 0; const char *where; const unsigned char *oid; size_t oidlen; const unsigned char *data; size_t datalen; int intval; - char salt[20]; + char salt[64]; ... After recompiling I could import the certificate without issues. I do not know if I did something risky from the security perspective and I am sorry for not reporting it directly in bug tracker, but I do not have an account there. Please let me, if this change is going to make into one of the next versions of gpg. Best regards, Nils Schween -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5989 bytes Desc: not available URL: From nils.schween at mpi-hd.mpg.de Tue Sep 17 21:45:36 2024 From: nils.schween at mpi-hd.mpg.de (Nils Schween) Date: Tue, 17 Sep 2024 21:45:36 +0200 Subject: Bad salt length AES Message-ID: <87tteeukrj.fsf@mpi-hd.mpg.de> Dear gpg community, I had difficulties to import a p12 certificiate with gpgsm --import cert.p12 I got the following error message: gpgsm: bad length of salt (32) for AES gpgsm: parse_shrouded_key_bag(shrouded_key_bag.pkcs5PBES2-params): lvl=16 (tlv_expect_octet_string): Success - Invalid length gpgsm: parse_bag_data(data.oid): lvl=16 (tlv_expect_octet_string): Success - Invalid length gpgsm: p12_parse(bag.data): @6724 lvl=16 tlv_expect_octet_string: Success - Invalid length gpgsm: error parsing or decrypting the PKCS#12 file gpgsm: total number processed: 4 gpgsm: unchanged: 4 I searched the internet and I found the following bug report https://dev.gnupg.org/T6757#182217 I checked with the lenght of the salt in my certificate with the command command openssl pkcs12 -info -nokeys -noout -in smime_eyJpZCI6MzYzNTkwMSwidHlwZSI6IlNNSU1FIn0_.p12 The output was MAC: sha256, Iteration 20000 MAC length: 32, salt length: 64 In agreement with the error message and along the lines of the mentioned bug report I changed the following lines in the sm/minip12.c : static int parse_bag_encrypted_data (struct p12_parse_ctx_s *ctx, tlv_parser_t tlv) { gpg_error_t err = 0; const char *where; const unsigned char *oid; size_t oidlen; const unsigned char *data; size_t datalen; int intval; - char salt[32]; + char salt[64]; static gpg_error_t parse_shrouded_key_bag (struct p12_parse_ctx_s *ctx, tlv_parser_t tlv) { gpg_error_t err = 0; const char *where; const unsigned char *oid; size_t oidlen; const unsigned char *data; size_t datalen; int intval; - char salt[20]; + char salt[64]; ... After recompiling I could import the certificate without issues. I do not know if I did something risky from the security perspective and I am sorry for not reporting it directly in bug tracker, but I do not have an account there. Please let me, if this change is going to make into one of the next versions of gpg. Best regards, Nils Schween -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5989 bytes Desc: not available URL: From nils.schween at mpi-hd.mpg.de Thu Sep 19 09:07:11 2024 From: nils.schween at mpi-hd.mpg.de (Nils Schween) Date: Thu, 19 Sep 2024 09:07:11 +0200 Subject: Error: Bad length of salt (32) for AES when importing a p12 certificate In-Reply-To: <87msk6ukkc.fsf@mpi-hd.mpg.de> (Nils Schween's message of "Tue, 17 Sep 2024 21:49:55 +0200") References: <87msk6ukkc.fsf@mpi-hd.mpg.de> Message-ID: <87jzf8rujk.fsf@mpi-hd.mpg.de> A short follow up: I did some more tests and I found that the change of the length of the salt array in the function 'parse_shrouded_key_bag' suffices to import the certificate. It is actually enough to increase the value from 20 to 32. Here is the git diff of my change of minip12.c (version 2.5.1 ) diff --git a/minip12.c-original b/minip12.c index 028be91..00ba26d 100644 --- a/minip12.c-original +++ b/minip12.c @@ -1248,7 +1248,7 @@ parse_shrouded_key_bag (struct p12_parse_ctx_s *ctx, tlv_parser_t tlv) const unsigned char *data; size_t datalen; int intval; - char salt[20]; + char salt[32]; size_t saltlen; char iv[16]; unsigned int iter; Regards, Nils Nils Schween writes: > Dear gpg community, > > I had difficulties to import a p12 certificiate with gpgsm --import > cert.p12 > > I got the following error message: > > gpgsm: bad length of salt (32) for AES > gpgsm: parse_shrouded_key_bag(shrouded_key_bag.pkcs5PBES2-params): lvl=16 (tlv_expect_octet_string): Success - Invalid length > gpgsm: parse_bag_data(data.oid): lvl=16 (tlv_expect_octet_string): Success - Invalid length > gpgsm: p12_parse(bag.data): @6724 lvl=16 tlv_expect_octet_string: Success - Invalid length > gpgsm: error parsing or decrypting the PKCS#12 file > gpgsm: total number processed: 4 > gpgsm: unchanged: 4 > > > I searched the internet and I found the following bug report > > https://dev.gnupg.org/T6757#182217 > > I checked with the lenght of the salt in my certificate with the command > command > > openssl pkcs12 -info -nokeys -noout -in smime_eyJpZCI6MzYzNTkwMSwidHlwZSI6IlNNSU1FIn0_.p12 > > The output was > > MAC: sha256, Iteration 20000 > MAC length: 32, salt length: 64 > > In agreement with the error message and along the lines of the mentioned > bug report I changed the following lines in the sm/minip12.c : > > static int > parse_bag_encrypted_data (struct p12_parse_ctx_s *ctx, tlv_parser_t tlv) > { > gpg_error_t err = 0; > const char *where; > const unsigned char *oid; > size_t oidlen; > const unsigned char *data; > size_t datalen; > int intval; > - char salt[32]; > + char salt[64]; > > static gpg_error_t > parse_shrouded_key_bag (struct p12_parse_ctx_s *ctx, tlv_parser_t tlv) > { > gpg_error_t err = 0; > const char *where; > const unsigned char *oid; > size_t oidlen; > const unsigned char *data; > size_t datalen; > int intval; > - char salt[20]; > + char salt[64]; > ... > > After recompiling I could import the certificate without issues. I do > not know if I did something risky from the security perspective and I am > sorry for not reporting it directly in bug tracker, but I do not have an > account there. > > Please let me, if this change is going to make into one of the next > versions of gpg. > > Best regards, > Nils Schween > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users -- Nils Schween PhD Student Phone: +49 6221 516 557 Mail: nils.schween at mpi-hd.mpg.de PGP-Key: 4DD3DCC0532EE96DB0C1F8B5368DBFA14CB81849 Max Planck Institute for Nuclear Physics Astrophysical Plasma Theory (APT) Saupfercheckweg 1, D-69117 Heidelberg https://www.mpi-hd.mpg.de/mpi/en/research/scientific-divisions-and-groups/independent-research-groups/apt -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5989 bytes Desc: not available URL: From wk at gnupg.org Thu Sep 19 11:29:31 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Sep 2024 11:29:31 +0200 Subject: Error: Bad length of salt (32) for AES when importing a p12 certificate In-Reply-To: <87jzf8rujk.fsf@mpi-hd.mpg.de> (Nils Schween's message of "Thu, 19 Sep 2024 09:07:11 +0200") References: <87msk6ukkc.fsf@mpi-hd.mpg.de> <87jzf8rujk.fsf@mpi-hd.mpg.de> Message-ID: <875xqs2dqc.fsf@jacob.g10code.de> On Thu, 19 Sep 2024 09:07, Nils Schween said: > A short follow up: I did some more tests and I found that the change of > the length of the salt array in the function 'parse_shrouded_key_bag' > suffices to import the certificate. It is actually enough to increase > the value from 20 to 32. Here is the git diff of my change of minip12.c Thanks for looking into this. Do have have a sample P12 file we can put into our regression tests? In case you don't want to see that in a public repo we also have an internal collection of p12 files, in this case mail it to me privately - of course only if that is test data and not real key material. 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 nils.schween at mpi-hd.mpg.de Thu Sep 19 13:42:29 2024 From: nils.schween at mpi-hd.mpg.de (Nils Schween) Date: Thu, 19 Sep 2024 13:42:29 +0200 Subject: Error: Bad length of salt (32) for AES when importing a p12 certificate In-Reply-To: <875xqs2dqc.fsf@jacob.g10code.de> (Werner Koch's message of "Thu, 19 Sep 2024 11:29:31 +0200") References: <87msk6ukkc.fsf@mpi-hd.mpg.de> <87jzf8rujk.fsf@mpi-hd.mpg.de> <875xqs2dqc.fsf@jacob.g10code.de> Message-ID: <877cb7swd6.fsf@mpi-hd.mpg.de> Thanks for replying. > Do have have a sample P12 file we can put into our regression tests? I asked our IT department and unfortunately it is not allowed to issue test certificates with dummy email addresses. If it is necessary, I can try to create a certificate with openssl, that reproduces the error. Greetings, Nils Werner Koch writes: > On Thu, 19 Sep 2024 09:07, Nils Schween said: >> A short follow up: I did some more tests and I found that the change of >> the length of the salt array in the function 'parse_shrouded_key_bag' >> suffices to import the certificate. It is actually enough to increase >> the value from 20 to 32. Here is the git diff of my change of minip12.c > > Thanks for looking into this. > > Do have have a sample P12 file we can put into our regression tests? In > case you don't want to see that in a public repo we also have an > internal collection of p12 files, in this case mail it to me privately - > of course only if that is test data and not real key material. > > > Salam-Shalom, > > Werner -- Nils Schween PhD Student Phone: +49 6221 516 557 Mail: nils.schween at mpi-hd.mpg.de PGP-Key: 4DD3DCC0532EE96DB0C1F8B5368DBFA14CB81849 Max Planck Institute for Nuclear Physics Astrophysical Plasma Theory (APT) Saupfercheckweg 1, D-69117 Heidelberg https://www.mpi-hd.mpg.de/mpi/en/research/scientific-divisions-and-groups/independent-research-groups/apt -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5989 bytes Desc: not available URL: From wk at gnupg.org Thu Sep 19 15:02:17 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Sep 2024 15:02:17 +0200 Subject: Error: Bad length of salt (32) for AES when importing a p12 certificate In-Reply-To: <877cb7swd6.fsf@mpi-hd.mpg.de> (Nils Schween's message of "Thu, 19 Sep 2024 13:42:29 +0200") References: <87msk6ukkc.fsf@mpi-hd.mpg.de> <87jzf8rujk.fsf@mpi-hd.mpg.de> <875xqs2dqc.fsf@jacob.g10code.de> <877cb7swd6.fsf@mpi-hd.mpg.de> Message-ID: <87setv23vq.fsf@jacob.g10code.de> On Thu, 19 Sep 2024 13:42, Nils Schween said: > If it is necessary, I can try to create a certificate with openssl, that > reproduces the error. Given the brittleness of pkcs#12/minip12.c I would really appricate to have a sample file. But the worst thing which could happen is that the 64 bit salt does not work anymore in the future. It is unlikey, though. Please give me some days to apply the patch. 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 nils.schween at mpi-hd.mpg.de Fri Sep 20 12:02:09 2024 From: nils.schween at mpi-hd.mpg.de (Nils Schween) Date: Fri, 20 Sep 2024 12:02:09 +0200 Subject: Error: Bad length of salt (32) for AES when importing a p12 certificate In-Reply-To: <87setv23vq.fsf@jacob.g10code.de> (Werner Koch's message of "Thu, 19 Sep 2024 15:02:17 +0200") References: <87msk6ukkc.fsf@mpi-hd.mpg.de> <87jzf8rujk.fsf@mpi-hd.mpg.de> <875xqs2dqc.fsf@jacob.g10code.de> <877cb7swd6.fsf@mpi-hd.mpg.de> <87setv23vq.fsf@jacob.g10code.de> Message-ID: <878qvmzlr2.fsf@mpi-hd.mpg.de> > Given the brittleness of pkcs#12/minip12.c I would really appricate to > have a sample file. But the worst thing which could happen is that the > 64 bit salt does not work anymore in the future. It is unlikey, though. I do understand. I tried to create one this morning, but I was not able to reproduce the error when importing my self created certificate. I used the following commands to create the certificate: openssl req -newkey rsa:4096 -nodes -keyout key.pem -x509 -sha384 -days 365 -out certificate.pem openssl pkcs12 -inkey key.pem -in certificate.pem -export -macsaltlen 64 -iter 20000 -out certificate.p12 To compare my own certificate with the one issued by the certificate provider I used the following two commands: openssl pkcs12 -in certificate.p12 -noout -info openssl x509 -text -noout -in certificate.p12 I could not find any significant difference in the output. Though the one from the certificate provider causes the error when imported with gpgsm while my own certificate does not. Since I am not very knowledgeable when it comes to S/MIME certificates, it is riddle to me why the error appears: My certificate and the one from the provider have a salt length of 64bit and that was the only thing I changed in minip12.c So, I have to say that I am sorry, I cannot reproduce the error with a self-created certificate. > Please give me some days to apply the patch. No hurry, for now I have a personal work around. Thank you, Nils Werner Koch writes: > On Thu, 19 Sep 2024 13:42, Nils Schween said: > >> If it is necessary, I can try to create a certificate with openssl, that >> reproduces the error. > > Given the brittleness of pkcs#12/minip12.c I would really appricate to > have a sample file. But the worst thing which could happen is that the > 64 bit salt does not work anymore in the future. It is unlikey, though. > > Please give me some days to apply the patch. > > > Salam-Shalom, > > Werner -- Nils Schween PhD Student Phone: +49 6221 516 557 Mail: nils.schween at mpi-hd.mpg.de PGP-Key: 4DD3DCC0532EE96DB0C1F8B5368DBFA14CB81849 Max Planck Institute for Nuclear Physics Astrophysical Plasma Theory (APT) Saupfercheckweg 1, D-69117 Heidelberg https://www.mpi-hd.mpg.de/mpi/en/research/scientific-divisions-and-groups/independent-research-groups/apt From jb-gnumlists at wisemo.com Fri Sep 20 17:13:56 2024 From: jb-gnumlists at wisemo.com (Jakob Bohm) Date: Fri, 20 Sep 2024 17:13:56 +0200 Subject: Error: Bad length of salt (32) for AES when importing a p12 certificate In-Reply-To: <878qvmzlr2.fsf@mpi-hd.mpg.de> References: <87msk6ukkc.fsf@mpi-hd.mpg.de> <87jzf8rujk.fsf@mpi-hd.mpg.de> <875xqs2dqc.fsf@jacob.g10code.de> <877cb7swd6.fsf@mpi-hd.mpg.de> <87setv23vq.fsf@jacob.g10code.de> <878qvmzlr2.fsf@mpi-hd.mpg.de> Message-ID: Dear Nils, Given the error message in the subject line above, the step to reproduce may be to pass 32 instead of 64 to the openssl command that makes the test certificate. Otherwise, look for a command that can dump out the formatting details of the (non-distributable) problematic pkcs12 file to see what values it actually uses. On 2024-09-20 12:02, Nils Schween wrote: >> Given the brittleness of pkcs#12/minip12.c I would really appricate to >> have a sample file. But the worst thing which could happen is that the >> 64 bit salt does not work anymore in the future. It is unlikey, though. > I do understand. I tried to create one this morning, but I was not able > to reproduce the error when importing my self created certificate. > > I used the following commands to create the certificate: > > openssl req -newkey rsa:4096 -nodes -keyout key.pem -x509 -sha384 -days 365 -out certificate.pem > > openssl pkcs12 -inkey key.pem -in certificate.pem -export -macsaltlen 64 -iter 20000 -out certificate.p12 > > To compare my own certificate with the one issued by the certificate > provider I used the following two commands: > > openssl pkcs12 -in certificate.p12 -noout -info > openssl x509 -text -noout -in certificate.p12 > > I could not find any significant difference in the output. Though the > one from the certificate provider causes the error when imported with > gpgsm while my own certificate does not. > > Since I am not very knowledgeable when it comes to S/MIME certificates, > it is riddle to me why the error appears: My certificate and the one > from the provider have a salt length of 64bit and that was the only > thing I changed in minip12.c > > So, I have to say that I am sorry, I cannot reproduce the error with a > self-created certificate. > >> Please give me some days to apply the patch. > No hurry, for now I have a personal work around. > > Thank you, > Nils > > Werner Koch writes: > >> On Thu, 19 Sep 2024 13:42, Nils Schween said: >> >>> If it is necessary, I can try to create a certificate with openssl, that >>> reproduces the error. >> Given the brittleness of pkcs#12/minip12.c I would really appricate to >> have a sample file. But the worst thing which could happen is that the >> 64 bit salt does not work anymore in the future. It is unlikey, though. >> >> Please give me some days to apply the patch. >> >> >> Salam-Shalom, >> >> Werner 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 nils.schween at mpi-hd.mpg.de Fri Sep 20 22:33:36 2024 From: nils.schween at mpi-hd.mpg.de (Nils Schween) Date: Fri, 20 Sep 2024 22:33:36 +0200 Subject: Error: Bad length of salt (32) for AES when importing a p12 certificate In-Reply-To: (Jakob Bohm via Gnupg-users's message of "Fri, 20 Sep 2024 17:13:56 +0200") References: <87msk6ukkc.fsf@mpi-hd.mpg.de> <87jzf8rujk.fsf@mpi-hd.mpg.de> <875xqs2dqc.fsf@jacob.g10code.de> <877cb7swd6.fsf@mpi-hd.mpg.de> <87setv23vq.fsf@jacob.g10code.de> <878qvmzlr2.fsf@mpi-hd.mpg.de> Message-ID: <87cykycbfj.fsf@mpi-hd.mpg.de> Thanks for joining the discussion. I changed the value of the salt length to 32. That did not change anything. However, I tried to get some more information. I used gpsm -vv --import for both certificates and a difference appeared: When I am importing the self-created certificate the import process is skipping shrouded_key_bag.attribute_set when reaching the private key. Here the output: gpgsm: enabled compatibility flags: gpgsm: processing bag.encryptedData gpgsm: 1536 bytes of AES256 encrypted text gpgsm: processing certBag gpgsm: certificate already in DB gpgsm: skipping bag.attribute_set gpgsm: processing bag data gpgsm: processing shrouded_key_bag gpgsm: 2384 bytes of AES256 encrypted text gpgsm: skipping shrouded_key_bag.attribute_set Whereas the import of the (non-distributable) certificate yields gpgsm: bad length of salt (32) for AES gpgsm: parse_shrouded_key_bag(shrouded_key_bag.pkcs5PBES2-params): lvl=16 (tlv_expect_octet_string): Erfolg - Ung?ltige L?nge gpgsm: parse_bag_data(data.oid): lvl=16 (tlv_expect_octet_string): Erfolg - Ung?ltige L?nge gpgsm: p12_parse(bag.data): @6724 lvl=16 tlv_expect_octet_string: Erfolg - Ung?ltige L?nge gpgsm: error parsing or decrypting the PKCS#12 file The import is not skipping shrouded_key_bag.attribute_set. That the error goes away when I change the salt array length in parse_shrouded_key_bag, makes from sense from this perspective. Unfortunately, I do not know how I can change my self-created certificate such that the gpgsm --import command does not skip the shrouded_key_bag attribute when importing the private key. Do you have any idea what options I need to set when creating the key or the p12 file to set the shrouded_key_bag attribute? Thank you. Nils Jakob Bohm via Gnupg-users writes: > Dear Nils, > > Given the error message in the subject line above, the step to reproduce may be > to pass 32 instead of 64 to the openssl command that makes the test certificate. > > Otherwise, look for a command that can dump out the formatting details of the > (non-distributable) problematic pkcs12 file to see what values it actually uses. > > On 2024-09-20 12:02, Nils Schween wrote: >>> Given the brittleness of pkcs#12/minip12.c I would really appricate to >>> have a sample file. But the worst thing which could happen is that the >>> 64 bit salt does not work anymore in the future. It is unlikey, though. >> I do understand. I tried to create one this morning, but I was not able >> to reproduce the error when importing my self created certificate. >> >> I used the following commands to create the certificate: >> >> openssl req -newkey rsa:4096 -nodes -keyout key.pem -x509 -sha384 -days 365 -out certificate.pem >> >> openssl pkcs12 -inkey key.pem -in certificate.pem -export -macsaltlen 64 -iter 20000 -out certificate.p12 >> >> To compare my own certificate with the one issued by the certificate >> provider I used the following two commands: >> >> openssl pkcs12 -in certificate.p12 -noout -info >> openssl x509 -text -noout -in certificate.p12 >> >> I could not find any significant difference in the output. Though the >> one from the certificate provider causes the error when imported with >> gpgsm while my own certificate does not. >> >> Since I am not very knowledgeable when it comes to S/MIME certificates, >> it is riddle to me why the error appears: My certificate and the one >> from the provider have a salt length of 64bit and that was the only >> thing I changed in minip12.c >> >> So, I have to say that I am sorry, I cannot reproduce the error with a >> self-created certificate. >> >>> Please give me some days to apply the patch. >> No hurry, for now I have a personal work around. >> >> Thank you, >> Nils >> >> Werner Koch writes: >> >>> On Thu, 19 Sep 2024 13:42, Nils Schween said: >>> >>>> If it is necessary, I can try to create a certificate with openssl, that >>>> reproduces the error. >>> Given the brittleness of pkcs#12/minip12.c I would really appricate to >>> have a sample file. But the worst thing which could happen is that the >>> 64 bit salt does not work anymore in the future. It is unlikey, though. >>> >>> Please give me some days to apply the patch. >>> >>> >>> Salam-Shalom, >>> >>> Werner > > Enjoy > > Jakob -- Nils Schween PhD Student Phone: +49 6221 516 557 Mail: nils.schween at mpi-hd.mpg.de PGP-Key: 4DD3DCC0532EE96DB0C1F8B5368DBFA14CB81849 Max Planck Institute for Nuclear Physics Astrophysical Plasma Theory (APT) Saupfercheckweg 1, D-69117 Heidelberg https://www.mpi-hd.mpg.de/mpi/en/research/scientific-divisions-and-groups/independent-research-groups/apt From nils.schween at mpi-hd.mpg.de Sat Sep 21 14:50:33 2024 From: nils.schween at mpi-hd.mpg.de (Nils Schween) Date: Sat, 21 Sep 2024 14:50:33 +0200 Subject: Error: Bad length of salt (32) for AES when importing a p12 certificate In-Reply-To: <87cykycbfj.fsf@mpi-hd.mpg.de> (Nils Schween's message of "Fri, 20 Sep 2024 22:33:36 +0200") References: <87msk6ukkc.fsf@mpi-hd.mpg.de> <87jzf8rujk.fsf@mpi-hd.mpg.de> <875xqs2dqc.fsf@jacob.g10code.de> <877cb7swd6.fsf@mpi-hd.mpg.de> <87setv23vq.fsf@jacob.g10code.de> <878qvmzlr2.fsf@mpi-hd.mpg.de> <87cykycbfj.fsf@mpi-hd.mpg.de> Message-ID: <87bk0hjhly.fsf@mpi-hd.mpg.de> I just did some more tests. I noticed that if I export the private key and the certificates contained in the (non-distributable) p12 file with the following commands openssl pkcs12 -nokeys -in client.p12 > certs.pem openssl pkcs12 -nocerts -in client.p12 > keys.pem and then create an new p12 file with openssl pkcs12 -in certs.pem -inkey keys.pem -export -out client_new.p12 I can import it without any issues using gpgsm --import To investigate what the difference between the newly created p12 file and the old one is I diffed the output of openssl pkcs12 -in old.p12 -nodes -info and openssl pkcs12 -in new.p12 -nodes -info The result is the following 47c47 < Bag Attributes: --- > Bag Attributes: 89c89 < Bag Attributes: --- > Bag Attributes: 124c124 < Bag Attributes: --- > Bag Attributes: This means that in the old p12 file the string "Empty Attributes" is used to indicate that there are no attributes, whereas in the newly created p12 file they use "No Attributes" I do not know how gpgsm checks if there are additional attributes. May this observation also hints into the direction of the error. Regards, Nils Nils Schween writes: > Thanks for joining the discussion. I changed the value of the salt length > to 32. That did not change anything. However, I tried to get some more > information. I used gpsm -vv --import for both certificates and a > difference appeared: > > When I am importing the self-created certificate the import process is > skipping shrouded_key_bag.attribute_set when reaching the private key. > Here the output: > > gpgsm: enabled compatibility flags: > gpgsm: processing bag.encryptedData > gpgsm: 1536 bytes of AES256 encrypted text > gpgsm: processing certBag > gpgsm: certificate already in DB > gpgsm: skipping bag.attribute_set > gpgsm: processing bag data > gpgsm: processing shrouded_key_bag > gpgsm: 2384 bytes of AES256 encrypted text > gpgsm: skipping shrouded_key_bag.attribute_set > > Whereas the import of the (non-distributable) certificate yields > > gpgsm: bad length of salt (32) for AES > gpgsm: parse_shrouded_key_bag(shrouded_key_bag.pkcs5PBES2-params): lvl=16 (tlv_expect_octet_string): Erfolg - Ung?ltige L?nge > gpgsm: parse_bag_data(data.oid): lvl=16 (tlv_expect_octet_string): Erfolg - Ung?ltige L?nge > gpgsm: p12_parse(bag.data): @6724 lvl=16 tlv_expect_octet_string: Erfolg - Ung?ltige L?nge > gpgsm: error parsing or decrypting the PKCS#12 file > > The import is not skipping shrouded_key_bag.attribute_set. > > That the error goes away when I change the salt array length in > parse_shrouded_key_bag, makes from sense from this perspective. > > Unfortunately, I do not know how I can change my self-created certificate > such that the gpgsm --import command does not skip the shrouded_key_bag > attribute when importing the private key. Do you have any idea what > options I need to set when creating the key or the p12 file to set the > shrouded_key_bag attribute? > > Thank you. > Nils > > Jakob Bohm via Gnupg-users writes: > >> Dear Nils, >> >> Given the error message in the subject line above, the step to reproduce may be >> to pass 32 instead of 64 to the openssl command that makes the test certificate. >> >> Otherwise, look for a command that can dump out the formatting details of the >> (non-distributable) problematic pkcs12 file to see what values it actually uses. >> >> On 2024-09-20 12:02, Nils Schween wrote: >>>> Given the brittleness of pkcs#12/minip12.c I would really appricate to >>>> have a sample file. But the worst thing which could happen is that the >>>> 64 bit salt does not work anymore in the future. It is unlikey, though. >>> I do understand. I tried to create one this morning, but I was not able >>> to reproduce the error when importing my self created certificate. >>> >>> I used the following commands to create the certificate: >>> >>> openssl req -newkey rsa:4096 -nodes -keyout key.pem -x509 -sha384 -days 365 -out certificate.pem >>> >>> openssl pkcs12 -inkey key.pem -in certificate.pem -export -macsaltlen 64 -iter 20000 -out certificate.p12 >>> >>> To compare my own certificate with the one issued by the certificate >>> provider I used the following two commands: >>> >>> openssl pkcs12 -in certificate.p12 -noout -info >>> openssl x509 -text -noout -in certificate.p12 >>> >>> I could not find any significant difference in the output. Though the >>> one from the certificate provider causes the error when imported with >>> gpgsm while my own certificate does not. >>> >>> Since I am not very knowledgeable when it comes to S/MIME certificates, >>> it is riddle to me why the error appears: My certificate and the one >>> from the provider have a salt length of 64bit and that was the only >>> thing I changed in minip12.c >>> >>> So, I have to say that I am sorry, I cannot reproduce the error with a >>> self-created certificate. >>> >>>> Please give me some days to apply the patch. >>> No hurry, for now I have a personal work around. >>> >>> Thank you, >>> Nils >>> >>> Werner Koch writes: >>> >>>> On Thu, 19 Sep 2024 13:42, Nils Schween said: >>>> >>>>> If it is necessary, I can try to create a certificate with openssl, that >>>>> reproduces the error. >>>> Given the brittleness of pkcs#12/minip12.c I would really appricate to >>>> have a sample file. But the worst thing which could happen is that the >>>> 64 bit salt does not work anymore in the future. It is unlikey, though. >>>> >>>> Please give me some days to apply the patch. >>>> >>>> >>>> Salam-Shalom, >>>> >>>> Werner >> >> Enjoy >> >> Jakob -- Nils Schween PhD Student Phone: +49 6221 516 557 Mail: nils.schween at mpi-hd.mpg.de PGP-Key: 4DD3DCC0532EE96DB0C1F8B5368DBFA14CB81849 Max Planck Institute for Nuclear Physics Astrophysical Plasma Theory (APT) Saupfercheckweg 1, D-69117 Heidelberg https://www.mpi-hd.mpg.de/mpi/en/research/scientific-divisions-and-groups/independent-research-groups/apt -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5989 bytes Desc: not available URL: From mm at dorfdsl.de Sun Sep 22 08:52:05 2024 From: mm at dorfdsl.de (Marco Moock) Date: Sun, 22 Sep 2024 08:52:05 +0200 Subject: website charset encoding for manual Message-ID: <20240922085205.43f172b6@ryz.dorfdsl.de> Hello! https://gnupg.org/gph/de/manual/f20.html#AEN33 doesn't seem to have any charset encoding information. If the charset in the browser isn't set to "western", it won't display many special characters like "?" properly. In the HTTP inspector I also can't find any encoding info. Content-Type:"text/html" -- kind regards Marco From ciohb at outlook.com Mon Sep 23 07:14:54 2024 From: ciohb at outlook.com (ciohb) Date: Mon, 23 Sep 2024 13:14:54 +0800 Subject: bugtracker account In-Reply-To: References: Message-ID: Hi(????)?? I'd like an account on dev.gnupg.org please. * Handle : Dallying5371 * Display name: Dallying * Email:ciohb at outlook.com Thanks, ? ciohb -------------- next part -------------- An HTML attachment was scrubbed... URL: From phill at thesusis.net Wed Sep 25 23:17:16 2024 From: phill at thesusis.net (Phillip Susi) Date: Wed, 25 Sep 2024 17:17:16 -0400 Subject: Upgrade woes Message-ID: <87v7yjl9gj.fsf@vps.thesusis.net> So I upgraded to the new release of Debian a while back. I just realized I forgot to migrate my gpg keys to the new system. Old one was running 2.2.27, and now I am running 2.2.40. I tried copying the .gnupg directory to the new system, but gpg -k wouldn't show any keys. I seem to remember the last time I upgraded, I had to export and import the keys to get them to be recognized. I chrooted into the old system and tried to export the keys, but it just keeps commplaining: error receiving key from agent, permission denied. Is there a way to get it to stop using this dang agent stuff and just prompt me for the password normally like it used to? From wk at gnupg.org Thu Sep 26 15:50:12 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 26 Sep 2024 15:50:12 +0200 Subject: Upgrade woes In-Reply-To: <87v7yjl9gj.fsf@vps.thesusis.net> (Phillip Susi's message of "Wed, 25 Sep 2024 17:17:16 -0400") References: <87v7yjl9gj.fsf@vps.thesusis.net> Message-ID: <87r096wmln.fsf@jacob.g10code.de> Hi! On Wed, 25 Sep 2024 17:17, Phillip Susi said: > realized I forgot to migrate my gpg keys to the new system. Old one was > running 2.2.27, and now I am running 2.2.40. I tried copying the .gnupg There is no difference in the architecture between 2.2.27 and 2.2.40. However, Debian has a lot of intrusive patches on top of GnuPG and thus you can't compare a stock GnuPG with what Debian delivers. If you copy ~/.gnupg make sure to copy also subdirectories and hidden files (cp -a). You also need to stop any running agent but gpg will show you a warning if you forget this. > I chrooted into the old system and tried to export the keys, but it just > keeps commplaining: error receiving key from agent, permission denied. That are the private keys which you might have not copied (~/.gnupg/private-keys-v1.d) > Is there a way to get it to stop using this dang agent stuff and just > prompt me for the password normally like it used to? No. We use the agent for more than 20 years and you used it with 2.2.27 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: 247 bytes Desc: not available URL: From phill at thesusis.net Fri Sep 27 15:23:11 2024 From: phill at thesusis.net (Phillip Susi) Date: Fri, 27 Sep 2024 09:23:11 -0400 Subject: Upgrade woes In-Reply-To: <87r096wmln.fsf@jacob.g10code.de> References: <87v7yjl9gj.fsf@vps.thesusis.net> <87r096wmln.fsf@jacob.g10code.de> Message-ID: <87bk098c3k.fsf@vps.thesusis.net> Werner Koch writes: > If you copy ~/.gnupg make sure to copy also subdirectories and hidden > files (cp -a). You also need to stop any running agent but gpg will > show you a warning if you forget this. I used midnight commander to copy. I think it included everything and was set to preserve attributes. I'll try again with cp -a. >> I chrooted into the old system and tried to export the keys, but it just >> keeps commplaining: error receiving key from agent, permission denied. > > That are the private keys which you might have not copied > (~/.gnupg/private-keys-v1.d) What copy? I said I chrooted into the original system. >> Is there a way to get it to stop using this dang agent stuff and just >> prompt me for the password normally like it used to? > > No. We use the agent for more than 20 years and you used it with > 2.2.27 too. Then how do you convince the agent to work in a chroot? At first it just keep saying inappropriate ioctl for the device. I tried bind mounting /sys, /proc, /dev, and /dev/pts into the chroot and it changed to the permission denied error without any prompting for my password. From buo.ren.lin at gmail.com Sat Sep 28 20:48:45 2024 From: buo.ren.lin at gmail.com (=?UTF-8?B?5p6X5Y2a5LuBQnVvLXJlbiBMaW4=?=) Date: Sun, 29 Sep 2024 02:48:45 +0800 Subject: Concerns regarding T3065 dirmngr: proxy issues with dnslookup causing failure Message-ID: Hello list, I want to express my concerns over the following closed ticket: ? T3065 dirmngr: proxy issues with dnslookup causing failure https://dev.gnupg.org/T3065 I can reproduce the same issue: dirmngr is unable to function properly if the DNS resolution is not working on the host system but has an otherwise functioning HTTP proxy configuration. The Internet access worked for most of the applications on the system(as they delegate the task of DNS resolution to the proxy service) except for GnuPG and a very few others. Here are the dirmngr log entries that were generated when I ran the following command in a terminal: ``` gpg2 --keyserver hkps://keyserver.ubuntu.com --keyserver-options "timeout=40 http-proxy=$http_proxy" --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 ``` ``` Sep 29 02:41:15 brlin-fw13 dirmngr[182307]: resolve_dns_addr for 'keyserver.ubuntu.com': '[2620:2d:4000:1007::d43]' Sep 29 02:41:15 brlin-fw13 dirmngr[182307]: resolve_dns_addr for 'keyserver.ubuntu.com': '[2620:2d:4000:1007::70c]' Sep 29 02:41:15 brlin-fw13 dirmngr[182307]: resolve_dns_addr for 'keyserver.ubuntu.com': '185.125.188.27' Sep 29 02:41:15 brlin-fw13 dirmngr[182307]: resolve_dns_addr for 'keyserver.ubuntu.com': '185.125.188.26' Sep 29 02:41:15 brlin-fw13 dirmngr[182307]: number of system provided CAs: 146 Sep 29 02:41:15 brlin-fw13 dirmngr[182307]: can't connect to '192.168.49.1': no IP address for host Sep 29 02:41:15 brlin-fw13 dirmngr[182307]: error connecting to 'https://[2620:2d:4000:1007::d43]:443': Unknown host Sep 29 02:41:15 brlin-fw13 dirmngr[182307]: marking host '[2620:2d:4000:1007::d43]' as dead Sep 29 02:41:15 brlin-fw13 dirmngr[182307]: can't connect to '192.168.49.1': no IP address for host Sep 29 02:41:15 brlin-fw13 dirmngr[182307]: error connecting to 'https://[2620:2d:4000:1007::70c]:443': Unknown host Sep 29 02:41:15 brlin-fw13 dirmngr[182307]: marking host '[2620:2d:4000:1007::70c]' as dead Sep 29 02:41:16 brlin-fw13 dirmngr[182307]: TLS handshake failed: The TLS connection was non-properly terminated. Sep 29 02:41:16 brlin-fw13 dirmngr[182307]: error connecting to 'https://185.125.188.27:443': Network error Sep 29 02:41:16 brlin-fw13 dirmngr[182307]: marking host '185.125.188.27' as dead Sep 29 02:41:16 brlin-fw13 dirmngr[182307]: TLS handshake failed: The TLS connection was non-properly terminated. Sep 29 02:41:16 brlin-fw13 dirmngr[182307]: error connecting to 'https://185.125.188.26:443': Network error Sep 29 02:41:16 brlin-fw13 dirmngr[182307]: marking host '185.125.188.26' as dead Sep 29 02:41:16 brlin-fw13 dirmngr[182307]: command 'KS_GET' failed: Network error ``` According to werner's comment in the thread: > If you specify a pool of keyservers dirmngr selects a keyserver on its own from the pool. This is so that it can use its own heuristics to detect whether a keyserver is dead and then retry another one. Now the default is a pool and your specified keyserver.ubuntu.com is also a pool (of two servers). So if your DNS resolver does not tell us the IP addresses, we can't do anything about it. IMHO as the actual DNS resolution may not be available in a networking environment that provides internet access over an HTTP proxy service, dirmngr should: * Treat the requested keyserver as the single server in the pool and avoid checking the availability. * Access the keyserver by name instead of IP address, and delegate the name resolution task to the configured proxy service. * Avoid resolving the host address of the proxy service itself if the supplied proxy address is an IP address. Thanks for your time and attention, ???(Buo-ren Lin) buo.ren.lin at gmail.com Note: Please CC me when replying as I only subscribed the list in digest mode, thank you.