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'