From gordiancrypt at gmail.com  Tue Apr  1 15:11:24 2025
From: gordiancrypt at gmail.com (Gordian Crypt)
Date: Tue, 1 Apr 2025 06:11:24 -0700
Subject: New Encryption Algorithm - GordianCrypt
Message-ID: <5582EAC0-45CE-4CD5-BD23-A4864FF3DF2F@gmail.com>

Dear GNUPG team,

I hope you are having a productive day.

I am writing to introduce myself and share details about a new encryption algorithm I have developed?GordianCrypt. With over 10 years of experience in security and networking, I have dedicated my career to advancing encryption technologies. This algorithm is the culmination of that work, and I am eager to receive insights and feedback from experts like you.

GordianCrypt is designed to provide robust security through an innovative approach to public key encryption. I invite you to visit the demo website at www.gordiancrypt.com, where you can review the white paper and experiment with the encryption and decryption processes firsthand.

If you are interested or know anyone who might be, I would greatly appreciate the opportunity to discuss GordianCrypt further and hear your thoughts.

Thank you for your time and consideration. I look forward to your response.

Best regards,
-Ben
GordianCrypt Author


From andrewg at andrewg.com  Wed Apr  2 11:07:49 2025
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 2 Apr 2025 10:07:49 +0100
Subject: New Encryption Algorithm - GordianCrypt
In-Reply-To: <5582EAC0-45CE-4CD5-BD23-A4864FF3DF2F@gmail.com>
References: <5582EAC0-45CE-4CD5-BD23-A4864FF3DF2F@gmail.com>
Message-ID: <E98061B0-684A-411A-84D2-AB0007B0C3F0@andrewg.com>

Hi, Ben.

On 1 Apr 2025, at 14:11, Gordian Crypt via Gnupg-users <gnupg-users at gnupg.org> wrote:
> 
> I am writing to introduce myself and share details about a new encryption algorithm I have developed?GordianCrypt. With over 10 years of experience in security and networking, I have dedicated my career to advancing encryption technologies. This algorithm is the culmination of that work, and I am eager to receive insights and feedback from experts like you.

> GordianCrypt is designed to provide robust security through an innovative approach to public key encryption. I invite you to visit the demo website at www.gordiancrypt.com <http://www.gordiancrypt.com/>, where you can review the white paper and experiment with the encryption and decryption processes firsthand.

Without a copy of the code, we are not doing anything firsthand, it?s just a web form with unclear properties. It could be doing anything in the back end for all an external observer can know. And your white paper contains no technical info; it reads as a press release. If you want meaningful feedback, you need to publish your algorithm - in excruciating detail.

What little I can glean from your website is concerning, for example when you sum the bit lengths of each of your ten (!) layers - this merely provides an upper bound on the cryptographic strength, which could be orders of magnitude lower (or even zero) depending on the implementation details. In general, superimposing multiple layers of algorithms with smaller individual key spaces does not compare to using a single algorithm with a larger key space, and these layers may interact in non-trivial ways - see 3DES for a real world example of how such a construction can fail.

You claim that your algorithm is quantum-safe, but provide no security proof. You also claim that it is ?unbreakable by AI?, which is a trivial property since AI can?t even break the weakest known ciphers. It is not clear that you have any experience in cryptanalysis or algorithm design - might I humbly suggest that you start with something a little less ambitious?

In short, there is nothing here (yet) to review.

Thanks,
Andrew.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250402/d1782845/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250402/d1782845/attachment.sig>

From anze at anze.dev  Wed Apr  2 12:03:05 2025
From: anze at anze.dev (Anze Jensterle)
Date: Wed, 2 Apr 2025 12:03:05 +0200
Subject: New Encryption Algorithm - GordianCrypt
In-Reply-To: <E98061B0-684A-411A-84D2-AB0007B0C3F0@andrewg.com>
References: <5582EAC0-45CE-4CD5-BD23-A4864FF3DF2F@gmail.com>
 <E98061B0-684A-411A-84D2-AB0007B0C3F0@andrewg.com>
Message-ID: <CAM+zwjQYsFNNNfeqEmsn1Eu93KdsJwUbepMMCQsJtUDBbWe+_A@mail.gmail.com>

Hey all,

On Wed, 2 Apr 2025 at 11:50, Andrew Gallagher via Gnupg-users <
gnupg-users at gnupg.org> wrote:

> Hi, Ben.
>
> On 1 Apr 2025, at 14:11, Gordian Crypt via Gnupg-users <
> gnupg-users at gnupg.org> wrote:
>
>
> I am writing to introduce myself and share details about a new encryption
> algorithm I have developed?GordianCrypt. With over 10 years of experience
> in security and networking, I have dedicated my career to advancing
> encryption technologies. This algorithm is the culmination of that work,
> and I am eager to receive insights and feedback from experts like you.
>
>
> GordianCrypt is designed to provide robust security through an innovative
> approach to public key encryption. I invite you to visit the demo website at
>  www.gordiancrypt.com, where you can review the white paper and
> experiment with the encryption and decryption processes firsthand.
>
>
> Without a copy of the code, we are not doing anything firsthand, it?s just
> a web form with unclear properties. It could be doing anything in the back
> end for all an external observer can know. And your white paper contains no
> technical info; it reads as a press release. If you want meaningful
> feedback, you need to publish your algorithm - in excruciating detail.
>
> What little I can glean from your website is concerning, for example when
> you sum the bit lengths of each of your ten (!) layers - this merely
> provides an upper bound on the cryptographic strength, which could be
> orders of magnitude lower (or even zero) depending on the implementation
> details. In general, superimposing multiple layers of algorithms with
> smaller individual key spaces does not compare to using a single algorithm
> with a larger key space, and these layers may interact in non-trivial ways
> - see 3DES for a real world example of how such a construction can fail.
>
> You claim that your algorithm is quantum-safe, but provide no security
> proof. You also claim that it is ?unbreakable by AI?, which is a trivial
> property since AI can?t even break the weakest known ciphers. It is not
> clear that you have any experience in cryptanalysis or algorithm design -
> might I humbly suggest that you start with something a little less
> ambitious?
>
> In short, there is nothing here (yet) to review.
>
> Thanks,
> Andrew.
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-use
> <https://lists.gnupg.org/mailman/listinfo/gnupg-users>rs

I really hope this message was just an April Fools joke, since if you
really want us to audit what you made, technical details of the algorithms
need to be public. I also noticed this was only sent to the GnuPG mailing
list. Do you have anything to support your backing like academic
affiliation or a company? Deciding to launch a cryptography product without
proper peer review is just plain irresponsible.

Have a good one,
Anze

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250402/00f99a7f/attachment-0001.html>

From ralph at ml.seichter.de  Wed Apr  2 12:47:03 2025
From: ralph at ml.seichter.de (Ralph Seichter)
Date: Wed, 02 Apr 2025 12:47:03 +0200
Subject: New Encryption Algorithm - GordianCrypt
In-Reply-To: <5582EAC0-45CE-4CD5-BD23-A4864FF3DF2F@gmail.com>
References: <5582EAC0-45CE-4CD5-BD23-A4864FF3DF2F@gmail.com>
Message-ID: <D8W3D2F7MYOH.39Y2TF2ZT7I26@ml.seichter.de>

* Gordian Crypt via Gnupg-users:

> I am writing to introduce myself and share details about a new
> encryption algorithm I have developed?GordianCrypt.

Sure you do. On April Fools' Day, with a generic gmail.com address.
Wat heb wi lacht. ;-)

-Ralph


From stuartl at longlandclan.id.au  Wed Apr  9 23:57:24 2025
From: stuartl at longlandclan.id.au (Stuart Longland)
Date: Thu, 10 Apr 2025 07:57:24 +1000
Subject: pinentry-qt and on-screen keyboards
Message-ID: <fbbf9268-e79e-483b-b00a-46afd8404564@longlandclan.id.au>

Hi all,

I recently bought a second hand Panasonic Toughpad FZ-G1 which is a 
tablet form-factor PC.  I've loaded it with Debian 12 using the KDE 
Plasma desktop (using X11 for now) and have `xvkbd` set up as a virtual 
keyboard.

It is important to note this machine has a single USB (USB3 type A) port 
and *NO* hardware keyboard beyond a couple of macro buttons on the bezel.

pinentry, it seems, does not get along with xvkbd.  When I need to 
unlock a private key, pinentry (I'm using pinentry-qt) blocks input 
events from all other applications, including xvkbd.  I'm not sure the 
situation would change if I used something else.

While I can understand this on a standard keyboard-equipped computer in 
normal circumstances, doing it on a touchscreen-driven tablet is 
ridiculous.  I basically cannot use GnuPG at all on this computer unless 
my keys are stored without a passphrase, which is demonstrably worse 
security than pinentry preventing input to other applications.

Is there a way to relax this restriction?
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
   ...it's backed up on a tape somewhere.


From stuartl at longlandclan.id.au  Thu Apr 10 06:47:38 2025
From: stuartl at longlandclan.id.au (Stuart Longland)
Date: Thu, 10 Apr 2025 14:47:38 +1000
Subject: pinentry-qt and on-screen keyboards
In-Reply-To: <fbbf9268-e79e-483b-b00a-46afd8404564@longlandclan.id.au>
References: <fbbf9268-e79e-483b-b00a-46afd8404564@longlandclan.id.au>
Message-ID: <78b3a807-3722-4282-8337-2a71aa31bd0e@longlandclan.id.au>

On 10/4/25 07:57, Stuart Longland via Gnupg-users wrote:
> 
> Is there a way to relax this restriction?

I had a moment to experiment? `pinentry-fltk` does not block input, so 
while it doesn't "look" like everything else, it works.

Good enough ? so long as someone doesn't port this "security feature" 
and break it on me.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
   ...it's backed up on a tape somewhere.



From jb-gnumlists at wisemo.com  Thu Apr 10 14:09:56 2025
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Thu, 10 Apr 2025 14:09:56 +0200
Subject: pinentry-qt and on-screen keyboards
In-Reply-To: <fbbf9268-e79e-483b-b00a-46afd8404564@longlandclan.id.au>
References: <fbbf9268-e79e-483b-b00a-46afd8404564@longlandclan.id.au>
Message-ID: <846f236f-3794-4710-bd56-22de3952cb4e@wisemo.com>

On 4/9/2025 23:57:24, Stuart Longland via Gnupg-users wrote:
> Hi all,
>
> I recently bought a second hand Panasonic Toughpad FZ-G1 which is a 
> tablet form-factor PC.? I've loaded it with Debian 12 using the KDE 
> Plasma desktop (using X11 for now) and have `xvkbd` set up as a 
> virtual keyboard.
>
> It is important to note this machine has a single USB (USB3 type A) 
> port and *NO* hardware keyboard beyond a couple of macro buttons on 
> the bezel.
>
> pinentry, it seems, does not get along with xvkbd.? When I need to 
> unlock a private key, pinentry (I'm using pinentry-qt) blocks input 
> events from all other applications, including xvkbd.? I'm not sure the 
> situation would change if I used something else.
>
> While I can understand this on a standard keyboard-equipped computer 
> in normal circumstances, doing it on a touchscreen-driven tablet is 
> ridiculous.? I basically cannot use GnuPG at all on this computer 
> unless my keys are stored without a passphrase, which is demonstrably 
> worse security than pinentry preventing input to other applications.
>
> Is there a way to relax this restriction?

Ditto,

As someone who co-writes other tools that deal with the user terminal in 
"unexpected" ways, hardwired "features" that restrict terminal 
input/output to/from "sensitive" entry fields tend to be a PITA and a 
major problem when the actual user that needs to handle the secret has 
no access other than through something that such a "feature" blocks.

I have not had opportunity to test our tools with pinentry-qt yet, but 
thanks for the heads up about this misfeature.

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 kloecker at kde.org  Thu Apr 10 20:48:25 2025
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Thu, 10 Apr 2025 20:48:25 +0200
Subject: pinentry-qt and on-screen keyboards
In-Reply-To: <fbbf9268-e79e-483b-b00a-46afd8404564@longlandclan.id.au>
References: <fbbf9268-e79e-483b-b00a-46afd8404564@longlandclan.id.au>
Message-ID: <2308430.vFx2qVVIhK@daneel>

On Mittwoch, 9. April 2025 23:57:24 Mitteleurop?ische Sommerzeit Stuart 
Longland via Gnupg-users wrote:
> Is there a way to relax this restriction?

$ man gpg-agent
       --grab
       --no-grab
              Tell  the  pinentry  to  grab the keyboard and mouse.  This 
option should be used on X-Servers to avoid X-sniffing at?
              tacks. Any use of the option --grab overrides an used option --
no-grab.  The default is --no-grab.

So, adding "no-grab" to ~/.gnupg/gpg-agent.conf should do what you want.

Granted. Unless you know that pinentry is always invoked and controlled by 
gpg-agent it's not obvious that you have to look at the manual page of gpg-
agent to look for options to configure pinentry.

Hmm, the default should be "no-grab" according to the man page. According to 
the history "no-grab" is default since gnupg 2.1.23 (released almost 8 years 
ago). Maybe Debian decided that "grab" is better for you.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250410/e9b5e204/attachment.sig>

From kloecker at kde.org  Thu Apr 10 20:50:44 2025
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Thu, 10 Apr 2025 20:50:44 +0200
Subject: pinentry-qt and on-screen keyboards
In-Reply-To: <846f236f-3794-4710-bd56-22de3952cb4e@wisemo.com>
References: <fbbf9268-e79e-483b-b00a-46afd8404564@longlandclan.id.au>
 <846f236f-3794-4710-bd56-22de3952cb4e@wisemo.com>
Message-ID: <3627711.dWV9SEqChM@daneel>

On Donnerstag, 10. April 2025 14:09:56 Mitteleurop?ische Sommerzeit Jakob Bohm 
via Gnupg-users wrote:
> I have not had opportunity to test our tools with pinentry-qt yet, but
> thanks for the heads up about this misfeature.

Dear Mr. Bohm,

I'd appreciate if you checked the facts the next time before you make such 
unfounded accusations.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250410/5870971b/attachment.sig>

From stuartl at longlandclan.id.au  Fri Apr 11 02:35:37 2025
From: stuartl at longlandclan.id.au (Stuart Longland)
Date: Fri, 11 Apr 2025 10:35:37 +1000
Subject: pinentry-qt and on-screen keyboards
In-Reply-To: <2308430.vFx2qVVIhK@daneel>
References: <fbbf9268-e79e-483b-b00a-46afd8404564@longlandclan.id.au>
 <2308430.vFx2qVVIhK@daneel>
Message-ID: <701a0ace-a18d-4c08-8a9b-2f0294f78e72@longlandclan.id.au>

On 11/4/25 04:48, Ingo Kl?cker wrote:
> $ man gpg-agent
>         --grab
>         --no-grab
>                Tell  the  pinentry  to  grab the keyboard and mouse.  This
> option should be used on X-Servers to avoid X-sniffing at?
>                tacks. Any use of the option --grab overrides an used option --
> no-grab.  The default is --no-grab.
> 
> So, adding "no-grab" to ~/.gnupg/gpg-agent.conf should do what you want.

Ahh bingo, I'll give that a try in a moment.  I was looking at the 
`pinentry` documentation, which was the completely wrong place to look 
for this setting.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
   ...it's backed up on a tape somewhere.



From stuartl at longlandclan.id.au  Fri Apr 11 05:40:22 2025
From: stuartl at longlandclan.id.au (Stuart Longland)
Date: Fri, 11 Apr 2025 13:40:22 +1000
Subject: pinentry-qt and on-screen keyboards [resolved]
In-Reply-To: <701a0ace-a18d-4c08-8a9b-2f0294f78e72@longlandclan.id.au>
References: <fbbf9268-e79e-483b-b00a-46afd8404564@longlandclan.id.au>
 <2308430.vFx2qVVIhK@daneel>
 <701a0ace-a18d-4c08-8a9b-2f0294f78e72@longlandclan.id.au>
Message-ID: <77af95c0-b048-44e1-94ac-2e8fc990ca17@longlandclan.id.au>

On 11/4/25 10:35, Stuart Longland via Gnupg-users wrote:
>> So, adding "no-grab" to ~/.gnupg/gpg-agent.conf should do what you want.
> 
> Ahh bingo, I'll give that a try in a moment.? I was looking at the 
> `pinentry` documentation, which was the completely wrong place to look 
> for this setting.

A follow up, this was indeed the fix.  Debian seems to ship a 
`gpg-agent` binary that defaults to `grab`.  Adding this one line and 
rebooting (overkill, but I had a pending kernel update) fixed the issue.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
   ...it's backed up on a tape somewhere.



From kloecker at kde.org  Fri Apr 11 09:40:16 2025
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Fri, 11 Apr 2025 09:40:16 +0200
Subject: pinentry-qt and on-screen keyboards [resolved]
In-Reply-To: <77af95c0-b048-44e1-94ac-2e8fc990ca17@longlandclan.id.au>
References: <fbbf9268-e79e-483b-b00a-46afd8404564@longlandclan.id.au>
 <701a0ace-a18d-4c08-8a9b-2f0294f78e72@longlandclan.id.au>
 <77af95c0-b048-44e1-94ac-2e8fc990ca17@longlandclan.id.au>
Message-ID: <2300396.vFx2qVVIhK@daneel>

On Freitag, 11. April 2025 05:40:22 Mitteleurop?ische Sommerzeit Stuart 
Longland via Gnupg-users wrote:
> On 11/4/25 10:35, Stuart Longland via Gnupg-users wrote:
> >> So, adding "no-grab" to ~/.gnupg/gpg-agent.conf should do what you want.
> > 
> > Ahh bingo, I'll give that a try in a moment.  I was looking at the
> > `pinentry` documentation, which was the completely wrong place to look
> > for this setting.
> 
> A follow up, this was indeed the fix.  Debian seems to ship a
> `gpg-agent` binary that defaults to `grab`.  Adding this one line and
> rebooting (overkill, but I had a pending kernel update) fixed the issue.

Excellent.

I had a look at the patches Debian applies to gnupg for current stable 
(bookworm). There doesn't seem to be a patch that changes the default. Maybe 
they ship a global configuration file, but I couldn't find anything in the gpg-
agent package. Maybe I'm looking in the wrong places. I know near nothing 
about Debian packaging.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250411/8713f45f/attachment-0001.sig>

From stuartl at longlandclan.id.au  Fri Apr 11 12:37:19 2025
From: stuartl at longlandclan.id.au (Stuart Longland)
Date: Fri, 11 Apr 2025 20:37:19 +1000
Subject: pinentry-qt and on-screen keyboards [resolved]
In-Reply-To: <2300396.vFx2qVVIhK@daneel>
References: <fbbf9268-e79e-483b-b00a-46afd8404564@longlandclan.id.au>
 <701a0ace-a18d-4c08-8a9b-2f0294f78e72@longlandclan.id.au>
 <77af95c0-b048-44e1-94ac-2e8fc990ca17@longlandclan.id.au>
 <2300396.vFx2qVVIhK@daneel>
Message-ID: <f0a397c2-8975-4887-bc21-8c216e722677@longlandclan.id.au>

On 11/4/25 17:40, Ingo Kl?cker wrote:
> I had a look at the patches Debian applies to gnupg for current stable
> (bookworm). There doesn't seem to be a patch that changes the default. Maybe
> they ship a global configuration file, but I couldn't find anything in the gpg-
> agent package. Maybe I'm looking in the wrong places. I know near nothing
> about Debian packaging.

Indeed, I'm not sure where to look either.

These are the offending packages:

> root at vk4msl-tp:~# dpkg -l gnupg*
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name           Version      Architecture Description
> +++-==============-============-============-=======================================================================
> ii  gnupg          2.2.40-1.1   all          GNU privacy guard - a free PGP replacement
> un  gnupg-agent    <none>       <none>       (no description available)
> ii  gnupg-l10n     2.2.40-1.1   all          GNU privacy guard - localization files
> ii  gnupg-utils    2.2.40-1.1   amd64        GNU privacy guard - utility programs
> un  gnupg1         <none>       <none>       (no description available)
> ii  gnupg2         2.2.40-1.1   all          GNU privacy guard - a free PGP replacement (dummy transitional package)
> root at vk4msl-tp:~# dpkg -l gpg*
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name           Version      Architecture Description
> +++-==============-============-============-=====================================================
> ii  gpg            2.2.40-1.1   amd64        GNU Privacy Guard -- minimalist public key operations
> ii  gpg-agent      2.2.40-1.1   amd64        GNU privacy guard - cryptographic agent
> ii  gpg-wks-client 2.2.40-1.1   amd64        GNU privacy guard - Web Key Service client
> ii  gpg-wks-server 2.2.40-1.1   amd64        GNU privacy guard - Web Key Service server
> ii  gpgconf        2.2.40-1.1   amd64        GNU privacy guard - core configuration utilities
> ii  gpgsm          2.2.40-1.1   amd64        GNU privacy guard - S/MIME version
> ii  gpgv           2.2.40-1.1   amd64        GNU privacy guard - signature verification tool
> un  gpgv1          <none>       <none>       (no description available)
> un  gpgv2          <none>       <none>       (no description available)
> root at vk4msl-tp:~# dpkg -l pinentry*
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name            Version      Architecture Description
> +++-===============-============-============-======================================================
> un  pinentry        <none>       <none>       (no description available)
> ii  pinentry-curses 1.2.1-1      amd64        curses-based PIN or pass-phrase entry dialog for GnuPG
> un  pinentry-doc    <none>       <none>       (no description available)
> ii  pinentry-fltk   1.2.1-1      amd64        FLTK-based PIN or pass-phrase entry dialog for GnuPG
> ii  pinentry-gnome3 1.2.1-1      amd64        GNOME 3 PIN or pass-phrase entry dialog for GnuPG
> ii  pinentry-qt     1.2.1-1      amd64        Qt-based PIN or pass-phrase entry dialog for GnuPG
> un  pinentry-x11    <none>       <none>       (no description available)

I had a sticky-beak at the `gpg-agent` package, but like you found 
nothing incriminating.

The `.gnupg/` directory was copied across wholesale (`rsync` over SSH) 
from a machine running Gentoo.  That said, none of the machines I have 
running Gentoo use a touchscreen.  (I nearly did put Gentoo on this 
tablet actually? but 128GB SSD does not leave much space, hence I 
thought Debian was better here.)

A search revealed that there were rumblings that Debian were going to 
revert the patch, but no indication that those rumblings got acted upon:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884517
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
   ...it's backed up on a tape somewhere.


From jb-gnumlists at wisemo.com  Fri Apr 11 15:54:09 2025
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Fri, 11 Apr 2025 15:54:09 +0200
Subject: pinentry-qt and on-screen keyboards
In-Reply-To: <3627711.dWV9SEqChM@daneel>
References: <fbbf9268-e79e-483b-b00a-46afd8404564@longlandclan.id.au>
 <846f236f-3794-4710-bd56-22de3952cb4e@wisemo.com> <3627711.dWV9SEqChM@daneel>
Message-ID: <d24c94e3-9d2f-4e53-9aa0-9da6442fb143@wisemo.com>

On 4/10/2025 20:50:44, Ingo Kl?cker wrote:
> On Donnerstag, 10. April 2025 14:09:56 Mitteleurop?ische Sommerzeit Jakob Bohm
> via Gnupg-users wrote:
>> I have not had opportunity to test our tools with pinentry-qt yet, but
>> thanks for the heads up about this misfeature.
> Dear Mr. Bohm,
>
> I'd appreciate if you checked the facts the next time before you make such
> unfounded accusations.
Later messages in this thread state that this bug is apparently limited to
certain OS distributions, so testing of compatibility needs to be done on
those dists rather than gnupg upstream.

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 ametzler at bebt.de  Sat Apr 12 07:36:18 2025
From: ametzler at bebt.de (Andreas Metzler)
Date: Sat, 12 Apr 2025 07:36:18 +0200
Subject: pinentry-qt and on-screen keyboards
In-Reply-To: <2308430.vFx2qVVIhK@daneel>
References: <fbbf9268-e79e-483b-b00a-46afd8404564@longlandclan.id.au>
 <2308430.vFx2qVVIhK@daneel>
Message-ID: <Z_n70jgGcGLb6EMq@argenau.bebt.de>

On 2025-04-10 Ingo Kl?cker <kloecker at kde.org> wrote:
[...]
> Hmm, the default should be "no-grab" according to the man page. According to 
> the history "no-grab" is default since gnupg 2.1.23 (released almost 8 years 
> ago). Maybe Debian decided that "grab" is better for you.
[...]

Hello Ingo,

that default somehow does not seem to be set as it should be.

I have just rebuilt 2.5.5 with:
./configure --enable-maintainer-mode  --prefix=/tmp/GNUPG/usr --sysconfdir=/tmp/GNUPG/etc --localstatedir=/tmp/GNUPG/var  --runstatedir=/tmp/GNUPG/run  --disable-gpgtar --disable-bzip2 && make -j5 && make install

testit at argenau:~$ /tmp/GNUPG/usr/bin/gpgconf  --list-options gpg-agent | grep grab
grab:8:2:let PIN-Entry grab keyboard and mouse:0:0::::

The respective test user has no ~/.gnupg/ and /tmp/GNUPG/etc does not
even exist.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From kloecker at kde.org  Sun Apr 13 00:15:44 2025
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Sun, 13 Apr 2025 00:15:44 +0200
Subject: pinentry-qt and on-screen keyboards
In-Reply-To: <Z_n70jgGcGLb6EMq@argenau.bebt.de>
References: <fbbf9268-e79e-483b-b00a-46afd8404564@longlandclan.id.au>
 <2308430.vFx2qVVIhK@daneel> <Z_n70jgGcGLb6EMq@argenau.bebt.de>
Message-ID: <3619950.dWV9SEqChM@daneel>

On Samstag, 12. April 2025 07:36:18 Mitteleurop?ische Sommerzeit Andreas 
Metzler wrote:
> On 2025-04-10 Ingo Kl?cker <kloecker at kde.org> wrote:
> > Hmm, the default should be "no-grab" according to the man page. According
> > to the history "no-grab" is default since gnupg 2.1.23 (released almost 8
> > years ago). Maybe Debian decided that "grab" is better for you.
> 
> that default somehow does not seem to be set as it should be.
> 
> I have just rebuilt 2.5.5 with:
> ./configure --enable-maintainer-mode  --prefix=/tmp/GNUPG/usr
> --sysconfdir=/tmp/GNUPG/etc --localstatedir=/tmp/GNUPG/var 
> --runstatedir=/tmp/GNUPG/run  --disable-gpgtar --disable-bzip2 && make -j5
> && make install
> 
> testit at argenau:~$ /tmp/GNUPG/usr/bin/gpgconf  --list-options gpg-agent |
> grep grab
> grab:8:2:let PIN-Entry grab keyboard and mouse:0:0::::

Looks correct to me. The format is
name:flags:level:description:type:alt-type:argname:default:argdef:value

Type 0 (= none) indicates that this is an option that's either set or not set. 
A default is not defined, but if an option is not set explicitly then it's 
considered unset. And the value is empty which means that the option is not 
set explicitly.

> The respective test user has no ~/.gnupg/ and /tmp/GNUPG/etc does not
> even exist.

What do you get when you run the same gpgconf command for the gnupg provided 
by Debian for your user account with and without the no-grab option in your 
gpg-agent.conf?

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250413/f63a0fd3/attachment.sig>

From ametzler at bebt.de  Sun Apr 13 07:30:55 2025
From: ametzler at bebt.de (Andreas Metzler)
Date: Sun, 13 Apr 2025 07:30:55 +0200
Subject: pinentry-qt and on-screen keyboards
Message-ID: <Z_tKva9I0LwiEryD@argenau.bebt.de>

On 2025-04-13 Ingo Kl?cker <kloecker at kde.org> wrote:
> On Samstag, 12. April 2025 07:36:18 Mitteleurop?ische Sommerzeit Andreas 
> Metzler wrote:
[...]
>> testit at argenau:~$ /tmp/GNUPG/usr/bin/gpgconf  --list-options gpg-agent |
>> grep grab
>> grab:8:2:let PIN-Entry grab keyboard and mouse:0:0::::

> Looks correct to me. The format is
> name:flags:level:description:type:alt-type:argname:default:argdef:value

> Type 0 (= none) indicates that this is an option that's either set or not set. 
> A default is not defined, but if an option is not set explicitly then it's 
> considered unset. And the value is empty which means that the option is not 
> set explicitly.

Ah, I had expected to see no-grab there.

>> The respective test user has no ~/.gnupg/ and /tmp/GNUPG/etc does not
>> even exist.

> What do you get when you run the same gpgconf command for the gnupg provided 
> by Debian for your user account with and without the no-grab option in your 
> gpg-agent.conf?

testit at argenau:~$ rm -f  ~/.gnupg/gpg-agent.conf ; gpgconf  --list-options gpg-agent | grep grab
grab:8:2:let PIN-Entry grab keyboard and mouse:0:0::::
testit at argenau:~$ echo grab >  ~/.gnupg/gpg-agent.conf ; gpgconf  --list-options gpg-agent | grep grab
grab:8:2:let PIN-Entry grab keyboard and mouse:0:0::::1
testit at argenau:~$ echo no-grab >  ~/.gnupg/gpg-agent.conf ; gpgconf  --list-options gpg-agent | grep grab
grab:8:2:let PIN-Entry grab keyboard and mouse:0:0::::

I get the same outcome on both Debian/stable (2.2.x) and unstable (2.4.x).

And indeed I get the expected grab/no-grab behavior (on Debian/testing
with 2.4 from unstable). This is with pinentry-gtk2. With
pinentry-gnome3 grab/no-grab is ignored and always enforced, but that is
known completely different issue https://dev.gnupg.org/T4587 ,
pinentry-qt also seems to ignore grab/no-grab but never grabs for me.
Perhaps that would be different when using KDE.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From u.kleine-koenig at baylibre.com  Tue Apr 15 16:17:44 2025
From: u.kleine-koenig at baylibre.com (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Tue, 15 Apr 2025 16:17:44 +0200
Subject: list option show-unusable-uids has no effect on show-only-fpr-mbox
 output
Message-ID: <wsd5oib6g65uel3dbxk3uf4bekn25rntr3kspykdncti6eldeb@txrziqlh32vq>

Hello,

my original intention was to create a bug report on
https://dev.gnupg.org/, but I don't have an account there and to get one
I have to post on a mailing list. To have some interesting content in
the mail, here comes my bugreport. Maybe it can even be resolved here.
If I should take this to the bug tracker, please help me create an
account there:

	handle: ukleinek
	name: Uwe Kleine-K?nig
	email: u.kleine-koenig at baylibre.com

Recently a UID of a key in the WKD I maintain was revoked. While trying
to add the key with the revoked UID to the WKD I noticed this
inconsistency (which made it unnecessarily hard to add the key to the
WKD):

	test at taurus:~$ rm -rf .gnupg
	test at taurus:~$ gpg --locate-external-keys u.kleine-koenig at baylibre.com mkorpershoek at baylibre.com
	gpg: directory '/home/test/.gnupg' created
	gpg: keybox '/home/test/.gnupg/pubring.kbx' created
	gpg: /home/test/.gnupg/trustdb.gpg: trustdb created
	gpg: key 570338B018144F28: public key "Mattijs Korpershoek <mkorpershoek at baylibre.com>" imported
	gpg: Total number processed: 1
	gpg:               imported: 1
	gpg: key E2DCDD9132669BD6: public key "Uwe Kleine-K?nig <u.kleine-koenig at baylibre.com>" imported
	gpg: Total number processed: 1
	gpg:               imported: 1
	gpg: no ultimately trusted keys found
	pub   rsa4096 2022-09-23 [SCEA]
	      8234A35B45C0D26B31C1A2DA570338B018144F28
	sub   rsa2048 2025-03-20 [S] [expires: 2027-03-20]
	sub   rsa2048 2025-03-20 [E] [expires: 2027-03-20]

	pub   rsa4096 2010-06-15 [SC] [expires: 2027-06-21]
	      0D2511F322BFAB1C1580266BE2DCDD9132669BD6
	uid           [ unknown] Uwe Kleine-K?nig <u.kleine-koenig at baylibre.com>
	sub   rsa2048 2023-03-17 [A] [expires: 2027-06-21]
	sub   rsa2048 2023-03-17 [S] [expires: 2027-06-21]
	sub   rsa2048 2023-03-17 [E] [expires: 2027-06-21]

The key 8234A35B45C0D26B31C1A2DA570338B018144F28 is the one with the
revoked UID, the other is my key that is included here to show how a
non-revoked key behaves.

	test at taurus:~$ gpg --list-keys
	/home/test/.gnupg/pubring.kbx
	-----------------------------
	pub   rsa4096 2022-09-23 [SCEA]
	      8234A35B45C0D26B31C1A2DA570338B018144F28
	sub   rsa2048 2025-03-20 [S] [expires: 2027-03-20]
	sub   rsa2048 2025-03-20 [E] [expires: 2027-03-20]

	pub   rsa4096 2010-06-15 [SC] [expires: 2027-06-21]
	      0D2511F322BFAB1C1580266BE2DCDD9132669BD6
	uid           [ unknown] Uwe Kleine-K?nig <u.kleine-koenig at baylibre.com>
	sub   rsa2048 2023-03-17 [A] [expires: 2027-06-21]
	sub   rsa2048 2023-03-17 [S] [expires: 2027-06-21]
	sub   rsa2048 2023-03-17 [E] [expires: 2027-06-21]

So Mattijs' UID isn't listed as it's revoked. If I want to see it I can
do:

	test at taurus:~$ gpg --list-options show-unusable-uids --list-keys
	/home/test/.gnupg/pubring.kbx
	-----------------------------
	pub   rsa4096 2022-09-23 [SCEA]
	      8234A35B45C0D26B31C1A2DA570338B018144F28
	uid           [ revoked] Mattijs Korpershoek <mkorpershoek at baylibre.com>
	sub   rsa2048 2025-03-20 [S] [expires: 2027-03-20]
	sub   rsa2048 2025-03-20 [E] [expires: 2027-03-20]

	pub   rsa4096 2010-06-15 [SC] [expires: 2027-06-21]
	      0D2511F322BFAB1C1580266BE2DCDD9132669BD6
	uid           [ unknown] Uwe Kleine-K?nig <u.kleine-koenig at baylibre.com>
	sub   rsa2048 2023-03-17 [A] [expires: 2027-06-21]
	sub   rsa2048 2023-03-17 [S] [expires: 2027-06-21]
	sub   rsa2048 2023-03-17 [E] [expires: 2027-06-21]

To generate the WKD content, I'm using

	test at taurus:~$ gpg --list-options show-only-fpr-mbox,show-unusable-uids --list-keys
	0D2511F322BFAB1C1580266BE2DCDD9132669BD6 u.kleine-koenig at baylibre.com

(and pipe that into `gpg-wks-client -C $docroot --install-key`).

Here the list-option `show-unusable-uids` doesn't have the desired
effect and no line is generated for Mattijs's key and email address.
With `show-unusable-uids` in the list-options I would have expected that
had this effect on the fpr-mbox listing in the same way as on the
default format.

I'm using gpg as provided in Debian unstable (version: 2.4.7-14):

	$ gpg --version
	gpg (GnuPG) 2.4.7
	libgcrypt 1.11.0
	Copyright (C) 2024 g10 Code GmbH
	License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
	This is free software: you are free to change and redistribute it.
	There is NO WARRANTY, to the extent permitted by law.

	Home: /home/test/.gnupg
	Supported algorithms:
	Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
	Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
		CAMELLIA128, CAMELLIA192, CAMELLIA256
	Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
	Compression: Uncompressed, ZIP, ZLIB, BZIP2

Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250415/253fb103/attachment-0001.sig>

From accounts-gnupg at holbrook.no  Wed Apr 16 01:09:47 2025
From: accounts-gnupg at holbrook.no (Louis Holbrook)
Date: Wed, 16 Apr 2025 00:09:47 +0100
Subject: schnorr /secp256k1
Message-ID: <Z_7nO3RTjQ7_PUXH@holbrook.no>

Hello,

Is it possible to use gnupg / libgcrypt to calculate the schnorr
signatures used by Nostr?

https://github.com/nostr-protocol/nips/blob/master/01.md#events-and-signatures

If not; what would it take?

Thanks,
Louis


From bernhard at intevation.de  Thu Apr 17 10:04:48 2025
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 17 Apr 2025 10:04:48 +0200
Subject: list option show-unusable-uids has no effect on
 show-only-fpr-mbox output
In-Reply-To: <wsd5oib6g65uel3dbxk3uf4bekn25rntr3kspykdncti6eldeb@txrziqlh32vq>
References: <wsd5oib6g65uel3dbxk3uf4bekn25rntr3kspykdncti6eldeb@txrziqlh32vq>
Message-ID: <202504171004.54827.bernhard@intevation.de>

Hello Uwe,

using gnupg 2.2.40-1.1 on Debian GNU/Linux
I can confirm the behaviour you are seeing.

rm -r ~/tmp/dot.gnupg/
GNUPGHOME=~/tmp/dot.gnupg/ bash
gpg --locate-external-keys \
 mkorpershoek at baylibre.com u.kleine-koenig at baylibre.com

gpg --list-options show-unusable-uids--list-keys
gpg --list-options \
 show-unusable-uids,show-only-fpr-mbox --list-keys

interesting enough adding --with-colons does show both pubkeys.

Am Dienstag 15 April 2025 16:17:44 schrieb Uwe Kleine-K?nig:
> To generate the WKD content, I'm using
>
> 	test at taurus:~$ gpg --list-options show-only-fpr-mbox,show-unusable-uids
> --list-keys 0D2511F322BFAB1C1580266BE2DCDD9132669BD6
> u.kleine-koenig at baylibre.com
>
> (and pipe that into `gpg-wks-client -C $docroot --install-key`).

Because you are using it in a script, --with-colons is usually recommended to 
keep the interface more stable. That does not easily output the email 
address.

> Here the list-option `show-unusable-uids` doesn't have the desired
> effect and no line is generated for Mattijs's key and email address.

I wonder if this is a defect at all as the documentation says:
   
https://gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.html#index-list_002doptions_003ashow_002donly_002dfpr_002dmbox

| For each user-id which has a valid mail address print
| only the fingerprint followed by the mail address.  

As the user-id is revoked, 
it somehow is not a _valid_ email address, isn't it?

> With `show-unusable-uids` in the list-options I would have expected that
> had this effect on the fpr-mbox listing in the same way as on the
> default format.

I also wonder:
What sense would it make to put a pubkey for an invalid uid on the WKD?

However either the documentation or the behaviour could be improved somehow I 
guess. 

> I'm using gpg as provided in Debian unstable (version: 2.4.7-14).

Thanks for taking the time to writeup your report!
This how GnuPG gets better!

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250417/d1bcdfa7/attachment.sig>

From me at shniubobo.com  Fri Apr 18 06:39:32 2025
From: me at shniubobo.com (shniubobo)
Date: Fri, 18 Apr 2025 05:39:32 +0100
Subject: `--list-filter select='disabled-f'` does not seem to work
Message-ID: <2b32199c-2325-45da-bbe9-4ee832a4d645@shniubobo.com>

Hello,

I am trying to filter out disabled keys (disabled via `gpg 
--quick-set-ownertrust [...] disable`), using:

     gpg -K --list-filter select='disabled-f'

However, all keys are still shown, including disabled ones. Is this 
expected behavior? If yes, are there any other options that I can use to 
filter out disabled keys?

FYI, I have also tried the opposite (`select='disabled-t'`), which works 
as expected and only shows disabled keys.

Thanks in advance,
shniubobo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250418/1b15e98e/attachment.sig>

From pyromania at disroot.org  Sun Apr 20 02:06:54 2025
From: pyromania at disroot.org (Pyromania)
Date: Sun, 20 Apr 2025 03:36:54 +0330
Subject: `--list-filter select='disabled-f'` does not seem to work
In-Reply-To: <2b32199c-2325-45da-bbe9-4ee832a4d645@shniubobo.com> (shniubobo
 via Gnupg-users's message of "Fri, 18 Apr 2025 05:39:32 +0100")
References: <2b32199c-2325-45da-bbe9-4ee832a4d645@shniubobo.com>
Message-ID: <yphw1ptnitlt.fsf@disroot.org>

On Fri, Apr 18 2025, shniubobo via Gnupg-users <gnupg-users at gnupg.org> wrote:

> However, all keys are still shown, including disabled ones. Is this
> expected behavior? If yes, are there any other options that I can use
> to filter out disabled keys?

> Fyi, I have also tried the opposite (`select='disabled-t'`), which
> works as expected and only shows disabled keys.

I think you have to report it as a bug.  I disabled one of my keys and
could reproduce your issue.

-- 
English is not my native/mother language.  While I can read and
understand English fluently, I have problems expressing my thoughts
in it.  Please, bear with me.  Sincerely, Pyromania.

PGP fingerprint = 2B24 291E 0637 4D2E 0D14  9EFC D7B3 10D4 5C9D 5892
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1304 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250420/d0a35331/attachment.sig>

From 4slam at mythicflow.com  Sun Apr 20 02:53:59 2025
From: 4slam at mythicflow.com (aslamK)
Date: Sun, 20 Apr 2025 00:53:59 +0000
Subject: `gpg --verify` does not report whether verification succeeded or
 failed.
Message-ID: <d767d104-6646-498f-b54e-7f5add74b047@mythicflow.com>

This is what happened when I try to verify a signature (the same message 
appears when I do `gpg --dearmor`):

```
$ gpg --verify syncthingtray-1.7.6-x86_64-pc-linux-gnu.tar.xz.sig
can't connect to 'socket:///home/user/.gnupg/log-socket': Connection refused
```

There is no other output. I am able to see the log using KWatchGnuPG 
(via Kleopatra). With the log thus open, the `gpg --verify` command does 
not report the error but it also does not any other output.

I do have the public key used for the signature and it has not expired.

Here's what the command shows with the verbose option, while the log is 
open in KWatchGnuPG. It doesn't report whether the verification succeeded.

```
$ gpg -vv --verify syncthingtray-1.7.6-x86_64-pc-linux-gnu.tar.xz.sig 
syncthingtray-1.7.6-x86_64-pc-linux-gnu.tar.xz
# off=0 ctb=89 tag=2 hlen=3 plen=307
:signature packet: algo 1, keyid E06FE8F53CDC6A4C
         version 4, created 1745078192, md5len 0, sigclass 0x00
         digest algo 8, begin of digest 4c 82
         hashed subpkt 33 len 21 (issuer fpr v4 
B9E36A7275FC61B464B67907E06FE8F53CDC6A4C)
         hashed subpkt 2 len 4 (sig created 2025-04-19)
         subpkt 16 len 8 (issuer key ID E06FE8F53CDC6A4C)
         data: [2047 bits]
```

Shouldn't the result of `gpg --verify` be an explicit affirmative or 
negative?

-- 
aslamK




From 4slam at mythicflow.com  Sun Apr 20 08:51:44 2025
From: 4slam at mythicflow.com (aslamK)
Date: Sun, 20 Apr 2025 06:51:44 +0000
Subject: "Can't connect to 'log-socket': Connection refused
In-Reply-To: <CAJj0OuujbnkhdSd8c_Qe-5j8WQ1pwHv9EwLw+MG123r1py7WTQ@mail.gmail.com>
References: <d767d104-6646-498f-b54e-7f5add74b047@mythicflow.com>
 <CAJj0OuujbnkhdSd8c_Qe-5j8WQ1pwHv9EwLw+MG123r1py7WTQ@mail.gmail.com>
Message-ID: <20312a64-e118-4e98-8d86-0e24ef00e1fc@mythicflow.com>

Thanks. Yes, the exit status is 0, so the verification succeeds.

I used to see output like the following, and I found that it goes to the log when I run KWatchGnuPG.
===
$ gpg --verify pdfsam_5.1.2-1_amd64.deb.asc pdfsam_5.1.2-1_amd64.deb=
gpg: enabled debug flags: memstat
gpg: Signature made Wed 26 Apr 2023 05:58:12 AM EDT
gpg:
 using RSA key 9F2499EF7ABB9050D7401BCAA3FC4B4C79E8FD49
gpg: Good signature from "Sober Lemur S.r.l.
[<info at pdfsam.org>](mailto:info at pdfsam.org)
" [unknown]
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: 9F24 99EF 7ABB 9050 D740 1BCA A3FC 4B4C 79E8 FD49
gpg: keydb: handles=3 locks=0 parse=3 get=3
gpg:
 build=0 update=0 insert=0 delete=0
gpg:
 reset=0 found=3 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=6 cached=6 good=6 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0
gpg: secmem usage: 0/65536 bytes in 0 blocks
===

The issue is therefore not with `gnu --verify`, but with the connection
to `log-socket`:
===
can't connect to '
socket:///home/user/.gnupg/log-socket
': Connection refused
===

My config hasn't changed but I did upgrade my OS
(Ubuntu 20.04.2). How can I get commands to output to the console?

---
aslamK

On 4/19/25 23:15, C.J. Collier wrote:

> I like to do something like:
>
> set -e
> gpg --verify
>
> Or
>
> gpg --verify || {
> echo "onoes ever buddy panik!!!"
> exit 1
> }
>
> Or
>
> gpg --verify && echo "Verified!"
>
> Or
>
> gpg --verify
> if [[ $? == 0 ]] ; then
> echo "yay!"
> else
> echo "nay!"
> fi
>
> On Sat, Apr 19, 2025, 19:16 aslamK <4slam at mythicflow.com> wrote:
>
>> This is what happened when I try to verify a signature (the same message
>> appears when I do `gpg --dearmor`):
>>
>> ```
>> $ gpg --verify syncthingtray-1.7.6-x86_64-pc-linux-gnu.tar.xz.sig
>> can't connect to 'socket:///home/user/.gnupg/log-socket': Connection refused
>> ```
>>
>> There is no other output. I am able to see the log using KWatchGnuPG
>> (via Kleopatra). With the log thus open, the `gpg --verify` command does
>> not report the error but it also does not any other output.
>>
>> I do have the public key used for the signature and it has not expired.
>>
>> Here's what the command shows with the verbose option, while the log is
>> open in KWatchGnuPG. It doesn't report whether the verification succeeded.
>>
>> ```
>> $ gpg -vv --verify syncthingtray-1.7.6-x86_64-pc-linux-gnu.tar.xz.sig
>> syncthingtray-1.7.6-x86_64-pc-linux-gnu.tar.xz
>> # off=0 ctb=89 tag=2 hlen=3 plen=307
>> :signature packet: algo 1, keyid E06FE8F53CDC6A4C
>> version 4, created 1745078192, md5len 0, sigclass 0x00
>> digest algo 8, begin of digest 4c 82
>> hashed subpkt 33 len 21 (issuer fpr v4
>> B9E36A7275FC61B464B67907E06FE8F53CDC6A4C)
>> hashed subpkt 2 len 4 (sig created 2025-04-19)
>> subpkt 16 len 8 (issuer key ID E06FE8F53CDC6A4C)
>> data: [2047 bits]
>> ```
>>
>> Shouldn't the result of `gpg --verify` be an explicit affirmative or
>> negative?
>>
>> --
>> aslamK
>>
>> _______________________________________________
>> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250420/e7c9ad41/attachment-0001.html>

From me at shniubobo.com  Mon Apr 21 06:18:41 2025
From: me at shniubobo.com (shniubobo)
Date: Mon, 21 Apr 2025 05:18:41 +0100
Subject: `--list-filter select='disabled-f'` does not seem to work
In-Reply-To: <yphw1ptnitlt.fsf@disroot.org>
References: <2b32199c-2325-45da-bbe9-4ee832a4d645@shniubobo.com>
 <yphw1ptnitlt.fsf@disroot.org>
Message-ID: <b77904b1-2b93-4b17-9993-4cb41c87967c@shniubobo.com>

On 2025/4/20 1:06, Pyromania wrote:
> On Fri, Apr 18 2025, shniubobo via Gnupg-users <gnupg-users at gnupg.org> wrote:
> 
>> However, all keys are still shown, including disabled ones. Is this
>> expected behavior? If yes, are there any other options that I can use
>> to filter out disabled keys?
> 
>> Fyi, I have also tried the opposite (`select='disabled-t'`), which
>> works as expected and only shows disabled keys.
> 
> I think you have to report it as a bug.  I disabled one of my keys and
> could reproduce your issue.
> 

Thank you for testing this!

Since I don't have an account on the bug tracker, I think I have to wait 
for a developer to report it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250421/484a1adb/attachment.sig>