From rjh at sixdemonbag.org Fri May 1 03:04:54 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 30 Apr 2026 21:04:54 -0400 Subject: quantum computing and symmetric algotithms In-Reply-To: References: Message-ID: <2ff66836-8d9a-4336-b52d-5c4d23b298fe@sixdemonbag.org> > It would be useful in discussions on quantum computing and > cryptography not to miss that vulnerability (if and to the extent it > exists) only pertains to the asymmetric algorithms. As far as we > know, no modern symmetric block cipher is affected. True, with 3DES as a possible exception. There's a meet in the middle attack that means with truly ludicrous amounts of hardware it could be reduced to complexity 2**112, which is ... not practical for Grover's algorithm for many reasons, but is definitely not as wildly impractical as I'd like. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From rca at disroot.org Sat May 2 23:05:48 2026 From: rca at disroot.org (rca) Date: Sat, 2 May 2026 18:05:48 -0300 Subject: Bikeshedding while the world burns In-Reply-To: <166dd3b5-64d1-4f9d-a4dc-eced780bd512@sixdemonbag.org> References: <166dd3b5-64d1-4f9d-a4dc-eced780bd512@sixdemonbag.org> Message-ID: <0bda6225-bfe4-4642-b5d8-30b7c5443a85@disroot.org> I convinced some of my co-workers to use GPG, we have been using it to secure some emails/Whatsapp messages, but your email got me thinking about keyloggers. Are there some security recommendations to stay safe from it? Ricardo On 4/28/26 00:37, Robert J. Hansen via Gnupg-users wrote: > 1. INTRODUCTION > > Around 1997, Sun Microsystems hauled Microsoft in court over the Java > virtual machine (JVM) Microsoft was shipping with new versions of > Windows. Microsoft had entered an agreement with Sun to ship a JVM that > fully complied with Sun's compatibility tests, but they failed to honor > this promise. They insisted they were doing the right thing for their > users, which may have well been true -- but "best for our users" was not > the same as "best for Java users". > > I'm told that after Microsoft lost this lawsuit they decided to embrace > C# and the Common Language Runtime as sort of a "Java that we control." > Java and C# started off as very similar languages but drifted apart over > time; likewise with their virtual machines. > > I am afraid GnuPG is soon going to be a retelling of this story. > > I downloaded GnuPG 1.0 the day it was released. I was at the time > writing an RFC1991 ("ClassicPGP") implementation for a now-defunct > telecom that had very strange ideas about why PGP 2.6 exposed them to > legal liability, and I wanted to see how GnuPG implemented some packet > parsing magic. At that time GnuPG's mission statement was crystal clear: > to provide a libre command-line implementation of the RFC2440 standard. > > For a quarter-century GnuPG has been the gold standard of OpenPGP > implementations and 100% libre software. This is an amazing achievement, > and I think Werner deserves immense accolades for his persistence and > determination in achieving this vision. > > But I think we're heading down the wrong road by turning away from the RFC. > > 2. THE COLD TRUTH > > You could replace RFC9580 with RFC1991 from thirty years ago and still > be sufficient for many users. > > Seriously. Most users don't need 30-year security, they need 10-year > security at the outside, for secrets that are relatively low value > (under $1 million). RSA-1024 still looks solid for that time window. It > might be possible to break an RSA-1024 key today, but not for a million > dollars. > > A lot of users don't care very much about signatures, either. They care > a lot about the confidentiality of their email: the authenticity takes a > back seat. MD5 matters a lot less. > > RFC1991 used a single key for authentication and encryption. This meant > trouble if a user was ever compelled by a court to reveal their > decryption key. That was a major motivator of RFC2440, and yet it turns > out compelled turnover of an asymmetric encryption key is incredibly > rare: it happens so infrequently it might as well not happen. > > Over the last thirty years the IETF working group leading RFC design has > invented an ever-more-impregnable bank vault door, even as the building > that bank vault is installed in (operating systems and environments) > have become ever shoddier. > > In my mind, the LibrePGP versus OpenPGP technical arguments are about as > interesting to me as arguing whether a meter-thick tempered steel vault > door that laughs in the face of explosives, diamond-tipped drill bits, > and antitank rockets is secure enough, or whether we need to also have a > Belgian malinois watching things. > > Please don't think, "oh, Rob doesn't understand the specifications, > that's why he's saying these differences don't matter". I _do_ > understand the specifications. I don't influence the specs. I never said > I didn't read them or have opinions on them. > > Here's the truth: I love Belgian malinois. After German shepherds > they're my favorite breed. They're a little too energetic and high- > strung for me to ever own one, but I adore them. I also don't care if my > vault door is guarded by one. > > 3. THE REAL RISK > > The real risk today is endpoint compromise. It's cheap, it's easy, it's > fun. > > Many years ago a divorce attorney came to me with a problem: his client > was divorcing her husband. They lived in separate apartments since the > divorce petition was filed. She had reason to believe he was lying about > his assets but had no way to check on his bank accounts without his > knowledge. Was there any way I could help? > > After confirming they lived in a marital joint property state (where, > until the time a divorce is finalized, all property in the marriage is > owned by both), I agreed to do the job. The woman wrote a letter > authorizing me to enter her husband's apartment to look for financial > records, and I filed this with my attorney. > > I showed up at his apartment after he left for work, picked the lock, > walked into his office and started taking photographs so I could leave > the place in the exact same state as when I left. I made a forensic > image of his hard drive, connected a keylogger, and left. I returned the > next day to pick up the keylogger. > > All of his online security measures -- only using HTTPS through a VPN, > using Bitlocker, not using a password manager, etcetera -- vanished in > about a day the moment a semi-skilled attacker decided to go after the > endpoint. Even Bitlocker fails when the enemy has a forensic image of > your hard drive and, thanks to a keylogger, your BitLocker password. > > Had he shared his apartment with a Belgian malinois, I would have been > deterred. But neither a cryptographic vault door nor a cryptographic > Belgian malinois proved any obstacle whatsoever. > > 4. MORE ON ENDPOINTS > > Physical endpoint compromise, like what I describe above, is the > ultimate game over condition. Network endpoint compromise is almost as bad. > > The network landscape in 2026 is not what it was in 1996. There is no > longer any meaningful concept of a secure network perimeter. In the > cyberwarfare trade the Internet of Things is instead called the > "Internet of Targets". > > Here in Washington D.C., it's widely believed the Chinese government, > through a cyberwarfare program called SALT TYPHOON, has at-will access > to any smartphone it wants in the metropolitan area. (This may be > revenge of a kind: Edward Snowden revealed to them the NSA had at-will > access to any text message in Hong Kong.) > > My apartment building has decided my front door should no longer have a > physical key, but instead be locked and unlocked from my smartphone. My > bank encourages me to do all my banking via an app. Local hotels do the > same thing. > > The endpoints are already compromised, and we're ... > > ... arguing about whether we need a Belgian malinois _and_ a meter-thick > tempered steel vault door?! > > 5. C# AND JAVA, REDUX > > When Microsoft was told the Java spec was what it was and wouldn't be > changed to accommodate them and their users' needs, Microsoft made a > wise call. They walked away and made a clean break. Over time C# has > become its own thing and a vastly different ecosystem compared to Java. > > I would very much like GnuPG to decide either to: > > ????(a) implement RFC9580 in GnuPG, even if it's not enabled > ??????? by default > ????(b) make a clean break from RFC9580 and go on to solve a > ??????? similar-but-different set of problems a similar-but- > ??????? different way > > I don't care which is done but I really think we need to do one or the > other. > > This community is suffering, *badly*, because people are arguing over > the presence of a Belgian malinois. We should stop the bleeding, even if > the tourniquet hurts. > > 6. AM I LEAVING THE COMMUNITY? > > Of course not. That would be silly. I love this community too much for > that. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users From rjh at sixdemonbag.org Sun May 3 09:36:34 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 3 May 2026 03:36:34 -0400 Subject: Bikeshedding while the world burns In-Reply-To: <0bda6225-bfe4-4642-b5d8-30b7c5443a85@disroot.org> References: <166dd3b5-64d1-4f9d-a4dc-eced780bd512@sixdemonbag.org> <0bda6225-bfe4-4642-b5d8-30b7c5443a85@disroot.org> Message-ID: > I convinced some of my co-workers to use GPG, we have been using it to > secure some emails/Whatsapp messages, but your email got me thinking > about keyloggers. Are there some security recommendations to stay safe > from it? Control all physical access to the machine. That's the only reliable method to prevent physical keyloggers. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From mm at dorfdsl.de Sun May 3 10:28:56 2026 From: mm at dorfdsl.de (Marco Moock) Date: Sun, 3 May 2026 10:28:56 +0200 Subject: Bikeshedding while the world burns In-Reply-To: <0bda6225-bfe4-4642-b5d8-30b7c5443a85@disroot.org> References: <166dd3b5-64d1-4f9d-a4dc-eced780bd512@sixdemonbag.org> <0bda6225-bfe4-4642-b5d8-30b7c5443a85@disroot.org> Message-ID: <6e69b172-283d-499c-b61b-5f0a03b363e8@dorfdsl.de> Am 02.05.26 um 23:05 schrieb rca via Gnupg-users: > I convinced some of my co-workers to use GPG, we have been using it to > secure some emails/Whatsapp messages, but your email got me thinking > about keyloggers. Are there some security recommendations to stay safe > from it? If you have a software keylogger, you need to know the source of it. Check from where you install software and reduce the sources to the lowest as possible. Avoid proprietary software and support groups who do code reviews to make backdoors less easy. There is still the risk that someone in the supply chain places malware inside, see the ssh/liblzma issue. -- Gru? Marco Junk-Mail bitte an trashcan at stinkedores.dorfdsl.de From andrewg at andrewg.com Sun May 3 14:17:24 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 3 May 2026 13:17:24 +0100 Subject: No v5 support in hockeypuck (Was: Undocumented novel Ed448 point encoding breaks interoperability) In-Reply-To: <4e12f3b7-3a6c-41b8-8f8d-83a89db9da63@andrewg.com> References: <4e12f3b7-3a6c-41b8-8f8d-83a89db9da63@andrewg.com> Message-ID: Hi, all. In reply to my previous email to gnupg-devel [0], but cross-posting for maximum audience: On 05/01/2026 13:55, Andrew Gallagher via Gnupg-devel wrote: > It has been brought to my attention that Ed448 keys are being encoded > without prefix octets in their MPIs/SOSes, which breaks compatibility > with go-crypto (and perhaps others) and is not documented anywhere that > I can find. The librepgp specification requires prefix octets for all > ECC curve point representations. After (finally!) enabling support for v5 keys in hockeypuck, I have discovered that ECDH curve448 encryption subkeys have the same curve point encoding issue as Ed448 signing (sub)keys. protonmail/go-crypto, the OpenPGP library that hockeypuck relies on, implemented v5 support according to the latest rfc4880bis [1] draft, which consistently specifies prefix octets of 0x04 or 0x40 for all ECC point curves, whether ECDSA, ECDH, or EdDSA. (protonmail/go-crypto was an early adopter of the rfc4880bis draft, and as such it is the only library available to hockeypuck that provides production v5 support of any kind; most of the alternatives never officially released v5 support) The change in the Ed448 point encoding since rfc4880bis, as mentioned in my previous email, has been (belatedly) acknowledged in the most recent version of draft-librepgp [2]. The discrepancy in the ECDH point encoding still has not. As a result, it is not now possible for hockeypuck to process *any* v5 key material that GnuPG generates, even if we include support for the v5 packet format as planned, since v5 is only generated in practice for x448 and type 8 kyber algorithms, neither of which are parseable. Note also that x448 key generation is gated behind expert mode in gnupg and type 8 "kyber" keys are not. This means that only a small fraction of the wild population of v5 keys would be fully usable even if this encoding discrepancy was addressed. Type 8 will not be implemented in pm/gc as the library is prioritising support for the upcoming standard draft-ietf-openpgp-pqc [3] and draft-ietf-openpgp-nist-bp-comp [4] PQC keys instead. At this point, even though it would be easy for me to claim a theoretical "v5 support" in hockeypuck 2.4, it would be a cruel and misleading prank on our users because none of them would be able to upload a real v5 key to any of the keyservers. Even if we were to patch in a hotfix for prefix-less code points (which would not be prohibitively difficult) it would still only serve a small number of expert users, and expert users are much more likely to prefer PQC encryption. So I am (as of today) dropping v5 support as a design goal of hockeypuck, and pausing work on it indefinitely. If and when a meaningful fraction of GnuPG-compatible algorithm code points are added to pm/gc, or if GnuPG added support for interoperable PQC algorithms [3][4], I would happily reconsider. I'm sorry that it has taken me three years to come to this conclusion. I could (in theory) have spotted this incompatibility earlier and saved users the false hope that v5 and v6 keys could coexist on the keyservers in the current state of the ecosystem. Thanks once again to Liz Fong-Jones for finding this issue and bringing it to my attention. A [0] https://lists.gnupg.org/pipermail/gnupg-devel/2026-January/036128.html [1] https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-rfc4880bis#name-ecdsa-and-ecdh-conversion-p [2] https://author-tools.ietf.org/iddiff?url1=draft-koch-librepgp-04&url2=draft-koch-librepgp-05&difftype=--html#part-10 [3] https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc [4] https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-nist-bp-comp PS here's a hexdump of a v5 curve448 ECDH subkey that I generated this morning using gnupg 2.5.18 from macports, showing that there is no 0x40 or 0x04 octet present. The prefix octet would be expected at byte 0x12, immediately following the x448 curve OID 0x2b656f and the MPI length 0x01be. (It's an MPI length BTW, not an SOS length - SOS lengths are rounded up to the nearest multiple of 8) ``` 00000000 b8 CTB 00000001 4c length 00000002 05 version 00000003 69 f7 0a 31 12 00 00 00 42 03 2b 65 6f 00000010 01 be 37 69 62 e9 a7 a7 81 c5 7b c5 c7 5d da f6 00000020 d2 aa 26 e1 7e fc 35 ce 3c 11 d9 50 b9 c9 71 84 00000030 5d 61 60 84 93 af 60 fa db 59 aa 15 68 b4 3f 65 00000040 cd 1d fc 3d d6 34 c3 64 1a 49 03 01 0a 09 ``` From jb-gnumlists at wisemo.com Mon May 4 20:04:51 2026 From: jb-gnumlists at wisemo.com (Jakob Bohm) Date: Mon, 4 May 2026 20:04:51 +0200 Subject: quantum computing and symmetric algotithms In-Reply-To: References: Message-ID: <2ab7be36-d83b-aba4-3563-027144abbf7f@wisemo.com> On 30/04/2026 16:47, aton6074 at Safe-mail.net wrote: > It would be useful in discussions on quantum computing and cryptography not to miss that vulnerability (if and to the extent it exists) only pertains to the asymmetric algorithms. As far as we know, no modern symmetric block cipher is affected. > I was under the impression that for any generic symmetric cipher, Grover's algorithm would halve the strength in bit, for example a 128 bit key would be as weak against Quantum computers as a current 64 bit key against normal computers. 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 May 4 20:14:52 2026 From: jb-gnumlists at wisemo.com (Jakob Bohm) Date: Mon, 4 May 2026 20:14:52 +0200 Subject: Bikeshedding while the world burns In-Reply-To: <6e69b172-283d-499c-b61b-5f0a03b363e8@dorfdsl.de> References: <166dd3b5-64d1-4f9d-a4dc-eced780bd512@sixdemonbag.org> <0bda6225-bfe4-4642-b5d8-30b7c5443a85@disroot.org> <6e69b172-283d-499c-b61b-5f0a03b363e8@dorfdsl.de> Message-ID: On 03/05/2026 10:28, Marco Moock via Gnupg-users wrote: > Am 02.05.26 um 23:05 schrieb rca via Gnupg-users: >> I convinced some of my co-workers to use GPG, we have been using it >> to secure some emails/Whatsapp messages, but your email got me >> thinking about keyloggers. Are there some security recommendations to >> stay safe from it? > > If you have a software keylogger, you need to know the source of it. > Check from where you install software and reduce the sources to the > lowest as possible. Avoid proprietary software and support groups who > do code reviews to make backdoors less easy. > > There is still the risk that someone in the supply chain places > malware inside, see the ssh/liblzma issue. > However for the hardware keyloggers that can be plugged into relevant cables (such as keyboard cables), physical security is the only known defence, as only the bad ones cause readily identifiable signal interference that might be detectable with special defence software. Software keyboards avoid wiretaps on hardware keyboards but are wide open to software attacks and weaknesses, plus the risk of remote screen monitoring to observer key entry. The FIPS-140 solution is to have a dedicated keyboard for key entry, wired directly to the hardware component that processes the key, for example some smart card readers with keypads only provide the pin code digits to the secure chip in the smartcard, not to the attached computer, and Microsoft operating systems refuse to support those readers by insisting that the pin code is provided as standard keystrokes to the Windows pincode entry user interface. 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 rjh at sixdemonbag.org Tue May 5 00:31:18 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 4 May 2026 18:31:18 -0400 Subject: quantum computing and symmetric algotithms In-Reply-To: <2ab7be36-d83b-aba4-3563-027144abbf7f@wisemo.com> References: <2ab7be36-d83b-aba4-3563-027144abbf7f@wisemo.com> Message-ID: > I was under the impression that for any generic symmetric cipher, Grover's > algorithm would halve the strength in bit, for example a 128 bit key would > be as weak against Quantum computers as a current 64 bit key > against normal computers. This is only approximately true. It's more of a rule of thumb than a final answer. AES-128 is currently believed safe against Grover's. See the conclusion (section 6) in this excellent paper: https://csrc.nist.gov/csrc/media/Events/2024/fifth-pqc-standardization-conference/documents/papers/on-practical-cost-of-grover.pdf From bernhard at intevation.de Tue May 5 17:55:34 2026 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 5 May 2026 17:55:34 +0200 Subject: Discussion style differences between OpenPGP design groups In-Reply-To: References: <202604290937.18253.bernhard@intevation.de> <202604301620.01120.bernhard@intevation.de> Message-ID: <202605051755.45126.bernhard@intevation.de> Am Donnerstag 30 April 2026 19:32:38 schrieb Robert J. Hansen via Gnupg-users: > Werner gets accused of hubris constantly. I think there is some truth > there. I've seen him behave in ways I find unhelpful and > counterproductive. (Werner, as your friend, I'm telling you that Andrew > is trying really really hard to be your friend. Please rethink your > characterization of his criticisms as "bait".) > > But at the same time there is an enormous level of hubris in the WG > demanding that all of these recently-installed vault doors be > reinstalled with this newer vault door which offers *no* practical > capability improvements for 95% of users [..] except for "now, with a > Belgian malinois!". We should notice that, too. Thanks for setting this straight. > > If you accuse me of "endlessly" arguing, I might just stop. > > I didn't read Andrew as accusing you of being dilatory; I read him as > being frustrated with how long this is taking. I share in his > frustration, but I think everyone is talking in good faith. Thanks for the alternative reading, I was't sure of what to understand, however, I wanted to point out that a first step to potental new understanding is to be extra careful to not accuse someone or jump to conclusions too early, not even indirectly. Even if we are frustrated, it does not help at all. We need to leave room for others to reconsider, and even staying on talking terms has some value it, even if it is for a long time without seemingly significant progress. > I would have preferred if LibrePGP had become the new standard. This is > no slam on the WG, which put out a spec I believe is technically > superior to LibrePGP. But the LibrePGP spec is definitely good enough > and is already fielded in large numbers. That LibrePGP is good enough and simpler, is an argument I see. What I think would be helpful is, if people recognised it as a proposed standard that has as much potential and right to exist and call itself a "standard" like RFC9580. (You have given the reasons in your previous email. I won't repeat.) I seriously cannot say if RFC9580 is "technically superior" or not, as I value the deployed code base and simplicity as "technical" in another way. > At the same time, it's not about which one I want to have won. It's > about *where we are now as a community*, and how do we bridge this rift? Yes. > There are genuinely good people in the RFC9580 camp. Our community will > be stronger and better if we can reconcile with them. I agree. > I've already shared my thoughts on how we can do that. I won't rehash > them here. (Can you point me to them again, its okay in personal email.) > > Werner Koch has devoted the major fraction of his professional life > > towards creating a Free Software product for end-to-end > > cryptography. He is the active technical and architectual lead of > > the major and most widely used OpenPGP implementation (seen over 25 > > years). As you have written before, he was right on a number of > > decision he took in those roles. He as a lot of experience. > > > > Yes, I think it is worth a real consideration to give him a veto. > > This is the same logic the FSF has used for decades to justify RMS's > veto power. I think this reasoning leads to bad outcomes (see: RMS). No, this is not what I mean. I said it is worth a real consideration. If Werner would get a veto just for the next common standard together, for instance. That could be an offer that might (or might not, I haven't asked him) give Werner a strong signal that people will try to understand and listen to him seriously again. It could be a symbol to build initial trust to say: we go your tempo. We will try to convince you, in return you give us your time and potential blessing, but you have a safety card. It only works if people really feel this way and have the openess, though. Anyhow it is just one example to use that consideration. To explain: Consensus would mean that several people get a "veto" and that would be equally fair. The challenge I see with RMS' behaviour with some GNU software was different. > I am *not* accusing Werner of being an RMS-like figure. I am saying that > if we want to prevent an RMS-like figure from forming, we need to stop > giving dictators-for-life veto authority over projects. See above, I do not propose "for-life", maybe only for one round for a common standard. There will be a point in the future, where GnuPG, in its current implementation, will get to be less relevant. And hopefully for good. (Which means Werner's and other companies will have a good continuation with Free Software business and users have good end-to-end crypto implementations to chose from.) Motivation is: Outside of the *PGP and end-to-end email circles, we are seen as a unit and we can archieve much more together. Best Regards, Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Tue May 5 18:13:07 2026 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 5 May 2026 18:13:07 +0200 Subject: GnuPG design goals (Re: Bikeshedding while the world burns) In-Reply-To: <87pl3jpl50.fsf@nyarlathotep> References: <166dd3b5-64d1-4f9d-a4dc-eced780bd512@sixdemonbag.org> <87pl3jpl50.fsf@nyarlathotep> Message-ID: <202605051813.13911.bernhard@intevation.de> Am Dienstag 28 April 2026 10:03:07 schrieb jman via Gnupg-users: > I get the feeling that for the users I mention above, > GnuPG is just not a choice > because it is stuck into this "email confidentiality" scenario which has > become much less relevant. I hope for an email renaissance, as email is the working example of a decentral, securable, interoperable, multi-use communication standard. It is much more useful to people as many realize. > I would also would love GnuPG to get up-to-speed with a number of modern > threat scenarios and use cases that currently are solved (good or bad I > can't say) by Signal or Threema or . > > I don't know if GnuPG is, by design, a tool oriented to other use cases. GnuPG (as I understand it) is designed for asynchronous communication and a key pair holder can stay anonymous. So GnuPG is not really designed for online use (like with webpages and services, where there is TLS and CMS client certificates) and not for streaming or file systems either (because missing regular throughput or random access). The problem with messengers is that they are more inclined towards online usage and they need a central registry. As example as far as I know, perfect forward secrecy only works if there is an online connection to negociate the keys. To allow a pseudo asynchronous use, the double Double Ratchet Algorithm used in some messengers uses prekeys that have to be generated and uploaded so a server. And I guess you can deplete them. There are GnuPG/OpenPGPv4 based solutions with messenger properties, e.g. https://xmpp.org/extensions/xep-0373.html aka OpenPGP for XMPP (though OMEMO is probably more distributed) https://delta.chat/en Best Regards, Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From andrewg at andrewg.com Wed May 6 10:08:22 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 6 May 2026 09:08:22 +0100 Subject: GnuPG design goals (Re: Bikeshedding while the world burns) In-Reply-To: <202605051813.13911.bernhard@intevation.de> References: <166dd3b5-64d1-4f9d-a4dc-eced780bd512@sixdemonbag.org> <87pl3jpl50.fsf@nyarlathotep> <202605051813.13911.bernhard@intevation.de> Message-ID: <2cfd2036-9865-4c32-9c46-b8e88deb326e@andrewg.com> On 05/05/2026 17:13, Bernhard Reiter via Gnupg-users wrote: > The problem with messengers is that they are more inclined towards online > usage and they need a central registry. As example as far as I know, perfect > forward secrecy only works if there is an online connection to negociate the > keys. To allow a pseudo asynchronous use, the double Double Ratchet Algorithm > used in some messengers uses prekeys that have to be generated and uploaded > so a server. And I guess you can deplete them. Forward secrecy is definitely more challenging in a high-latency environment like email. It's not impossible, but Signal's double ratchet protocol is designed to be tolerant of reasonably long periods of disconnection (in *very* handwavey terms, that's what the second ratchet in "double" ratchet is there for). The Really Hard Problem with double ratchet isn't comms latency, it's group management. But that's also a problem with encrypted email. And the greatest flaw in Signal's architecture is the authoritative keyserver. It is possible to get most of the benefits of forward secrecy without using double ratchet or authoritative servers. That's what DeltaChat [1] is aiming for with Autocrypt2 [2]. (I would strongly recommend that anyone with an interest in PGP pays close attention to what DeltaChat is doing - they are leaving the rest of us in their dust) Thanks, A [1] https://delta.chat [2] https://autocrypt2.org From rjh at sixdemonbag.org Wed May 6 10:44:28 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 6 May 2026 04:44:28 -0400 Subject: GnuPG design goals (Re: Bikeshedding while the world burns) In-Reply-To: <2cfd2036-9865-4c32-9c46-b8e88deb326e@andrewg.com> References: <166dd3b5-64d1-4f9d-a4dc-eced780bd512@sixdemonbag.org> <87pl3jpl50.fsf@nyarlathotep> <202605051813.13911.bernhard@intevation.de> <2cfd2036-9865-4c32-9c46-b8e88deb326e@andrewg.com> Message-ID: > Forward secrecy is definitely more challenging in a high-latency > environment like email. It's not impossible, but Signal's double ratchet > protocol is designed to be tolerant of reasonably long periods of > disconnection (in *very* handwavey terms, that's what the second ratchet > in "double" ratchet is there for). One of the things I'm concerned about, with respect to LibrePGP/OpenPGP direction, is it's easy to lose some of the best use cases of *PGP in pursuit of the New Hotness In Crypto. One of the best use cases is in bootstrapping a secure communications network. From an almost wholly untrusted set of connections, with just a little usage of GnuPG you can bootstrap the maze of technologies we depend upon to communicate safely. It would break my heart -- and endanger people -- if we lost bootstrapping in the pursuit of PFS and other goals. I'd like it if we could make it a point to remember it as a special high-value use case. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Wed May 6 18:03:38 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 6 May 2026 17:03:38 +0100 Subject: GnuPG design goals (Re: Bikeshedding while the world burns) In-Reply-To: References: <166dd3b5-64d1-4f9d-a4dc-eced780bd512@sixdemonbag.org> <87pl3jpl50.fsf@nyarlathotep> <202605051813.13911.bernhard@intevation.de> <2cfd2036-9865-4c32-9c46-b8e88deb326e@andrewg.com> Message-ID: On 06/05/2026 09:44, Robert J. Hansen wrote: > > One of the things I'm concerned about, with respect to LibrePGP/OpenPGP > direction, is it's easy to lose some of the best use cases of *PGP in > pursuit of the New Hotness In Crypto. > > One of the best use cases is in bootstrapping a secure communications > network. From an almost wholly untrusted set of connections, with just a > little usage of GnuPG you can bootstrap the maze of technologies we > depend upon to communicate safely. > > It would break my heart -- and endanger people -- if we lost > bootstrapping in the pursuit of PFS and other goals. I'd like it if we > could make it a point to remember it as a special high-value use case. PGP's greatest strength (and its greatest weakness!) is its flexibility. The building blocks it provides can be used for pretty much anything we want. I wrote up a back-of-a-napkin scheme for how to do full double ratchet in PGP last year. It doesn't need that many changes to the wire format, but it would be quite an undertaking to implement it correctly and safely (so no, I'm not going to build it any time soon). What my scheme and DeltaChat's much simpler one have in common is that they use a standard PGP key for the initial message round trip, but the ephemeral key for subsequent messages. And if the message chain gets broken, you can start again from the initial bootstrap. This gets you a "progressive enhancement" security model that doesn't sacrifice any of PGP's existing security features. I do agree that we shouldn't rush into following any fads. It's important for long term stability and interoperability that all of the tyres are properly kicked before we put anything into production. That does mean that PGP gets a reputation for being behind the times, but that's not necessarily a bad thing - so long as we don't stagnate, or dissolve into chaos... A From loup at loup-vaillant.fr Wed May 6 23:45:27 2026 From: loup at loup-vaillant.fr (Loup Vaillant) Date: Wed, 6 May 2026 23:45:27 +0200 Subject: Post-quantum defaults In-Reply-To: <87lde8w224.fsf@jacob.g10code.de> References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org> <87zf2oyirs.fsf@jacob.g10code.de> <9f0252f7-c907-4f22-a2f8-185f1381ce40@andrewg.com> <87jytsya00.fsf@jacob.g10code.de> <144d13a7-40d7-4266-9801-39c5b2222d61@andrewg.com> <87lde8w224.fsf@jacob.g10code.de> Message-ID: <7e5e36d6-d3d0-4dde-b6ae-e9d353a0791f@loup-vaillant.fr> >> Please, for the love of all that is good and beautiful in the world, >> can we work together to implement algorithm 35 from >> draft-ietf-openpgp-pqc in GnuPG, so that we can at least have one > > If that is code point for Kyber+ECC: The LibrePGP specification for this > has been in deployed in beta versions for a long time and is since > January part of the most widely used *PGP implementation, namely > Gpg4win. I?m a complete outsider here. The only reason I?m subscribed is because I?once had to ask a question, which uncovered a rift that, from the outside, looked thus: an entire community on the one hand (OpenPGP), and on the other hand the 800 pound gorilla (GnuPG). Unlike any other implementation, we can?t ignore what GnuPG outputs by default, and we can?t output anything it cannot decode. Which gives you, Mr Koch, a rather unique ability: bending the world to your will. Using that ability tends to breed resentment though: every time you diverge from the rest of the world, every time they change something *and you don?t*, more people will wish they could break free from GnuPG?s hold. (For full disclosure, I?already do.) And today I learn that on the upcoming post quantum support, there will be *another* divergence between OpenPGP and LibrePGP? Unless you can argue urgency, and everyone believes you, this will breed more resentment. > For signatures I see no immediate need, thus better let the > algorithms settle 2 or 3 years before they get specified in *PGP. Good. Avoiding a third rift sounds reasonable. Loup. From joel.rees at gmail.com Thu May 7 02:51:23 2026 From: joel.rees at gmail.com (Joel Rees) Date: Thu, 7 May 2026 09:51:23 +0900 Subject: Post-quantum defaults In-Reply-To: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org> References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org> Message-ID: >From a crackpot way out in left field, quantum physics is a poor attempt to deal with the statistical nature of all our (pseudo-)fundamental particles. In other words, attempts to produce mathematics to deal with the fact that our fundamental particles are not fundamental after all. (Yeah, including quarks and strings, et. al.) Quantum computing is a statistical technique that tries to take advantage of the structures we can't even see because they are too small (require too much energy to get a grip on with tools we can actually manipulate even indirectly). Quantum computing that actually works will require fundamental changes of nature in our physics, and in us. What we call security won't even be relevant then. That said, our attempts at security need to address statistical methods better. Just a thought from _way_ out in left field. -- Joel Rees http://reiisi.blogspot.jp/p/novels-i-am-writing.html From wk at gnupg.org Thu May 7 11:28:00 2026 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 May 2026 11:28:00 +0200 Subject: PGP and GnuPG specifications (was: Post-quantum defaults) In-Reply-To: <7e5e36d6-d3d0-4dde-b6ae-e9d353a0791f@loup-vaillant.fr> (Loup Vaillant's message of "Wed, 6 May 2026 23:45:27 +0200") References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org> <87zf2oyirs.fsf@jacob.g10code.de> <9f0252f7-c907-4f22-a2f8-185f1381ce40@andrewg.com> <87jytsya00.fsf@jacob.g10code.de> <144d13a7-40d7-4266-9801-39c5b2222d61@andrewg.com> <87lde8w224.fsf@jacob.g10code.de> <7e5e36d6-d3d0-4dde-b6ae-e9d353a0791f@loup-vaillant.fr> Message-ID: <87bjerpo0v.fsf_-_@jacob.g10code.de> Hi! There is a thing one should remember when talking about GnuPG and *PGP: GnuPG did not start on a clean field but had to be compatible with PGP-5 and later (and also for a long time with PGP-2). Certain details are not as I or others would have done them but they needed to be done in that way because PGP did it so. If was a smart good move from Phil and Jon to initialize the OpenPGP WG in 1997 leading to RFC2440 a year later and with minor updates in RFC4880 another 9 years later. However, one thing is a specification and the other thing is running code. The running code in 1997 was PGP 5 and GnuPG followed the development and peculiarities of that implementation closely. There has been a good understanding between the folks actually writing the code on how to do things which have not been fully specified of where an one implementation derived from the RFC. The overall result was a way better interoperable protocol than the committee designed CMS specifications with all there profiles and non-interoperable implementation assumptions. Shalom-Salam, Werner p.s. I did not like to coin the term LibrePGP because actually GnuPG was the software which consistently talked about OpenPGP and not about PGP or GPG when talking about the protocol. But eventually I came up with LibrePGP to help avoiding confusion about what new protocol variant we are talking about. -- 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: 284 bytes Desc: not available URL: From andrewg at andrewg.com Thu May 7 15:13:28 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 7 May 2026 14:13:28 +0100 Subject: PGP and GnuPG specifications (was: Post-quantum defaults) In-Reply-To: <87bjerpo0v.fsf_-_@jacob.g10code.de> References: <87bjerpo0v.fsf_-_@jacob.g10code.de> Message-ID: Hey, Werner. On 7 May 2026, at 10:26, Werner Koch via Gnupg-users wrote: > > However, one thing is a specification and the other thing is running > code. The running code in 1997 was PGP 5 and GnuPG followed the > development and peculiarities of that implementation closely. There has > been a good understanding between the folks actually writing the code on > how to do things which have not been fully specified of where an one > implementation derived from the RFC. That?s fair when you are taking a once-proprietary protocol and adopting it as an open one. Backwards compat with the install base is crucial of course, and bug-for-bug compatibility is a necessary evil at the beginning of a standardisation process. Where we disagree is how to manage the open standard afterwards. I don?t think we should just replace PGP with GnuPG and carry on in the same manner with the names changed. A healthy ecosystem needs a broad spectrum of input, not just hand-picked people in a private chat. We need experimental code with open discussion and public interop testing before shipping anything in production. That doesn?t mean that private chats have no place in the process, or that we need to pay equal attention to everyone?s half-baked ideas. But gnupg has swung too far in the opposite direction. Take draft-koch-librepgp-05: there are three new ?reserved code points? in the tables. What are they for? Where are the design docs? Public key algorithm code point 29 is burned because gnupg shipped experimental PQC code that used it - and then moved to code point 8 instead. We have a private and experimental area for this, why was it not used? Curve 448 wire representations had their prefix octets removed without any discussion or notice. There?s a truncated ?25-octet v5 fingerprint? that appears sometimes if you use a particular combination of CLI flags, and you can create ?v5? fingerprints over v4 keys and/or ?v4? fps over v5 (I?ve lost track). These are not bugs; they are deliberate choices made without regard for other implementors. How is anyone expected to interoperate with this? A From wk at gnupg.org Thu May 7 16:22:11 2026 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 May 2026 16:22:11 +0200 Subject: PGP and GnuPG specifications In-Reply-To: (Andrew Gallagher's message of "Thu, 7 May 2026 14:13:28 +0100") References: <87bjerpo0v.fsf_-_@jacob.g10code.de> Message-ID: <871pfnpaek.fsf@jacob.g10code.de> On Thu, 7 May 2026 14:13, Andrew Gallagher said: > That?s fair when you are taking a once-proprietary protocol and Actually, it was never proprietary. PRZ feared that by a future acquisation the new owner could close the source code and thus limit good privicay for evertone. This is why he wanted to have an open specification. This also helped to avoid possible copyright infringement claims against authors having read the code. (cf. AT&T and Unix). For similar reasons RFC1991 was published in 1996 which acted as an open specification for the specification which accompanied PGP-2. 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: 284 bytes Desc: not available URL: From andrewg at andrewg.com Thu May 7 18:04:11 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 7 May 2026 17:04:11 +0100 Subject: PGP and GnuPG specifications In-Reply-To: <871pfnpaek.fsf@jacob.g10code.de> References: <871pfnpaek.fsf@jacob.g10code.de> Message-ID: <8A76DA75-9DB8-4B33-9511-CF6E8DAC35C1@andrewg.com> On 7 May 2026, at 15:19, Werner Koch wrote: > > On Thu, 7 May 2026 14:13, Andrew Gallagher said: > >> That?s fair when you are taking a once-proprietary protocol and > > Actually, it was never proprietary. PRZ feared that by a future > acquisation the new owner could close the source code and thus limit > good privicay for evertone. This is why he wanted to have an open > specification I used ?proprietary? in the sense of ?controlled by a single person/org?, so we are in agreement here. Proprietary as in .docx, not as in Coke; if you will. A From loup at loup-vaillant.fr Fri May 8 00:44:01 2026 From: loup at loup-vaillant.fr (Loup Vaillant) Date: Fri, 8 May 2026 00:44:01 +0200 Subject: PGP and GnuPG specifications In-Reply-To: <87bjerpo0v.fsf_-_@jacob.g10code.de> References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org> <87zf2oyirs.fsf@jacob.g10code.de> <9f0252f7-c907-4f22-a2f8-185f1381ce40@andrewg.com> <87jytsya00.fsf@jacob.g10code.de> <144d13a7-40d7-4266-9801-39c5b2222d61@andrewg.com> <87lde8w224.fsf@jacob.g10code.de> <7e5e36d6-d3d0-4dde-b6ae-e9d353a0791f@loup-vaillant.fr> <87bjerpo0v.fsf_-_@jacob.g10code.de> Message-ID: <93e15600-f592-4990-b663-6298950cdba1@loup-vaillant.fr> > However, one thing is a specification and the other thing is running > code. Wait a minute, are you saying that running code comes first, and specs are meant to play catch up? At the beginning of the standardisation process that makes a ton of sense, but once the standard is established, it should take precedence. Now in 2026, the onus is on GnuPG to follow OpenPGP, the same way GCC is complying to the C and C++ standards. > p.s. > I did not like to coin the term LibrePGP because actually GnuPG was the > software which consistently talked about OpenPGP and not about PGP or > GPG when talking about the protocol. Promoting the standard instead of your particular implementation is commendable. On the flip side, doing so strongly implies a promise to follow those specs going forward. > But eventually I came up with LibrePGP to help avoiding confusion > about what new protocol variant we are talking about. Had GnuPG kept its implied promise to follow OpenPGP, there would be no confusion. Other problems perhaps, but no confusion. To most people outside the GnuPG project, it's crystal clear OpenPGP is the mainline. Most haven't even heard of LibrePGP. Of course they're confused when they find GnuPG has stopped complying with OpenPGP (if it ever has). In fact, I'm pretty sure the most effective way to end the confusion is to deprecate LibrePGP and start complying with OpenPGP again. It may be a ton of work of course (I've heard GnuPG's code base is old and may be hard to change), but it would end the confusion. Loup. From rjh at sixdemonbag.org Fri May 8 04:29:40 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 7 May 2026 22:29:40 -0400 Subject: PGP and GnuPG specifications In-Reply-To: <93e15600-f592-4990-b663-6298950cdba1@loup-vaillant.fr> References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org> <87zf2oyirs.fsf@jacob.g10code.de> <9f0252f7-c907-4f22-a2f8-185f1381ce40@andrewg.com> <87jytsya00.fsf@jacob.g10code.de> <144d13a7-40d7-4266-9801-39c5b2222d61@andrewg.com> <87lde8w224.fsf@jacob.g10code.de> <7e5e36d6-d3d0-4dde-b6ae-e9d353a0791f@loup-vaillant.fr> <87bjerpo0v.fsf_-_@jacob.g10code.de> <93e15600-f592-4990-b663-6298950cdba1@loup-vaillant.fr> Message-ID: <728839b5-67c9-4a6e-b484-1c48169e6917@sixdemonbag.org> > Wait a minute, are you saying that running code comes first, and > specs are meant to play catch up? At the beginning of the > standardisation process that makes a ton of sense, but once the > standard is established, it should take precedence. To repeat something I've said before: I'm not a GnuPG insider. I don't want to be one. I'm not part of this argument (despite some people in the RFC9580 camp occasionally loudly declaring I am). What follows here is my best understanding of what happened, *speaking as an outsider*. In the very beginning there's no choice but to simply document how existing code works. Once conformance with that initial spec is reached, vendors are encouraged to extend the spec however they see useful, so long as (a) existing conformance with the spec is upheld, and (b) they publicly share their proposed extensions to the spec so the community can discuss them. RFC4880 was getting a bit long in the tooth. New extensions were necessary. Werner behaved responsibly here by preserving strict RFC4880 compliance (the "--rfc4880" flag) and bringing his changes to the Working Group (the "WG") for community deliberation. Over time multiple technical addenda were officially added to the spec: following normal practice, there were called "bis" releases (from the French "encore" or "repeat"). LibrePGP is effectively RFC4880-bis-10, I think, dating from July 2016 or so. RFC4880 was published in 2007, so Werner had been extending the spec *and fully cooperating with the process* for nine years. Over those nine years GnuPG picked up a lot of users and became the most commonly used RFC4880 and RFC4880bis implementation out there. A few years ago there came a point where the WG needed to decide whether to say "RFC4880-bis-10 is going to be the end of our experiments, this is going to be the long-term release going forward", or ... something else. The WG decided, in essence, the past nine years of -bis releases should be seen as mere experimentation -- never minding the fact many many users depend on GnuPG supporting the -bis series. They would instead start fresh from a clean sheet of paper using lessons learned from almost twenty years of RFC4880 use, and -- most controversially -- breaking backwards compatibility with the RFC4880-bis series ("LibrePGP"). RFC9580 is what they came up with instead. It is a good spec. It was designed by competent, knowledgeable people. But there's also next to no userbase for RFC9580 right now, as opposed to the vastly larger LibrePGP userbase. On the one side you have Werner saying, "I fully cooperated with the WG for years and all these extensions were developed in collaboration with the WG, now you're expecting me to tell millions of users who relied on RFC4880-bis-10 being the next standard that no, they have to do something else?!" And on the other side you have people saying, "it was unwise for you to encourage users to migrate to something that hadn't yet been standardized, and we're not going to apologize for at the very last minute deciding to release a better spec." > Promoting the standard instead of your particular implementation is > commendable. On the flip side, doing so strongly implies a promise > to follow those specs going forward. Werner did. He promised RFC2440 support and delivered on that. As RFC2440 evolved through -bis releases he tracked those. When the last RFC2440-bis became RFC4880 support he tracked that. He has a quarter- century history of tracking the evolution of the specs very closely. When a new spec was released, RFC9580, that's when the schism occurred. GnuPG does not support RFC9580. > To most people outside the GnuPG project, it's crystal clear OpenPGP > is the mainline. 99% of people outside the GnuPG project have no idea what either OpenPGP or LibrePGP are and don't care. Of all humanity's billions a few million, at most, track this stuff. Nobody has ever asked me for my RFC9580 certificate. (Yes, I have one. Yes, I would cheerfully use it if anyone asked.) A few people a year pull down my LibrePGP certificate through the Web Key Directory. Proton Mail has RFC9580 support in their back-end, but also support RFC4880-bis-10. There's one for-pay email app in the Apple Store that claims RFC9580 conformance. I am unaware of any open-source email clients with RFC9580 support. Thunderbird is by far the most commonly used *PGP email client. They use the LibRNP library, which has said they'll follow LibrePGP. Evolution also supports GnuPG through a complex set of custom C code, last I looked (which wasn't recently): I doubt they're going to be willing to yank it all out to replace it with Sequoia. > confused when they find GnuPG has stopped complying with OpenPGP (if > it ever has). RFC2440 was published in '98, and GnuPG came into full compliance with it in '99, I think. It *stayed* in full compliance until July 2024, when RFC9580 was published. Please don't insult Werner's quarter-century of hard work. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From jcb62281 at gmail.com Fri May 8 06:18:44 2026 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Thu, 7 May 2026 23:18:44 -0500 Subject: PGP and GnuPG specifications In-Reply-To: <93e15600-f592-4990-b663-6298950cdba1@loup-vaillant.fr> References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org> <87zf2oyirs.fsf@jacob.g10code.de> <9f0252f7-c907-4f22-a2f8-185f1381ce40@andrewg.com> <87jytsya00.fsf@jacob.g10code.de> <144d13a7-40d7-4266-9801-39c5b2222d61@andrewg.com> <87lde8w224.fsf@jacob.g10code.de> <7e5e36d6-d3d0-4dde-b6ae-e9d353a0791f@loup-vaillant.fr> <87bjerpo0v.fsf_-_@jacob.g10code.de> <93e15600-f592-4990-b663-6298950cdba1@loup-vaillant.fr> Message-ID: On 5/7/26 17:44, Loup Vaillant wrote: >> However, one thing is a specification and the other thing is running >> code. > > Wait a minute, are you saying that running code comes first, and specs > are meant to play catch up?? At the beginning of the standardisation > process that makes a ton of sense, but once the standard is > established, it should take precedence. > > Now in 2026, the onus is on GnuPG to follow OpenPGP, > the same way GCC is complying to the C and C++ standards. My understanding is that there exists an OpenPGP v5 ("LibrePGP") and OpenPGP v6 ("OpenPGP", the latest RFC); GnuPG currently implements v4 and v5 with no current plans to support v6 while others are implementing v4 and v6 with no plans to support v5. -- Jacob From look at my.amazin.horse Fri May 8 09:59:18 2026 From: look at my.amazin.horse (Vincent Breitmoser) Date: Fri, 8 May 2026 09:59:18 +0200 Subject: PGP and GnuPG specifications In-Reply-To: <728839b5-67c9-4a6e-b484-1c48169e6917@sixdemonbag.org> References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org> <87zf2oyirs.fsf@jacob.g10code.de> <9f0252f7-c907-4f22-a2f8-185f1381ce40@andrewg.com> <87jytsya00.fsf@jacob.g10code.de> <144d13a7-40d7-4266-9801-39c5b2222d61@andrewg.com> <87lde8w224.fsf@jacob.g10code.de> <7e5e36d6-d3d0-4dde-b6ae-e9d353a0791f@loup-vaillant.fr> <87bjerpo0v.fsf_-_@jacob.g10code.de> <93e15600-f592-4990-b663-6298950cdba1@loup-vaillant.fr> <728839b5-67c9-4a6e-b484-1c48169e6917@sixdemonbag.org> Message-ID: <8941db7f-5752-4fce-a3f3-2929465086c9@my.amazin.horse> Hey list, On 5/8/26 04:29, Robert J. Hansen via Gnupg-users wrote: > LibrePGP is effectively RFC4880-bis-10, I think, dating from July 2016 > or so. RFC4880 was published in 2007, so Werner had been extending the > spec *and fully cooperating with the process* for nine years. > > Over those nine years GnuPG picked up a lot of users and became the most > commonly used RFC4880 and RFC4880bis implementation out there. > > A few years ago there came a point where the WG needed to decide whether > to say "RFC4880-bis-10 is going to be the end of our experiments, this > is going to be the long-term release going forward", or ... something else. While I think your description is largely fair, I'll add that the timeline of conflict is more compressed and less linear than what you describe: * rfc4880bis-00 was published in November 2015. It contained basically no original content, but only merged errata and RFCs like ECC and the Camellia cipher. * The v5 format was first added to the spec in March 2017, published as -02 in June 2017. * In the following three years, there was lots of disagreement in the working group. If memory serves, the hot debate was actually more centered around AEAD than what a v5 packet format would look like. * Things came to a head in 2020. I wrote an email to the list that ultimately triggered the schism, but this was not a momentary event. The writing had been on the wall for a long time at that point. * Werner released rfc4880bis-10 in August 2020 (not July 2016 as you stated), before leaving his position as editor. * Support for v5 was released in [GnuPG 2.3.0] (2021-04-07), and released in a stable version as GnuPG 2.4.0 (2022-12-16). Obviously none of this is black-and-white. And you're right, GnuPG was in a first-mover position in several things and tried to follow process for a long time. But I will also say that GnuPG's current position as an incompatible implementation is at least partially caused by an intentional bet to leverage its de-facto weight in ~2021-2022, hoping everyone would follow suit, that backfired when everyone didn't. - V [GnuPG 2.3.0]: https://dev.gnupg.org/source/gnupg/browse/master/NEWS$1666 From wk at gnupg.org Fri May 8 10:35:41 2026 From: wk at gnupg.org (Werner Koch) Date: Fri, 08 May 2026 10:35:41 +0200 Subject: PGP and GnuPG specifications In-Reply-To: <8941db7f-5752-4fce-a3f3-2929465086c9@my.amazin.horse> (Vincent Breitmoser via Gnupg-users's message of "Fri, 8 May 2026 09:59:18 +0200") References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org> <87zf2oyirs.fsf@jacob.g10code.de> <9f0252f7-c907-4f22-a2f8-185f1381ce40@andrewg.com> <87jytsya00.fsf@jacob.g10code.de> <144d13a7-40d7-4266-9801-39c5b2222d61@andrewg.com> <87lde8w224.fsf@jacob.g10code.de> <7e5e36d6-d3d0-4dde-b6ae-e9d353a0791f@loup-vaillant.fr> <87bjerpo0v.fsf_-_@jacob.g10code.de> <93e15600-f592-4990-b663-6298950cdba1@loup-vaillant.fr> <728839b5-67c9-4a6e-b484-1c48169e6917@sixdemonbag.org> <8941db7f-5752-4fce-a3f3-2929465086c9@my.amazin.horse> Message-ID: <87fr42nvs2.fsf@jacob.g10code.de> Hi! Check out https://librepgp.org/#timeline to see what I consider the timeline. Vincent's description in large parts correct, though. I have been involved in the WG since late fall 1997. At DebConf 2015 I gave a presentation on my current work on updating OpenPGP foro newer algorithms. 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: 284 bytes Desc: not available URL: From rjh at sixdemonbag.org Fri May 8 10:49:17 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 8 May 2026 04:49:17 -0400 Subject: PGP and GnuPG specifications In-Reply-To: <8941db7f-5752-4fce-a3f3-2929465086c9@my.amazin.horse> References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org> <87zf2oyirs.fsf@jacob.g10code.de> <9f0252f7-c907-4f22-a2f8-185f1381ce40@andrewg.com> <87jytsya00.fsf@jacob.g10code.de> <144d13a7-40d7-4266-9801-39c5b2222d61@andrewg.com> <87lde8w224.fsf@jacob.g10code.de> <7e5e36d6-d3d0-4dde-b6ae-e9d353a0791f@loup-vaillant.fr> <87bjerpo0v.fsf_-_@jacob.g10code.de> <93e15600-f592-4990-b663-6298950cdba1@loup-vaillant.fr> <728839b5-67c9-4a6e-b484-1c48169e6917@sixdemonbag.org> <8941db7f-5752-4fce-a3f3-2929465086c9@my.amazin.horse> Message-ID: > * Werner released rfc4880bis-10 in August 2020 (not July 2016 as you > stated), before leaving his position as editor. I agree: my eyes read the wrong line of timestamps on my timeline. My error, I'm sorry. Thank you for the fix! -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From gnupg at shoran-und-alira.de Fri May 8 13:52:25 2026 From: gnupg at shoran-und-alira.de (Frank) Date: Fri, 8 May 2026 13:52:25 +0200 Subject: libgpg-error 1.61 compile IBM POWER AIX Message-ID: Hello, it has been a while and I am trying to compile a new version of GPG (2.5.19) and its libraries. Only npth was already successfully compiled. I am already struggling with libgpg-error and since libgpg-error is the basis for everything else I am stuck. error message: libtool: link: ( cd ".libs" && rm -f "libgpg-error.la" && ln -s "../libgpg-error.la" "libgpg-error.la" ) /opt/freeware/bin/bash ../libtool --tag=CC --mode=link cc -qlanglvl=extc1x -qmaxmem=16384 -DSYSV -D_AIX -D_AIX32 -D_AIX41 -D_AIX43 -D_AIX51 -D_AIX52 -D_AIX53 -D_AIX61 -D_AIX71 -D_AIX72 -D_ALL_SOURCE -DFUNCPROTO=15 -O2 -I/opt/freeware/include -L/opt/freeware/lib64 -L/opt/freeware/lib -Wl,-blibpath:/opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib -Wl,-bmaxdata:0x80000000 -o gpg-error gpg_error-strsource-sym.o gpg_error-strerror-sym.o gpg_error-gpg-error.o libgpg-error.la libtool: link: cc -qlanglvl=extc1x -qmaxmem=16384 -DSYSV -D_AIX -D_AIX32 -D_AIX41 -D_AIX43 -D_AIX51 -D_AIX52 -D_AIX53 -D_AIX61 -D_AIX71 -D_AIX72 -D_ALL_SOURCE -DFUNCPROTO=15 -O2 -I/opt/freeware/include -Wl,-blibpath:/opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib -Wl,-bmaxdata:0x80000000 -o .libs/gpg-error gpg_error-strsource-sym.o gpg_error-strerror-sym.o gpg_error-gpg-error.o -L/opt/freeware/lib64 -L/opt/freeware/lib -L./.libs -lgpg-error -lpthread -Wl,-blibpath:/opt/freeware/lib:/opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib ld: 0711-317 ERROR: Undefined symbol: .gpgrt_fconcat ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make: The error code from the last command is 8. Stop. make: The error code from the last command is 2. Stop. make: The error code from the last command is 1. Stop. make: The error code from the last command is 2. Stop. I found this in the Changelog: 2025-12-09 Werner Koch argparse: gpgrt_fconcat to get the SYSCONFDIR. + commit 6fe7cf710254d78ada27fbf63747ab0e97bc6979 * src/stringutils.c (_gpgrt_fconcat): New internal function. * src/argparse.c (_gpgrt_argparser): Use it. New function gpgrt_fconcat. + commit 34dba88757fedb61d1ea63616a3e03837ccf50ab * src/w32-utils.c: New. * src/init.c (_gpg_err_init, DllMain): Call new init function. * src/visibility.c (gpgrt_fconcat): New. * src/gpg-error.h.in (gpgrt_fconcat): New prototype. (GPGRT_FCONCAT_ABS): New. (GPGRT_FCONCAT_TILDE): New. (GPGRT_FCONCAT_SYSCONF): New. * src/gpg-error.def.in (gpgrt_fconcat): New. * src/gpg-error.vers: (gpgrt_fconcat): New. * src/stringutils.c (_gpgrt_vfnameconcat): Repalce want-abs but a new flags arg. Change to support GPGRT_FCONCAT_SYSCONF. Fix tilde expansion under Windows to use CISDL_PROFILE instead of $HOME. Adjust all callers. * src/gpg-error.c (main): New command "fconcat". Any idea, what the reason might be? Which additional information can I provide to pinpoint the issue? Best regards Frank From gnupg at shoran-und-alira.de Fri May 8 15:29:20 2026 From: gnupg at shoran-und-alira.de (Frank) Date: Fri, 8 May 2026 15:29:20 +0200 Subject: libgpg-error 1.61 compile IBM POWER AIX In-Reply-To: References: Message-ID: On 5/8/2026 1:52 PM, Frank wrote: > Hello, > > it has been a while and I am trying to compile a new version of GPG > (2.5.19) and its libraries. > Only npth was already successfully compiled. > > I am already struggling with libgpg-error and > since libgpg-error is the basis for everything else I am stuck. > > error message: > libtool: link: ( cd ".libs" && rm -f "libgpg-error.la" && ln -s "../ > libgpg-error.la" "libgpg-error.la" ) > > ??????? /opt/freeware/bin/bash ../libtool? --tag=CC??? --mode=link cc - > qlanglvl=extc1x? -qmaxmem=16384 -DSYSV -D_AIX -D_AIX32 -D_AIX41 -D_AIX43 > -D_AIX51 -D_AIX52 -D_AIX53 -D_AIX61 -D_AIX71 -D_AIX72 -D_ALL_SOURCE - > DFUNCPROTO=15 -O2 -I/opt/freeware/include -L/opt/freeware/lib64 -L/opt/ > freeware/lib -Wl,-blibpath:/opt/freeware/lib64:/opt/freeware/lib:/usr/ > lib:/lib -Wl,-bmaxdata:0x80000000 -o gpg-error gpg_error-strsource-sym.o > gpg_error-strerror-sym.o gpg_error-gpg-error.o libgpg-error.la > > libtool: link: cc -qlanglvl=extc1x -qmaxmem=16384 -DSYSV -D_AIX -D_AIX32 > -D_AIX41 -D_AIX43 -D_AIX51 -D_AIX52 -D_AIX53 -D_AIX61 -D_AIX71 -D_AIX72 > -D_ALL_SOURCE -DFUNCPROTO=15 -O2 -I/opt/freeware/include -Wl,-blibpath:/ > opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib -Wl,- > bmaxdata:0x80000000 -o .libs/gpg-error gpg_error-strsource-sym.o > gpg_error-strerror-sym.o gpg_error-gpg-error.o? -L/opt/freeware/lib64 - > L/opt/freeware/lib -L./.libs -lgpg-error -lpthread -Wl,-blibpath:/opt/ > freeware/lib:/opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib > > ld: 0711-317 ERROR: Undefined symbol: .gpgrt_fconcat > > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more > information. > > make: The error code from the last command is 8. > > Stop. > make: The error code from the last command is 2. > > > Stop. > make: The error code from the last command is 1. > > > Stop. > make: The error code from the last command is 2. > > > Stop. > > I found this in the Changelog: > 2025-12-09? Werner Koch? > ??????? argparse: gpgrt_fconcat to get the SYSCONFDIR. > ??????? + commit 6fe7cf710254d78ada27fbf63747ab0e97bc6979 > ??????? * src/stringutils.c (_gpgrt_fconcat): New internal function. > ??????? * src/argparse.c (_gpgrt_argparser): Use it. > > ??????? New function gpgrt_fconcat. > ??????? + commit 34dba88757fedb61d1ea63616a3e03837ccf50ab > ??????? * src/w32-utils.c: New. > ??????? * src/init.c (_gpg_err_init, DllMain): Call new init function. > ??????? * src/visibility.c (gpgrt_fconcat): New. > ??????? * src/gpg-error.h.in (gpgrt_fconcat): New prototype. > ??????? (GPGRT_FCONCAT_ABS): New. > ??????? (GPGRT_FCONCAT_TILDE): New. > ??????? (GPGRT_FCONCAT_SYSCONF): New. > ??????? * src/gpg-error.def.in (gpgrt_fconcat): New. > ??????? * src/gpg-error.vers: (gpgrt_fconcat): New. > ??????? * src/stringutils.c (_gpgrt_vfnameconcat): Repalce want-abs but > a new > ??????? flags arg.? Change to support GPGRT_FCONCAT_SYSCONF.? Fix tilde > ??????? expansion under Windows to use CISDL_PROFILE instead of $HOME. > Adjust > ??????? all callers. > > ??????? * src/gpg-error.c (main): New command "fconcat". > > > Any idea, what the reason might be? > Which additional information can I provide to pinpoint the issue? > > Best regards > ????Frank > > On a different side note: I tried to compile the library using xlclang++ and it resulted in an empty (rather malformed) mkerror.h. I was curious to why and found that the xlclang option '-P' creates a .i-file and does not generate the output on stdout. In case you want to support xlclang, either the option -P needs to be dropped or the .i-file put into the following '| grep...'. Regardless, even xlclang++ runs into the same 'Undefined symbol' after that. Best regards Frank From gnupg at shoran-und-alira.de Fri May 8 16:37:08 2026 From: gnupg at shoran-und-alira.de (Frank) Date: Fri, 8 May 2026 16:37:08 +0200 Subject: libgpg-error 1.61 compile IBM POWER AIX In-Reply-To: References: Message-ID: <0f7c9f1e-778f-4711-8077-8fa4da14cf8a@shoran-und-alira.de> On 5/8/2026 1:52 PM, Frank wrote: > Hello, > > it has been a while and I am trying to compile a new version of GPG > (2.5.19) and its libraries. > Only npth was already successfully compiled. > > I am already struggling with libgpg-error and > since libgpg-error is the basis for everything else I am stuck. > > error message: > libtool: link: ( cd ".libs" && rm -f "libgpg-error.la" && ln -s "../ > libgpg-error.la" "libgpg-error.la" ) > > ??????? /opt/freeware/bin/bash ../libtool? --tag=CC??? --mode=link cc - > qlanglvl=extc1x? -qmaxmem=16384 -DSYSV -D_AIX -D_AIX32 -D_AIX41 -D_AIX43 > -D_AIX51 -D_AIX52 -D_AIX53 -D_AIX61 -D_AIX71 -D_AIX72 -D_ALL_SOURCE - > DFUNCPROTO=15 -O2 -I/opt/freeware/include -L/opt/freeware/lib64 -L/opt/ > freeware/lib -Wl,-blibpath:/opt/freeware/lib64:/opt/freeware/lib:/usr/ > lib:/lib -Wl,-bmaxdata:0x80000000 -o gpg-error gpg_error-strsource-sym.o > gpg_error-strerror-sym.o gpg_error-gpg-error.o libgpg-error.la > > libtool: link: cc -qlanglvl=extc1x -qmaxmem=16384 -DSYSV -D_AIX -D_AIX32 > -D_AIX41 -D_AIX43 -D_AIX51 -D_AIX52 -D_AIX53 -D_AIX61 -D_AIX71 -D_AIX72 > -D_ALL_SOURCE -DFUNCPROTO=15 -O2 -I/opt/freeware/include -Wl,-blibpath:/ > opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib -Wl,- > bmaxdata:0x80000000 -o .libs/gpg-error gpg_error-strsource-sym.o > gpg_error-strerror-sym.o gpg_error-gpg-error.o? -L/opt/freeware/lib64 - > L/opt/freeware/lib -L./.libs -lgpg-error -lpthread -Wl,-blibpath:/opt/ > freeware/lib:/opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib > > ld: 0711-317 ERROR: Undefined symbol: .gpgrt_fconcat > > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more > information. > > make: The error code from the last command is 8. > > Stop. > make: The error code from the last command is 2. > > > Stop. > make: The error code from the last command is 1. > > > Stop. > make: The error code from the last command is 2. > > > Stop. > > I found this in the Changelog: > 2025-12-09? Werner Koch? > ??????? argparse: gpgrt_fconcat to get the SYSCONFDIR. > ??????? + commit 6fe7cf710254d78ada27fbf63747ab0e97bc6979 > ??????? * src/stringutils.c (_gpgrt_fconcat): New internal function. > ??????? * src/argparse.c (_gpgrt_argparser): Use it. > > ??????? New function gpgrt_fconcat. > ??????? + commit 34dba88757fedb61d1ea63616a3e03837ccf50ab > ??????? * src/w32-utils.c: New. > ??????? * src/init.c (_gpg_err_init, DllMain): Call new init function. > ??????? * src/visibility.c (gpgrt_fconcat): New. > ??????? * src/gpg-error.h.in (gpgrt_fconcat): New prototype. > ??????? (GPGRT_FCONCAT_ABS): New. > ??????? (GPGRT_FCONCAT_TILDE): New. > ??????? (GPGRT_FCONCAT_SYSCONF): New. > ??????? * src/gpg-error.def.in (gpgrt_fconcat): New. > ??????? * src/gpg-error.vers: (gpgrt_fconcat): New. > ??????? * src/stringutils.c (_gpgrt_vfnameconcat): Repalce want-abs but > a new > ??????? flags arg.? Change to support GPGRT_FCONCAT_SYSCONF.? Fix tilde > ??????? expansion under Windows to use CISDL_PROFILE instead of $HOME. > Adjust > ??????? all callers. > > ??????? * src/gpg-error.c (main): New command "fconcat". > > > Any idea, what the reason might be? > Which additional information can I provide to pinpoint the issue? > > Best regards > ????Frank > > Towards this, I found that the -L./.libs which is there for/from the linktool seems to be to late. Putting it before the environment provided LDDFLAGS solves the problem. Which spurred a thought: checking, I still have several former libraries installed on the host. Removing them, solves the problem. Still might be good to change the order of the libraries as we want to create new ones and local .libs should find precedence over already installed versions. Did I run into the same problem once before? Best regards Frank From gnupg at shoran-und-alira.de Fri May 8 18:29:29 2026 From: gnupg at shoran-und-alira.de (Frank) Date: Fri, 8 May 2026 18:29:29 +0200 Subject: libgcrpyt 1.12.2 compile IBM POWER AIX Message-ID: <4fda37e8-eade-4249-ad84-e0412289e16b@shoran-und-alira.de> Hello, with this library I am having more troubles. Last time I compiled with XL cc (xlC) compiler. This currently results in two issues: 1) the -Werror flag is not supported. According to the IBM documentation it is a xlclang/++ flag For xlc/xlC it should be -qhalt. Which would also work for xlclang/++. 2) cc need the flag -qtls to support __thread storage class xlclang would do this without If I try to compile with xlclang I get several warnings option '-fno-delete-null-pointer-checks' is not supported And an error at Assembler: .libs/mpi-inline$1.s: line 48: invalid opcode or pseudo-op 1500-067: (S) asm statement generates error in assembler output. What is the intended way to compile the library xlC or xlclang? Unless somebody can point out a fix for the assembler error I will for now proceede to remove -Werror and add my '-qtls' option. Best regards Frank From gniibe at fsij.org Wed May 13 02:52:48 2026 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 13 May 2026 09:52:48 +0900 Subject: libgpg-error 1.61 compile IBM POWER AIX In-Reply-To: <0f7c9f1e-778f-4711-8077-8fa4da14cf8a@shoran-und-alira.de> References: <0f7c9f1e-778f-4711-8077-8fa4da14cf8a@shoran-und-alira.de> Message-ID: <871pfgt9jz.fsf@haruna.fsij.org> Frank wrote: > Towards this, I found that the -L./.libs which is there for/from the > linktool seems to be to late. > Putting it before the environment provided LDDFLAGS solves the problem. You manually edited Makefile, right? All in all, IIUC, the way you "configure" was wrong. (And the information was missing in your report.) Because it was wrongly configured, you needed to edit the Makefile. For configure, specifying LDFLAGS with -L/opt/freeware/lib64 -L/opt/freeware/lib is wrong when you have old library there already. Because it comes earlier than -L./.libs, it results linking with old library installed, instead of the one just built. -- From gnupg at shoran-und-alira.de Wed May 13 09:28:02 2026 From: gnupg at shoran-und-alira.de (Frank) Date: Wed, 13 May 2026 09:28:02 +0200 Subject: libgpg-error 1.61 compile IBM POWER AIX In-Reply-To: <871pfgt9jz.fsf@haruna.fsij.org> References: <0f7c9f1e-778f-4711-8077-8fa4da14cf8a@shoran-und-alira.de> <871pfgt9jz.fsf@haruna.fsij.org> Message-ID: <755fb9cc-d174-483d-9da1-6d941f06b8fb@shoran-und-alira.de> On 5/13/2026 2:52 AM, NIIBE Yutaka wrote: > Frank wrote: >> Towards this, I found that the -L./.libs which is there for/from the >> linktool seems to be to late. >> Putting it before the environment provided LDDFLAGS solves the problem. > > You manually edited Makefile, right? > > All in all, IIUC, the way you "configure" was wrong. (And the > information was missing in your report.) Because it was wrongly > configured, you needed to edit the Makefile. > > For configure, specifying LDFLAGS with -L/opt/freeware/lib64 > -L/opt/freeware/lib is wrong when you have old library there already. > Because it comes earlier than -L./.libs, it results linking with old > library installed, instead of the one just built. There was a reason why I added the libraries to the LDDFLAGS, but I cannot remember. I am using these option for several years by now. I agree with you, the -L./.libs needs to come before the LDDFLAGS. I just am unable to understand the logic of the .in / .am and Makefiles to find the proper solution. The option -L./.libs is added during configure and in my understanding it should be added before any LDDFLAGS. From wk at gnupg.org Wed May 13 11:22:40 2026 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 May 2026 11:22:40 +0200 Subject: libgcrpyt 1.12.2 compile IBM POWER AIX In-Reply-To: <4fda37e8-eade-4249-ad84-e0412289e16b@shoran-und-alira.de> (Frank's message of "Fri, 8 May 2026 18:29:29 +0200") References: <4fda37e8-eade-4249-ad84-e0412289e16b@shoran-und-alira.de> Message-ID: <877bp7ll3z.fsf@jacob.g10code.de> Hi! On Fri, 8 May 2026 18:29, Frank said: > 1) the -Werror flag is not supported. > According to the IBM documentation it is a xlclang/++ flag The -Werror flag is only used by some configure test and they will thus fail, which is okay. That is the reason we do configure tests. The original CFLAGS are restored after the tests. PLease remember that you may not edit the Makefiles and execpt that things work out. The proper way to pass flags is to pass them to configure or execptionally to the make invocation. More details on the configure system can be found in INSTALL. The README file has some hints on build problems on RS/6000 but in general we have not other reports that anything from the GnuPG suite does not build on AIX. 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: 284 bytes Desc: not available URL: From wk at gnupg.org Wed May 13 15:14:27 2026 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 May 2026 15:14:27 +0200 Subject: [Announce] GnuPG 2.5.20 released Message-ID: <87wlx7jvt8.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: Version 2.5.20. This release adds two features to gpgsm and fixes a some minor security bugs. The main features in the 2.5 series are improvements for 64 bit Windows and the introduction of Kyber (aka ML-KEM or FIPS-203) as PQC encryption algorithm. Other than PQC support 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. Note that the old 2.4 series reaches end-of-life in just 6 week. Thus update to 2.5.20 in time. As always with GnuPG, new versions are fully compatible with previous versions. 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.20 (2026-05-13) ================================================= [compared to version 2.5.19] * New and extended features: - gpgsm: Implement GCM encryption. Note that decryption works since version 2.3.2. [T3979] - gpgsm: New option --attribute and server command SETATTR to include arbitrary signed or unsigned attributes into a signature. Enable only with libksba 1.7.0 or later. [T4537] - gpgsm: Introduce system attribute _signingCertificateV2. [rG0335a9cb04] * Bug fixes: - gpg: Fix wrong assertion failure which could very rarely occur during key signature checking. [rG693f5642f6] - gpg: Consider certify-only keys for revocation signature check. [T8196] - gpgsm: Fix possible double free in the CMS parser. [T8240] - gpgsm: Fix possible too early removal of ephemeral keys. [T8236] - gpgsm: Avoid emitting a final FAILURE status line if --status-fd is not used. [rG69c27fe377] - gpgsm: Fix a regression in 2.5.19 for password encrypted GCM data. [rG60a823c97b] - agent: Fix not using cache for pinentry loopback. [rGd4b608a31f] - agent: Fix command PUT_SECRET by saving input line. [rG1875bc185e] - keyboxd: Mark keys searched but not imported via LDAP correctly as ephemeral. [T8048] - scdaemon: Avoid buffer overflow with SC-HSM cards providing RSA keys > 2k. [T8244] - dirmngr: Fix uninitialized use of the dns_any union in dns_rr_cmp. [T8251] Release-info: https://dev.gnupg.org/T7997 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.20.tar.bz2 (8132k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.20.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.20_20260513.exe (5631k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.20_20260513.exe.sig The source used to build this installer for 64-bit Windows is available as https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.20_20260513.tar.xz (15M) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.20_20260513.tar.xz.sig This 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. Debian Packages =============== We also provide Debian style packages for a couple of Debian variants. See https://repos.gnupg.org/deb/gnupg/trixie/ or use the menu to switch to other distros/releases. If you encounter packaging problems please report them to the gnupg-devel mailing list. Due to holiday tomorrow it may take a few days until new packages are available. Windows Installer ================= A new version of Gpg4win is in planning. For those who are affected by one of the now fixed bugs, it is possible to install the simple Windows installer mentioned above on top of gpg4win 5.0.2. 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.20.tar.bz2 you would use this command: gpg --verify gnupg-2.5.20.tar.bz2.sig gnupg-2.5.20.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.20.tar.bz2, you run the command like this: sha1sum gnupg-2.5.20.tar.bz2 and check that the output matches the next line: 96371ec0260da5a22edbf8e4d3bf0e54b3ea5b8e gnupg-2.5.20.tar.bz2 a8e1b948766d82430d9fd0f22f05f776973614ee gnupg-w32-2.5.20_20260513.tar.xz 6353c4a98c07b29250ce21ba0321e0d2abd7d1cb gnupg-w32-2.5.20_20260513.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, Dutch, French, Georgian, German, Italian, Japanese, Norwegian, Polish, Portuguese, 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. If you are using cleartext signatures in your application please read https://gnupg.org/blog/20251226-cleartext-signatures.html and maybe https://gnupg.com/20260122-39C3_reply_gpg_fail.html In case of build problems specific to this release please first check https://dev.gnupg.org/T7997 for updated information. We are sorry that due to ongoing DoS on this service, you may end up at a "is under maintenance page". Static copies of the ticket pages will soon be provided, though. 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. A team of full-time employed developers and contractors are working exclusively on GnuPG and related software like Libgcrypt, GPGME, Kleopatra, Okular, 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. * Debian Package Signing Key: The new Debian style packages are signed using this key: ed25519 2025-07-08 [SC] [expires: 2035-07-14] 3209 7B71 9B37 45D6 E61D DA1B 85C4 5AE3 E1A2 B355 GnuPG.org Package Signing Key See the package website (https://repos.gnupg.org/deb/gnupg) for a list of supported distributions and a download link for the key. * List of Release Signing Keys: To guarantee that a downloaded 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 five keys: ed25519 2020-08-24 [SC] [expires: 2030-06-30] 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) ed25519 2021-05-19 [SC] [expires: 2027-04-04] AC8E 115B F73E 2D8D 47FA 9908 E98E 9B2D 19C6 C8BD Niibe Yutaka (GnuPG Release Key) rsa3072 2025-05-09 [SC] [expires: 2033-03-03] 3B76 1AE4 E63B F351 9CE7 D63B ECB6 64CB E133 2EEF Alexander Kulbartsch (GnuPG Release Key) brainpoolP256r1 2021-10-15 [SC] [expires: 2029-12-31] 02F3 8DFF 731F F97C B039 A1DA 549E 695E 905B A208 GnuPG.com (Release Signing Key 2021) brainpoolP384r1 2026-02-23 [SC] [expires: 2034-02-23] 1493 269D E61F 124A A69A 316E 3ADF 34EB DBB2 00A4 GnuPG.com (Release Signing Key 2026) 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. * Debian Package Signing Key: The new Debian style packages are signed using this key: ed25519 2025-07-08 [SC] [expires: 2035-07-14] 3209 7B71 9B37 45D6 E61D DA1B 85C4 5AE3 E1A2 B355 GnuPG.org Package Signing Key See the package website (https://repos.gnupg.org/deb/gnupg) for a list of supported distributions and a download link for the 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: 284 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 gnupg at shoran-und-alira.de Wed May 13 16:18:13 2026 From: gnupg at shoran-und-alira.de (Frank) Date: Wed, 13 May 2026 16:18:13 +0200 Subject: libgcrpyt 1.12.2 compile IBM POWER AIX In-Reply-To: <877bp7ll3z.fsf@jacob.g10code.de> References: <4fda37e8-eade-4249-ad84-e0412289e16b@shoran-und-alira.de> <877bp7ll3z.fsf@jacob.g10code.de> Message-ID: On 5/13/2026 11:22 AM, Werner Koch wrote: > Hi! > > On Fri, 8 May 2026 18:29, Frank said: > >> 1) the -Werror flag is not supported. >> According to the IBM documentation it is a xlclang/++ flag > > The -Werror flag is only used by some configure test and they will thus > fail, which is okay. That is the reason we do configure tests. The > original CFLAGS are restored after the tests. > > PLease remember that you may not edit the Makefiles and execpt that > things work out. The proper way to pass flags is to pass them to > configure or execptionally to the make invocation. More details on the > configure system can be found in INSTALL. The README file has some > hints on build problems on RS/6000 but in general we have not other > reports that anything from the GnuPG suite does not build on AIX. > > > > Salam-Shalom, > > Werner > I do not claim to understand what I am doing. I fumble my way through compilation because there is not much information on OSS compilation on IBM POWER architecture using xlC. The settings I use are derived and adapted from perzl.org, which by now seems to be offline. That being said, if there are users out there, that are working with AIX 7.2 and higher and xlC 16.1 and higher, I am keen to know how they compile OSS releases. My fix was not on the Makefile but to the configure and configure.ac sed -e "s/-Werror/-qhalt/g" In your answer you mainly focused on -Werror. Which brings relevance to my question, what is the preferred compiler, xlC or xlclang? For xlC/cc -Werror is not supported and results in ------ begin config.log ------ configure:19067: checking whether compiler supports '__thread' storage class specifier configure:19086: cc -c -qtls -qalias=ansi -qlanglvl=extc99 -qmaxmem=16384 -O2 -Werror conftest.c >&5 /opt/IBM/xlC/16.1.0/bin/.orig/cc: 1501-210 (S) command option Werror contains an incorrect subargument configure:19086: $? = 40 ------ end config.log ------ ------ begin make ------ libtool: compile: cc -DHAVE_CONFIG_H -I. -I.. -I/opt/freeware/include -qtls -qalias=ansi -qlanglvl=extc99 -qmaxmem=16384 -O2 -c missing-string.c -Wp,-qmakedep=gcc,-MF.deps/libgcrypt_la-missing-string.TPlo -DPIC -o .libs/libgcrypt_la-missing-string.o source='fips.c' object='libgcrypt_la-fips.lo' libtool=yes DEPDIR=.deps depmode=xlc /opt/freeware/bin/bash ../build-aux/depcomp /opt/freeware/bin/bash ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I.. -I/opt/freeware/include -qtls -qalias=ansi -qlanglvl=extc99 -qmaxmem=16384 -O2 -c -o libgcrypt_la-fips.lo `test -f 'fips.c' || echo './'`fips.c libtool: compile: cc -DHAVE_CONFIG_H -I. -I.. -I/opt/freeware/include -qtls -qalias=ansi -qlanglvl=extc99 -qmaxmem=16384 -O2 -c fips.c -Wp,-qmakedep=gcc,-MF.deps/libgcrypt_la-fips.TPlo -DPIC -o .libs/libgcrypt_la-fips.o "fips.c", line 82.2: 1506-205 (S) #error libgcrypt requires thread-local storage to support FIPS mode "fips.c", line 88.3: 1506-045 (S) Undeclared identifier the_tc. "fips.c", line 94.13: 1506-045 (S) Undeclared identifier the_tc. "fips.c", line 100.3: 1506-045 (S) Undeclared identifier the_tc. "fips.c", line 106.10: 1506-045 (S) Undeclared identifier the_tc. make: The error code from the last command is 1. ------ end config.log ------ For xlclang, which would null and void the configure(.ac) modification, is the question about the assembler opcode outstanding. This cannot be solved by adding --disable-asm. From wk at gnupg.org Wed May 13 16:29:59 2026 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 May 2026 16:29:59 +0200 Subject: libgcrpyt 1.12.2 compile IBM POWER AIX In-Reply-To: (Frank's message of "Wed, 13 May 2026 16:18:13 +0200") References: <4fda37e8-eade-4249-ad84-e0412289e16b@shoran-und-alira.de> <877bp7ll3z.fsf@jacob.g10code.de> Message-ID: <87bjejjsbc.fsf@jacob.g10code.de> On Wed, 13 May 2026 16:18, Frank said: > Which brings relevance to my question, what is the preferred compiler, > xlC or xlclang? I don't know. Just use the system's standard compiler. One of configure's job is to figure this out. You may want to post a log of the configure run you did - but please using a verbatim copy of tye software in a clean source and build directory. 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: 284 bytes Desc: not available URL: From famubu at disroot.org Thu May 14 08:13:10 2026 From: famubu at disroot.org (famubu) Date: Thu, 14 May 2026 11:43:10 +0530 Subject: Using gpg with emacs mu4e and mbsync Message-ID: Hi. I am getting an error when trying to read a gpg encrypted file. This was the command: ``` gpg -q --for-your-eyes-only --no-tty -d ~/.authinfo.gpg ``` Error: ``` gpg: Sorry, no terminal at all requested - can't get input ``` I think the `--no-tty` is needed because I'm trying to use it from the emacs editor. Would anyone here know how to fix this? Any help would be appreciated. Versions: - gpg: 2.2.27 - emacs: 27.1 - mbsync: 1.3.0 - mu4e: 1.4 Background ========== I'm trying to use mu4e package of emacs as mail client. mbsync is used to fetch mails. I got my mail password in a gpg encrypted file: ~/.authinfo.gpg Now, I need to be able to run mbsync while within emacs/mu4e with the password prompt showing up in its minibuffer. For this, I put a 'pinentry loopback' in the conf file of gpg (config files shown at end of this post). I think this is not an editor problem because `mbsyc dirname` also gives the same error about 'no terminal at all requested' In emacs, it works fine when I open gpg encrypted file where the editor will prompt me for password in the minibuffer and open the file in its plain text form. conf files ========== These are the contents of the gpg conf files. gpg.conf: ``` use-agent pinentry-mode loopback ``` gpg-agent.conf: ``` pinentry-program /usr/bin/pinentry-curses allow-emacs-pinentry allow-loopback-pinentry ``` -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri May 15 10:10:04 2026 From: wk at gnupg.org (Werner Koch) Date: Fri, 15 May 2026 10:10:04 +0200 Subject: Using gpg with emacs mu4e and mbsync In-Reply-To: (famubu via Gnupg-users's message of "Thu, 14 May 2026 11:43:10 +0530") References: Message-ID: <877bp5jdpf.fsf@jacob.g10code.de> > gpg -q --for-your-eyes-only --no-tty -d ~/.authinfo.gpg --for-your-eyes-only does nothin but setting "_CONSOLE" as embedded filename - it is a useless option and is a PGP 2 legacy. Do not use --no-tty but use gpg -v --batch -d -o - ~/.authinfo.gpg assuming that you want to see the output on stdout (it is actually the default with -d but better better make it explicit). > For this, I put a 'pinentry loopback' in the conf file of gpg (config Don't. Put --pinentry-mode=loopback on the command line. Otherwiese you break other use cases of gpg. gpg.conf: > use-agent That is a no-op for many many years. > pinentry-mode loopback see above. > gpg-agent.conf: > > ``` > pinentry-program /usr/bin/pinentry-curses > allow-emacs-pinentry > allow-loopback-pinentry okay. There is also an emacs pinentry but I am not aware of the current state of things. I use Emacs on X with the GTK pinentry 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: 284 bytes Desc: not available URL: From wk at gnupg.org Fri May 15 10:13:01 2026 From: wk at gnupg.org (Werner Koch) Date: Fri, 15 May 2026 10:13:01 +0200 Subject: Using gpg with emacs mu4e and mbsync In-Reply-To: (famubu via Gnupg-users's message of "Thu, 14 May 2026 11:43:10 +0530") References: Message-ID: <8733ztjdki.fsf@jacob.g10code.de> On Thu, 14 May 2026 11:43, famubu said: > - gpg: 2.2.27 Pretty please update to a current version (2.5.20). 2.2.7 is 8 years old and the 2.2 series has long reached end-of-life and is only supported for certain customers which need this version for regulatory reasons. 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: 284 bytes Desc: not available URL: From gnupg at shoran-und-alira.de Fri May 15 12:31:16 2026 From: gnupg at shoran-und-alira.de (Frank) Date: Fri, 15 May 2026 12:31:16 +0200 Subject: libgcrpyt 1.12.2 compile IBM POWER AIX In-Reply-To: <87bjejjsbc.fsf@jacob.g10code.de> References: <4fda37e8-eade-4249-ad84-e0412289e16b@shoran-und-alira.de> <877bp7ll3z.fsf@jacob.g10code.de> <87bjejjsbc.fsf@jacob.g10code.de> Message-ID: <63819eed-15d8-4af4-ab6f-90c2e7d3ae53@shoran-und-alira.de> On 5/13/2026 4:29 PM, Werner Koch wrote: > On Wed, 13 May 2026 16:18, Frank said: > You may want to post a log of the configure run you did - but please > using a verbatim copy of tye software in a clean source and build > directory. I hope this works... If the attachment does not come through, I need a pointer on how to share those with the mailing group. Attached are two log files (config.log) from configure with cc and xlclang++ The compile environments are near identical: ---- common ---- CFLAGS=-qmaxmem=16384 -DSYSV -D_AIX -D_AIX32 -D_AIX41 -D_AIX43 -D_AIX51 -D_AIX52 -D_AIX53 -D_AIX61 -D_AIX71 -D_AIX72 -D_ALL_SOURCE -DFUNCPROTO=15 -O2 -I/opt/freeware/include CONFIG_ENV_ARGS=/opt/freeware/bin/bash CONFIG_SHELL=/opt/freeware/bin/bash CXXFLAGS=-qmaxmem=16384 -DSYSV -D_AIX -D_AIX32 -D_AIX41 -D_AIX43 -D_AIX51 -D_AIX52 -D_AIX53 -D_AIX61 -D_AIX71 -D_AIX72 -D_ALL_SOURCE -DFUNCPROTO=15 -O2 -I/opt/freeware/include F77=xlf FFLAGS=-qmaxmem=16384 -O -I/opt/freeware/include LANG=C LC__FASTMSG=true LD=ld LDFLAGS=-L/opt/freeware/lib64 -L/opt/freeware/lib -Wl,-blibpath:/opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib -Wl,-bmaxdata:0x80000000 LOCPATH=/usr/lib/nls/loc MANPATH=/opt/freeware/man:/usr/local/share/man NLSPATH=/usr/lib/nls/msg/%L/%N:/usr/lib/nls/msg/%L/%N.cat:/usr/lib/nls/msg/%l.%c/%N:/usr/lib/nls/msg/%l.%c/%N.cat ODMDIR=/etc/objrepos PATH=/opt/IBM/xlC/16.1.0/bin:/opt/freeware/bin:/opt/freeware/sbin:/usr/bin:/bin:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/usr/vac/bin:/usr/vacpp/bin:/usr/ccs/bin:/usr/dt/bin:/usr/opt/perl5/bin:/usr/local/bin:/usr/lib/instl SHELL=/usr/bin/ksh TERM=xterm TZ=CET-1CEST,M3.5.0/02:00:00,M10.5.0/03:00:00 ------- xlclang++ ------ CC=xlclang++ CXX=xlclang++ ------- cc ------ CC=cc CXX=xlC -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log.tar.gz Type: application/x-gzip Size: 45601 bytes Desc: not available URL: From famubu at disroot.org Sat May 16 14:56:25 2026 From: famubu at disroot.org (famubu) Date: Sat, 16 May 2026 18:26:25 +0530 Subject: Using gpg with emacs mu4e and mbsync In-Reply-To: <8733ztjdki.fsf@jacob.g10code.de> References: <8733ztjdki.fsf@jacob.g10code.de> Message-ID: <37bf93a7782ad9fa434eaa622a28775d@disroot.org> > --for-your-eyes-only does nothin but setting "_CONSOLE" as embedded > filename - it is a useless option and is a PGP 2 legacy. I figured this would be needed since the man page mentions something about ensuring that no file is saved. I took it to mean that using this would be more secure. > Do not use --no-tty but use > > gpg -v --batch -d -o - ~/.authinfo.gpg Using `--batch` gave error: `Sorry, we are in batchmode - can't get input The command was: `gpg -q --batch --pinentry-mode loopback -d ~/file.gpg` > assuming that you want to see the output on stdout (it is actually the > default with -d but better better make it explicit). I need the output to be usable by mbsync. And mbsync would get the password via emacs. So I don't want the output on stdout. I had actually got this to work from within emacs at some point. But I suppose I ended up changing the config and messed it up. I tried different versions of the config that I ended up with by commenting/uncommenting out parts of it, but to no avail. > > use-agent > That is a no-op for many many years. Ah.. I now see in the man page about it being a dummy option. > Pretty please update to a current version (2.5.20). 2.2.7 is 8 > years I was just using the gpg version available in my distro. Got to update to newer distro version. But been putting it off since I got to back up my files first. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at postzone.org Sun May 17 12:28:10 2026 From: martin at postzone.org (Martin) Date: Sun, 17 May 2026 12:28:10 +0200 Subject: Upgrade to newest version Message-ID: <4bef6725-1702-4737-91d7-db713570c785@postzone.org> How do I keep the latest version of GnuPG on my Ubuntu 25.10 installation? The official repository of Ubuntu only has version 2.4.8. Simply upgrading gpg to the latest version by compiling it myself isn't much help?the other tools (dirmngr, gpg-agent, etc.) need to be updated to match that version. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.nooden at gmx.com Sun May 17 14:24:08 2026 From: lars.nooden at gmx.com (=?UTF-8?Q?Lars_Nood=C3=A9n?=) Date: Sun, 17 May 2026 15:24:08 +0300 Subject: Digital archeology -- verifying a signed Usenet message from 1995 Message-ID: <30dd480e-3ed7-4777-9c4e-b7c77d57ad3a@gmx.com> Hello, What should I be looking at to work with an old version of GnuPG having sufficiently outdated cipher and checksum algorithms to verify a Usenet message? from 1995? Should I try to get Debian Hamm (or earlier) in a 32-bit VM and work from there? Or would another approach be recommended? I realize that the cipher and checksum algorithms have moved on since 1995 so this is mostly a formality to see that the copy is accurate in lieu of MD5 etc. Regards, Lars ? The message in question is Tatu Yl?nen's post, "ANNOUNCEMENT: Ssh (Secure Shell) Remote Login Program", from 12 July 1995 to news://comp.security.unux/ and found via the Internet Archive at: https://archive.org/download/usenet-comp From rjh at sixdemonbag.org Sun May 17 16:35:55 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 17 May 2026 10:35:55 -0400 Subject: Digital archeology -- verifying a signed Usenet message from 1995 In-Reply-To: <30dd480e-3ed7-4777-9c4e-b7c77d57ad3a@gmx.com> References: <30dd480e-3ed7-4777-9c4e-b7c77d57ad3a@gmx.com> Message-ID: > What should I be looking at to work with an old version of GnuPG having > sufficiently outdated cipher and checksum algorithms to verify a Usenet > message? from 1995? GnuPG 1.4 might be able to. But you'll need Yl?nen's ClassicPGP certificate, I'm afraid, and that might be hard to find. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From mm at dorfdsl.de Sun May 17 17:04:02 2026 From: mm at dorfdsl.de (Marco Moock) Date: Sun, 17 May 2026 17:04:02 +0200 Subject: Upgrade to newest version In-Reply-To: <4bef6725-1702-4737-91d7-db713570c785@postzone.org> References: <4bef6725-1702-4737-91d7-db713570c785@postzone.org> Message-ID: Am 17.05.26 um 12:28 schrieb Martin: > How do I keep the latest version of GnuPG on my Ubuntu 25.10 > installation? The official repository of Ubuntu only has version 2.4.8. > Simply upgrading gpg to the latest version by compiling it myself isn't > much help?the other tools (dirmngr, gpg-agent, etc.) need to be updated > to match that version. Ubuntu takes the packages from Debian testing and creates their distribution from it. First step will be to upgrade to 26.04 and check if the version there fits your needs. If you need to compile yourself, you no only need to compile all parts of GnuPG, but you also need to build .deb packages, so they can be installed and satisfy the dependencies of of other packages. -- Gru? Marco Muell und Spam bitte an abfalleimer2000 at stinkedores.dorfdsl.de -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x559E1A331A46B463.asc Type: application/pgp-keys Size: 2432 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: From lars.nooden at gmx.com Sun May 17 17:51:01 2026 From: lars.nooden at gmx.com (=?UTF-8?Q?Lars_Nood=C3=A9n?=) Date: Sun, 17 May 2026 18:51:01 +0300 Subject: Digital archeology -- verifying a signed Usenet message from 1995 In-Reply-To: References: <30dd480e-3ed7-4777-9c4e-b7c77d57ad3a@gmx.com> Message-ID: On 5/17/26 17:35, Robert J. Hansen via Gnupg-users wrote: >> What should I be looking at to work with an old version of GnuPG >> having sufficiently outdated cipher and checksum algorithms to verify >> a Usenet message? from 1995? > > GnuPG 1.4 might be able to. But you'll need Yl?nen's ClassicPGP > certificate, I'm afraid, and that might be hard to find. Thanks. I've installed GnuPG 1.4.23-2 for now. And it looks like Tatu Yl?nen's public key is there at the end of his message, plus there is the same key ID at pgp.mit.edu even today. But that public key is not self-signed which presents a problem that I have tried to address? with the --allow-non-selfsigned-uid option. However, if the above approach was correct, then I'm somehow approaching the verification incorrectly: $ gpg1 --list-keys /home/me/.gnupg/pubring.gpg ----------------------------- pub 1024R/DCB9AE01 1995-04-24 uid Ssh distribution key $ gpg1 --verify message.usenet gpg: Signature made Wed 12 Jul 1995 05:50:42 PM EEST using RSA key ID 961F4A35 gpg: Can't check signature: public key not found $ gpg1 -u ylo at cs.hut.fi --verify message.usenet gpg: Signature made Wed 12 Jul 1995 05:50:42 PM EEST using RSA key ID 961F4A35 gpg: Can't check signature: public key not found /Lars --- ? Here is the process which I used to import the key: $ gpg1 --import --allow-non-selfsigned-uid -v ylo-public.key gpg: keyring `/home/me/.gnupg/pubring.gpg' created gpg: armor header: Version: 2.6.i gpg: pub 1024R/DCB9AE01 1995-04-24 Ssh distribution key gpg: key DCB9AE01: accepted non self-signed user ID "Ssh distribution key " gpg: using PGP trust model gpg: Invalid key DCB9AE01 made valid by --allow-non-selfsigned-uid gpg: key DCB9AE01: public key "Ssh distribution key " imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) gpg: 1 keys cached (1 signatures) gpg: 23 keys processed (0 validity counts cleared) gpg: public key of ultimately trusted key 787E4228 not found gpg: public key of ultimately trusted key 71BDB2EB not found gpg: public key of ultimately trusted key 1011EF31 not found gpg: public key of ultimately trusted key 653CEAE7 not found gpg: public key of ultimately trusted key 00D026C4 not found gpg: public key of ultimately trusted key FE35B305 not found gpg: public key of ultimately trusted key 3845389F not found gpg: public key of ultimately trusted key DA87EF9A not found gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: Invalid key DCB9AE01 made valid by --allow-non-selfsigned-uid gpg: depth: 0 valid: 8 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 8u $ gpg1 --check-sigs /home/me/.gnupg/pubring.gpg ----------------------------- pub 1024R/DCB9AE01 1995-04-24 uid Ssh distribution key 1 signature not checked due to a missing key From jcb62281 at gmail.com Mon May 18 04:30:06 2026 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Sun, 17 May 2026 21:30:06 -0500 Subject: Digital archeology -- verifying a signed Usenet message from 1995 In-Reply-To: References: <30dd480e-3ed7-4777-9c4e-b7c77d57ad3a@gmx.com> Message-ID: On 5/17/26 10:51, Lars Nood?n via Gnupg-users wrote: > On 5/17/26 17:35, Robert J. Hansen via Gnupg-users wrote: >>> What should I be looking at to work with an old version of GnuPG >>> having sufficiently outdated cipher and checksum algorithms to >>> verify a Usenet message? from 1995? >> >> GnuPG 1.4 might be able to. But you'll need Yl?nen's ClassicPGP >> certificate, I'm afraid, and that might be hard to find. > > Thanks.? I've installed GnuPG 1.4.23-2 for now. > > And it looks like Tatu Yl?nen's public key is there at the end of his > message, plus there is the same key ID at pgp.mit.edu even today.? But > that public key is not self-signed which presents a problem that I > have tried to address? with the --allow-non-selfsigned-uid option. > > However, if the above approach was correct, then I'm somehow > approaching the verification incorrectly: > > $ gpg1 --list-keys > /home/me/.gnupg/pubring.gpg > ----------------------------- > pub?? 1024R/DCB9AE01 1995-04-24 > uid????????????????? Ssh distribution key > > $ gpg1 --verify message.usenet > gpg: Signature made Wed 12 Jul 1995 05:50:42 PM EEST using RSA key ID > 961F4A35 > gpg: Can't check signature: public key not found > > $ gpg1 -u ylo at cs.hut.fi --verify message.usenet > gpg: Signature made Wed 12 Jul 1995 05:50:42 PM EEST using RSA key ID > 961F4A35 > gpg: Can't check signature: public key not found Found your problem:? the signature is from key 961F4A35 but you only have key DCB9AE01.? "Go fish"---you will need the public key with ID 961F4A35 to verify that signature. -- Jacob From m at gnupg.org Mon May 18 08:27:55 2026 From: m at gnupg.org (Meik Michalke) Date: Mon, 18 May 2026 08:27:55 +0200 Subject: Upgrade to newest version In-Reply-To: <4bef6725-1702-4737-91d7-db713570c785@postzone.org> References: <4bef6725-1702-4737-91d7-db713570c785@postzone.org> Message-ID: <2195899.UP0FcZTL5h@kasidy> hi martin, Am Sonntag, 17. Mai 2026, 12:28:10 CEST schrieb Martin: > How do I keep the latest version of GnuPG on my Ubuntu 25.10 > installation? The official repository of Ubuntu only has version 2.4.8. > Simply upgrading gpg to the latest version by compiling it myself isn't > much help?the other tools (dirmngr, gpg-agent, etc.) need to be updated > to match that version. you don't have to compile those on your own. we provide a repository with most recent packages: https://repos.gnupg.org/deb/gnupg/questing/ there's also a blog article on the repos that might be helpful: https://gnupg.org/blog/20250827-new-repository.html note that we're currently shipping gnupg 2.5 in both the "stable" and "devel" repos, we'll need to update the blog post on that. 2.4 will be EOL soon. packages for 26.04 ("resolute") are in preparation -- there had been some issues with creating the build image before its actual release that are now resolved, fortunately. viele gr??e :: m.eik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 265 bytes Desc: This is a digitally signed message part. URL: From nils.schween at mpi-hd.mpg.de Mon May 18 09:44:05 2026 From: nils.schween at mpi-hd.mpg.de (Nils Schween) Date: Mon, 18 May 2026 09:44:05 +0200 Subject: Using gpg with emacs mu4e and mbsync In-Reply-To: <37bf93a7782ad9fa434eaa622a28775d@disroot.org> (famubu via Gnupg-users's message of "Sat, 16 May 2026 18:26:25 +0530") References: <8733ztjdki.fsf@jacob.g10code.de> <37bf93a7782ad9fa434eaa622a28775d@disroot.org> Message-ID: Hi famubu, mbsync nows a command called `PassCmd`. You can use it in your .mbsyncrc file in your IMAPAccount section. Here is an example that I found: PassCmd "gpg --decrypt --quiet --for-your-eyes-only --no-tty ~/.authinfo.gpg | grep -m 1 your-account-name | cut -d ' ' -f 8" But you should adapt it and not use --no--tty, --for-your-eyes-only as Werner wrote. Best, Nils famubu via Gnupg-users writes: >> --for-your-eyes-only does nothin but setting "_CONSOLE" as embedded >> filename - it is a useless option and is a PGP 2 legacy. > > I figured this would be needed since the man page mentions something > about ensuring that no file is saved. I took it to mean that using > this would be more secure. > >> Do not use --no-tty but use >> >> gpg -v --batch -d -o - ~/.authinfo.gpg > > Using `--batch` gave error: `Sorry, we are in batchmode - can't get input > The command was: `gpg -q --batch --pinentry-mode loopback -d ~/file.gpg` > >> assuming that you want to see the output on stdout (it is actually the >> default with -d but better better make it explicit). > > I need the output to be usable by mbsync. And mbsync would get the > password via emacs. So I don't want the output on stdout. > > I had actually got this to work from within emacs at some point. > But I suppose I ended up changing the config and messed it up. > I tried different versions of the config that I ended up with by > commenting/uncommenting out parts of it, but to no avail. > >> > use-agent >> That is a no-op for many many years. > > Ah.. I now see in the man page about it being a dummy option. > >> Pretty please update to a current version (2.5.20). 2.2.7 is 8 >> years > > I was just using the gpg version available in my distro. > Got to update to newer distro version. But been putting it off since I > got to back up my files first. > > _______________________________________________ > 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 From famubu at disroot.org Mon May 18 23:08:18 2026 From: famubu at disroot.org (famubu) Date: Tue, 19 May 2026 02:38:18 +0530 Subject: Using gpg with emacs mu4e and mbsync In-Reply-To: References: <8733ztjdki.fsf@jacob.g10code.de> <37bf93a7782ad9fa434eaa622a28775d@disroot.org> Message-ID: <9d8113635ecc0bec37e580c17097f1d7@disroot.org> > mbsync nows a command called `PassCmd`. You can use it in your > .mbsyncrc file in your IMAPAccount section. Yes, I am using that command like this: ``` PassCmd "gpg -q --for-your-eyes-only --pinentry-mode loopback -d ~/.authinfo.gpg | awk '/some regex/ {print $NF}'" ``` > But you should adapt it and not use --no--tty, --for-your-eyes-only as I am getting problems when invoking mbsync (which in turn invokes gpg) from emacs. With or without `--no-tty`. Without `--no-tty`: I am prompted to enter the password, but it is within an emacs buffer that is not editable. It should have appeared in the minibuffer where we can actually type the password. With `--no-tty` (same command as above): ``` gpg: Sorry, no terminal at all requested - can't get input ``` Almost all blog posts and forum entries that I came across uses `--no-tty` though. I am not sure why. Maybe it was needed for older versions of one of the software involved. Example posts: - https://jherrlin.github.io/posts/emacs-mu4e/ - https://f-santos.gitlab.io/2020-04-24-mu4e.html - https://www.erichgrunewald.com/posts/setting-up-gmail-in-doom-emacs-using-mbsync-and-mu4e/ - https://github.com/danielfleischer/mu4easy - https://emacs.stackexchange.com/questions/53506/user-friendly-setup-of-emacs-with-gpg-mu4e-and-mu4e-send-delay -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Tue May 19 04:04:42 2026 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 19 May 2026 11:04:42 +0900 Subject: Using gpg with emacs mu4e and mbsync In-Reply-To: <9d8113635ecc0bec37e580c17097f1d7@disroot.org> References: <8733ztjdki.fsf@jacob.g10code.de> <37bf93a7782ad9fa434eaa622a28775d@disroot.org> <9d8113635ecc0bec37e580c17097f1d7@disroot.org> Message-ID: <87fr3om9xh.fsf@haruna.fsij.org> Hello, famubu wrote: > Without `--no-tty`: I am prompted to enter the password, but it is > within an emacs buffer that is not editable. It should have appeared > in the minibuffer where we can actually type the password. IIUC, it is a problem of Emacs configuration to detect passphrase prompt (so that it can ask with the minibuffer). Do you mean that you are invoking mbsync in the shell buffer (or something) within Emacs? For me, it works when I use LANG=C. When I use LANG=ja_JP.utf8, it doesn't work (because Emacs fails to detect the prompt). The prompt string from GnuPG is "Enter passphrase: " in English (for the loopback mode). Please see the Emacs documentation for the configuration variable: comint-password-prompt-regexp If needed, for your native language, ask how it can be configured, possibly in Emacs forum. -- From lars.nooden at gmx.com Tue May 19 17:33:33 2026 From: lars.nooden at gmx.com (=?UTF-8?Q?Lars_Nood=C3=A9n?=) Date: Tue, 19 May 2026 18:33:33 +0300 Subject: Digital archeology -- verifying a signed Usenet message from 1995 In-Reply-To: References: <30dd480e-3ed7-4777-9c4e-b7c77d57ad3a@gmx.com> Message-ID: On 5/18/26 05:30, Jacob Bachmeyer wrote: > Found your problem:? the signature is from key 961F4A35 but you only > have key DCB9AE01.? "Go fish"---you will need the public key with ID > 961F4A35 to verify that signature. Thanks. I think I've been able to track down what might be the correct public key ID 961F4A35: https://web.archive.org/web/19970603193401/http://www.cs.hut.fi/ssh/ylo-key Though I had to use the --allow-non-selfsigned-uid option to import it. $ gpg1 --list-keys /home/me/.gnupg/pubring.gpg ----------------------------- gpg: Note: signatures using the MD5 algorithm are rejected pub 1024R/961F4A35 1995-01-23 uid Tatu Ylonen I've looked at the part of the GnuPG documentation which covers signature verification, and the matching article: https://www.gnupg.org/gph/en/manual/x135.html https://www.gnupg.org/blog/20251226-cleartext-signatures.html And I followed the instructions there. Oddly, gpg1 complains about the public key: $ gpg1 --verify message.usenet gpg: Signature made Wed 12 Jul 1995 05:50:42 PM EEST using RSA key ID 961F4A35 gpg: Note: signatures using the MD5 algorithm are rejected gpg: Can't check signature: bad public key Even if I split out the signature into a second file, I still get a "bad public key" error with the detached signature: $ sed -n -e '/BEGIN PGP SIGNATURE/,/END PGP SIGNATURE/p' \ message.usenet | tee message.sig $ gpg1 --verify message.sig message.usenet gpg: Signature made Wed 12 Jul 1995 05:50:42 PM EEST using RSA key ID 961F4A35 gpg: Note: signatures using the MD5 algorithm are rejected gpg: Can't check signature: bad public key At least it's not the "public key not found" error. What have I missed? Do I need an older version of GPG1? /Lars From wk at gnupg.org Tue May 19 20:16:56 2026 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 May 2026 20:16:56 +0200 Subject: Digital archeology -- verifying a signed Usenet message from 1995 In-Reply-To: ("Lars =?utf-8?Q?Nood=C3=A9n?= via Gnupg-users"'s message of "Tue, 19 May 2026 18:33:33 +0300") References: <30dd480e-3ed7-4777-9c4e-b7c77d57ad3a@gmx.com> Message-ID: <87zf1vclif.fsf@jacob.g10code.de> On Tue, 19 May 2026 18:33, Lars Nood?n said: > $ gpg1 --verify message.sig message.usenet > gpg: Signature made Wed 12 Jul 1995 05:50:42 PM EEST using RSA key ID > 961F4A35 > gpg: Note: signatures using the MD5 algorithm are rejected > gpg: Can't check signature: bad public key > > At least it's not the "public key not found" error. > > What have I missed? Do I need an older version of GPG1? Add this option: --allow-weak-digest-algos 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: 284 bytes Desc: not available URL: From lars.nooden at gmx.com Tue May 19 20:16:18 2026 From: lars.nooden at gmx.com (=?UTF-8?Q?Lars_Nood=C3=A9n?=) Date: Tue, 19 May 2026 21:16:18 +0300 Subject: Digital archeology -- verifying a signed Usenet message from 1995 In-Reply-To: <87zf1vclif.fsf@jacob.g10code.de> References: <30dd480e-3ed7-4777-9c4e-b7c77d57ad3a@gmx.com> <87zf1vclif.fsf@jacob.g10code.de> Message-ID: <0de1970f-c749-42b9-8155-e50112e801cf@gmx.com> On 5/19/26 21:16, Werner Koch wrote: > Add this option: --allow-weak-digest-algos Thanks! And thanks again to everyone who read and/or answered earlier. The final result is: $ gpg1 --allow-weak-digest-algos --verify message.usenet gpg: Signature made Wed 12 Jul 1995 05:50:42 PM EEST using RSA key ID 961F4A35 gpg: WARNING: digest algorithm MD5 is deprecated gpg: please see https://gnupg.org/faq/weak-digest-algos.html for more information gpg: Good signature from "Tatu Ylonen " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: B7 45 AF 9F F0 1A A1 F5 D3 38 B0 F8 36 D1 3F 17 Very cool. /Lars