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 From marqueandreprisal at duck.com Mon May 25 06:31:51 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 25 May 2026 00:31:51 -0400 Subject: intro Message-ID: Just let me introduce myself I am a GnuPG user looking for support. I am new to all of this gpg2 my experiece goes back to original PGP. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 281 bytes Desc: not available URL: From marqueandreprisal at duck.com Mon May 25 06:36:55 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 25 May 2026 00:36:55 -0400 Subject: standard comment References: <3d9cd3f3-cb48-4b44-9316-d4a74eedc14b@kolabnow.com> Message-ID: <858926A2-4B81-4A51-A22C-36F82DCEAA8C.1@smtp-inbound1.duck.com> ---------------------------------------- From: f3yrlbz3pm6kidor3rtwgy6afwzhrfntf1mo89drhkjnd9ad5oe3o4s15ak0j58 at kolabnow.com To: gnupg-users_at_gnupg.org_marqueandreprisal at duck.com Date: May 25, 2026 02:36:47 Subject: intro > Just let me introduce myself I am a GnuPG user looking for support. I > am new to all of this gpg2 my experiece goes back to original PGP. How would this fine community recommend to make a standardized comment about keys being used in unsecure environments. For example buying an android? off of the shelf and using keys with GnuPG Termux or Open Keychain is not sure because androids often have swap files which may be setup to dump memory and snag the private key. Something like: Note also that some systems (especially android?) may have not secure swap files. This writes memory to disk. Unless measures are taken in the operating system to protect memory the sensitive material may be exposed. Or: This key was created in an environment not known to be secure. (android?) Or some combination of both as concise as possible. Another to agree with myself upon the comment section should officialy make this a standard lack of security comment tag. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 281 bytes Desc: not available URL: From mm at dorfdsl.de Mon May 25 09:28:40 2026 From: mm at dorfdsl.de (Marco Moock) Date: Mon, 25 May 2026 09:28:40 +0200 Subject: intro In-Reply-To: References: Message-ID: Am 25.05.26 um 06:31 schrieb marqueandreprisal--- via Gnupg-users: > Just let me introduce myself I am a GnuPG user looking for support. I am > new to all of this gpg2 my experiece goes back to original PGP. Then you can ask your question here. -- Gru? Marco Muell und Spam bitte an abfalleimer2002 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 mm at dorfdsl.de Mon May 25 09:30:15 2026 From: mm at dorfdsl.de (Marco Moock) Date: Mon, 25 May 2026 09:30:15 +0200 Subject: standard comment In-Reply-To: <858926A2-4B81-4A51-A22C-36F82DCEAA8C.1@smtp-inbound1.duck.com> References: <3d9cd3f3-cb48-4b44-9316-d4a74eedc14b@kolabnow.com> <858926A2-4B81-4A51-A22C-36F82DCEAA8C.1@smtp-inbound1.duck.com> Message-ID: Am 25.05.26 um 06:36 schrieb marqueandreprisal--- via Gnupg-users: > Something like: Note also that some systems (especially android?) may > have not secure swap files. This writes memory to disk. Unless measures > are taken in the operating system to protect memory the sensitive > material may be exposed. This is common for various operating systems. Encrypt the hard disk (and the place of the swap) to circumvent that. -- Gru? Marco Muell und Spam bitte an abfalleimer2002 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 marqueandreprisal at duck.com Mon May 25 09:44:04 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 25 May 2026 03:44:04 -0400 Subject: standard comment References: <3d9cd3f3-cb48-4b44-9316-d4a74eedc14b@kolabnow.com> <858926A2-4B81-4A51-A22C-36F82DCEAA8C.1@smtp-inbound1.duck.com> <2CC12F39-7465-4198-B155-A39AA84496E1.1@smtp-inbound1.duck.com> Message-ID: <1973ED0D-7AA7-4C41-A4A2-8FB1A49ECF3D.1@smtp-inbound1.duck.com> That is really an OS developer's job and because of this most of GnuPG users will find gpg impotent. The original PGP was released for DOS where most of the assumptions were met and your private key may have been placed on a removable floppy. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 281 bytes Desc: not available URL: From marqueandreprisal at duck.com Mon May 25 09:51:14 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 25 May 2026 03:51:14 -0400 Subject: Unable to issue subkey revocation Message-ID: <5DF4C95C-A318-4389-B782-B0D16B86FD20.1@smtp-inbound1.duck.com> After the key was revoked looking at it in Open Keychain shows the primary key revoked and the encryption subkey is not listed as revoked showing active. In GnuPG list the subkey shows revoked. After hours of trying it seems like GnuPG is unable to issue a subkey revocation properly because I even tried implicitly specifying the subkey ID. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 281 bytes Desc: not available URL: From marqueandreprisal at duck.com Mon May 25 09:53:18 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 25 May 2026 03:53:18 -0400 Subject: intro References: <51C94258-CBFA-4DC9-8720-C3A6D05CC4A8.1@smtp-inbound1.duck.com> Message-ID: What are the rules about posting to the list encrypted? From mm at dorfdsl.de Mon May 25 09:57:14 2026 From: mm at dorfdsl.de (Marco Moock) Date: Mon, 25 May 2026 09:57:14 +0200 Subject: standard comment In-Reply-To: <1973ED0D-7AA7-4C41-A4A2-8FB1A49ECF3D.1@smtp-inbound1.duck.com> References: <3d9cd3f3-cb48-4b44-9316-d4a74eedc14b@kolabnow.com> <858926A2-4B81-4A51-A22C-36F82DCEAA8C.1@smtp-inbound1.duck.com> <2CC12F39-7465-4198-B155-A39AA84496E1.1@smtp-inbound1.duck.com> <1973ED0D-7AA7-4C41-A4A2-8FB1A49ECF3D.1@smtp-inbound1.duck.com> Message-ID: Am 25.05.26 um 09:44 schrieb marqueandreprisal--- via Gnupg-users: > That is really an OS developer's job and because of this most of GnuPG > users will find gpg impotent. The original PGP was released for DOS > where most of the assumptions were met and your private key may have > been placed on a removable floppy. This is part of the OS, not GnuPG. You can configure your OS to encrypt the entire disk (except the boot loader and kernel) to have such an environment. If the swap is the issue, you can also disable swap in Linux, BSD and Windows. -- Gru? Marco Muell und Spam bitte an abfalleimer2002 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 mm at dorfdsl.de Mon May 25 09:58:56 2026 From: mm at dorfdsl.de (Marco Moock) Date: Mon, 25 May 2026 09:58:56 +0200 Subject: intro In-Reply-To: References: <51C94258-CBFA-4DC9-8720-C3A6D05CC4A8.1@smtp-inbound1.duck.com> Message-ID: <0d802505-7b26-45f5-a67a-a6bbe452b2ac@dorfdsl.de> Am 25.05.26 um 09:53 schrieb marqueandreprisal--- via Gnupg-users: > What are the rules about posting to the list encrypted? You cannot, as you would need the public key of every (possible) subscriber. This list is public and will be archived, so be aware that anyone can read it later. -- Gru? Marco Muell und Spam bitte an abfalleimer2002 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 marqueandreprisal at duck.com Mon May 25 10:51:09 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 25 May 2026 04:51:09 -0400 Subject: intro References: <51C94258-CBFA-4DC9-8720-C3A6D05CC4A8.1@smtp-inbound1.duck.com> <0d802505-7b26-45f5-a67a-a6bbe452b2ac@dorfdsl.de> <8ABFEF9E-1B89-4536-98A7-D7F9838A7696.1@smtp-inbound1.duck.com> Message-ID: <41C5F612-35B4-44DA-AF3A-28AE2F78FBE0.1@smtp-inbound1.duck.com> A non-text attachment was scrubbed... Name: not available Type: application/pgp-encrypted Size: 11 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: encrypted.asc Type: application/octet-stream Size: 1284 bytes Desc: not available URL: From andrewg at andrewg.com Mon May 25 10:51:52 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 25 May 2026 09:51:52 +0100 Subject: Unable to issue subkey revocation In-Reply-To: <5DF4C95C-A318-4389-B782-B0D16B86FD20.1@smtp-inbound1.duck.com> References: <5DF4C95C-A318-4389-B782-B0D16B86FD20.1@smtp-inbound1.duck.com> Message-ID: Would you be willing to post the revoked key here so we can examine it? The problem may not be in gnupg. A On 25/05/2026 08:51, marqueandreprisal--- via Gnupg-users wrote: > After the key was revoked looking at it in Open Keychain shows the > primary key revoked and the encryption subkey is not listed as revoked > showing active. In GnuPG list the subkey shows revoked. After hours of > trying it seems like GnuPG is unable to issue a subkey revocation > properly because I even tried implicitly specifying the subkey ID. From andrewg at andrewg.com Mon May 25 10:54:19 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 25 May 2026 09:54:19 +0100 Subject: Unable to issue subkey revocation In-Reply-To: References: <5DF4C95C-A318-4389-B782-B0D16B86FD20.1@smtp-inbound1.duck.com> Message-ID: <8ec9d54a-5db3-4354-baf2-844db21affe1@andrewg.com> I should also say: be careful to post only the public key, not the private key! On 25/05/2026 09:51, Andrew Gallagher via Gnupg-users wrote: > Would you be willing to post the revoked key here so we can examine it? > The problem may not be in gnupg. > > A > On 25/05/2026 08:51, marqueandreprisal--- via Gnupg-users wrote: >> After the key was revoked looking at it in Open Keychain shows the >> primary key revoked and the encryption subkey is not listed as revoked >> showing active. In GnuPG list the subkey shows revoked. After hours of >> trying it seems like GnuPG is unable to issue a subkey revocation >> properly because I even tried implicitly specifying the subkey ID. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users From marqueandreprisal at duck.com Mon May 25 11:01:05 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 25 May 2026 05:01:05 -0400 Subject: Unable to issue subkey revocation References: <5DF4C95C-A318-4389-B782-B0D16B86FD20.1@smtp-inbound1.duck.com> Message-ID: ---------------------------------------- From: Andrew Gallagher via Gnupg-users To: gnupg-users at gnupg.org Date: May 25, 2026 08:53:04 Subject: Re: Unable to issue subkey revocation > Would you be willing to post the revoked key here so we can examine it? > The problem may not be in gnupg. > > A > On 25/05/2026 08:51, marqueandreprisal--- via Gnupg-users wrote: >> After the key was revoked looking at it in Open Keychain shows the >> primary key revoked and the encryption subkey is not listed as revoked >> showing active. In GnuPG list the subkey shows revoked. After hours of >> trying it seems like GnuPG is unable to issue a subkey revocation >> properly because I even tried implicitly specifying the subkey ID. > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users The key is displayed in this screenshot attached. Perhaps I can also post the appended revocation packets which seem to only revoke the primary key. How would I go about doing that with gpg2? -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot_20260525-085348_OpenKeychain.png Type: image/png Size: 63266 bytes Desc: not available URL: From marqueandreprisal at duck.com Mon May 25 11:06:33 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 25 May 2026 05:06:33 -0400 Subject: Unable to issue subkey revocation References: <5DF4C95C-A318-4389-B782-B0D16B86FD20.1@smtp-inbound1.duck.com> <8ec9d54a-5db3-4354-baf2-844db21affe1@andrewg.com> <309469AF-3740-45D6-A266-564922F7D511.1@smtp-inbound1.duck.com> Message-ID: About being careful not to post the private key. I would be embarrassed to accidentally upload my private key. I recall PGP 1 having a "keypair" with a fingerprint of the private key and public key however in this new gpg2 it appears the same fingerprint identifies both the seckey and pubkey. Is the long ID actually a fingerprint of the pubkey even when identifying the seckey within gpg2? From marqueandreprisal at duck.com Mon May 25 11:19:16 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 25 May 2026 05:19:16 -0400 Subject: standard comment References: <3d9cd3f3-cb48-4b44-9316-d4a74eedc14b@kolabnow.com> <858926A2-4B81-4A51-A22C-36F82DCEAA8C.1@smtp-inbound1.duck.com> <2CC12F39-7465-4198-B155-A39AA84496E1.1@smtp-inbound1.duck.com> <1973ED0D-7AA7-4C41-A4A2-8FB1A49ECF3D.1@smtp-inbound1.duck.com> Message-ID: As you may lookup in the uid of the key used to sign this post the standard comment is: This key was created in an environment not known to be secure. END OF THREAD -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 281 bytes Desc: not available URL: From andrewg at andrewg.com Mon May 25 11:49:33 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 25 May 2026 10:49:33 +0100 Subject: Unable to issue subkey revocation In-Reply-To: References: <5DF4C95C-A318-4389-B782-B0D16B86FD20.1@smtp-inbound1.duck.com> Message-ID: <90ba0e03-e767-40a5-843f-fe5a4dcd1a2e@andrewg.com> On 25/05/2026 10:01, marqueandreprisal--- via Gnupg-users wrote: > The key is displayed in this screenshot attached. Perhaps I can also > post the appended revocation packets which seem to only revoke the > primary key. The screenshot attached appears to show two subkeys - one is a signing subkey that is revoked and one an encryption subkey that is not. But the signing subkey appears to have the same fingerprint as the primary, which should not happen. > How would I go about doing that with gpg2? gpg --armor --export a3ed3c7160b7e73f > revoked-key.asc And then attach the file to your reply. Thanks, A From andrewg at andrewg.com Mon May 25 11:52:12 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 25 May 2026 10:52:12 +0100 Subject: Unable to issue subkey revocation In-Reply-To: References: <5DF4C95C-A318-4389-B782-B0D16B86FD20.1@smtp-inbound1.duck.com> <8ec9d54a-5db3-4354-baf2-844db21affe1@andrewg.com> <309469AF-3740-45D6-A266-564922F7D511.1@smtp-inbound1.duck.com> Message-ID: <92d69d5d-d86a-4cd3-986a-87622aa5bcd8@andrewg.com> On 25/05/2026 10:06, marqueandreprisal--- via Gnupg-users wrote: > About being careful not to post the private key. I would be embarrassed > to accidentally upload my private key. I recall PGP 1 having a "keypair" > with a fingerprint of the private key and public key however in this new > gpg2 it appears the same fingerprint identifies both the seckey and > pubkey. Is the long ID actually a fingerprint of the pubkey even when > identifying the seckey within gpg2? The fingerprint identifies the key pair, not the public or secret component separately, and is always calculated from the public key. If a key appears to have multiple fingerprints, it will be because there are one or more subkeys. A From marqueandreprisal at duck.com Mon May 25 12:52:39 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 25 May 2026 06:52:39 -0400 Subject: Unable to issue subkey revocation References: <5DF4C95C-A318-4389-B782-B0D16B86FD20.1@smtp-inbound1.duck.com> <8ec9d54a-5db3-4354-baf2-844db21affe1@andrewg.com> <309469AF-3740-45D6-A266-564922F7D511.1@smtp-inbound1.duck.com> <92d69d5d-d86a-4cd3-986a-87622aa5bcd8@andrewg.com> <0CD4CCC6-AF5B-48B6-8EA2-587C32611CE1.1@smtp-inbound1.duck.com> Message-ID: <26B6F5E2-0CDD-4D93-A306-7D96D3654F3C.1@smtp-inbound1.duck.com> ---------------------------------------- From: Andrew Gallagher via Gnupg-users To: gnupg-users at gnupg.org Date: May 25, 2026 09:53:42 Subject: Re: Unable to issue subkey revocation > On 25/05/2026 10:06, marqueandreprisal--- via Gnupg-users wrote: >> About being careful not to post the private key. I would be >> embarrassed to accidentally upload my private key. I recall PGP 1 >> having a "keypair" with a fingerprint of the private key and public >> key however in this new gpg2 it appears the same fingerprint >> identifies both the seckey and pubkey. Is the long ID actually a >> fingerprint of the pubkey even when identifying the seckey within >> gpg2? > The fingerprint identifies the key pair, not the public or secret > component separately, and is always calculated from the public key. If > a key appears to have multiple fingerprints, it will be because there > are one or more subkeys. > > A > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users Would you be able to quickly and accurately explain this fingerprint function of gpg2 in a small paragraph? -- G? From marqueandreprisal at duck.com Mon May 25 13:03:24 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 25 May 2026 07:03:24 -0400 Subject: Unable to issue subkey revocation References: <5DF4C95C-A318-4389-B782-B0D16B86FD20.1@smtp-inbound1.duck.com> <90ba0e03-e767-40a5-843f-fe5a4dcd1a2e@andrewg.com> <2CDBD1EF-C958-48E7-A3CE-7D954EC989A1.1@smtp-inbound1.duck.com> Message-ID: <6170FD2E-5492-42B6-9D92-52723617C239.1@smtp-inbound1.duck.com> I didn't notice a signing subkey in the screenshot it appeared to me the primary key is revoked while the E subkey was not. Again however in gpg2 it reportes the E revoked maybe based only in the assumption that if the primary is revoked so are the subkeys, it seems to be a bug in gpg2. What is it that looks like a S subkey to you, A? As far as the export revocation command it is not clear why you want me to send it to you here. In the hours wasted with AI trying to figure this out as I stated in the opening I did try to implicitly revoke the subkey by using the subkey ID to issue revocation and when doing so gpg2 would report "no change". -- G? From marqueandreprisal at duck.com Mon May 25 13:10:02 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 25 May 2026 07:10:02 -0400 Subject: Unable to issue subkey revocation References: <5DF4C95C-A318-4389-B782-B0D16B86FD20.1@smtp-inbound1.duck.com> <90ba0e03-e767-40a5-843f-fe5a4dcd1a2e@andrewg.com> <2CDBD1EF-C958-48E7-A3CE-7D954EC989A1.1@smtp-inbound1.duck.com> Message-ID: <761D0370-3835-4239-A326-7FDD7223FA11.1@smtp-inbound1.duck.com> A, oh it seems you want me to attach the pubkey for you to examine. The key is still on keys.openpgp.org[https://keys.openpgp.org] just search the key id shown in the screenshot. From andrewg at andrewg.com Mon May 25 13:15:21 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 25 May 2026 12:15:21 +0100 Subject: Unable to issue subkey revocation In-Reply-To: <6170FD2E-5492-42B6-9D92-52723617C239.1@smtp-inbound1.duck.com> References: <5DF4C95C-A318-4389-B782-B0D16B86FD20.1@smtp-inbound1.duck.com> <90ba0e03-e767-40a5-843f-fe5a4dcd1a2e@andrewg.com> <2CDBD1EF-C958-48E7-A3CE-7D954EC989A1.1@smtp-inbound1.duck.com> <6170FD2E-5492-42B6-9D92-52723617C239.1@smtp-inbound1.duck.com> Message-ID: <59498334-26c8-4ccd-bde6-299a6efdf27a@andrewg.com> On 25/05/2026 12:03, marqueandreprisal--- via Gnupg-users wrote: > I didn't notice a signing subkey in the screenshot it appeared to me the > primary key is revoked while the E subkey was not. Well, the first key is listed under "subkeys" so if it's actually the primary key then there's a bug in openkeychain, because the primary key is not a subkey. > Again however in gpg2 > it reportes the E revoked maybe based only in the assumption that if the > primary is revoked so are the subkeys, it seems to be a bug in gpg2. Or it could be a bug in openkeychain. Given that it already seems to think that the primary key is a subkey, it may be that something internally has recorded that "the first subkey is revoked" and there's a mismatch internally so it gets displayed wrong. > As far as the export revocation command it is not clear why you want me > to send it to you here. Because I can tell by looking at it which (sub)key is really revoked - and it seems more likely to me that it is gpg that is correct. > In the hours wasted with AI trying to figure > this out as I stated in the opening I did try to implicitly revoke the > subkey by using the subkey ID to issue revocation and when doing so gpg2 > would report "no change". If you had already revoked it, and tried to revoke it again, then this would be expected. A From rjh at sixdemonbag.org Mon May 25 13:18:05 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 25 May 2026 07:18:05 -0400 Subject: standard comment In-Reply-To: <858926A2-4B81-4A51-A22C-36F82DCEAA8C.1@smtp-inbound1.duck.com> References: <3d9cd3f3-cb48-4b44-9316-d4a74eedc14b@kolabnow.com> <858926A2-4B81-4A51-A22C-36F82DCEAA8C.1@smtp-inbound1.duck.com> Message-ID: <853cdc1d-56f2-4f6b-bfd2-59d4adff1d66@sixdemonbag.org> > How would this fine community recommend to make a standardized comment > about keys being used in unsecure environments. Your question sounds like "how can I best mitigate the risks of playing Russian roulette?" The answer is elegantly simple: don't play Russian roulette. There is no way to effectively mitigate the risks once you start playing Russian roulette. If I were to see a warning like the one you mention, I would read it as, "I cannot be trusted to properly employ even basic communications security. Everything I'm doing is security theater." Don't expose your unencrypted private certificate to an untrusted environment. It really is that simple. If you don't trust your Android environment, don't ever allow your unencrypted private certificate to be stored on it, even briefly. -------------- 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 Mon May 25 13:45:59 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 25 May 2026 12:45:59 +0100 Subject: Unable to issue subkey revocation In-Reply-To: <761D0370-3835-4239-A326-7FDD7223FA11.1@smtp-inbound1.duck.com> References: <5DF4C95C-A318-4389-B782-B0D16B86FD20.1@smtp-inbound1.duck.com> <90ba0e03-e767-40a5-843f-fe5a4dcd1a2e@andrewg.com> <2CDBD1EF-C958-48E7-A3CE-7D954EC989A1.1@smtp-inbound1.duck.com> <761D0370-3835-4239-A326-7FDD7223FA11.1@smtp-inbound1.duck.com> Message-ID: <673230fa-ab06-4e5c-bbfc-ce5a751ec8c6@andrewg.com> On 25/05/2026 12:10, marqueandreprisal--- via Gnupg-users wrote: > A, oh it seems you want me to attach the pubkey for you to examine. The > key is still on keys.openpgp.org[https://keys.openpgp.org] just search > the key id shown in the screenshot. OK, got it. It appears that the primary key is indeed revoked. The openkeychain screenshot implies that the primary key is a "subkey", which is incorrect, but this does not appear to have affected the validity calculation. If I look at the key in gpg, it also shows that the primary has been revoked: ``` pub rsa3072/0xA3ED3C7160B7E73F 2026-04-27 [SCEA] [revoked: 2026-05-24] C18FAB74166C6BBB2196B5B5A3ED3C7160B7E73F reason for revocation: Key has been compromised revocation comment: private key was copied during backup operation ``` Do you see something different in yours? How did you revoke the subkey? The usual procedure on the command line would be: ``` gpg --edit-key key 1 revkey save ``` The critical part being "key 1" that selects the first subkey (it should show a "*" beside the subkey after you do it). If you don't select the subkey then you will revoke the primary. Beware also that if you say "key 1" twice, the second will undo the first (because it is a toggle) and you will still revoke the primary. A From paolobrignoli25 at proton.me Mon May 25 20:38:37 2026 From: paolobrignoli25 at proton.me (paolobrignoli25) Date: Mon, 25 May 2026 18:38:37 +0000 Subject: pinentry-tty writes the typed passphrase to stdin if it times out Message-ID: <6IU1q8FF8B2jvSkpbEwPbBDkmCveOmcQ71CA5cqVQ6jqoFanzLc0S_PalVB1USG9nldUllu5vsjJF-v3INyvoVwImlr-gLpH29Z21FcIL4o=@proton.me> [N] tc at fedora ~> cat .gnupg/gpg-agent.conf no-allow-loopback-pinentry pinentry-program /usr/bin/pinentry-tty pinentry-timeout 2 [N] tc at fedora ~> gpg -d /tmp/file.gpg gpg: encrypted with cv25519 key, ID E667CEDA83DFC1C0, created 2026-05-25 "tom" Please enter the passphrase to unlock the OpenPGP secret key: "tom" 255-bit ECDH key, ID E667CEDA83DFC1C0, created 2026-05-25 (main key ID 6EC11A7823852CC9). Passphrase: gpg: public key decryption failed: Timeout gpg: decryption failed: Timeout [I] tc at fedora ~ [2]> fef #that's what i wrote before pinentry timed out, in my shell's stdin #(not that writing it to stdout or stderr would be better, #but i thought that was relevant). here is the proof: fish: fef: command not found... # my shell tried to run `fef' after i pressed enter Is this an intended, or at least known behavior? Should i report it as a bug? i found nothing on the bug tracker. From marqueandreprisal at duck.com Tue May 26 00:33:36 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 25 May 2026 18:33:36 -0400 Subject: Unable to issue subkey revocation References: <5DF4C95C-A318-4389-B782-B0D16B86FD20.1@smtp-inbound1.duck.com> <90ba0e03-e767-40a5-843f-fe5a4dcd1a2e@andrewg.com> <2CDBD1EF-C958-48E7-A3CE-7D954EC989A1.1@smtp-inbound1.duck.com> <6170FD2E-5492-42B6-9D92-52723617C239.1@smtp-inbound1.duck.com> <59498334-26c8-4ccd-bde6-299a6efdf27a@andrewg.com> <4CC26646-9C4E-4AC4-8E94-50F557FAD038.1@smtp-inbound1.duck.com> Message-ID: <6671D42E-8833-4E7D-A859-288C83B51F2B.1@smtp-inbound1.duck.com> I glossed over the fact that it is listed under subkeys because I was focused on the wax seal icon which I take it indicates the primary key. It look's like a red thesecret wax seal but in the screenshot is greyed out. You suppose this is a bug in OpenKeychain. I also supposed it is a bug in gpgp2 because I was not able to confirm revocation packets in the subkey while gpg2 report's the subkey revoked. Can you examine the key from the keys.openpgp.org[https://keys.openpgp.org] keyserver and see if there are revocation packets in the subkey? When I looked as I stated in the opening I am a beginner at gpg2 and I did not see any indication the subkey has revocation packets. What are the gpg2 commands to read the pubkey for revocation packets under the subkey? What should I look for? From andrewg at andrewg.com Tue May 26 00:42:31 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 25 May 2026 23:42:31 +0100 Subject: Unable to issue subkey revocation In-Reply-To: <6671D42E-8833-4E7D-A859-288C83B51F2B.1@smtp-inbound1.duck.com> References: <5DF4C95C-A318-4389-B782-B0D16B86FD20.1@smtp-inbound1.duck.com> <90ba0e03-e767-40a5-843f-fe5a4dcd1a2e@andrewg.com> <2CDBD1EF-C958-48E7-A3CE-7D954EC989A1.1@smtp-inbound1.duck.com> <6170FD2E-5492-42B6-9D92-52723617C239.1@smtp-inbound1.duck.com> <59498334-26c8-4ccd-bde6-299a6efdf27a@andrewg.com> <4CC26646-9C4E-4AC4-8E94-50F557FAD038.1@smtp-inbound1.duck.com> <6671D42E-8833-4E7D-A859-288C83B51F2B.1@smtp-inbound1.duck.com> Message-ID: On 25/05/2026 23:33, marqueandreprisal--- via Gnupg-users wrote: > What are the gpg2 commands to read the pubkey for revocation packets > under the subkey? What should I look for? `gpg --list-packets < FILENAME` will show you the packets in order. All signature packets (including revocation packets) apply to the immediately preceding non-signature packet. A From marqueandreprisal at duck.com Tue May 26 01:02:42 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 25 May 2026 19:02:42 -0400 Subject: Unable to issue subkey revocation References: <5DF4C95C-A318-4389-B782-B0D16B86FD20.1@smtp-inbound1.duck.com> <90ba0e03-e767-40a5-843f-fe5a4dcd1a2e@andrewg.com> <2CDBD1EF-C958-48E7-A3CE-7D954EC989A1.1@smtp-inbound1.duck.com> <761D0370-3835-4239-A326-7FDD7223FA11.1@smtp-inbound1.duck.com> <673230fa-ab06-4e5c-bbfc-ce5a751ec8c6@andrewg.com> Message-ID: <9DAD5DD1-0EAC-4BB4-9ED0-5D956F2E7C26.1@smtp-inbound1.duck.com> As I said yes I have done exactly this: ``` gpg --edit-key key 1 revkey save ``` and is why I supposed a bug in gpg2. After doing so the key reports "no change". My guess of what the bug is would be when the primary key has been revoked gpg2 only assumes all subkeys are revoked while not actually applying subkey revocation packets. To confirm this bug take a look at the key on keys.openpgp.org[https://keys.openpgp.org] and see if there are no revocation packets in the subkey. From marqueandreprisal at duck.com Tue May 26 02:15:06 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 25 May 2026 20:15:06 -0400 Subject: building from source Message-ID: <7A681C43-E138-4730-AAFC-4307365D7FA7.1@smtp-inbound1.duck.com> When downloading the source tar it is labled w32 is the source not designed to build on linux? -- G? From gniibe at fsij.org Tue May 26 02:25:42 2026 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 26 May 2026 09:25:42 +0900 Subject: pinentry-tty writes the typed passphrase to stdin if it times out In-Reply-To: <6IU1q8FF8B2jvSkpbEwPbBDkmCveOmcQ71CA5cqVQ6jqoFanzLc0S_PalVB1USG9nldUllu5vsjJF-v3INyvoVwImlr-gLpH29Z21FcIL4o=@proton.me> References: <6IU1q8FF8B2jvSkpbEwPbBDkmCveOmcQ71CA5cqVQ6jqoFanzLc0S_PalVB1USG9nldUllu5vsjJF-v3INyvoVwImlr-gLpH29Z21FcIL4o=@proton.me> Message-ID: <878q972f09.fsf@haruna.fsij.org> Hello, Thank you for your report. paolobrignoli25 wrote: > Is this an intended, or at least known behavior? I don't think it is intended. I think that pinentry-tty is not recommended to use (use loopback pinentry mode, instead). I will commit the change attached if no one complains. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: pinentry-tty-should-flush-input-at-timeout.patch Type: text/x-patch Size: 789 bytes Desc: not available URL: From rjh at sixdemonbag.org Tue May 26 02:38:41 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 25 May 2026 20:38:41 -0400 Subject: building from source In-Reply-To: <7A681C43-E138-4730-AAFC-4307365D7FA7.1@smtp-inbound1.duck.com> References: <7A681C43-E138-4730-AAFC-4307365D7FA7.1@smtp-inbound1.duck.com> Message-ID: > When downloading the source tar it is labled w32 is the source not > designed to build on linux? The website's Download page (https://www.gnupg.org/download/index.html) lists this as the current location of the stable source code: https://www.gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.20.tar.bz2 Given it is not labeled w32, I don't see the problem. -------------- 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 marqueandreprisal at duck.com Tue May 26 02:44:56 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 25 May 2026 20:44:56 -0400 Subject: Unable to issue subkey revocation References: <5DF4C95C-A318-4389-B782-B0D16B86FD20.1@smtp-inbound1.duck.com> <90ba0e03-e767-40a5-843f-fe5a4dcd1a2e@andrewg.com> <2CDBD1EF-C958-48E7-A3CE-7D954EC989A1.1@smtp-inbound1.duck.com> <6170FD2E-5492-42B6-9D92-52723617C239.1@smtp-inbound1.duck.com> <59498334-26c8-4ccd-bde6-299a6efdf27a@andrewg.com> <4CC26646-9C4E-4AC4-8E94-50F557FAD038.1@smtp-inbound1.duck.com> <6671D42E-8833-4E7D-A859-288C83B51F2B.1@smtp-inbound1.duck.com> <1172AC7A-D65D-4DCC-9683-8A9C84465614.1@smtp-inbound1.duck.com> Message-ID: A, can you get it on keyserver and examine it because that is the purpose of support I get a clean environment to test outside of my stuff. Also I don't know what to look for I have never revoked a gpg2 key before. From marqueandreprisal at duck.com Tue May 26 02:56:44 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 25 May 2026 20:56:44 -0400 Subject: Unable to issue subkey revocation References: <5DF4C95C-A318-4389-B782-B0D16B86FD20.1@smtp-inbound1.duck.com> <90ba0e03-e767-40a5-843f-fe5a4dcd1a2e@andrewg.com> <2CDBD1EF-C958-48E7-A3CE-7D954EC989A1.1@smtp-inbound1.duck.com> <6170FD2E-5492-42B6-9D92-52723617C239.1@smtp-inbound1.duck.com> <59498334-26c8-4ccd-bde6-299a6efdf27a@andrewg.com> <4CC26646-9C4E-4AC4-8E94-50F557FAD038.1@smtp-inbound1.duck.com> <6671D42E-8833-4E7D-A859-288C83B51F2B.1@smtp-inbound1.duck.com> <1172AC7A-D65D-4DCC-9683-8A9C84465614.1@smtp-inbound1.duck.com> Message-ID: <5EC00FED-5B7C-4E2C-850A-9C548A6F1BDC.1@smtp-inbound1.duck.com> Just be honest and say we don't care because the bug in my termux build is not an official w32 GnuPG build if this is the case. However I ask you to check because.maybe somebody can confirm this same bug comes from an upstream official w32 build code. I need you to check, A. Not guess it is a bug in something else. This is supposed to be a support group not a waste time and diversion. Just going through basic troubleshooting steps over and over again to find out the same things I initially find drags on for days and wastes hours. Again I do not see any revocation packet for the subkey as I have already humbly asserted because of my inexperience with gpg2. Here is the full output that seems to show the SUBKEY WAS NOT REVOKED: ~ $ gpg --list-packets revokedkey?????????????????????????????? # off=0 ctb=99 tag=6 hlen=3 plen=397 :public key packet: ??????? version 4, algo 1, created 1777277631, expires 0??????????????? pkey[0]: [3072 bits] ??????? pkey[1]: [17 bits] ??????? keyid: A3ED3C7160B7E73F???????????????????????????????? # off=400 ctb=89 tag=2 hlen=3 plen=438 :signature packet: algo 1, keyid A3ED3C7160B7E73F ??????? version 4, created 1779673718, md5len 0, sigclass 0x20 ??????? digest algo 8, begin of digest 59 aa ??????? hashed subpkt 33 len 21 (issuer fpr v4 C18FAB74166C6BBB2196B5B5A3ED3C7160B7E73F) ??????? hashed subpkt 2 len 4 (sig created 2026-05-25)????????????????? hashed subpkt 29 len 1 (revocation reason 0x02 ()) ??????? subpkt 16 len 8 (issuer key ID A3ED3C7160B7E73F) ??????? data: [3071 bits] # off=841 ctb=89 tag=2 hlen=3 plen=484 :signature packet: algo 1, keyid A3ED3C7160B7E73F ??????? version 4, created 1779631000, md5len 0, sigclass 0x20 ??????? digest algo 8, begin of digest 6a 74 ??????? hashed subpkt 33 len 21 (issuer fpr v4 C18FAB74166C6BBB2196B5B5A3ED3C7160B7E73F) ??????? hashed subpkt 2 len 4 (sig created 2026-05-24) ??????? hashed subpkt 29 len 47 (revocation reason 0x02 (private key was copied during backup operation)) ??????? subpkt 16 len 8 (issuer key ID A3ED3C7160B7E73F) ??????? data: [3072 bits] # off=1328 ctb=b4 tag=13 hlen=2 plen=55 :user ID packet: "marqueandreprisal at duck.com " # off=1385 ctb=89 tag=2 hlen=3 plen=529 :signature packet: algo 1, keyid A3ED3C7160B7E73F ??????? version 4, created 1779632530, md5len 0, sigclass 0x13 ??????? digest algo 8, begin of digest 38 97 ??????? hashed subpkt 20 len 26 (notation: manu=2,2.5+1.11,3,2) ??????? hashed subpkt 27 len 1 (key flags: 03) ??????? hashed subpkt 9 len 4 (key expires after 249d0h0m) ??????? hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2) ??????? hashed subpkt 34 len 1 (pref-aead-algos: 2) ??????? hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2) ??????? hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1) ??????? hashed subpkt 30 len 1 (features: 07) ??????? hashed subpkt 23 len 1 (keyserver preferences: 80) ??????? hashed subpkt 33 len 21 (issuer fpr v4 C18FAB74166C6BBB2196B5B5A3ED3C7160B7E73F) ??????? hashed subpkt 2 len 4 (sig created 2026-05-24) ??????? hashed subpkt 24 len 28 (preferred keyserver: hkps://keys.openpgp.org[https://openpgp.org] send) ??????? subpkt 16 len 8 (issuer key ID A3ED3C7160B7E73F) ??????? data: [3069 bits] # off=1917 ctb=b9 tag=14 hlen=3 plen=397 :public sub key packet: ??????? version 4, algo 1, created 1777277631, expires 0 ??????? pkey[0]: [3072 bits] ??????? pkey[1]: [17 bits] ??????? keyid: 2F9717264A3E71DC # off=2317 ctb=89 tag=2 hlen=3 plen=472 :signature packet: algo 1, keyid A3ED3C7160B7E73F ??????? version 4, created 1777277631, md5len 0, sigclass 0x18 ??????? digest algo 8, begin of digest 99 86 ??????? hashed subpkt 33 len 21 (issuer fpr v4 C18FAB74166C6BBB2196B5B5A3ED3C7160B7E73F) ??????? hashed subpkt 2 len 4 (sig created 2026-04-27)????????????????? hashed subpkt 20 len 26 (notation: manu=2,2.5+1.11,3,2) ??????? hashed subpkt 27 len 1 (key flags: 0C)????????????????????????? hashed subpkt 9 len 4 (key expires after 249d0h0m) ??????? subpkt 16 len 8 (issuer key ID A3ED3C7160B7E73F) ??????? data: [3068 bits] From rjh at sixdemonbag.org Tue May 26 03:08:05 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 25 May 2026 21:08:05 -0400 Subject: Unable to issue subkey revocation In-Reply-To: <5EC00FED-5B7C-4E2C-850A-9C548A6F1BDC.1@smtp-inbound1.duck.com> References: <5DF4C95C-A318-4389-B782-B0D16B86FD20.1@smtp-inbound1.duck.com> <90ba0e03-e767-40a5-843f-fe5a4dcd1a2e@andrewg.com> <2CDBD1EF-C958-48E7-A3CE-7D954EC989A1.1@smtp-inbound1.duck.com> <6170FD2E-5492-42B6-9D92-52723617C239.1@smtp-inbound1.duck.com> <59498334-26c8-4ccd-bde6-299a6efdf27a@andrewg.com> <4CC26646-9C4E-4AC4-8E94-50F557FAD038.1@smtp-inbound1.duck.com> <6671D42E-8833-4E7D-A859-288C83B51F2B.1@smtp-inbound1.duck.com> <1172AC7A-D65D-4DCC-9683-8A9C84465614.1@smtp-inbound1.duck.com> <5EC00FED-5B7C-4E2C-850A-9C548A6F1BDC.1@smtp-inbound1.duck.com> Message-ID: <1f7c9f8c-af7a-4683-bc88-8eb19004f326@sixdemonbag.org> > This is supposed to be a support group not a waste time and diversion. Andrew is the author of the OpenPGP HTTP Keyserver RFC (along with Daphne Shaw and Daniel Huigens). He's also the principal maintainer of Hockeypuck, the principal implementation of the aforementioned protocol. He's also made significant contributions to the OpenPGP and LibrePGP specs. He gives away his code for free, works behind the scenes to keep essential infrastructure running, and in his free time -- of which there isn't very much -- hangs out on this mailing list and smiles at newcomers and offers what help he can in his limited time. I understand you are frustrated. I sympathize. But you are taking out your frustrations on a valuable member of our community. Now might be a fine time to take a moment to step away. -------------- 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 marqueandreprisal at duck.com Tue May 26 04:23:07 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 25 May 2026 22:23:07 -0400 Subject: reporting a bug Message-ID: <0F222AFD-CC6E-4391-8EB5-46C7F4051333.1@smtp-inbound1.duck.com> "you need to ask on the gnupg-users or -devel mailing list for an account." Please provide the proper account to report a bug. -- G? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 281 bytes Desc: not available URL: From marqueandreprisal at duck.com Tue May 26 04:25:17 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 25 May 2026 22:25:17 -0400 Subject: building from source References: <7A681C43-E138-4730-AAFC-4307365D7FA7.1@smtp-inbound1.duck.com> <3D897F25-6F24-4152-8C49-B236C7088E48.1@smtp-inbound1.duck.com> Message-ID: gnupg-w32-2.5.20_20260513.tar.xz see w32. Oh you are here to bother me. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 281 bytes Desc: not available URL: From rjh at sixdemonbag.org Tue May 26 04:31:54 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 25 May 2026 22:31:54 -0400 Subject: building from source In-Reply-To: References: <7A681C43-E138-4730-AAFC-4307365D7FA7.1@smtp-inbound1.duck.com> <3D897F25-6F24-4152-8C49-B236C7088E48.1@smtp-inbound1.duck.com> Message-ID: > Oh you are here to bother me. So I * give you the full URL to the download page, * give you the full URL to the latest source for UNIX systems, * point out that it is not filled with Win32- specific code, * tell you I don't see the problem ... and this makes me * the bad guy. I'm curiously okay with that. I wish you well and I'll leave you be. Have a nice day. -------------- 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 marqueandreprisal at duck.com Tue May 26 05:44:58 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 25 May 2026 23:44:58 -0400 Subject: building from source References: <7A681C43-E138-4730-AAFC-4307365D7FA7.1@smtp-inbound1.duck.com> <3D897F25-6F24-4152-8C49-B236C7088E48.1@smtp-inbound1.duck.com> Message-ID: I selected stable with libs which does not specify w32 therefore stable looked to be w32. U said I wouldn't rely on other guys libs, source code like that is not auditable and thatbus not really full source code. Especially for security software the program should function self contained and there is no other way to audit it. If you doenload a piece of source code and it does not function without other guys libs that is a problem. You should be able to infer why I asked the question and what you handed out is not really useful to anybody because it isn't going to function without the code from the libs. That needs to be moved into the sodtware. From marqueandreprisal at duck.com Tue May 26 06:11:52 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Tue, 26 May 2026 00:11:52 -0400 Subject: Unable to issue subkey revocation References: <5DF4C95C-A318-4389-B782-B0D16B86FD20.1@smtp-inbound1.duck.com> <90ba0e03-e767-40a5-843f-fe5a4dcd1a2e@andrewg.com> <2CDBD1EF-C958-48E7-A3CE-7D954EC989A1.1@smtp-inbound1.duck.com> <6170FD2E-5492-42B6-9D92-52723617C239.1@smtp-inbound1.duck.com> <59498334-26c8-4ccd-bde6-299a6efdf27a@andrewg.com> <4CC26646-9C4E-4AC4-8E94-50F557FAD038.1@smtp-inbound1.duck.com> <6671D42E-8833-4E7D-A859-288C83B51F2B.1@smtp-inbound1.duck.com> <1172AC7A-D65D-4DCC-9683-8A9C84465614.1@smtp-inbound1.duck.com> <5EC00FED-5B7C-4E2C-850A-9C548A6F1BDC.1@smtp-inbound1.duck.com> <1f7c9f8c-af7a-4683-bc88-8eb19004f326@sixdemonbag.org> Message-ID: Mr. Hansen what do you value Andrew at a half of a shilling with you being the remainder? It's cute at least you didn't brand it death.ai[https://death.ai]. This is a BUG I need an account to report a bug and the GnuPG page says to ask this mailing list. You mean the GnuPG project doesn't even write the cryptography and is only a front end to libgcrypt and still can't do the basic parts left to the frontend right like revoke a key. Where to get a bug reporting account? From andrewg at andrewg.com Tue May 26 10:28:14 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 26 May 2026 09:28:14 +0100 Subject: Unable to issue subkey revocation In-Reply-To: <9DAD5DD1-0EAC-4BB4-9ED0-5D956F2E7C26.1@smtp-inbound1.duck.com> References: <5DF4C95C-A318-4389-B782-B0D16B86FD20.1@smtp-inbound1.duck.com> <90ba0e03-e767-40a5-843f-fe5a4dcd1a2e@andrewg.com> <2CDBD1EF-C958-48E7-A3CE-7D954EC989A1.1@smtp-inbound1.duck.com> <761D0370-3835-4239-A326-7FDD7223FA11.1@smtp-inbound1.duck.com> <673230fa-ab06-4e5c-bbfc-ce5a751ec8c6@andrewg.com> <9DAD5DD1-0EAC-4BB4-9ED0-5D956F2E7C26.1@smtp-inbound1.duck.com> Message-ID: <952f942e-e03d-462c-a367-8d6c4b8b7b55@andrewg.com> Hi, On 26/05/2026 00:02, marqueandreprisal--- via Gnupg-users wrote: > My guess of what the bug is would be when the primary key has > been revoked gpg2 only assumes all subkeys are revoked while not > actually applying subkey revocation packets. When the primary key is revoked (and particularly when it has been "hard" revoked, such as "key has been compromised") the entire key is rendered unusable. If revoking the primary key was intentional, then there is no pressing need to revoke the subkey also. That said, normally when gnupg revokes a primary key, it also revokes all the subkeys, for avoidance of confusion (I have reproduced this behaviour with a fresh key). So the issue here appears to be that somehow the primary key was revoked without explicitly revoking the subkey. One possible alternative explanation is that keys.openpgp.org is not retaining the subkey revocation on seeing the primary key revocation (based on my argument in the first paragraph above). Is the copy of the key you are working with the same one that you initially revoked, or one that was downloaded from keys.openpgp.org? A From andrewg at andrewg.com Tue May 26 10:29:40 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 26 May 2026 09:29:40 +0100 Subject: Unable to issue subkey revocation In-Reply-To: References: <5DF4C95C-A318-4389-B782-B0D16B86FD20.1@smtp-inbound1.duck.com> <90ba0e03-e767-40a5-843f-fe5a4dcd1a2e@andrewg.com> <2CDBD1EF-C958-48E7-A3CE-7D954EC989A1.1@smtp-inbound1.duck.com> <6170FD2E-5492-42B6-9D92-52723617C239.1@smtp-inbound1.duck.com> <59498334-26c8-4ccd-bde6-299a6efdf27a@andrewg.com> <4CC26646-9C4E-4AC4-8E94-50F557FAD038.1@smtp-inbound1.duck.com> <6671D42E-8833-4E7D-A859-288C83B51F2B.1@smtp-inbound1.duck.com> <1172AC7A-D65D-4DCC-9683-8A9C84465614.1@smtp-inbound1.duck.com> <5EC00FED-5B7C-4E2C-850A-9C548A6F1BDC.1@smtp-inbound1.duck.com> <1f7c9f8c-af7a-4683-bc88-8eb19004f326@sixdemonbag.org> Message-ID: <7251365b-a1a6-452d-bac2-c2472d3693cc@andrewg.com> Hi, On 26/05/2026 05:11, marqueandreprisal--- via Gnupg-users wrote: > Mr. Hansen what do you value Andrew at a half of a shilling with you > being the remainder? It's cute at least you didn't brand it > death.ai[https://death.ai]. Robert and I frequent this mailing list on our own time. Neither of us work for g10code. I have been trying to walk you through the analysis of your own issue because it helps you to write a better bug report. For example, you did not initially say that the primary key had already been intentionally revoked. This is useful information that changes my understanding of your problem. (I'm not *blaming* you for any of this, gnupg is a complex system and the technical details are often highly obscure. But please, work with people who are trying to help you for free.) A From ebo at gnupg.org Tue May 26 12:26:36 2026 From: ebo at gnupg.org (ebo at gnupg.org) Date: Tue, 26 May 2026 12:26:36 +0200 Subject: reporting a bug In-Reply-To: <0F222AFD-CC6E-4391-8EB5-46C7F4051333.1@smtp-inbound1.duck.com> References: <0F222AFD-CC6E-4391-8EB5-46C7F4051333.1@smtp-inbound1.duck.com> Message-ID: <16796920.QkKSJPGmyG@jackson> Hi, the communication style in your other mails ensures that you will at the current time not get a account on dev.gnupg.org. It is anyway not necessary to report a bug there, reporting it here on the mailing list or in the forum is usually enough. We will check and make a bugticket ourselves if you really found a bug. Apart from your account request: It should be obvious that it helps your case(s) if you reply to questions in a friendly fashion. It is not helpful to assume all people have to understand what you write immediately and they answer only to "bother" you. People are trying to help, even if they maybe misunderstand something you wrote. From jhudson at cedaron.com Thu May 28 19:55:04 2026 From: jhudson at cedaron.com (Joshua Hudson) Date: Thu, 28 May 2026 10:55:04 -0700 Subject: import key failure, apparent bug Message-ID: I have here a private key that gpg won't import. ~/keystest$ gpg --homedir home --import private2.gpg gpg: WARNING: unsafe permissions on homedir '/home/DEXTER2/jhudson/keystest/home' gpg: read_block: read error: Invalid packet gpg: import from 'private2.gpg' failed: Invalid keyring gpg: Total number processed: 0 The problem with the error message is it's wrong. I have hand verified the packet structure is correct. The file can be imported by https://github.com/mattosaurus/pgpcore (which isn't where it came from) and the resulting imported key is a working key. This is a test key file being imported into a test keyring; I don't mind publishing the private key in entirety. Apologies for the headerless base64, gpg won't armor the file for me xcLUBGoYX8wBB/+n49lopA4uHNk1fZxx+S2A/fvIrw4OXTSbAUJ8FgELTORboguaXBJCjBxxmZqZ rRyE2OyUF3bub5I+FEnehi3DlD1a+gaddoE0DVaApzxZW+ZeAymbDAoyvj9UT3atRoMt1w7vKnRt RYh5S+0Q3Kep8orT7ukM7snjEM9UWdvLyNlNui6V4BYxQBq+RvcN6wz0C//Y423XQSTStM973s6i +vq8be1nf6o16cKHP8hh/VijAO+c4BlCxYknBtEDqlnTdcJNZjlzwXbbes2uIGUtmeA37rlthVxf fE4Cd7mvNGuM/7r1vmWmJZe5TK02cOKTnRBgQb3oJ31DguWgnuk5AAURAAgAWOIJr95h3C1j7yRh 4fxjYmhYHvNDrUBnJOKMnAumMyi1IXPoBmz6m7OWln5/BhBaZHLXmbIRyYZcezfq3zf6HD9rxsCa FyCewTQ82rLjttZMyFwG97sUdTeK8GZN40Nyn8w1FTSX/Z1IQDdBRSmF8I92rG9sUiQQh0Uid/NW PrTCzHu40AYcOTbsMIkvZ+/Ln8cRGlYtXs0PxgKf5jxjgzdtpOdNeKKfKooOQHlQuuYvEgO7wM40 cln6+wi56bbv1NIhd2v3YChpgGqxCWKmYGpzQ8N9vCCqMnHi4DHhmcEug7D/gLa/UTN7YnnEsTgS 3lGHzFur0/49OQJGojZO8QP/tbZH6Y0iopXj+3fNjZQnk2Nd8bDe8VQFabrE3hmeVxT5zQFoN5Au SVdF2vKLc83xKLdCMUYOTnwxXr3jvnx13rqkIBXQ+MSXGXqq2PfUL26YQv90MXC6qM8QXtCbv7mk wTA7gXgrg3PuJ5rPCUvdWru7BYBIwY0+FYVCXiX0jkEEAOyG+lm4sej2ZihAIPN8jMANi1+g7+3s m/Kh6vw9lYKymHsRwpVIyN7jnyH+ediIWWU7fs142oQneGzH2bNb92C/tn9yc/ukM101W8LBA6Yl VPxjJbbuxePbzbRt74i2sP0rII/DViN8ZGqdXr6b1EfCK5iW2g0f0ElvA1dktYz5A/+F98+trLaa V8kspIEDUos1IV8tkjKc61OhivdZocAjSvIqUWsMXQuvsSdyawTPotRdngHCYc6NFffFN3Vu3NqN cHBx2vMrqbvacnWBW1nt7aO+eCxbow+g0vXs8FcYhsV3bMIpoVObLngFy6GSg006LVpvks4tCwCB y3+g3KfHf8LAaAQfAQoAHAUCahhfzAkQRTZm8WKHh+oCGwMCFQgCCwcCFgcAAOGOCABP5jd4noVM e2y3askyL/sFtN1VNuqQPfLBbxxBZN5ryAR/uw37h7sGfs+3YuMiUvML61hBH2lkRYWIl5Uy7Kua jMiY9YE4aYua4LhoqkETAsr9UjsSDtwLjjDiN8jufPB+aXM1/xbZfFpkl3ulSezzkNClA68gj/0T 0Qom+0xmYu4ejw+5waLWRRdE8502c2AHUfFvWehNOZgR7IbMMWww0J+41vJpaLydsaRpu6XwZ+wZ uHjgDTCr8wsytZ34F/TO1OPFnT/w4GbOa1wVP9fky0q9vskeXIT/h0c424mRi9qqMsr0JESBxBvc wEZ7rUnk5HUIbLFEHFHMAyxI9cdizQJNZcLAXAQTAQgAEAUCahhfzQkQRTZm8WKHh+oAAIj2CABZ ba1NofrhMqwpT55GqsyRpi/JuD+hof83SGEennk5FbyXnN6bTdvSdBj16/2I00o8bJlXFzTS0Nrz MKHKQmMSZJj3tE9nvhbU2cDBYVIpT0h6qJmtQYfHNlgV+ZivyUH2OJ1U91uYOhOjLNciVqkWirX/ NMq+mCwTqSeF4jh1+YwYlhxL1l8n7FxJiF/K2ynfT8LpfVw5MJvIMxbJFnIxnhXi0x/6cNwzBooR gyNzhzHe7YntJIaI/gDqEp7SToCRDWB0VghnDPgTEKwxJopJlrL4sTWyCvNpnsUTYNdA9SBUzN7f l409rGhEUhyMdHuBLBceXfx6hDNfEdQysLA2x8LUBGoYX80BCACrTWCCxlaAZ+2oc0xx6EBj5zqV r9Ls9Zsh08f25sbtwqeOWfy6qrK+1lSRPRK9Us3XbNsZaSvN0IOvXb+DMsbIRNAbRkEA3gkNE4og e3Vq6i1iRYlsY1ZGz6jG8iOvLRHFGcXDW6TMm3dPv/HHP7humIMWaSeVAX3R34CULbvGWGhm9f0M 9saVFybbKAafqNicR5uyhUXpAhnC8fPgPUZhxuPoNB6igZtN8iSXuHLvvECTPvb4Qk/3KmoEbXPK niwScnKWMSM6ulO46QlmtYHN80CUdFeW4h5WRrbpTZPcNi4xbWSaLsXGfs2DqRWi5NZuPxN9fWxT S6i837Epa9ifAAURAAgAHjrUy8il2myxeBRYyM6h84ModMSswGeT2MsFK5IjGuYdkZdo1aWnEp5L KLBst/+NvJq9QLg06BW84rYw2urXyP0VqnXPPGNrAk6+BbtvEt4IAkiBqbctV8pK9e5+xI97m0DI i+L+9u5COz/9fYO3IpNibV3ZzwBDYUWPKTU/QR5fCNEtyb0uK88D9dZexDYAFD9OrOV5vBfwFNZ9 G9sTh9jQvPpIQrAo2qZf+Hht07GdKKSKwdAVXjAY0a2kL0gQxXRl1gZFHwgP/ILR1yIizz5JpBXr 2+AWEzuORujaApq2pnSyZUUj2b7AqvtcmgDDjS/NmDrgM+yJYDvX5zACiQQAyKUgAvOMjj3Ad9SG DWqXDYf2/2/q0IsIlltRj3aMErSH2sF1LYjVNy6KI745nMTjGjJoilalU3FPfptfg1QszbWu94wf Ua7GJ4r+Xo2I1lXLrUjxp82aWsc3b/fiHz4l+H/ZRS84hCBEHVRBigCC/0xweSy1Po2MyrMgqiva VaUEANqP30v3j4gJwZiVjeAyinVMPzPEMMOJcd2cNkohLRpWHRT331efxidIY+EEKb0l6qvP3K+s rINwH7QaNfi/2P9TL+SimPSGxnxBsAXAwJDhxpypsSHrUfEiEyC07qE5+NVXqYHXw8vUVxcRLH7k XYMBv7fyJTdKLSjoa+o01snzA/1Rqna9iDLQKnU7SR4q2r3Rlx7LaMYODwcVimgJn5qwm3UowsB8 UifOixcH2D2c4/Zp2nj0y8WOayU6snNg72spNiQvpmbewev3B1+5HyyvhCpmgUMLJQsR+7kPD6FK YTO/O4T2SVfbu8ZA/GeTWEvi0gMX0Ar2OouoXujq5gZ8g8LAaAQYAQgAHAUCahhfzwkQRTZm8WKH h+oCGwMCFQgCCwcCFgcAAPPfCABxO9gGhL4qRZrvw9zKG0FdHQEQO6ZPZJjeKUSTeYOiqEcmWKeq SMCCvHH0LSunXm9cp/Bm/LkQEqVuhiNgsK05ZJKI1FawFQabK3E6nLCn1nZMwLqpReNrAUPTnR22 fE+3bXPFjRTjmTbIk4ApDjpq5WCsanmuQ3OAhBd6ODgYzZA38THcPkE/F5ExUhKLDL00KKfXokp2 7vqKl2mr/SujuZyMpWUlubIcyVMMFGfdBfjwhVHuhyHK7g51dlHQmdL5Bh+u6ovaZPuAT1n4GlDA UnkJ1ixPWwlrytsf1MrAFaPM6J0JupZvXVPrekUoZFlBAVAgrFhwdNQ37pvXDx7o No, you don't need a password to open this. From johndoe65534 at mail.com Fri May 29 07:21:47 2026 From: johndoe65534 at mail.com (john doe) Date: Fri, 29 May 2026 07:21:47 +0200 Subject: import key failure, apparent bug In-Reply-To: References: Message-ID: <39fa2ab8-41ec-4cb9-90be-87a8ea102a5f@mail.com> On 5/28/26 19:55, Joshua Hudson via Gnupg-users wrote: > I have here a private key that gpg won't import. > > ~/keystest$ gpg --homedir home --import private2.gpg > gpg: WARNING: unsafe permissions on homedir '/home/DEXTER2/jhudson/ > keystest/home' > gpg: read_block: read error: Invalid packet > gpg: import from 'private2.gpg' failed: Invalid keyring > gpg: Total number processed: 0 > > The problem with the error message is it's wrong. I have hand verified > the packet structure > is correct. The file can be imported by https://github.com/mattosaurus/ > pgpcore (which isn't > where it came from) and the resulting imported key is a working key. > > This is a test key file being imported into a test keyring; I don't mind > publishing the private key > in entirety. > > Apologies for the headerless base64, gpg won't armor the file for me > So you have twoerrors with the gpg installation that you have.. How did you install it and what version is this? -- John Doe From bernhard at intevation.de Fri May 29 09:04:01 2026 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 29 May 2026 09:04:01 +0200 Subject: Depending on libs and other components (Re: building from source) In-Reply-To: References: <7A681C43-E138-4730-AAFC-4307365D7FA7.1@smtp-inbound1.duck.com> <3D897F25-6F24-4152-8C49-B236C7088E48.1@smtp-inbound1.duck.com> Message-ID: <202605290904.08302.bernhard@intevation.de> Hi, Am Dienstag 26 Mai 2026 05:44:58 schrieb marqueandreprisal--- via Gnupg-users: > Especially for security software the program should function self > contained and there is no other way to audit it. If you doenload a piece > of source code and it does not function without other guys libs that is a > problem. it is normal and unavoidable for (any resonable complex and useful) software today to depend on many other software components. There are the compiler, the operating system and other libraries. Please look into the recent https://en.wikipedia.org/wiki/Software_supply_chain literature and research. 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 Fri May 29 09:10:26 2026 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 29 May 2026 09:10:26 +0200 Subject: GnuPG cannot know if is runs in a "secure" environment (Re: standard comment) In-Reply-To: <858926A2-4B81-4A51-A22C-36F82DCEAA8C.1@smtp-inbound1.duck.com> References: <3d9cd3f3-cb48-4b44-9316-d4a74eedc14b@kolabnow.com> <858926A2-4B81-4A51-A22C-36F82DCEAA8C.1@smtp-inbound1.duck.com> Message-ID: <202605290910.27159.bernhard@intevation.de> Hi, Am Montag 25 Mai 2026 06:36:55 schrieb marqueandreprisal--- via Gnupg-users: > How would this fine community recommend to make a standardized comment > about keys being used in unsecure environments. For example buying an > android? off of the shelf and using keys with GnuPG Termux or Open > Keychain is not sure because androids often have swap files which may be > setup to dump memory and snag the private key. as far as I can say a crypto component cannot tell if it is run on an "unsecure" environment or not. So even if GnuPG or Openkeychain wanted to record this, they would not be able to find out about this with reasonable certainty. Consider the example that the software is running in a virtualized environment like qemu, which is "unsecure" in the sense that qemu can observe everything. As qemu can "simulate" everything, it is not really possible to detect the fact. On the other hand, a Android system maybe run air-gapped in a confined place, with a self build kernel and everything, which would make it quite "secure". So detecting that termux was used would not make a key pair "unsecure" alone. 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 wk at gnupg.org Fri May 29 13:20:01 2026 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 May 2026 13:20:01 +0200 Subject: import key failure, apparent bug In-Reply-To: (Joshua Hudson via Gnupg-users's message of "Thu, 28 May 2026 10:55:04 -0700") References: Message-ID: <87o6hya2e6.fsf@jacob.g10code.de> Hi! I had a quick look at the problem. It seems that the length as given by the packet header is shorter than the length as given by the MPIs. More on this in a few days. 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 29 13:45:54 2026 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 May 2026 13:45:54 +0200 Subject: import key failure, apparent bug In-Reply-To: (Joshua Hudson via Gnupg-users's message of "Thu, 28 May 2026 10:55:04 -0700") References: Message-ID: <87jysma171.fsf@jacob.g10code.de> Hi! A closer inspection shows that the key is missing the 2 checksum bytes. According to the specs (RFC-4880 or LibrePGP): * If the string-to-key usage octet is zero or 255, then a two-octet checksum of the plaintext of the algorithm-specific portion (sum of all octets, mod 65536). A string-to-key usage octet of zero means unencrypted key material. 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 andrewg at andrewg.com Fri May 29 13:45:51 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 29 May 2026 12:45:51 +0100 Subject: import key failure, apparent bug In-Reply-To: References: Message-ID: <3c08cedb-2169-4b6a-8fed-7f655b0010d0@andrewg.com> On 28/05/2026 18:55, Joshua Hudson via Gnupg-users wrote: > I have here a private key that gpg won't import. > > ~/keystest$ gpg --homedir home --import private2.gpg > gpg: WARNING: unsafe permissions on homedir '/home/DEXTER2/jhudson/ > keystest/home' > gpg: read_block: read error: Invalid packet > gpg: import from 'private2.gpg' failed: Invalid keyring > gpg: Total number processed: 0 > > The problem with the error message is it's wrong. I have hand verified > the packet structure > is correct. The file can be imported by https://github.com/mattosaurus/ > pgpcore (which isn't > where it came from) and the resulting imported key is a working key. The first MPI length in the secret key packet (rsa public n) is incorrect. It is 0x07ff, but the high bit of the next byte (0xa7) is set - which implies the length *should* have been 0x8000. This is particularly unusual considering that it is using SOSes (i.e. with untrimmed leading zero bits) for at least some of the other MPIs (I haven't checked them all). What did you use to generate this? A From webbiforetag at proton.me Fri May 29 15:47:11 2026 From: webbiforetag at proton.me (W. F.) Date: Fri, 29 May 2026 13:47:11 +0000 Subject: Compress and encrypt files and folders Message-ID: Hello, I'm in need of compressing and encrypting both individual files, but also folders in my Linux environment. Suppose I have a file called "schema.sql" that I need to compress and encrypt, or a folder called "daily_backup" which consists of 5 files and 3 subdirectories (each containing various files). How would you recommend I compress and encrypt this data? I want to use a passphrase for encryption - and not a key file. Currently, I have configured GnuPG using a configuration file with the following: $ nano ~/.gnupg/gpg.conf cipher-algo AES256 digest-algo SHA512 cert-digest-algo SHA512 s2k-cipher-algo AES256 s2k-digest-algo SHA512 s2k-mode 3 s2k-count 65011712 compress-algo none throw-keyids no-emit-version no-comments no-symkey-cache disable-cipher-algo 3DES disable-cipher-algo CAST5 disable-cipher-algo BLOWFISH $ chmod 700 ~/.gnupg $ chmod 600 ~/.gnupg/gpg.conf And so far I've tried encrypting a single file using a passphrase like so: $ echo "hello world" > file.txt $ gpg -c -o encrypted.dat --batch --passphrase "Password123!" file.txt $ rm file.txt $ gpg --batch --yes --passphrase "Password123!" -d -o file.txt encrypted.dat $ cat file.txt I can also use it interactively by omitting "--passphrase". I'm a beginner when it comes to encryption and for me it's important that the encryption I use is secure enough to withstand brute force attacks, so please help me out by configuring the GPG configuration file properly. I don't know if my settings are considered bad practice in 2026. I also need a way to compress an entire directory. And preferably also hide all file names and metadata. I want the encrypted file to show as little information as possible (dates, groups, user, filenames, metadata, etc). I suppose I need to use "tar" and pipe it to GPG. Please show me your commands using best practices in 2026, using a passphrase (and not a key file). Thank you! Best Regards Wilhelm Futtiger From jhudson at cedaron.com Fri May 29 16:17:56 2026 From: jhudson at cedaron.com (Joshua Hudson) Date: Fri, 29 May 2026 07:17:56 -0700 Subject: import key failure, apparent bug In-Reply-To: <87jysma171.fsf@jacob.g10code.de> References: <87jysma171.fsf@jacob.g10code.de> Message-ID: Yup; which does explain everything and apparently some libraries think optional and some don't. On 5/29/2026 4:45 AM, Werner Koch wrote: > Hi! > > A closer inspection shows that the key is missing the 2 checksum bytes. > According to the specs (RFC-4880 or LibrePGP): > > * If the string-to-key usage octet is zero or 255, then a two-octet > checksum of the plaintext of the algorithm-specific portion (sum > of all octets, mod 65536). > > A string-to-key usage octet of zero means unencrypted key material. > > > Shalom-Salam, > > Werner > > From rjh at sixdemonbag.org Fri May 29 18:34:56 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 29 May 2026 12:34:56 -0400 Subject: Compress and encrypt files and folders In-Reply-To: References: Message-ID: <65ef1d4b-306e-4c8e-bbe0-39e2427852ac@sixdemonbag.org> > cipher-algo AES256 > digest-algo SHA512 Those are bad news: you can sabotage your interoperability with other RFC4880 or LibrePGP applications that way. Better by far to use the cipher preference mechanism. An example is found in section 8.7 of the official FAQ: https://www.gnupg.org/faq/gnupg-faq.html#new_user_gpg_conf > Suppose I have a file called "schema.sql" that I need to compress > and encrypt, or a folder called "daily_backup" which consists of 5 > files and 3 subdirectories (each containing various files). How > would you recommend I compress and encrypt this data? $ tar cJf daily_backup.txz /path/to/daily_backup $ gpg --symmetric daily_backup.txz -------------- 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 rjh at sixdemonbag.org Fri May 29 18:36:49 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 29 May 2026 12:36:49 -0400 Subject: import key failure, apparent bug In-Reply-To: References: <87jysma171.fsf@jacob.g10code.de> Message-ID: <4ca3f934-91f1-4400-850b-79e2cc1ae97e@sixdemonbag.org> > Yup; which does explain everything and apparently some libraries > think optional and some don't. More troubling, that some libraries *do not check the checksums*. -------------- 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 marqueandreprisal at duck.com Fri May 29 22:06:06 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Fri, 29 May 2026 16:06:06 -0400 Subject: Unable to issue subkey revocation References: <5DF4C95C-A318-4389-B782-B0D16B86FD20.1@smtp-inbound1.duck.com> <90ba0e03-e767-40a5-843f-fe5a4dcd1a2e@andrewg.com> <2CDBD1EF-C958-48E7-A3CE-7D954EC989A1.1@smtp-inbound1.duck.com> <761D0370-3835-4239-A326-7FDD7223FA11.1@smtp-inbound1.duck.com> <673230fa-ab06-4e5c-bbfc-ce5a751ec8c6@andrewg.com> <9DAD5DD1-0EAC-4BB4-9ED0-5D956F2E7C26.1@smtp-inbound1.duck.com> <952f942e-e03d-462c-a367-8d6c4b8b7b55@andrewg.com> Message-ID: It shouldn't make any difference. I explicitly revoked the subkey after the primary was revoked and it does not revoke the subkey. This is a bug: GnuPG is Unable to revoke subkey properly. You may continue to try and find a workaround yet after having done things right without expected results the BUG has been established. I need an account to report the BUG to the bug tracker and the site says to ask here for an account login. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 281 bytes Desc: not available URL: From marqueandreprisal at duck.com Fri May 29 22:14:07 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Fri, 29 May 2026 16:14:07 -0400 Subject: Unable to issue subkey revocation References: <90ba0e03-e767-40a5-843f-fe5a4dcd1a2e@andrewg.com> <2CDBD1EF-C958-48E7-A3CE-7D954EC989A1.1@smtp-inbound1.duck.com> <6170FD2E-5492-42B6-9D92-52723617C239.1@smtp-inbound1.duck.com> <59498334-26c8-4ccd-bde6-299a6efdf27a@andrewg.com> <4CC26646-9C4E-4AC4-8E94-50F557FAD038.1@smtp-inbound1.duck.com> <6671D42E-8833-4E7D-A859-288C83B51F2B.1@smtp-inbound1.duck.com> <1172AC7A-D65D-4DCC-9683-8A9C84465614.1@smtp-inbound1.duck.com> <5EC00FED-5B7C-4E2C-850A-9C548A6F1BDC.1@smtp-inbound1.duck.com> <1f7c9f8c-af7a-4683-bc88-8eb19004f326@sixdemonbag.org> <7251365b-a1a6-452d-bac2-c2472d3693cc@andrewg.com> <3A989275-F1FA-4710-A501-42045512F5A0.1@smtp-inbound1.duck.com> Message-ID: The primary key had been initially revoked and should have revoked the subkey also. The revocation of the primary key should not be an issue because no error is given about usability when going back to reissue the revocation explicitly against the subkey. GnuPG BUG: Unable to issue subkey revocation Workaround possibility: There may be some difficult workaround like exporting the subkey as a single key and then using it's own authority to revoke itself as a primary key but if there are it seems difficult to paste this all together back into a pubkey to upload to the keyserver. You may formulate a path to try in this meanwhile time of getting it straightened out. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 281 bytes Desc: not available URL: From marqueandreprisal at duck.com Sat May 30 05:45:50 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Fri, 29 May 2026 23:45:50 -0400 Subject: Depending on libs and other components (Re: building from source) References: <7A681C43-E138-4730-AAFC-4307365D7FA7.1@smtp-inbound1.duck.com> <3D897F25-6F24-4152-8C49-B236C7088E48.1@smtp-inbound1.duck.com> <202605290904.08302.bernhard@intevation.de> <4AC8311D-6712-48D4-962D-A06BBC52CB9A.1@smtp-inbound1.duck.com> Message-ID: <07A8319A-2A8D-4E5B-80BA-247259688045.1@smtp-inbound1.duck.com> No. It is not unavoidable a properly functioning PGP 1 without bugs like GnuPG has can fit on a floppy and runs on DOS. Actually you could do a 180 and rebuild libs specifically for GnuPG but it is counterintuitive. There is no reason why developers can't develop fully functioning programs, believe it or not it can still be done even on these junk machines you can still build a full functional program and it could be a PGP clone that works right. Might could be. I would be interested in hearing Andrew's libreGPG is fully functional. This is just slop. I would be embarrassed to be you and be defending slop. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 281 bytes Desc: not available URL: From marqueandreprisal at duck.com Sat May 30 05:49:28 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Fri, 29 May 2026 23:49:28 -0400 Subject: GnuPG cannot know if is runs in a "secure" environment (Re: standard comment) References: <3d9cd3f3-cb48-4b44-9316-d4a74eedc14b@kolabnow.com> <858926A2-4B81-4A51-A22C-36F82DCEAA8C.1@smtp-inbound1.duck.com> <202605290910.27159.bernhard@intevation.de> <82131A49-43E0-4467-ADF1-6C3C47E99A2F.1@smtp-inbound1.duck.com> Message-ID: <7E0E5A54-BA8C-44DA-8162-9FBAB4A9969E.1@smtp-inbound1.duck.com> Hi Bernhard I seen you came over from the forum. Yeah I applied the comment manually ultimately the final authority in security is the user. That is what I meant for the user to apply the standard comment if you look at my key I applied the minimal comment as a standard comment "this key was not created in an environment known to be secure". Like I said generally PGP was designed for DOS which is pretty good security wise. Now days I guess what you can do is build your own minix floppy for GPG + Email but modern machines won't even take a floppy unless it uses some maybe compromised USB packet driver <- you can't boot from that -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 281 bytes Desc: not available URL: From marqueandreprisal at duck.com Sat May 30 06:07:35 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Sat, 30 May 2026 00:07:35 -0400 Subject: Compress and encrypt files and folders References: <591EFBD2-BB04-476F-8B5F-775DCA1782B0.1@smtp-inbound1.duck.com> Message-ID: <786B692A-A040-4899-B9E5-2DEF45E65101.1@smtp-inbound1.duck.com> Do you have a PS/2 keyboard. USB operates as a hub and in packet driver mode or whatever they use it can log everything password only meant something when it was on DOS when you had PS/2 keyboard and a real keyboard driver. This is slop now. From marqueandreprisal at duck.com Sat May 30 09:41:55 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Sat, 30 May 2026 03:41:55 -0400 Subject: import key failure, apparent bug References: <87jysma171.fsf@jacob.g10code.de> <4ca3f934-91f1-4400-850b-79e2cc1ae97e@sixdemonbag.org> <00CD5E19-5950-4540-B468-7C5F1EED1E6A.1@smtp-inbound1.duck.com> Message-ID: <6032A5DD-5600-42DF-995A-A7A24A56D202.1@smtp-inbound1.duck.com> Yeah like I said GnuPG you really shouldn't rely on other guys libs. GnuPG is not a good fit for me because they do so it is nothing but a buggy frontend with unreliable cryptography. Do you inspectors have any recommendations? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 281 bytes Desc: not available URL: From sam at gentoo.org Sat May 30 09:55:25 2026 From: sam at gentoo.org (Sam James) Date: Sat, 30 May 2026 08:55:25 +0100 Subject: import key failure, apparent bug In-Reply-To: <6032A5DD-5600-42DF-995A-A7A24A56D202.1@smtp-inbound1.duck.com> References: <87jysma171.fsf@jacob.g10code.de> <4ca3f934-91f1-4400-850b-79e2cc1ae97e@sixdemonbag.org> <00CD5E19-5950-4540-B468-7C5F1EED1E6A.1@smtp-inbound1.duck.com> <6032A5DD-5600-42DF-995A-A7A24A56D202.1@smtp-inbound1.duck.com> Message-ID: <87a4thuyaa.fsf@gentoo.org> marqueandreprisal--- via Gnupg-users writes: > Yeah like I said GnuPG you really shouldn't rely on other guys > libs. GnuPG is not a good fit for me because they do so it is nothing > but a buggy frontend with unreliable cryptography. Do you inspectors > have any recommendations? GnuPG only uses libraries from the GnuPG suite (libgcrypt and friends). The discussion in this thread is about third party libraries producing broken PGP keys. OP hasn't answered which library was used to generate these keys. sam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 418 bytes Desc: not available URL: From andrewg at andrewg.com Sat May 30 12:31:03 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sat, 30 May 2026 11:31:03 +0100 Subject: Unable to issue subkey revocation In-Reply-To: References: <90ba0e03-e767-40a5-843f-fe5a4dcd1a2e@andrewg.com> <2CDBD1EF-C958-48E7-A3CE-7D954EC989A1.1@smtp-inbound1.duck.com> <6170FD2E-5492-42B6-9D92-52723617C239.1@smtp-inbound1.duck.com> <59498334-26c8-4ccd-bde6-299a6efdf27a@andrewg.com> <4CC26646-9C4E-4AC4-8E94-50F557FAD038.1@smtp-inbound1.duck.com> <6671D42E-8833-4E7D-A859-288C83B51F2B.1@smtp-inbound1.duck.com> <1172AC7A-D65D-4DCC-9683-8A9C84465614.1@smtp-inbound1.duck.com> <5EC00FED-5B7C-4E2C-850A-9C548A6F1BDC.1@smtp-inbound1.duck.com> <1f7c9f8c-af7a-4683-bc88-8eb19004f326@sixdemonbag.org> <7251365b-a1a6-452d-bac2-c2472d3693cc@andrewg.com> <3A989275-F1FA-4710-A501-42045512F5A0.1@smtp-inbound1.duck.com> Message-ID: On 29/05/2026 21:14, marqueandreprisal--- via Gnupg-users wrote: > The primary key had been initially revoked and should have revoked the > subkey also. This is conventional, but not necessary. If one of your correspondents found a way to use that subkey when its primary was revoked, that would be a serious bug - but in your correspondent's software, not yours. Subkeys attached to revoked primary keys should not be used. It should not make any difference whether the subkey itself is revoked. > The revocation of the primary key should not be an issue > because no error is given about usability when going back to reissue the > revocation explicitly against the subkey. GnuPG BUG: Unable to issue > subkey revocation It may well be a bug, but afaict it is a minor one with no practical consequences. > Workaround possibility: There may be some difficult workaround like > exporting the subkey as a single key and then using it's own authority > to revoke itself as a primary key This would not do anything. If you used the same key material in a new primary key it would be a different key. If it then revoked itself, the new primary key would be revoked but the subkey attached to the original primary would not. Subkeys cannot revoke themselves. > You may formulate a path to try in this meanwhile time of getting it > straightened out. None of this is necessary. Your primary key has been hard revoked as intended, and it is correctly unusable. You don't need to do anything more. A From marqueandreprisal at duck.com Sun May 31 04:05:01 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Sat, 30 May 2026 22:05:01 -0400 Subject: Unable to issue subkey revocation References: <2CDBD1EF-C958-48E7-A3CE-7D954EC989A1.1@smtp-inbound1.duck.com> <6170FD2E-5492-42B6-9D92-52723617C239.1@smtp-inbound1.duck.com> <59498334-26c8-4ccd-bde6-299a6efdf27a@andrewg.com> <4CC26646-9C4E-4AC4-8E94-50F557FAD038.1@smtp-inbound1.duck.com> <6671D42E-8833-4E7D-A859-288C83B51F2B.1@smtp-inbound1.duck.com> <1172AC7A-D65D-4DCC-9683-8A9C84465614.1@smtp-inbound1.duck.com> <5EC00FED-5B7C-4E2C-850A-9C548A6F1BDC.1@smtp-inbound1.duck.com> <1f7c9f8c-af7a-4683-bc88-8eb19004f326@sixdemonbag.org> <7251365b-a1a6-452d-bac2-c2472d3693cc@andrewg.com> <3A989275-F1FA-4710-A501-42045512F5A0.1@smtp-inbound1.duck.com> <1DB029D1-60E2-407E-A885-5F2241B9EC17.1@smtp-inbound1.duck.com> Message-ID: ---------------------------------------- From: Andrew Gallagher via Gnupg-users To: gnupg-users at gnupg.org Date: May 30, 2026 10:34:51 Subject: Re: Unable to issue subkey revocation > On 29/05/2026 21:14, marqueandreprisal--- via Gnupg-users wrote: >> The primary key had been initially revoked and should have revoked the >> subkey also. > > This is conventional, but not necessary. If one of your correspondents > found a way to use that subkey when its primary was revoked, that would > be a serious bug - but in your correspondent's software, not yours. > Subkeys attached to revoked primary keys should not be used. It should > not make any difference whether the subkey itself is revoked. > >> The revocation of the primary key should not be an issue because no >> error is given about usability when going back to reissue the >> revocation explicitly against the subkey. GnuPG BUG: Unable to issue >> subkey revocation > > It may well be a bug, but afaict it is a minor one with no practical > consequences. > >> Workaround possibility: There may be some difficult workaround like >> exporting the subkey as a single key and then using it's own authority >> to revoke itself as a primary key > > This would not do anything. If you used the same key material in a new > primary key it would be a different key. If it then revoked itself, the > new primary key would be revoked but the subkey attached to the > original primary would not. Subkeys cannot revoke themselves. > >> You may formulate a path to try in this meanwhile time of getting it >> straightened out. > > None of this is necessary. Your primary key has been hard revoked as > intended, and it is correctly unusable. You don't need to do anything > more. > > A > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users No you are wrong it is not a minor bug I do not agree with you. The ability to revoke keys is a major feature therefor it is a major bug and moreso because it is an even larger chunk of what the code of a frontend is supposed to do, sad that a frontend focuses on the user interface of functionality only and still fails at a major feature. If you see my posts on the forum you will see that the supplimental gen-revoke program no longer works and when you read about gen-revoke in the context of Michael's blog you will see this major bug would break a massive system of automation for which is the ideal use of a subkey system. If this had been PGP 1 this wouldn't be screwed up like this and I don't appreciate when people argue about this slop instead of fixing it when they should pay me gratuity for reporting the bug. That being said where can I get PGP 1 clone to GPG 1 or something that is fully functional self contained program? With your favoritism of bugs I wouldn't be quick to pick LibrePGP while you are the developer. What other options have I? From rjh at sixdemonbag.org Sun May 31 12:40:50 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 31 May 2026 06:40:50 -0400 Subject: Unable to issue subkey revocation In-Reply-To: References: <2CDBD1EF-C958-48E7-A3CE-7D954EC989A1.1@smtp-inbound1.duck.com> <59498334-26c8-4ccd-bde6-299a6efdf27a@andrewg.com> <4CC26646-9C4E-4AC4-8E94-50F557FAD038.1@smtp-inbound1.duck.com> <6671D42E-8833-4E7D-A859-288C83B51F2B.1@smtp-inbound1.duck.com> <1172AC7A-D65D-4DCC-9683-8A9C84465614.1@smtp-inbound1.duck.com> <5EC00FED-5B7C-4E2C-850A-9C548A6F1BDC.1@smtp-inbound1.duck.com> <1f7c9f8c-af7a-4683-bc88-8eb19004f326@sixdemonbag.org> <7251365b-a1a6-452d-bac2-c2472d3693cc@andrewg.com> <3A989275-F1FA-4710-A501-42045512F5A0.1@smtp-inbound1.duck.com> <1DB029D1-60E2-407E-A885-5F2241B9EC17.1@smtp-inbound1.duck.com> Message-ID: <9d10eb17-6fcf-4d6a-91e9-2f6dc5cdc789@sixdemonbag.org> > No you are wrong it is not a minor bug I do not agree with you. Although you are free to disagree with anyone you wish, your conduct is both unhelpful and unnecessarily combatative. > With your favoritism of bugs I wouldn't be quick to pick LibrePGP while > you are the developer. What other options have I? None you'd consider safe, given your hostility to libraries. -------------- 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 rjh at sixdemonbag.org Sun May 31 12:50:36 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 31 May 2026 06:50:36 -0400 Subject: import key failure, apparent bug In-Reply-To: <87a4thuyaa.fsf@gentoo.org> References: <87jysma171.fsf@jacob.g10code.de> <4ca3f934-91f1-4400-850b-79e2cc1ae97e@sixdemonbag.org> <00CD5E19-5950-4540-B468-7C5F1EED1E6A.1@smtp-inbound1.duck.com> <6032A5DD-5600-42DF-995A-A7A24A56D202.1@smtp-inbound1.duck.com> <87a4thuyaa.fsf@gentoo.org> Message-ID: <326cd8cd-12a4-43fb-9546-89767d673ae4@sixdemonbag.org> > GnuPG only uses libraries from the GnuPG suite (libgcrypt and > friends). Not true. The latest Fedora 43 links against the following non-GnuPG libraries: * libc, libm -> standard system libs * libz, libbz2 -> provides compression algorithms * libsqlite3 -> modern keybox format is an SQLite db * libreadline -> command completion and history * libtinfo -> ncurses Verify it for yourself (with `ldd` on Linux or `otool -L` on macOS). -------------- 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 wk at gnupg.org Sun May 31 14:18:06 2026 From: wk at gnupg.org (Werner Koch) Date: Sun, 31 May 2026 14:18:06 +0200 Subject: Unable to issue subkey revocation In-Reply-To: (marqueandreprisal's message of "Sat, 30 May 2026 22:05:01 -0400") References: <2CDBD1EF-C958-48E7-A3CE-7D954EC989A1.1@smtp-inbound1.duck.com> <6170FD2E-5492-42B6-9D92-52723617C239.1@smtp-inbound1.duck.com> <59498334-26c8-4ccd-bde6-299a6efdf27a@andrewg.com> <4CC26646-9C4E-4AC4-8E94-50F557FAD038.1@smtp-inbound1.duck.com> <6671D42E-8833-4E7D-A859-288C83B51F2B.1@smtp-inbound1.duck.com> <1172AC7A-D65D-4DCC-9683-8A9C84465614.1@smtp-inbound1.duck.com> <5EC00FED-5B7C-4E2C-850A-9C548A6F1BDC.1@smtp-inbound1.duck.com> <1f7c9f8c-af7a-4683-bc88-8eb19004f326@sixdemonbag.org> <7251365b-a1a6-452d-bac2-c2472d3693cc@andrewg.com> <3A989275-F1FA-4710-A501-42045512F5A0.1@smtp-inbound1.duck.com> <1DB029D1-60E2-407E-A885-5F2241B9EC17.1@smtp-inbound1.duck.com> Message-ID: <87y0gz93i9.fsf@jacob.g10code.de> On Sat, 30 May 2026 22:05, marqueandreprisal--- said: > bug. That being said where can I get PGP 1 clone to GPG 1 or something You may want to read up on the history of PGP to learn that PGP 1 was an attempt on encryption for masses but used an easy to crack algorithm. You probably meant PGP 2.x which can be replaced by GnuPG 1.4 after setting some options - but this is only intended to decrypt data once encrypted with PGP 2 and not for encrypting or signing data today. 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 Sun May 31 19:50:11 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 31 May 2026 18:50:11 +0100 Subject: Unable to issue subkey revocation In-Reply-To: References: Message-ID: On 31 May 2026, at 03:06, marqueandreprisal--- via Gnupg-users wrote: > > No you are wrong it is not a minor bug I do not agree with you. The ability to revoke keys is a major feature therefor it is a major bug Your key *is* revoked though. The fact that it doesn?t explicitly say that the subkey is revoked is a minor issue because subkeys should not be used when their primary key is revoked. > when you read about gen-revoke in the context of Michael's blog you will see this major bug would break a massive system of automation for which is the ideal use of a subkey system. I haven?t seen those posts. But if you have an automation system that can use a subkey when its primary key is hard revoked, then there is a bug in that automation system. > With your favoritism of bugs I wouldn't be quick to pick LibrePGP while you are the developer. What other options have I? You are mixing me up with somebody else. A