From marqueandreprisal at duck.com Mon Jun 1 02:10:52 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Sun, 31 May 2026 20:10:52 -0400 Subject: Unable to issue subkey revocation References:

Message-ID: <936D65D1-E4BE-460E-B6D0-29F503BEA901.1@smtp-inbound1.duck.com> You might take a look at my forum posts. https://forum.gnupg.org/t/unable-to-issue-subkey-revocation/7288 The subjey is not revoked. This was a supplemental fix now broke, gen-revoke: https://blogs.gentoo.org/mgorny/2019/02/20/gen-revoke-extending-revocation-certificates-to-subkeys/ No, your other guy said you are the LibrePGP dev, what's the mixup you believe ,A? From rjh at sixdemonbag.org Mon Jun 1 04:01:04 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 31 May 2026 22:01:04 -0400 Subject: Unable to issue subkey revocation In-Reply-To: <936D65D1-E4BE-460E-B6D0-29F503BEA901.1@smtp-inbound1.duck.com> References:

<936D65D1-E4BE-460E-B6D0-29F503BEA901.1@smtp-inbound1.duck.com> Message-ID: > No, your other guy said you are the LibrePGP dev, what's the mixup you > believe ,A? I said no such thing. "He's also made significant contributions to the OpenPGP and LibrePGP specs," is what I wrote, and I stand by it. Andrew is a contributor to these formal specifications. He is not a GnuPG developer, and I never claimed he was a developer on any LibrePGP implementation. -------------- 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 Mon Jun 1 04:21:12 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 31 May 2026 22:21:12 -0400 Subject: Unable to issue subkey revocation In-Reply-To: <936D65D1-E4BE-460E-B6D0-29F503BEA901.1@smtp-inbound1.duck.com> References:

<936D65D1-E4BE-460E-B6D0-29F503BEA901.1@smtp-inbound1.duck.com> Message-ID: > You might take a look at my forum posts. https://forum.gnupg.org/t/ > unable-to-issue-subkey-revocation/7288 > The subjey is not revoked. As has been explained to you many times now, both here and in the forum, revoking the primary key implicitly revokes all the subkeys which depend upon it for validity. $ gpg --fixed-list-mode --with-colons --list-sig B44427C7 [irrelevant certificate information removed] pub:u:3072:1:1DCBDC01B44427C7:1437075659:::u:::scESC::::::23::0: sub:u:3072:1:DC0F82625FA6AADE:1437075659::::::e::::::23: sig:::1:1DCBDC01B44427C7:1437075659:::: Robert J. Hansen :18x:::::8: The first line, 'pub', identifies the root of my certificate. The second line, 'sub', identifies a secondary chunk of key material -- a subkey. The third line, 'sig', is my certificate root attesting that the subkey should be trusted as coming from me. When and if the pubkey gets revoked, the self-signature on subkeys ceases to be trusted. After all, it's a signature from a revoked key. A subkey without a trusted self-signature is a nullity. They're not allowed to be used. It really is that simple. I would point you to chapter and verse of the RFCs, but you've also said in the forum that "I wouldn't trust modern RFCs." We seem to be at an impasse. We are telling you facts and backing them up by showing you the precise language of the RFC in which these facts can be found, but you refuse to accept the RFC as a source of ground truth. > This was a supplemental fix now broke, gen-revoke: https:// > blogs.gentoo.org/mgorny/2019/02/20/gen-revoke-extending-revocation- > certificates-to-subkeys/ I am unaware of Gentoo ever filing a bug about this. If it's impacting their workflow we'd love to hear from them about it. But it is also very possible that you don't understand the problem that shellscript exists to solve, and are misusing it yourself, and thinking that it's buggy when it's not giving you the results you want. -------------- 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 Mon Jun 1 06:55:42 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 01 Jun 2026 00:55:42 -0400 Subject: Unable to issue subkey revocation References:

<936D65D1-E4BE-460E-B6D0-29F503BEA901.1@smtp-inbound1.duck.com> <91033131-901D-45FE-9867-5A9479ECD598.1@smtp-inbound1.duck.com> Message-ID: No. It does not revoke the subkey. That is why I posted my forum posts to not have to retype paragraphs over and over. It does not revoke the subkey. Furthermore testing after my forum posts shows plainly I can export the still active subkey and list packets and obviously no subkey revocation is listed neither any mention of the primary revocation, and you could go on to reattach it and keep using it. I did confirm what I already said on the forum: it is not revoked. I just gave you the PoC which should have been obvious to anybody that knows what they are talking about. I now tell you to stop replying to me I need this fixed I don't need your nonsense arguments. From andrewg at andrewg.com Mon Jun 1 08:12:09 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 1 Jun 2026 07:12:09 +0100 Subject: Unable to issue subkey revocation In-Reply-To: <936D65D1-E4BE-460E-B6D0-29F503BEA901.1@smtp-inbound1.duck.com> References: <936D65D1-E4BE-460E-B6D0-29F503BEA901.1@smtp-inbound1.duck.com> Message-ID: <2479D3BB-241B-4CDB-8F9D-96A79C2339DB@andrewg.com> On 1 Jun 2026, at 01:47, marqueandreprisal--- via Gnupg-users wrote: > > ?You might take a look at my forum posts. https://forum.gnupg.org/t/unable-to-issue-subkey-revocation/7288 > The subjey is not revoked. The subkey is not revoked, but you do not need to revoke it because the primary is revoked and that takes precedence. It really is that simple. In the very first reply to your forum post, Sebastian gave you the answer to your question: it is a display inconsistency in openkeychain. It is visually confusing but is not a security issue. Multiple people have since told you the same thing, but you do not accept their answers because you have apparently misunderstood the spec. This is not your fault, PGP *is* complex and confusing, and often badly documented. But please stop telling PGP experts that they are not experts just because they do not give you the answer that you expected. > This was a supplemental fix now broke, gen-revoke: https://blogs.gentoo.org/mgorny/2019/02/20/gen-revoke-extending-revocation-certificates-to-subkeys/ You misunderstand the purpose of this tool. It is designed to generate revocation certificates for subkeys *where the primary key is still valid*. It is a workaround for an *offline* primary key, not a revoked one. A From marqueandreprisal at duck.com Mon Jun 1 09:01:00 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 01 Jun 2026 03:01:00 -0400 Subject: import key failure, apparent bug References: <87jysma171.fsf@jacob.g10code.de> <6EEDB0E9-7017-4D2F-A6B4-1C61FEA63351.1@smtp-inbound1.duck.com> Message-ID: <8534F271-C20E-4B58-8B2F-DAF1688DCD69.1@smtp-inbound1.duck.com> Hey Joshua can you help out since you seem to be so good at inspecting gpg keys that you can notice checksum differences? I have a revoked primary key and GnuPG has a bug where it wrongly shows the subkey as revoked and refuses to issue a 0x28. I did some more research and it looks like gpgsplit can be used to write the revocation manually somehow. A few more hours with AI reveals more bugs in the latest GnuPG where all of the subkey options are broke nearly every export will export the entire set of keys even when specifying specific LONG ID of the subkey. The biggest hints that GnuPG used to work is Michael's blog and the "(deprecated)" in the RFC meaning it used to be working and not bugged. From marqueandreprisal at duck.com Mon Jun 1 09:39:35 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 01 Jun 2026 03:39:35 -0400 Subject: Unable to issue subkey revocation References: <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> <87y0gz93i9.fsf@jacob.g10code.de> <7E711963-38F6-45D4-9515-3EB2C51FAF30.1@smtp-inbound1.duck.com> <87tsrm94dt.fsf@jacob.g10code.de> Message-ID: <199DFE78-BEC4-41A1-B574-E4681790FF8B.1@smtp-inbound1.duck.com> ---------------------------------------- From: Werner Koch To: marqueandreprisal at duck.com Date: Jun 1, 2026 06:06:57 Subject: Re: Unable to issue subkey revocation > On Sun, 31 May 2026 22:26, marqueandreprisal at duck.com said: >> Did I accidentally email you outside of the mailing list? The way I >> recall PGP 1 is that it used an algorithm that became proprietary and > > Nope. > > > Shalom-Salam, > > ?? Werner > > -- > The pioneers of a warless world are the youth that > refuse military service.???????????? - A. Einstein wk, The rights were eventually consumed by Broadcom where the use of PGP 1 collapsed likely because of code bugs like this I here report forcing misusage and no mathematically cracked problem, forced usage error by devs making bugs like this. The subkey is not revoked. Read the thread title: Unable to issue subkey revocation. BUG CONFIRMED? From marqueandreprisal at duck.com Mon Jun 1 09:48:17 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 01 Jun 2026 03:48:17 -0400 Subject: Another bug, can't export subkeys or private keys Message-ID: <8A7CE4F8-DC62-4EAE-A034-5D755B9990EA.1@smtp-inbound1.duck.com> Another bug the community can confirm. This is a separate issue 'can't export subkeys or private keys'? There are various options to export secret and public keys and subkeys. Steps to repro: export any subkey and the primary is always included. Export any private key and the public key is always included. What would you say at this rate that is about 20% of your frontend GnuPG malfunctioning. From chd at chud.net Mon Jun 1 08:46:46 2026 From: chd at chud.net (Chris DeYoung) Date: Sun, 31 May 2026 23:46:46 -0700 Subject: Unable to issue subkey revocation In-Reply-To: References:

<936D65D1-E4BE-460E-B6D0-29F503BEA901.1@smtp-inbound1.duck.com> <91033131-901D-45FE-9867-5A9479ECD598.1@smtp-inbound1.duck.com> Message-ID: <78a33651-6c5f-4452-8481-2644a5219b9a@chud.net> I don't claim to have anything approaching the technical expertise of several of the people who have already addressed the issue, but nonetheless I think I have followed the explanation reasonably well (and I invite correction if I'm mistaken). That said, > No. It does not revoke the subkey. It doesn't need to. The subkey is automatically invalid because the primary key associated with it is invalid (revoked). Any system using the subkey *must* check this; failure to do so means potentially trusting an invalid key - no different than using the primary key without checking whether it has been revoked. It seems like you want to require that the subkey itself is also explicitly revoked, but this is neither necessary nor required, so failure to do so is not a bug. Am I wrong? Cheers, -Chris From m at gnupg.org Mon Jun 1 11:30:00 2026 From: m at gnupg.org (Meik Michalke) Date: Mon, 01 Jun 2026 11:30:00 +0200 Subject: Unable to issue subkey revocation In-Reply-To: <78a33651-6c5f-4452-8481-2644a5219b9a@chud.net> References:

<78a33651-6c5f-4452-8481-2644a5219b9a@chud.net> Message-ID: <10794454.F3ui3E0B66@kasidy> Am Montag, 1. Juni 2026, 08:46:46 CEST schrieb Chris DeYoung: > It doesn't need to. The subkey is automatically invalid because the > primary key associated with it is invalid (revoked). yes, first revoking a primary key and then asking to use it once more to revoke one of its subkeys sound a bit like burning down the house and then wanting to lock your flat door. -------------- 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 rjh at sixdemonbag.org Mon Jun 1 12:04:00 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 1 Jun 2026 06:04:00 -0400 Subject: Another bug, can't export subkeys or private keys In-Reply-To: <8A7CE4F8-DC62-4EAE-A034-5D755B9990EA.1@smtp-inbound1.duck.com> References: <8A7CE4F8-DC62-4EAE-A034-5D755B9990EA.1@smtp-inbound1.duck.com> Message-ID: <639d99b0-74f0-4325-9233-8bcad40ef083@sixdemonbag.org> > Another bug the community can confirm. This is a separate issue 'can't > export subkeys or private keys'? There are various options to export > secret and public keys and subkeys. Steps to repro: export any subkey > and the primary is always included. Export any private key and the > public key is always included. What would you say at this rate that is > about 20% of your frontend GnuPG malfunctioning. I would say this behavior goes back to PGP 5.0, so for you to be correct I'd need to believe this bug had been hiding in plain sight for thirty years. Or I could simply realize, "this is the standard behavior ever since PGP 5.0," and move on. I elect for option two. I recommend everyone else do the same. -------------- 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 Mon Jun 1 13:00:44 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 1 Jun 2026 07:00:44 -0400 Subject: import key failure, apparent bug In-Reply-To: <8534F271-C20E-4B58-8B2F-DAF1688DCD69.1@smtp-inbound1.duck.com> References: <87jysma171.fsf@jacob.g10code.de> <6EEDB0E9-7017-4D2F-A6B4-1C61FEA63351.1@smtp-inbound1.duck.com> <8534F271-C20E-4B58-8B2F-DAF1688DCD69.1@smtp-inbound1.duck.com> Message-ID: > A few more hours with AI reveals more bugs... I think I see where much of the problem lies: you seem to think that Andrew and I are LLMs, and that by just insisting we are wrong we'll immediately tell you that of course we screwed that up and you're right to bring this to our attention. This is of course bollocks, and for that reason I won't belabor it further. In philosophy they like to talk about "category error," by which they mean to have so completely misunderstood a subject that there is no point in even holding discourse until the fundamental misunderstanding is corrected. If President Roosevelt's reaction to Japanese naval aviation bombing the U.S. at Pearl Harbor was to say "this is horrific, the scourge of naval aviation must be ended, immediately scuttle all our aircraft carriers with their planes on them!", he would be suffering category error: he would have so completely misunderstood things that any and all discussion would be pointless until it was corrected. That's where you are right now. It stings to be told "you've so completely misunderstood things there's no point in talking to you," but that's where we are. I'm sorry. Specifically: * You are glorifying the days of PGP 1. PGP 1 was a professional embarrassment to Phil Z, as he himself has said. PGP did not reach any state worth using until PGP 2.6, and even then there were problems. * PGP 2.6 is not more reliable than GnuPG 2.5. PGP 2.6 was written in 1992. We know vastly more now about writing security-critical code than we did back then. * The use of software libraries does not mean software is unreliable, buggy, or insecure. * The RFCs defining OpenPGP (RFC2440, 4880, 4880bis, and 9580) are not just trustworthy: they are defining. The same can be said of the LibrePGP specification. To disagree with the plain text of the RFC is rather like disagreeing with the number pi and saying it's actually 22/7 on the nose and you won't put up with this entire "ratio of a circle's perimeter to its diameter" nonsense. * You think that being rude to people who are helpfully providing you with correct information is somehow acceptable. If you're willing to confront these five different things you have gotten fundamentally wrong, further discussion might be fruitful. If you're not, I'm going to respectfully suggest you be given the boot, in order to keep this community one we all want to be part of. Please choose wisely. -------------- 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 sam at gentoo.org Mon Jun 1 15:01:49 2026 From: sam at gentoo.org (Sam James) Date: Mon, 01 Jun 2026 14:01:49 +0100 Subject: import key failure, apparent bug In-Reply-To: <326cd8cd-12a4-43fb-9546-89767d673ae4@sixdemonbag.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> <326cd8cd-12a4-43fb-9546-89767d673ae4@sixdemonbag.org> Message-ID: <87cxyaxvlu.fsf@gentoo.org> "Robert J. Hansen via Gnupg-users" writes: >> 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 Well, yeah. > * libz, libbz2 -> provides compression algorithms > * libsqlite3 -> modern keybox format is an SQLite db > * libreadline -> command completion and history > * libtinfo -> ncurses But not for cryptography, which was the point of what I was replying to, or for anything really other than auxiliary features (certainly not "just a frontend"). > ... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 418 bytes Desc: not available URL: From jhudson at cedaron.com Mon Jun 1 18:25:01 2026 From: jhudson at cedaron.com (Joshua Hudson) Date: Mon, 1 Jun 2026 09:25:01 -0700 Subject: import key failure, apparent bug In-Reply-To: <87bjdwahn2.fsf@jacob.g10code.de> References: <87jysma171.fsf@jacob.g10code.de> <2669d974-acd7-43b9-941a-2436105791e3@cedaron.com> <87bjdwahn2.fsf@jacob.g10code.de> Message-ID: <486dd090-24e4-4294-8845-88156b0dace3@cedaron.com> On 5/30/2026 11:15 AM, Werner Koch wrote: > Andrew remarked on the ML that the encoding of the MPIs is also not > okay. I have not looked closer at this because I am still on vacation. > > What software was used for exporting the key? > > > Shalom-Salam, > > Werner I have a fifteen year old library for GPG keys that finally needs to add RSA key support. It was tagged not-working at the time it was written and the tech debt came due. And according to my records, fifteen years ago, gpg would import private keys without a checksum. I found the MPI encoding problem; conversion to bits to bytes was not correct. Since the keys were working elsewhere, that was the only possible location. (Conversion from bits to bytes is nontrivial because of the need to account for leading zero bits.) This caused the keyids to disagree and the subkey import to therefore fail. It would appear that gpg doesn't strictly follow the spec and compute the key fingerprint over the incoming subkey packet; but that's neither here nor there. From Steve at Sawczyn.com Mon Jun 1 21:08:40 2026 From: Steve at Sawczyn.com (Steve Sawczyn) Date: Mon, 1 Jun 2026 14:08:40 -0500 Subject: Another bug, can't export subkeys or private keys In-Reply-To: <639d99b0-74f0-4325-9233-8bcad40ef083@sixdemonbag.org> References: <8A7CE4F8-DC62-4EAE-A034-5D755B9990EA.1@smtp-inbound1.duck.com> <639d99b0-74f0-4325-9233-8bcad40ef083@sixdemonbag.org> Message-ID: <2F3C80E2-C008-47A9-95DA-72B4014C1FE1@Sawczyn.com> In the interest of learning and understanding, is there a use case where one might actually want to export a sub-key without exporting the primary key? My immediate thought would be if I want to generate sub-keys for each specific device, (e.g.) one for my laptop, one for my iPad, etc. In that case, wouldn?t I want to just export the relevant sub-key to import on a specific device? This is where the learning and understanding part comes in: If I were to do this, am I correct that I might I only be able to sign things on the devices with the sub-keys, but would not be able to decrypt anything or verify signatures? For example, I could write an Email on my iPad and sign it with the iPad?s sub-key, but if someone encrypted a reply using that sub-key, I would not be able to decrypt it, say, on my iPhone. I?m just trying to better understand what can and can?t be done with sub-keys in order to figure out how I should best be using them ? and, if my understanding is flawed, whether there really might be a use case for exporting just a sub-key without the primary. Steve > On Jun 1, 2026, at 5:04?AM, Robert J. Hansen via Gnupg-users wrote: > > Signed PGP part >> Another bug the community can confirm. This is a separate issue 'can't export subkeys or private keys' There are various options to export secret and public keys and subkeys. Steps to repro: export any subkey and the primary is always included. Export any private key and the public key is always included. What would you say at this rate that is about 20% of your frontend GnuPG malfunctioning. > > I would say this behavior goes back to PGP 5.0, so for you to be correct I'd need to believe this bug had been hiding in plain sight for thirty years. Or I could simply realize, "this is the standard behavior ever since PGP 5.0," and move on. > > I elect for option two. I recommend everyone else do the same. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From andrewg at andrewg.com Mon Jun 1 22:39:11 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 1 Jun 2026 21:39:11 +0100 Subject: Another bug, can't export subkeys or private keys In-Reply-To: <2F3C80E2-C008-47A9-95DA-72B4014C1FE1@Sawczyn.com> References: <8A7CE4F8-DC62-4EAE-A034-5D755B9990EA.1@smtp-inbound1.duck.com> <639d99b0-74f0-4325-9233-8bcad40ef083@sixdemonbag.org> <2F3C80E2-C008-47A9-95DA-72B4014C1FE1@Sawczyn.com> Message-ID: <92a4ae80-0dd5-4fa2-8ec3-570d69ac0238@andrewg.com> On 01/06/2026 20:08, Steve Sawczyn via Gnupg-users wrote: > In the interest of learning and understanding, is there a use case where > one might actually want to export a sub-key without exporting the > primary key? There are plenty of use cases where you want to export only the *private* subkey, where the primary key material stays on a more secure device or even offline, while the private subkey material is used on a daily basis. I'm not aware of any use case where you would want to export only the public subkey, and it would not be usable without its primary in any case. A From rjh at sixdemonbag.org Tue Jun 2 02:12:20 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 1 Jun 2026 20:12:20 -0400 Subject: Another bug, can't export subkeys or private keys In-Reply-To: <92a4ae80-0dd5-4fa2-8ec3-570d69ac0238@andrewg.com> References: <8A7CE4F8-DC62-4EAE-A034-5D755B9990EA.1@smtp-inbound1.duck.com> <639d99b0-74f0-4325-9233-8bcad40ef083@sixdemonbag.org> <2F3C80E2-C008-47A9-95DA-72B4014C1FE1@Sawczyn.com> <92a4ae80-0dd5-4fa2-8ec3-570d69ac0238@andrewg.com> Message-ID: > I'm not aware of any use case where you would want to > export only the public subkey, and it would not be usable without its > primary in any case. I can imagine a use case, it's just ... weird: if you need to verify signatures and certifications made with the corresponding private subkey *and* you're so space-confined you need to strip things down as far as possible, like you're in some embedded space on a ridiculously small PIC. I've seen environments where that requirement exists. So, yeah, it's a weird one: an embedded environment so small you want to strip everything to the bone, but still powerful enough to run GnuPG. I'm not saying it's impossible, just ... weird, like someone confessing from the grave via a seance that there is in fact no life after death. It's the kind of thing to make you scratch your head and think things have gotten pretty weird around here. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4583 bytes Desc: S/MIME Cryptographic Signature URL: From marqueandreprisal at duck.com Tue Jun 2 03:49:45 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 01 Jun 2026 21:49:45 -0400 Subject: Unable to issue subkey revocation References:

<78a33651-6c5f-4452-8481-2644a5219b9a@chud.net> <10794454.F3ui3E0B66@kasidy> <40E0A8B9-AF0D-4412-842E-E32FAB908A31.1@smtp-inbound1.duck.com> Message-ID: <1F3CA1DA-B025-41B2-B788-767BB45D416E.1@smtp-inbound1.duck.com> ---------------------------------------- From: Meik Michalke via Gnupg-users To: gnupg-users at gnupg.org Date: Jun 1, 2026 09:33:17 Subject: Re: Unable to issue subkey revocation > Am Montag, 1. Juni 2026, 08:46:46 CEST schrieb Chris DeYoung: >> It doesn't need to. The subkey is automatically invalid because the >> primary key associated with it is invalid (revoked). > > yes, first revoking a primary key and then asking to use it once more > to > revoke one of its subkeys sound a bit like burning down the house and > then > wanting to lock your flat door. > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users No, it is more like burning down the useless signatures, office maybe, and leaving a perfectly fine valuable encryption engine that may be linked to buildbots in gentoo infrastructure out for the scrappers. From marqueandreprisal at duck.com Tue Jun 2 04:48:33 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 01 Jun 2026 22:48:33 -0400 Subject: Another bug, can't export subkeys or private keys References: <8A7CE4F8-DC62-4EAE-A034-5D755B9990EA.1@smtp-inbound1.duck.com> <639d99b0-74f0-4325-9233-8bcad40ef083@sixdemonbag.org> <2F3C80E2-C008-47A9-95DA-72B4014C1FE1@Sawczyn.com> <68B26280-D7E3-4C0C-BF30-796317386797.1@smtp-inbound1.duck.com> Message-ID: Hi Steve, It sounds like your imagination is about right yet to be exact you would need to try those ideas out and find out it's all bugged up so you can't do any of your right ideas right. Yeah that is an example you could create a subkey for your ipod and then revoke your compromised stolen laptop primary key and want to export the ipod key you still have to a new primary. It doesn't make a whole lot of sense because it is a gpg2 bugged up junk addition that you don't need you could do just as well with signing single keypairs on your own. Moreso using your imagination be aware the fact that this bugged out frontend uses gcrypt library Mallory can momentarily point your junk frontend to a bad library and take all of your secret keys the junk frontend would be communicating to the library. Steve feel free to email this military email direct for my main email to apply for apprenticeship. You got a good and honest imagination; what it takes to be successful. You just need to hear the right answers. Exchange keys and email now. From marqueandreprisal at duck.com Tue Jun 2 04:48:46 2026 From: marqueandreprisal at duck.com (marqueandreprisal at duck.com) Date: Mon, 01 Jun 2026 22:48:46 -0400 Subject: import key failure, apparent bug References: <87jysma171.fsf@jacob.g10code.de> <6EEDB0E9-7017-4D2F-A6B4-1C61FEA63351.1@smtp-inbound1.duck.com> <8534F271-C20E-4B58-8B2F-DAF1688DCD69.1@smtp-inbound1.duck.com> <6C2710B8-0886-4BDB-8DEE-2429C918C583.1@smtp-inbound1.duck.com> Message-ID: <82EBE3F0-5CA1-4BE2-AFCE-F2E2E26C6736.1@smtp-inbound1.duck.com> Robert J. Hansen via Gnupg-users No. I told you you don't have to reply. Your bonsense is getting so bad I bow tell you directly DO NOT ADDRESS ME ANYMORE. If you do, go on and sign and document your harassment crimes. From wk at gnupg.org Tue Jun 2 11:10:37 2026 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jun 2026 11:10:37 +0200 Subject: import key failure, apparent bug In-Reply-To: <82EBE3F0-5CA1-4BE2-AFCE-F2E2E26C6736.1@smtp-inbound1.duck.com> (marqueandreprisal's message of "Mon, 01 Jun 2026 22:48:46 -0400") References: <87jysma171.fsf@jacob.g10code.de> <6EEDB0E9-7017-4D2F-A6B4-1C61FEA63351.1@smtp-inbound1.duck.com> <8534F271-C20E-4B58-8B2F-DAF1688DCD69.1@smtp-inbound1.duck.com> <6C2710B8-0886-4BDB-8DEE-2429C918C583.1@smtp-inbound1.duck.com> <82EBE3F0-5CA1-4BE2-AFCE-F2E2E26C6736.1@smtp-inbound1.duck.com> Message-ID: <874ijl8fzm.fsf@jacob.g10code.de> Hi! I have talked to several people and I hear only complaints about your communication style (to say it friendly). Due to this I set your account to moderated. You will still get posts but whether you can post depends on the willingness of our moderators to read you post and approve it. Note that the moderators in general only handle mails by non-subscribed posters. BTW, in the last >25 years we had to ban only very few people from the GnuPG lists. 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 roam at ringlet.net Tue Jun 2 22:35:23 2026 From: roam at ringlet.net (Peter Pentchev) Date: Tue, 2 Jun 2026 23:35:23 +0300 Subject: Depending on libs and other components (Re: building from source) In-Reply-To: <07A8319A-2A8D-4E5B-80BA-247259688045.1@smtp-inbound1.duck.com> 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> <07A8319A-2A8D-4E5B-80BA-247259688045.1@smtp-inbound1.duck.com> Message-ID: On Fri, May 29, 2026 at 11:45:50PM -0400, marqueandreprisal--- via Gnupg-users wrote: > 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. OK, I'll bite. But only this once. I am not engaging in a long discussion. ...and what happens if, later, either the same developer or a different one want to use some of the functionality without implementing it over and over and over again? Or without copying source code that, if not maintained in a library with versioned releases, *will* get stale and buggy? There are many reasons a software developer may decide to break some of the code out into a library. Most of them boil down to "...and I also want to use this in that other program", but there are also others - shared authorship, development by a different team for some specific subset, many others. Also, there are many reasons a software developer may decide to *use* an *already written* library instead of reimplenting the same thing from scratch and taking months to stumble across all the bugs and corner cases that *have already been solved* in the ready-made library. It is true that any programmer can choose to write any specific program from scratch without using any code already written. However, doing that *always*, as a rule, would be just... silly. Very, very silly. G'luck, Peter -- Peter Pentchev roam at ringlet.net roam at debian.org peter at morpheusly.com PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From roam at ringlet.net Wed Jun 3 02:50:07 2026 From: roam at ringlet.net (Peter Pentchev) Date: Wed, 3 Jun 2026 03:50:07 +0300 Subject: MS-DOS security [Was: Re: GnuPG cannot know if is runs in a "secure" environment (Re: standard comment)] In-Reply-To: <7E0E5A54-BA8C-44DA-8162-9FBAB4A9969E.1@smtp-inbound1.duck.com> 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> <7E0E5A54-BA8C-44DA-8162-9FBAB4A9969E.1@smtp-inbound1.duck.com> Message-ID: On Fri, May 29, 2026 at 11:49:28PM -0400, marqueandreprisal--- via Gnupg-users wrote: [snip] > Like I said generally PGP was > designed for DOS which is pretty good security wise. Sigh. I assume (okay, well, I remember Phil Zimmermann's PGP, so I know) that when you say "DOS", you mean MS-DOS and not any of the other literally dozens, if not hundreds, of formerly popular disk operating systems out there. I remember MS-DOS. Without any intent to offend anybody, I can assure you that security was never a design goal there. And it was never achieved. I mean, it took under a hundred lines of barely competent assembly (I know, it was my second attempt at 8086 assembly :)) to write a stealth resident program. For somebody who knew what they were doing, it took less than 512 bytes to write an incredibly powerful stealth virus (look up V512/Number of the Beast). Any program could intercept (and disable!) any interrupt. Any program could access any I/O ports. No, MS-DOS was not "pretty good security wise". It was never meant to be, and it never was. So please, please stop repeating that. G'luck, Peter -- Peter Pentchev roam at ringlet.net roam at debian.org peter at morpheusly.com PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From rjh at sixdemonbag.org Wed Jun 3 05:35:54 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 2 Jun 2026 23:35:54 -0400 Subject: MS-DOS security [Was: Re: GnuPG cannot know if is runs in a "secure" environment (Re: standard comment)] In-Reply-To: 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> <7E0E5A54-BA8C-44DA-8162-9FBAB4A9969E.1@smtp-inbound1.duck.com> Message-ID: > Sigh. I assume (okay, well, I remember Phil Zimmermann's PGP, so I know) that > when you say "DOS", you mean MS-DOS and not any of the other literally dozens, > if not hundreds, of formerly popular disk operating systems out there. Not necessarily true! He could've meant IBM PC-DOS! (For those thinking this is a serious post, PC-DOS *was* MS-DOS under a rebranding agreement. Around v6.1 PC-DOS began getting new features not in MS-DOS, but my comment above is pretty much the definition of "a distinction without a difference". And yes, you have to be older than dirt in order to have lived through this time period.) ObFreeSoftware: remember, folks, don't use either PC-DOS or MS-DOS. FreeDOS exists and is superior to both, not just in terms of your freedoms but technologically, too. -------------- 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 borden_c at tutanota.com Fri Jun 12 21:30:04 2026 From: borden_c at tutanota.com (Borden) Date: Fri, 12 Jun 2026 21:30:04 +0200 (CEST) Subject: GPG4Win slow to start Message-ID: GPG4Win takes up to a minute to start, which is nothing in the grand scheme but frustrating when one is trying to get things done (like log into a website with a timeout). I can't figure out whether this is a feature of the software or a problem that only I have. I dual boot between Linux and Windows on the same hardware. The gnupg folders are identical between both systems. Linux is almost instantaneous and Windows is not. Under advice from?https://www.etl-tools.com/wiki/knowledgebase/issues/gpg-issues/, I collected a verbose log out of Kleopatra. The sanitised version reads: 00:00:24 gpg[9999] enabled debug flags: memstat trust extprog 00:00:24 gpg[9999] enabled compatibility flags: 00:00:24 gpg[9999] public key is 0123456789ABCDEF 00:00:26 gpg[9999] no running keyboxd - starting 'C:\\Program Files\\GnuPG\\bin\\keyboxd.exe' 00:00:28 gpg[9999] waiting for the keyboxd to come up ... (8s) 00:00:28 gpg[9999] connection to the keyboxd established 00:00:28 gpg[9999] using subkey 0123456789ABCDEF instead of primary key FEDCBA9876543210 00:00:28 gpg[9999] encrypted with cv25519 key, ID 0123456789ABCDEF, created 2026-01-01 ????? "My Key" 00:00:30 gpg[9999] no running gpg-agent - starting 'C:\\Program Files\\GnuPG\\bin\\gpg-agent.exe' 00:00:32 gpg[9999] waiting for the agent to come up ... (8s) 00:00:32 gpg[9999] connection to the agent established 00:00:32 gpg[9999] pinentry launched (11111 qt 1.3.2 - - - - 0/0 -) 00:00:38 gpg[9999] AES256.CFB encrypted data 00:00:38 gpg[9999] original file name='myfile.txt' 00:00:38 gpg[9999] keydb: handles=0 locks=0 parse=4 get=0 00:00:38 gpg[9999]??????? build=0 update=0 insert=0 delete=0 00:00:38 gpg[9999]??????? reset=0 found=0 not=0 cache=0 not=0 00:00:38 gpg[9999] kid_not_found_cache: count=0 peak=0 flushes=0 00:00:38 gpg[9999] sig_cache: total=24 cached=24 good=24 bad=0 00:00:38 gpg[9999] objcache: keys=8/8/0 chains=375,1..1 buckets=383/20 attic=248 00:00:38 gpg[9999] objcache: uids=2/2/0 chains=105,1..1 buckets=107/20 00:00:38 gpg[9999] random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 ????????????? outmix=0 getlvl1=0/0 getlvl2=0/0 00:00:38 gpg[9999] rndjent stat: collector=0x0000000000000000 calls=0 bytes=0 00:00:38 gpg[9999] secmem usage: 0/32768 bytes in 0 blocks ... and the time stamps show about 14 seconds from me trying to decrypt something to it actually getting decrypted. That's a good day. Sometimes it takes upwards of 45 seconds or more, with the biggest time delta being from "connection to the agent established" to "pinentry launched". Again, I'm curious if I'm the only one suffering with this or if this is the cost of doing business or if I'm asking the right people. From wk at gnupg.org Sat Jun 13 18:44:22 2026 From: wk at gnupg.org (Werner Koch) Date: Sat, 13 Jun 2026 18:44:22 +0200 Subject: GPG4Win slow to start In-Reply-To: (Borden via Gnupg-users's message of "Fri, 12 Jun 2026 21:30:04 +0200 (CEST)") References: Message-ID: <87tsr61jbt.fsf@jacob.g10code.de> Hi! > I dual boot between Linux and Windows on the same hardware. The gnupg > folders are identical between both systems. Linux is almost > instantaneous and Windows is not. Interesting data point. We have a few reports from some cusomers where some users experience sometimes huge delays. It is not easy to track down but a common problem on Windows is anti-malware software (e.g. Symantec Endpoint Protection) in certain configurations. To test diable such software, restart backend process (or on the CLI "gpgconf -K all"), and check again. I _may_ even be an answer to the sometimes way longer delays you see noticed; the system may have called home for further analysis. > ... and the time stamps show about 14 seconds from me trying to > decrypt something to it actually getting decrypted. That's a good > day. Sometimes it takes upwards of 45 seconds or more, with the > biggest time delta being from "connection to the agent established" to > "pinentry launched". That is also interesting. You may want to enable a log for the gpg-agent at basic debug level or just with verbose. But as a first test you may run on the command line: gpg-connect-agent "getinfo s2k_count_cal" "getinfo s2k_time" /bye The output will besomething like: D 53686272 OK D 101 OK These are the calibrated interation counts. When gpg-agent is first started it checks which KDF parameters are required to let the KDF take 100ms on that system. It is actually the same function on Windows on and Linux but the way the times are retrieved from the OS are different. Frankly, I doubt that this is the reason but who knows. 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 borden_c at tutanota.com Wed Jun 17 22:46:27 2026 From: borden_c at tutanota.com (Borden) Date: Wed, 17 Jun 2026 22:46:27 +0200 (CEST) Subject: GPG4Win slow to start In-Reply-To: <87tsr61jbt.fsf@jacob.g10code.de> References: <87tsr61jbt.fsf@jacob.g10code.de> Message-ID: 13 Jun 2026, 12:44 by wk at gnupg.org: > Interesting data point. We have a few reports from some cusomers where > some users experience sometimes huge delays. It is not easy to track > down but a common problem on Windows is anti-malware software (e.g. > Symantec Endpoint Protection) in certain configurations. To test diable > such software, restart backend process (or on the CLI "gpgconf -K all"), > and check again. > The only anti-malware software on my system is Windows Defender. I would think that if that were the problem there would be more complaints. > That is also interesting. You may want to enable a log for the > gpg-agent at basic debug level or just with verbose. But as a first > test you may run on the command line: > Thank you for your help and interest. I'm probably launching these in the wrong order (I don't entirely understand how the GPG backend works and I know even less about Windows process management), but: PS $?gpgconf -K all # Takes a couple seconds and exits without output PS $?gpg-connect-agent "getinfo s2k_count_cal" "getinfo s2k_time" /bye gpg-connect-agent: no running gpg-agent - starting 'C:\\Program Files\\GnuPG\\bin\\gpg-agent.exe' gpg-connect-agent: waiting for the agent to come up ... (8s) gpg-connect-agent: connection to the agent established D 23966720 OK D 125 OK PS $ gpg-agent --debug=1 gpg-agent[1111]: reading options from 'C:/Users/me/AppData/Roaming/gnupg/gpg-agent.conf' gpg-agent[1111]: reading options from '[cmdline]' gpg-agent[1111]: reading options from 'C:/Users/me/AppData/Roaming/gnupg/common.conf' gpg-agent[1111]: gpg-agent running and available I'm not sure where to look for logs after that. The log I submitted earlier reads: 2026-06-17 16:26:02 gpg[0998] rndjent stat: collector=0x0000000000000000 calls=0 bytes=0 2026-06-17 16:26:02 gpg[0998] secmem usage: 0/32768 bytes in 0 blocks 2026-06-17 16:26:04 gpg[0999] pinentry launched (10724 qt 1.3.2 - - - - 0/0 -) 2026-06-17 16:26:16 gpg[0999] keydb_search failed: Input/output error 2026-06-17 16:26:16 gpg[0999] public key decryption failed: Operation cancelled 2026-06-17 16:26:16 gpg[0999] decryption failed: Operation cancelled 2026-06-17 16:26:16 gpg[0999] keydb: handles=0 locks=0 parse=3 get=0 2026-06-17 16:26:16 gpg[0999]??????? build=0 update=0 insert=0 delete=0 2026-06-17 16:26:16 gpg[0999]??????? reset=0 found=0 not=0 cache=0 not=0 2026-06-17 16:26:16 gpg[0999] kid_not_found_cache: count=0 peak=0 flushes=0 2026-06-17 16:26:16 gpg[0999] sig_cache: total=17 cached=17 good=17 bad=0 2026-06-17 16:26:16 gpg[0999] objcache: keys=8/8/0 chains=375,1..1 buckets=383/20 attic=248 2026-06-17 16:26:16 gpg[0999] objcache: uids=2/2/0 chains=105,1..1 buckets=107/20 2026-06-17 16:26:16 gpg[0999] random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 ????????????? outmix=0 getlvl1=0/0 getlvl2=0/0 2026-06-17 16:26:16 gpg[0999] rndjent stat: collector=0x0000000000000000 calls=0 bytes=0 2026-06-17 16:26:16 gpg[0999] secmem usage: 0/32768 bytes in 0 blocks 2026-06-17 16:27:25 gpg[1000] enabled debug flags: memstat trust extprog 2026-06-17 16:27:25 gpg[1000] enabled compatibility flags: 2026-06-17 16:27:25 gpg[1000] public key is ABCDEF0987654321 2026-06-17 16:27:27 gpg[1000] no running keyboxd - starting 'C:\\Program Files\\GnuPG\\bin\\keyboxd.exe' 2026-06-17 16:27:29 gpg[1000] waiting for the keyboxd to come up ... (8s) 2026-06-17 16:27:29 gpg[1000] connection to the keyboxd established 2026-06-17 16:27:29 gpg[1000] using subkey ABCDEF0987654321 instead of primary key 1234567890ABCDEF 2026-06-17 16:27:29 gpg[1000] encrypted with cv25519 key, ID ABCDEF0987654321, created 2026-01-01 ????? "Me" 2026-06-17 16:27:29 gpg[1000] pinentry launched (7080 qt 1.3.2 - - - - 0/0 -) 2026-06-17 16:27:33 gpg[1000] AES256.CFB encrypted data 2026-06-17 16:27:33 gpg[1000] original file name='encrypted_text.txt' 2026-06-17 16:27:33 gpg[1000] keydb: handles=0 locks=0 parse=4 get=0 2026-06-17 16:27:33 gpg[1000]??????? build=0 update=0 insert=0 delete=0 2026-06-17 16:27:33 gpg[1000]??????? reset=0 found=0 not=0 cache=0 not=0 2026-06-17 16:27:33 gpg[1000] kid_not_found_cache: count=0 peak=0 flushes=0 2026-06-17 16:27:33 gpg[1000] sig_cache: total=24 cached=24 good=24 bad=0 2026-06-17 16:27:33 gpg[1000] objcache: keys=8/8/0 chains=375,1..1 buckets=383/20 attic=248 2026-06-17 16:27:33 gpg[1000] objcache: uids=2/2/0 chains=105,1..1 buckets=107/20 2026-06-17 16:27:33 gpg[1000] random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 ????????????? outmix=0 getlvl1=0/0 getlvl2=0/0 2026-06-17 16:27:33 gpg[1000] rndjent stat: collector=0x0000000000000000 calls=0 bytes=0 2026-06-17 16:27:33 gpg[1000] secmem usage: 0/32768 bytes in 0 blocks # I sanitised the process numbers, account names & key IDs. Everything else is verbatim I don't know how much of that, if any of it, is relevant to the previous commands I launched. For what it's worth, the delay is worst during the first call after boot. Subsequent GPG calls are far almost Linux's speed. As a workaround, I sometimes start Kleopatra after boot so it loads everything before I need it. Sometimes Kleopatra hangs for a while while launching, sometimes it's not so bad. After Kleopatra is up, things are much smoother. I also noticed a quirk in the past few months that GPG was closing almost immediately after using it, which it hadn't before. I set?"C:\Users\me\AppData\Roaming\gnupg\gpg-agent.conf" to "pinentry-timeout 300", which helped. I don't know if any of that is relevant. Thanks again