From jw at raven.inka.de  Sun Feb  2 09:22:37 2025
From: jw at raven.inka.de (Josef Wolf)
Date: Sun, 2 Feb 2025 09:22:37 +0100
Subject: Please help verify signature within Dockerfile
In-Reply-To: <20250130231518.GX30202@raven.inka.de>
References: <20250130231518.GX30202@raven.inka.de>
Message-ID: <20250202082237.GZ30202@raven.inka.de>

Although I got a solution for the initial problem to use gpgv, I am still
curious why all the other methods fail.

Any ideas?

On Fri, Jan 31, 2025 at 12:15:18AM +0100, Josef Wolf wrote:
> Hello all,
> 
> I am trying to verify signature of downloaded files when creating a docker
> container. This is what I am trying to do within the Dockerfile:
> 
>    RUN gpg -v --status-fd 1 --no-keyring \
>       --trust-model always \
>       --recipient-file /pubkes/release-key.txt \
>       --verify sigfile.asc foo.tar.gz
> 
> This errors with "gpg: Can't check signature: No public key". Using strace, I
> can see that gpg won't even try to open /pubkeys/release-key.txt
> 
> I also tried to de-armor the pubkey file and pass it as
> 
>    RUN gpg --yes -o release-key.gpg --dearmor release-key.txt
>    RUN gpg -v --status-fd 1 --no-keyring \
>       --trust-model always \
>       --no-keyring --keyring /pubkes/release-key.gpg \
>       --verify sigfile.asc foo.tar.gz
> 
> with exactly the same result: gpg won't even try to open the keyfile.
> 
> I also tried to import the pubkey and verify using the default keyring:
> 
>    RUN gpg --import ql/release-key.txt
>    RUN gpg --verify --trust-model always ql/quicklisp.lisp.asc ql/quicklisp.lisp
> 
> but this one tries to start and connect to gpg-agent, which fails:
> 
>    [1/2] STEP 17/21: RUN gpg --verify --trust-model always ql/quicklisp.lisp.asc ql/quicklisp.lisp
>    gpg: Signature made Wed Jan 28 21:13:26 2015 UTC
>    gpg:                using RSA key 307965AB028B5FF7
>    gpg: Note: database_open 134217901 waiting for lock (held by 3) ...
>    gpg: Note: database_open 134217901 waiting for lock (held by 3) ...
>    gpg: Note: database_open 134217901 waiting for lock (held by 3) ...
>    gpg: Note: database_open 134217901 waiting for lock (held by 3) ...
>    gpg: Note: database_open 134217901 waiting for lock (held by 3) ...
>    gpg: keydb_search failed: Operation timed out
>    gpg: Can't check signature: No public key
>    Error: building at STEP "RUN gpg --verify --trust-model always ql/quicklisp.lisp.asc ql/quicklisp.lisp": while running runtime: exit status 2
> 
> BTW: I create an empty ~/.gnupg directory before the very first gpg invocation
> to prevent use-keyboxd option to be set.
> 
> Does it really need to be that hard to verify signature with a given pubkey?
> 
> Any help?
> 
> -- 
> Josef Wolf
> jw at raven.inka.de
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users

-- 
Josef Wolf
jw at raven.inka.de


From ametzler at bebt.de  Sun Feb  2 12:02:19 2025
From: ametzler at bebt.de (Andreas Metzler)
Date: Sun, 2 Feb 2025 12:02:19 +0100
Subject: Please help verify signature within Dockerfile
In-Reply-To: <20250202082237.GZ30202@raven.inka.de>
References: <20250130231518.GX30202@raven.inka.de>
 <20250202082237.GZ30202@raven.inka.de>
Message-ID: <Z59Qu0Jr1fwZAYSS@argenau.bebt.de>

On 2025-02-02 Josef Wolf <jw at raven.inka.de> wrote:
> Although I got a solution for the initial problem to use gpgv, I am still
> curious why all the other methods fail.

> Any ideas?

See below:

> On Fri, Jan 31, 2025 at 12:15:18AM +0100, Josef Wolf wrote:
> > Hello all,
> > 
> > I am trying to verify signature of downloaded files when creating a docker
> > container. This is what I am trying to do within the Dockerfile:
> > 
> >    RUN gpg -v --status-fd 1 --no-keyring \
> >       --trust-model always \
> >       --recipient-file /pubkes/release-key.txt \
> >       --verify sigfile.asc foo.tar.gz
> > 
> > This errors with "gpg: Can't check signature: No public key". Using strace, I
> > can see that gpg won't even try to open /pubkeys/release-key.txt

Looking at te manpage we find:
       --recipient-file file
       -f     This option is similar to --recipient except that it encrypts
              to a  key stored in the given file.  file must be the name
              of a file containing exactly one key.  gpg assumes that
              the  key  in  this file is fully valid.

So this has clearly nothing to do with specifying a keyring to check
against.

> > I also tried to de-armor the pubkey file and pass it as
> > 
> >    RUN gpg --yes -o release-key.gpg --dearmor release-key.txt
> >    RUN gpg -v --status-fd 1 --no-keyring \
> >       --trust-model always \
> >       --no-keyring --keyring /pubkes/release-key.gpg \
> >       --verify sigfile.asc foo.tar.gz
> > 
> > with exactly the same result: gpg won't even try to open the keyfile.

       --no-keyring
              Do  not  use  any keyring at all.  This overrides the default and
              all options which specify keyrings.

So --no-keyring should take care of ignoring --keyring
/pubkes/release-key.gpg. :-(

> > I also tried to import the pubkey and verify using the default keyring:
> > 
> >    RUN gpg --import ql/release-key.txt
> >    RUN gpg --verify --trust-model always ql/quicklisp.lisp.asc ql/quicklisp.lisp

This should work.

[...] 
> > BTW: I create an empty ~/.gnupg directory before the very first gpg
> > invocation to prevent use-keyboxd option to be set.
 
> > Does it really need to be that hard to verify signature with a given
> > pubkey?

(I would use a temporary directory with --homedir).

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 wk at gnupg.org  Mon Feb  3 09:05:18 2025
From: wk at gnupg.org (Werner Koch)
Date: Mon, 03 Feb 2025 09:05:18 +0100
Subject: Please help verify signature within Dockerfile
In-Reply-To: <20250202082237.GZ30202@raven.inka.de> (Josef Wolf's message of
 "Sun, 2 Feb 2025 09:22:37 +0100")
References: <20250130231518.GX30202@raven.inka.de>
 <20250202082237.GZ30202@raven.inka.de>
Message-ID: <874j1bmp1d.fsf@jacob.g10code.de>

On Sun,  2 Feb 2025 09:22, Josef Wolf said:

>> Does it really need to be that hard to verify signature with a given pubkey?

That is for what gpgv was created for.  Use it.

Or use the newer gpg option

     --assert-signer fpr_or_file
     
     This option checks whether at least one valid signature on a file
     has been made with the specified key.  The key is either specified
     as a fingerprint or a file listing fingerprints.  The fingerprint
     must be given or listed in compact format (no colons or spaces in
     between).  This option can be given multiple times and each
     fingerprint is checked against the signing key as well as the
     corresponding primary key.  If fpr_or_file specifies a file, empty
     lines are ignored as well as all lines starting with a hash sign.
     With this option gpg is guaranteed to return with an exit code of 0
     if and only if a signature has been encountered, is valid, and the
     key matches one of the fingerprints given by this option.

But here you need to import the keys first.  But you need to
store them anyway and have a way to update them. 


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250203/018c073f/attachment.sig>

From wk at gnupg.org  Mon Feb  3 09:08:17 2025
From: wk at gnupg.org (Werner Koch)
Date: Mon, 03 Feb 2025 09:08:17 +0100
Subject: Error generating subkey in gpg's batch mode using curve
 brainpoolP512r1
In-Reply-To: <FF102985-92FE-4A9B-A301-01160CD12C83@erghfe.com>
 (sgh@erghfe.com's message of "Sat, 1 Feb 2025 01:01:54 +0800")
References: <FF102985-92FE-4A9B-A301-01160CD12C83@erghfe.com>
Message-ID: <87zfj3laby.fsf@jacob.g10code.de>

Hi!

Thanks for the report.  Andre meanwhile looked in more detail at the
bug; see https://dev.gnupg.org/T7506


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: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250203/b6202981/attachment.sig>

From gpg at samoverton.dev  Sat Feb  8 03:45:17 2025
From: gpg at samoverton.dev (Sam Overton)
Date: Sat, 8 Feb 2025 03:45:17 +0100
Subject: Maniphest account request
Message-ID: <700debd9-64d9-4dea-b9a2-9d0bfe0169c4@samoverton.dev>

Hello,

I would like to file an issue in Maniphest prior to proposing a patch to 
the gnupg-devel list. Could I please get an account on
https://dev.gnupg.org ?

Preferred username: samoverton
email: gpg (at) samoverton (dot) dev

If you would prefer me to detail the report in a mail directly to
gnupg-devel, I'm happy to do that instead.

Thanks,

Sam Overton



From wk at gnupg.org  Sat Feb  8 13:04:38 2025
From: wk at gnupg.org (Werner Koch)
Date: Sat, 08 Feb 2025 13:04:38 +0100
Subject: Maniphest account request
In-Reply-To: <700debd9-64d9-4dea-b9a2-9d0bfe0169c4@samoverton.dev> (Sam
 Overton via Gnupg-users's message of "Sat, 8 Feb 2025 03:45:17 +0100")
References: <700debd9-64d9-4dea-b9a2-9d0bfe0169c4@samoverton.dev>
Message-ID: <87v7tkfxrd.fsf@jacob.g10code.de>

Hi!

> to the gnupg-devel list. Could I please get an account on
> https://dev.gnupg.org ?

Sure. Confirmation mail is on the way.


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: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250208/9e8505c6/attachment.sig>

From jay.kayes at posteo.com  Sat Feb  8 17:51:29 2025
From: jay.kayes at posteo.com (jay.kayes at posteo.com)
Date: Sat, 08 Feb 2025 16:51:29 +0000
Subject: Pinentry with flatpak applications
Message-ID: <e176016dbe571b3c6f34c5bba0ade007@posteo.com>

Hi all,

I've been debugging using gpg in flatpak apps.  Particularly, I use 
Evolution as a flatpak for email.  The issue I am having is that gpg 
private key operations only work if the card pin or key passphrase is 
already in the agent cache.  Pinentry does not work when triggered by a 
gpg operation from a flatpak sandboxed app.  I can only decrypt email 
when I've done a gpg operation outside the sandbox to get the pin 
entered.

The following debugging/demonstration notes are with Kleopatra for ease 
of testing gpg operations, but I observe the same behavior and results 
with Evolution.  The following are notes as I verified the behavior in a 
fresh VM (Fedora 41 Workstation) environment.


System GPG version:
   gpg (GnuPG) 2.4.5
   libgcrypt 1.11.0-unknown

Flatpak sandbox GPG version:
   gpg (GnuPG) 2.5.1
   libgcrypt 1.11.0

Agent configuration:
   $ cat ~/.gnupg/gpg-agent.conf
   pinentry-program /usr/bin/pinentry-gnome3
   debug-level basic

With a freshly started agent process, I open Kleopatra and attempt to 
sign some text in the Notepad view.  This fails.

The error message in Kleopatra's diagnostics:
   gpg: WARNING: server 'gpg-agent' is older than us (2.4.5 < 2.5.1)
   gpg: Note: Outdated servers may lack important security fixes.
   gpg: Note: Use the command "gpgconf --kill all" to restart them.
   gpg: signing failed: pinentry error
   gpg: -&48: sign+encrypt failed: pinentry error

Looking at the output of gpg-agent, I see this line:
   DBG: chan_6 <- OPTION 
putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/flatpak/bus

I think this is the smoking gun.  If I understand correctly, Kleopatra 
is telling the agent where it thinks the DBUS socket is and the agent 
attempts to use this value when launching pinentry.  This of course 
fails, as there is no dbus socket at that location from gpg-agent's 
perspective.  This value is what Flatpak sets up when it starts the 
sandbox, from Kleopatra's perspective this the correct value.  For 
gpg-agent, the correct value is of course 
`DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus`.

I now do a GPG operation outside the sandbox so that the passphrase gets 
prompted and cached.  Once the passphrase is cached, I can switch back 
to Kleopatra, and the signing operation (or any other using the private 
key) succeeds.  If I restart the agent, Kleopatra will fail to 
sign/decrypt again until I get the passphrase cached.

Another interesting demonstration is to modify DBUS_SESSION_BUS_ADDRESS 
before starting Kleopatra from a shell inside the sandbox.

If I first open a shell in the sandbox and launch Kleopatra, I do not 
get a pinentry prompt and operation fails.  Same as above.
   $ flatpak run --command=bash org.kde.kleopatra
   [? org.kde.kleopatra ~]$ echo $DBUS_SESSION_BUS_ADDRESS
   unix:path=/run/flatpak/bus
   [? org.kde.kleopatra ~]$ kleopatra

If I modify DBUS_SESSION_BUS_ADDRESS in the sandbox shell before 
launching Kleopatra as per below, everything works as expected. I get a 
pinentry prompt and private key operations are successful.  
Interestingly `$XDG_RUNTIME_DIR/bus` is symlinked to `/run/flatpak/bus`, 
but flatpak must have it's reasons for using 
`DBUS_SESSION_BUS_ADDRESS=/run/flatpak/bus`.

   [? org.kde.kleopatra ~]$ export 
DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus
   [? org.kde.kleopatra ~]$ ls -l $XDG_RUNTIME_DIR/bus
   lrwxrwxrwx. 1 jay jay 17 Feb  8 15:14 /run/user/1000/bus -> 
../../flatpak/bus
   [? org.kde.kleopatra ~]$ kleopatra


In summary, steps to reproduce:
1. Restart agent or otherwise clear cache
2. Attempt to use private key in Flatpak app, pinentry fails
3. Use gnupg outside sandbox so that the pin gets entered and cached
3. Repeat in Flatpak app, using the private key now works


In the notes above with a clean environment, I only tested with 
Kleopatra.  Kleopatra gets access to the gpg socket by a filesystem 
permission - `$XDG_RUNTIME_DIR/gnupg` is mapped into the sandbox.  On my 
production environment, Evolution gets access using Flatpak's socket 
portal mechanism (`--socket=gpg-agent` permission).  This does not seem 
to be significant, the same behavior happens in both cases.  Both 
options are just making the socket available inside the sandbox.

I imagine there are relevant uses for the calling gpg process to 
communicate variables from it's environment to the agent process (e.g. 
PINENTRY_GEOM_HINT?).  But this also means that the calling gpg process 
can unintentionally cause the pinentry process to fail.  I haven't 
thought about this further, but could a malicious program compromise the 
agent somehow by setting some unexpected values?  I wonder if it would 
be useful to either blocklist some specific variables (e.g. 
DBUS_SESSION_BUS_ADDRESS) from being set through the socket.  Or better 
yet, perhaps the agent should only accept values for allowlisted 
variables?

BR Jay



From gpg at samoverton.dev  Sat Feb  8 20:50:50 2025
From: gpg at samoverton.dev (Sam Overton)
Date: Sat, 8 Feb 2025 20:50:50 +0100
Subject: Pinentry with flatpak applications
In-Reply-To: <e176016dbe571b3c6f34c5bba0ade007@posteo.com>
References: <e176016dbe571b3c6f34c5bba0ade007@posteo.com>
Message-ID: <d0aedf8a-07ed-46dc-956e-279a4042f13f@samoverton.dev>

On 08/02/2025 17:51, jay.kayes--- via Gnupg-users wrote:
> Hi all,
> 
> I've been debugging using gpg in flatpak apps.? Particularly, I use 
> Evolution as a flatpak for email.? The issue I am having is that gpg 
> private key operations only work if the card pin or key passphrase is 
> already in the agent cache.? Pinentry does not work when triggered by a 
> gpg operation from a flatpak sandboxed app.? I can only decrypt email 
> when I've done a gpg operation outside the sandbox to get the pin entered.
Hi Jay,

I was about to file the same issue in the bug tracker, except in my case 
the flatpak in question is Thunderbird, which exhibits the same behavior 
that you detailed. I also traced the issue to the same cause - that gpg 
running in the flatpak is sending its DBUS_SESSION_BUS_ADDRESS to the 
agent which then passes it to pinentry.

I have a proposed patch which I am preparing to send which adds a 
gpg-agent configuration parameter to specify which environment variables 
sent by the client should be *ignored* by the agent. This solves the 
problem in my case, by filtering out DBUS_SESSION_BUS_ADDRESS ensuring 
that the agent's environment is used by pinentry (for that specific 
env-var).

In the meantime, the workaround I have been using is to configure 
gpg-agent to use a custom pinentry command (~/.gnupg/gpg-agent.conf):

     pinentry-program /home/sam/bin/pinentry-wrap

which then sets the correct environment for pinentry (pinentry-wrap):

     #!/bin/bash
     PINENTRY="/usr/bin/pinentry-gnome3"
     export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1001/bus"
     ${PINENTRY} "$@"


 > I haven't thought about this further, but could a malicious program
 > compromise the agent somehow by setting some unexpected values?

AFAIK the agent only accepts a specific list of environment variables 
from the client which can be listed using:

     $ gpg-connect-agent 'getinfo std_env_names' /bye


Best Regards,

Sam




From jay.kayes at posteo.com  Sat Feb  8 22:29:21 2025
From: jay.kayes at posteo.com (jay.kayes at posteo.com)
Date: Sat, 08 Feb 2025 21:29:21 +0000
Subject: Pinentry with flatpak applications
In-Reply-To: <d0aedf8a-07ed-46dc-956e-279a4042f13f@samoverton.dev>
References: <e176016dbe571b3c6f34c5bba0ade007@posteo.com>
 <d0aedf8a-07ed-46dc-956e-279a4042f13f@samoverton.dev>
Message-ID: <6fd64186b9a36e7a77ddd17ae9d16188@posteo.com>

On 2025-02-08 20:50, Sam Overton via Gnupg-users wrote:
> I have a proposed patch which I am preparing to send which adds a
> gpg-agent configuration parameter to specify which environment
> variables sent by the client should be *ignored* by the agent. This
> solves the problem in my case, by filtering out
> DBUS_SESSION_BUS_ADDRESS ensuring that the agent's environment is used
> by pinentry (for that specific env-var).

Looking forward to it. Are you proposing to ignore by default, or give 
the possibility to ignore DBUS_SESSION_BUS_ADDRESS? With the popularity 
of Flatpak apps, ignoring DBUS_SESSION_BUS_ADDRESS by default feels like 
it would be better UX overall. On the other hand, there must be a 
usecase for passing through the dbus address to pinentry which I'm not 
seeing.

> In the meantime, the workaround I have been using is to configure
> gpg-agent to use a custom pinentry command (~/.gnupg/gpg-agent.conf):
> 
>     pinentry-program /home/sam/bin/pinentry-wrap
> 
> which then sets the correct environment for pinentry (pinentry-wrap):

Ingenious hack, obvious in hindsight! Cheers for the idea, I'll 
implement this while waiting for your patch to trickle through the 
supply chain ;)

> AFAIK the agent only accepts a specific list of environment variables
> from the client which can be listed using:
> 
>     $ gpg-connect-agent 'getinfo std_env_names' /bye

Ah the wonderful niche commands that are available... if one only knew.

BR Jay


From mcepl at cepl.eu  Sat Feb  8 21:45:52 2025
From: mcepl at cepl.eu (=?utf-8?q?Mat=C4=9Bj_Cepl?=)
Date: Sat, 08 Feb 2025 21:45:52 +0100
Subject: Pinentry with flatpak applications
In-Reply-To: <e176016dbe571b3c6f34c5bba0ade007@posteo.com>
References: <e176016dbe571b3c6f34c5bba0ade007@posteo.com>
Message-ID: <D7NCWOGQ5T3V.1SAH9Y7I44Q1S@cepl.eu>

On Sat Feb 8, 2025 at 7:10 PM CET, jay.kayes--- via Gnupg-users wrote:
> Pinentry does not work when triggered by a gpg operation from a
> flatpak sandboxed app.

Wait? Why do you need to run pinentry from flatpak app? Isn?t it
run on the host system?

Mat?j
-- 
http://matej.ceplovi.cz/blog/, @mcepl at en.osm.town
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Think of how stupid the average person is, and realize half of
them are stupider than that.
  -- George Carlin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: E09FEF25D96484AC.asc
Type: application/pgp-keys
Size: 3102 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250208/a5c1c41c/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 216 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250208/a5c1c41c/attachment.sig>

From gpg at samoverton.dev  Sun Feb  9 05:13:51 2025
From: gpg at samoverton.dev (Sam Overton)
Date: Sun, 9 Feb 2025 05:13:51 +0100
Subject: Pinentry with flatpak applications
In-Reply-To: <6fd64186b9a36e7a77ddd17ae9d16188@posteo.com>
References: <e176016dbe571b3c6f34c5bba0ade007@posteo.com>
 <d0aedf8a-07ed-46dc-956e-279a4042f13f@samoverton.dev>
 <6fd64186b9a36e7a77ddd17ae9d16188@posteo.com>
Message-ID: <86a24a26-63ab-4feb-bd27-348301eacd59@samoverton.dev>

On 08/02/2025 22:29, jay.kayes at posteo.com wrote:
> Looking forward to it. Are you proposing to ignore by default, or give 
> the possibility to ignore DBUS_SESSION_BUS_ADDRESS? With the popularity 
> of Flatpak apps, ignoring DBUS_SESSION_BUS_ADDRESS by default feels like 
> it would be better UX overall. On the other hand, there must be a 
> usecase for passing through the dbus address to pinentry which I'm not 
> seeing.

The task in the issue tracker is here if you wish to follow it:
https://dev.gnupg.org/T7522

The default in my patch is to maintain the current behavior, since 
otherwise this would break existing deployments which rely on it (eg. 
https://dev.gnupg.org/T3947 ).

Regards,


From dkg at fifthhorseman.net  Mon Feb 10 05:53:45 2025
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 09 Feb 2025 23:53:45 -0500
Subject: Pinentry with flatpak applications
In-Reply-To: <D7NCWOGQ5T3V.1SAH9Y7I44Q1S@cepl.eu>
References: <e176016dbe571b3c6f34c5bba0ade007@posteo.com>
 <D7NCWOGQ5T3V.1SAH9Y7I44Q1S@cepl.eu>
Message-ID: <87pljqjt7q.fsf@fifthhorseman.net>

On Sat 2025-02-08 21:45:52 +0100, Mat?j Cepl via Gnupg-users wrote:
> Wait? Why do you need to run pinentry from flatpak app? Isn?t it
> run on the host system?

I think that's the point.  pinentry is run from the host system, but the
invocation of gpg (which talks to gpg-agent, which in turn invokes
pinentry) happens within the flatpak environment.

Since gpg passes the environment as a string (well, several strings) to
gpg-agent, which uses that to set up the environment in which to invoke
pinentry, pinentry ends up with the flatpak environment.

I see the proposed patch at T7522, to make yet another configuration
variable which one of the hops along the chain would use to filter out
specific environment variables, leaving the user to figure it out for
themselves.  I'm pretty sure most desktop users have no idea what the
"right" DBus session address is in any given context (even less than
they knew what $DISPLAY was supposed to be under X11), so it looks to me
like the whole process here is just giving the user enough rope to hang
themselves with :(

Have you considered pointing flatpak at gpg-agent's --extra-socket,
which i think is more constrained than the standard gpg-agent socket?
Does that help?

What if, in a FreeDesktop environment, the overall policy was just:

 - gpg-agent decides where to display the pinentry, *not* the gpg
   invocation which talks to gpg-agent

 - by default, gpg-agent should know how to display the pinentry in the
   main running desktop session.

 - if you want something fancier, you need to design and maintain it
   yourself.

This overall would suggest that passing through *any* environment
variables originating from gpg all the way through the
gpg?gpg-agent?pinentry chain would be a mistake, and argues for the
allowlisting approach proposed by ikloecker in T7522.

The only issue here is if gpg-agent somehow gets launched before the
DBUS_SESSION_BUS_ADDRESS variable is initially set for the login; in
that case, any D-Bus-based pinentry would simply fail each time
gpg-agent tried to launch it.  So we'd need to ensure that
DBUS_SESSION_BUS_ADDRESS is set correctly before launching gpg-agent.
This is made more confusing by the myriad pinentries, not all of which
care about DBUS or other environment variables anyway.

           --dkg


PS I also note that this whole process is starting to smell like
   something that lets a flatpak app smuggle a directive to something
   outside the flatpak environment -- which, as i understand it, is
   something that flatpak is supposed to limit.  I don't know whether
   anyone with a background in the flatpak security model has tried to
   analyze this situation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250209/ecf19cb5/attachment.sig>

From Klaus+mailop at Ethgen.de  Mon Feb  3 12:44:07 2025
From: Klaus+mailop at Ethgen.de (Klaus Ethgen)
Date: Mon, 3 Feb 2025 12:44:07 +0100
Subject: [mailop] OpenPGP WKD URL
In-Reply-To: <20250202123550.056f7f7a@bonifac.skk>
References: <20250202123550.056f7f7a@bonifac.skk>
Message-ID: <Z6CsBxm4kboirsUJ@ikki.ket>

Hi Slavko,

I'll try to share the little knowledge I have.

Am So den  2. Feb 2025 um 12:35 schrieb Slavko via mailop:
>     https://openpgpkey.example.com/.well-known/openpgpkey/example.com/hu/...
[...]
>     https://openpgpkey.example.com/.well-known/openpgpkey/hu/...

First of all, I did the easiest way in DNS:
openpgpkey  IN  CNAME   wkd.keys.openpgp.org.

That way, I don't have to worry about it. However.

My knowledge is the later one. But it might be that you could implement
both solutions. Other way, it would not work relyable with the DNS CNAME
solution. So I think, the wiki seems to be wrong in that case.

> Around of web i found another form, with subdomain, but without domain
> in path:

And yes, the subdomain is important.

Beside that, I implemented the DNS key lookup in the way:
4iwmtum663r8xnewtn7ugkdixws1d1n8._pka   IN      CERT    IPGP 0 0 FIXUykKVLJSbF1Nis3nQsG9OIK8caHR0cDovL3d3dy5ldGhnZW4uY2gvfmtsYXVzLzc5RDBCMDZGNEUyMEFGMUMudHh0

However, that makes only sense with DNSSEC.

Maybe Werner is reading this and can answer the questions. I'll xpost
to gnupg-users ML.

Regards
   Klaus
-- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus at Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 688 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250203/ce8d2549/attachment.sig>

From wk at gnupg.org  Mon Feb 10 16:16:14 2025
From: wk at gnupg.org (Werner Koch)
Date: Mon, 10 Feb 2025 16:16:14 +0100
Subject: Pinentry with flatpak applications
In-Reply-To: <6fd64186b9a36e7a77ddd17ae9d16188@posteo.com> (jay kayes's
 message of "Sat, 08 Feb 2025 21:29:21 +0000")
References: <e176016dbe571b3c6f34c5bba0ade007@posteo.com>
 <d0aedf8a-07ed-46dc-956e-279a4042f13f@samoverton.dev>
 <6fd64186b9a36e7a77ddd17ae9d16188@posteo.com>
Message-ID: <87ldudg79d.fsf@jacob.g10code.de>

On Sat,  8 Feb 2025 21:29, jay.kayes--- said:

> Ah the wonderful niche commands that are available... if one only knew.

Run gpg-connect-agent and then enter "help" or for example "help
getinfo".


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: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250210/2a281b7a/attachment.sig>

From wk at gnupg.org  Mon Feb 10 16:26:05 2025
From: wk at gnupg.org (Werner Koch)
Date: Mon, 10 Feb 2025 16:26:05 +0100
Subject: Pinentry with flatpak applications
In-Reply-To: <87pljqjt7q.fsf@fifthhorseman.net> (Daniel Kahn Gillmor via
 Gnupg-users's message of "Sun, 09 Feb 2025 23:53:45 -0500")
References: <e176016dbe571b3c6f34c5bba0ade007@posteo.com>
 <D7NCWOGQ5T3V.1SAH9Y7I44Q1S@cepl.eu>
 <87pljqjt7q.fsf@fifthhorseman.net>
Message-ID: <87h651g6sy.fsf@jacob.g10code.de>

On Sun,  9 Feb 2025 23:53, Daniel Kahn Gillmor said:

> What if, in a FreeDesktop environment, the overall policy was just:
>
>  - gpg-agent decides where to display the pinentry, *not* the gpg
>    invocation which talks to gpg-agent

Very funny: The pinentry pops up on the remove machine you are connected
to.  But we actually have options for this --keep-tty and --keep-display
which locks the pinentry to the tty were gpg-agent was started.
Original use case was to show the pinentry in a fixed screen(1) session.



Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250210/8861bc03/attachment-0001.sig>

From dkg at fifthhorseman.net  Tue Feb 11 03:16:47 2025
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 10 Feb 2025 21:16:47 -0500
Subject: Pinentry with flatpak applications
In-Reply-To: <87h651g6sy.fsf@jacob.g10code.de>
References: <e176016dbe571b3c6f34c5bba0ade007@posteo.com>
 <D7NCWOGQ5T3V.1SAH9Y7I44Q1S@cepl.eu> <87pljqjt7q.fsf@fifthhorseman.net>
 <87h651g6sy.fsf@jacob.g10code.de>
Message-ID: <87h651jkds.fsf@fifthhorseman.net>

On Mon 2025-02-10 16:26:05 +0100, Werner Koch wrote:
> On Sun,  9 Feb 2025 23:53, Daniel Kahn Gillmor said:
>
>> What if, in a FreeDesktop environment, the overall policy was just:
>>
>>  - gpg-agent decides where to display the pinentry, *not* the gpg
>>    invocation which talks to gpg-agent
>
> Very funny: The pinentry pops up on the remove machine you are connected
> to.

I'm not sure i understand what you mean by this.  In this case, folks
are talking about a *local* machine that has multiple channels that
*might* give feedback to the user (whether it's a dbus session or X11
display or whatever.  It's not a remote machine.

> But we actually have options for this --keep-tty and --keep-display
> which locks the pinentry to the tty were gpg-agent was started.
> Original use case was to show the pinentry in a fixed screen(1) session.

So maybe --keep-display is the option that jay and Sam need to add to
~/.gnupg/gpg-agent.conf, then?  Should those options also cover
DBUS_SESSION_BUS_ADDRESS? or should we add a third option
--keep-dbus-session?  or should there really just be one option,
something like --keep-user-channel, which resists the temptation to
adjust any of these settings?

       --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250210/61228d13/attachment.sig>

From bernhard at intevation.de  Tue Feb 11 09:55:42 2025
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 11 Feb 2025 09:55:42 +0100
Subject: External Debian apt repository
In-Reply-To: <20250110130034.47b3e0da@incubator.example.net>
References: <20241217170042.742643b7@incubator.example.net>
 <20250110130034.47b3e0da@incubator.example.net>
Message-ID: <202502110955.57127.bernhard@intevation.de>

Frank,

Am Freitag 10 Januar 2025 13:00:34 schrieb Frank Guthausen:
> Updated to GnuPG 2.5.3 (released yesterday 2025-01-09)
> from the ``GnuPG (devel with libs)'' sources.

thanks for offering that build.

https://blog.shimps.org/blogpost296-GnuPG-Upstream-packaged-in-Debian-style

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/20250211/0c846380/attachment.sig>

From bernhard at intevation.de  Tue Feb 11 11:15:01 2025
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 11 Feb 2025 11:15:01 +0100
Subject: Mastodon 1k followers reached (Fediverse, aka "Social Media")
Message-ID: <202502111115.01313.bernhard@intevation.de>

Hi,

started in May 2023, our GnuPG Mastodon account
has reached 1000 Followers!

  https://mstdn.social/@GnuPG

\o/  :)

To give some perspective on this number: Because there is no algorithm
to fill in what a users sees and you cannot "buy" a placement
there, a follower in the fediverse is more likely to see our news item.

For a reasoning see
https://www.viennawriter.net/blog/social-media-principles-the-myth-of-reach-en/

And those who can read German:
The special topic publisher Heise reports that they have more
people coming from their Mastodon presence with a quarter
of followers compared to an elder social media platform.
After two years:
  https://social.heise.de/@mho/113452797498902317

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/20250211/68e81206/attachment.sig>

From wk at gnupg.org  Tue Feb 11 13:28:39 2025
From: wk at gnupg.org (Werner Koch)
Date: Tue, 11 Feb 2025 13:28:39 +0100
Subject: [mailop] OpenPGP WKD URL
In-Reply-To: <Z6CsBxm4kboirsUJ@ikki.ket> (Klaus Ethgen's message of "Mon, 3
 Feb 2025 12:44:07 +0100")
References: <20250202123550.056f7f7a@bonifac.skk> <Z6CsBxm4kboirsUJ@ikki.ket>
Message-ID: <87bjv8fyx4.fsf@jacob.g10code.de>

On Mon,  3 Feb 2025 12:44, Klaus Ethgen said:

> First of all, I did the easiest way in DNS:
> openpgpkey  IN  CNAME   wkd.keys.openpgp.org.

CNAME will only work if the final webserver has a certificate for the
actual domain or the one with the "openpgpkey." prefix.  Thus I don't
understand how Vincent's hack can work without delegating the ownership
of one's own domain to his server.


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: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250211/65dafdad/attachment.sig>

From look at my.amazin.horse  Tue Feb 11 14:41:27 2025
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Tue, 11 Feb 2025 14:41:27 +0100
Subject: [mailop] OpenPGP WKD URL
In-Reply-To: <87bjv8fyx4.fsf@jacob.g10code.de>
References: <20250202123550.056f7f7a@bonifac.skk> <Z6CsBxm4kboirsUJ@ikki.ket>
 <87bjv8fyx4.fsf@jacob.g10code.de>
Message-ID: <a8ff6ad4-2068-4909-8b64-2af663da47f1@my.amazin.horse>

Hey list,

On 11.02.25 13:28, Werner Koch via Gnupg-users wrote:
> CNAME will only work if the final webserver has a certificate for the
> actual domain or the one with the "openpgpkey." prefix.  Thus I don't
> understand how Vincent's hack can work without delegating the ownership
> of one's own domain to his server.

That is indeed how it works - you delegate the openpgpkey subdomain to 
our gateway server, and we do the rest. Not that much different from 
delegating a domain's mail responsibility via an MX record in that 
sense, and fortunately the "openpgpkey" subdomain is neatly 
compartmentalized for just that purpose :)

It's of course a matter of trust. But for a fair amount of people, it 
seems to be a reasonable tradeoff.

Cheers

  - V


From wk at gnupg.org  Tue Feb 11 17:17:51 2025
From: wk at gnupg.org (Werner Koch)
Date: Tue, 11 Feb 2025 17:17:51 +0100
Subject: [mailop] OpenPGP WKD URL
In-Reply-To: <a8ff6ad4-2068-4909-8b64-2af663da47f1@my.amazin.horse> (Vincent
 Breitmoser via Gnupg-users's message of "Tue, 11 Feb 2025 14:41:27
 +0100")
References: <20250202123550.056f7f7a@bonifac.skk> <Z6CsBxm4kboirsUJ@ikki.ket>
 <87bjv8fyx4.fsf@jacob.g10code.de>
 <a8ff6ad4-2068-4909-8b64-2af663da47f1@my.amazin.horse>
Message-ID: <877c5wfob4.fsf@jacob.g10code.de>


> It's of course a matter of trust. But for a fair amount of people, it
> seems to be a reasonable tradeoff.

[ This also works around the trust model of WKD which claims that you are
  the owner of your domain.]

The openpgpkey prefix thingy was only introduced to work around the
t-online.de/Stroehr website and DNS responsibility mess.  I wished I
never had introduced that - in particular because t-online then never
introduced WKD.


Salam-Shalom,

   Werner


-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250211/0179f31c/attachment.sig>

From look at my.amazin.horse  Tue Feb 11 17:44:49 2025
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Tue, 11 Feb 2025 17:44:49 +0100
Subject: [mailop] OpenPGP WKD URL
In-Reply-To: <877c5wfob4.fsf@jacob.g10code.de>
References: <20250202123550.056f7f7a@bonifac.skk> <Z6CsBxm4kboirsUJ@ikki.ket>
 <87bjv8fyx4.fsf@jacob.g10code.de>
 <a8ff6ad4-2068-4909-8b64-2af663da47f1@my.amazin.horse>
 <877c5wfob4.fsf@jacob.g10code.de>
Message-ID: <4e128235-50b3-4e0f-9146-35387070eab1@my.amazin.horse>

Hey Werner, list,

On 11.02.25 17:17, Werner Koch wrote:
>> It's of course a matter of trust. But for a fair amount of people, it
>> seems to be a reasonable tradeoff.
> 
> [ This also works around the trust model of WKD which claims that you are
>    the owner of your domain.]

I'm not sure I follow. If I point my MX to my email provider, it's the 
same thing isn't it, delegating a specific service associated to the 
domain I own to a service provider? It's pretty nice even in terms of 
trust if email and WKD are served by independent entities, so the email 
provider can't MitM you if they also manage WKD.

I know Proton had plans to offer WKDaaS for their users as well. But 
turns out managing a large amount of certificates is quite the 
engineering challenge, so I guess they never finished it.

> The openpgpkey prefix thingy was only introduced to work around the
> t-online.de/Stroehr website and DNS responsibility mess.  I wished I
> never had introduced that - in particular because t-online then never
> introduced WKD.

Yeah. Bummer it didn't work out with them, but I wager they're not the 
only ones with this management problem. Placing content directly on the 
main domain is certainly much more difficult in terms of processes and 
ownership than adding a specialized subdomain.

  - V


From vuori at notcom.org  Wed Feb 12 11:48:23 2025
From: vuori at notcom.org (Valtteri Vuorikoski)
Date: Wed, 12 Feb 2025 12:48:23 +0200
Subject: [mailop] OpenPGP WKD URL
In-Reply-To: <4e128235-50b3-4e0f-9146-35387070eab1@my.amazin.horse>
References: <20250202123550.056f7f7a@bonifac.skk> <Z6CsBxm4kboirsUJ@ikki.ket>
 <87bjv8fyx4.fsf@jacob.g10code.de>
 <a8ff6ad4-2068-4909-8b64-2af663da47f1@my.amazin.horse>
 <877c5wfob4.fsf@jacob.g10code.de>
 <4e128235-50b3-4e0f-9146-35387070eab1@my.amazin.horse>
Message-ID: <fq3imb5er4jc3xtsk23dm67snzmx7gdr4z5t6trdlo5dn2rstd@bhie3e57tcu7>

On Tue, Feb 11, 2025 at 05:44:49PM +0100, Vincent Breitmoser via Gnupg-users wrote:
> > The openpgpkey prefix thingy was only introduced to work around the
> > t-online.de/Stroehr website and DNS responsibility mess.  I wished I
> > never had introduced that - in particular because t-online then never
> > introduced WKD.
> 
> Yeah. Bummer it didn't work out with them, but I wager they're not the only
> ones with this management problem. Placing content directly on the main
> domain is certainly much more difficult in terms of processes and ownership
> than adding a specialized subdomain.

100% agree with Vincent here. The prefix (or another DNS-based indirection
mechanism from the domain apex) is absolutely required to deploy this kind of
less-known feature for a mid-size or larger organization.

Getting enough buy-in to have a DNS name added to a domain representing the
company brand is often hard enough. Getting changes to the corporate site or
company's primary service site is often close enough to impossible: whatever
HTTP service lives at the apex will often by operated by consultants operating
an outsourced CMS fronted by an outsourced cache farm fronted by an outsourced
WAF, which will nowadays often block anything that looks like "automated"
access. All of this will be zealously guarded by extremely risk-averse PR and
IT/security departments.

I have plenty of stories about getting a single, static, business-critical file
deployed to the apex site of a large corporation. Without going into detail, you
can often expect a multi-week if not multi-month effort involving upper management
for that single file.

 -Valtteri
 


From wk at gnupg.org  Wed Feb 12 15:53:03 2025
From: wk at gnupg.org (Werner Koch)
Date: Wed, 12 Feb 2025 15:53:03 +0100
Subject: [Announce] GnuPG 2.5.4 released
Message-ID: <87pljndxkg.fsf@jacob.g10code.de>

Hello!

We are pleased to announce the availability of a new GnuPG release:
version 2.5.4.  This release is another one in a series of public
testing releases eventually leading to a new stable version 2.6.

The main features in the 2.6 series are improvements for 64 bit Windows
and the introduction of Kyber (FIPS-203) as PQC encryption algorithm.

Other than PQC support the 2.6 series will not differ a lot from 2.4
because the majority of changes are internal to make use of newer
features from the supporting libraries.


What is GnuPG
=============

The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation
of the OpenPGP and S/MIME standards.

GnuPG allows to encrypt and sign data and communication, features a
versatile key management system as well as access modules for public key
directories.  GnuPG itself is a command line tool with features for easy
integration with other applications.  The separate library GPGME provides
a uniform API to use the GnuPG engine by software written in common
programming languages.  A wealth of frontend applications and libraries
making use of GnuPG are available.  As an universal crypto engine GnuPG
provides support for S/MIME and Secure Shell in addition to OpenPGP.

GnuPG is Free Software (meaning that it respects your freedom).  It can
be freely used, modified and distributed under the terms of the GNU
General Public License.


Noteworthy changes in version 2.5.4 (2025-02-12)
================================================
         [compared to version 2.5.3]

  * gpg: New option --disable-pqc-encryption.  [rG00c31f8b04]

  * gpg: Fix --quick-add-key for Weierstrass ECC with usage given.
    [T7506]

  * gpg: Fix handling with no CRC armor.  [T7071]

  * gpg: New private Kyber keys are now cross-referenced using a new
    Link attribute.  [T6638]

  * gpg: Fix an import problem with keys having another primary key as
    a subkey.  [T7527]

  * gpgsm: Allow unattended PKCS#12 export without passphrase.
    [rG159e801043]

  * gpgsm: Allow CSR generation with an unprotected key.
    [rG89055f24f4]

  * agent: New option --change-std-env-name.  [T7522]

  * agent: Fix ssh-agent's request_identities for skipped Brainpool
    keys.  [rG2469dc5aae]

  * Do not package zlib and bzip2 object files in a Speedo release
    build.  [T7442]

  Release-info: https://dev.gnupg.org/T7480


Getting the Software
====================

Please follow the instructions found at <https://gnupg.org/download/> or
read on:

GnuPG may be downloaded from one of the GnuPG mirror sites or direct
from its primary file server.  The list of mirrors can be found at
<https://gnupg.org/download/mirrors.html>.  Note that GnuPG is not
available at ftp.gnu.org.

The GnuPG source code compressed using BZIP2 and its OpenPGP signature
are available here:

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.4.tar.bz2 (7983k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.4.tar.bz2.sig

An installer for Windows without any graphical frontend except for a
very minimal Pinentry tool is available here:

 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.4_20250212.exe (5661k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.4_20250212.exe.sig

The source used to build this installer for 64-bit Windows is available at

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.4_20250212.tar.xz (16M)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.4_20250212.tar.xz.sig

This source tarball may also be used to download all required libraries
at once to build a Unix version on any modern system.  See the included
README.

A new Beta version of Gpg4win, our full featured installer for Windows
including this version of GnuPG as well as Kleopatra GUI and a PDF
editor will soon be available at https://www.gpg4win.org/version5.html




Checking the Integrity
======================

In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:

 * If you already have a version of GnuPG installed, you can simply
   verify the supplied signature.  For example to verify the signature
   of the file gnupg-2.5.4.tar.bz2 you would use this command:

     gpg --verify gnupg-2.5.4.tar.bz2.sig gnupg-2.5.4.tar.bz2

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by one or more of the release signing keys.  Make sure that
   this is a valid key, either by matching the shown fingerprint
   against a trustworthy list of valid release signing keys or by
   checking that the key has been signed by trustworthy other keys.
   See the end of this mail for information on the signing keys.

 * If you are not able to use an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file gnupg-2.5.4.tar.bz2, you run the command like this:

     sha1sum gnupg-2.5.4.tar.bz2

   and check that the output matches the next line:

98b3f7161c62882c9cf2efc023bdb9caaf23111a  gnupg-2.5.4.tar.bz2
c69f25538a7738a8b9f79310ec99cfb77e2fa497  gnupg-w32-2.5.4_20250212.tar.xz
6febc0963df51c69b5c1752be66fd6b8f4c4b82d  gnupg-w32-2.5.4_20250212.exe


Internationalization
====================

This version of GnuPG has support for 26 languages with Chinese
(traditional and simplified), Czech, French, German, Italian, Japanese,
Norwegian, Polish, Portuguese, Russian, Turkish, and Ukrainian being
almost completely translated.


Documentation and Support
=========================

The file gnupg.info has the complete reference manual of the system.
Separate man pages are included as well but they miss some of the
details available only in the manual.  The manual is also available
online at

  https://gnupg.org/documentation/manuals/gnupg/

or can be downloaded as PDF at

  https://gnupg.org/documentation/manuals/gnupg.pdf

You may also want to search the GnuPG mailing list archives or ask on
the gnupg-users mailing list for advise on how to solve problems.  Most
of the new features are around for several years and thus enough public
experience is available.  https://wiki.gnupg.org has user contributed
information around GnuPG and relate software.

In case of build problems specific to this release please first check
https://dev.gnupg.org/T7480 for updated information.  

Please consult the archive of the gnupg-users mailing list before
reporting a bug: https://gnupg.org/documentation/mailing-lists.html.
We suggest to send bug reports for a new release to this list in favor
of filing a bug at https://bugs.gnupg.org.  If you need commercial
support go to https://gnupg.com or https://gnupg.org/service.html.

If you are a developer and you need a certain feature for your project,
please do not hesitate to bring it to the gnupg-devel mailing list for
discussion.


Thanks
======

Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH
and has mostly been financed by donations.  Several full-time employed
developers and contractors are working exclusively on GnuPG and closely
related software like Libgcrypt, GPGME, Kleopatra and Gpg4win.

Fortunately, and this is still not common with free software, we have
established a way of financing the development while keeping all our
software free and freely available for everyone.  Our model is similar
to the way RedHat manages RHEL and Fedora: Except for the actual binary
of the MSI installer for Windows and client specific configuration
files, all the software is available under the GNU GPL and other Open
Source licenses.  Thus customers may even build and distribute their own
version of the software as long as they do not use our trademarks
GnuPG Desktop? or GnuPG VS-Desktop?.

We like to thank all the nice people who are helping the GnuPG project,
be it testing, coding, translating, suggesting, auditing, administering
the servers, spreading the word, answering questions on the mailing
lists, or helped with donations.

*Thank you all*

   Your GnuPG hackers


p.s.
This is an announcement only mailing list.  Please send replies only to
the gnupg-users at gnupg.org mailing list.

List of Release Signing Keys:
To guarantee that a downloaded GnuPG version has not been tampered by
malicious entities we provide signature files for all tarballs and
binary versions.  The keys are also signed by the long term keys of
their respective owners.  Current releases are signed by one or more
of these four keys:

  rsa3072 2017-03-17 [expires: 2027-03-15]
  5B80 C575 4298 F0CB 55D8  ED6A BCEF 7E29 4B09 2E28
  Andre Heinecke (Release Signing Key)

  ed25519 2020-08-24 [expires: 2030-06-30]
  6DAA 6E64 A76D 2840 571B  4902 5288 97B8 2640 3ADA
  Werner Koch (dist signing 2020)

  ed25519 2021-05-19 [expires: 2027-04-04]
  AC8E 115B F73E 2D8D 47FA  9908 E98E 9B2D 19C6 C8BD
  Niibe Yutaka (GnuPG Release Key)

  brainpoolP256r1 2021-10-15 [expires: 2029-12-31]
  02F3 8DFF 731F F97C B039  A1DA 549E 695E 905B A208
  GnuPG.com (Release Signing Key 2021)

The keys are available at https://gnupg.org/signature_key.html and
in any recently released GnuPG tarball in the file g10/distsigkey.gpg .
Note that this mail has been signed by a different key.

-- 
Arguing that you don't care about the right to privacy because you have
nothing to hide is no different from saying you don't care about free
speech because you have nothing to say.                - Edward Snowden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250212/34c59b7a/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From wk at gnupg.org  Fri Feb 14 08:02:55 2025
From: wk at gnupg.org (Werner Koch)
Date: Fri, 14 Feb 2025 08:02:55 +0100
Subject: [mailop] OpenPGP WKD URL
In-Reply-To: <fq3imb5er4jc3xtsk23dm67snzmx7gdr4z5t6trdlo5dn2rstd@bhie3e57tcu7>
 (Valtteri Vuorikoski via Gnupg-users's message of "Wed, 12 Feb 2025
 12:48:23 +0200")
References: <20250202123550.056f7f7a@bonifac.skk> <Z6CsBxm4kboirsUJ@ikki.ket>
 <87bjv8fyx4.fsf@jacob.g10code.de>
 <a8ff6ad4-2068-4909-8b64-2af663da47f1@my.amazin.horse>
 <877c5wfob4.fsf@jacob.g10code.de>
 <4e128235-50b3-4e0f-9146-35387070eab1@my.amazin.horse>
 <fq3imb5er4jc3xtsk23dm67snzmx7gdr4z5t6trdlo5dn2rstd@bhie3e57tcu7>
Message-ID: <871pw1dn4w.fsf@jacob.g10code.de>

On Wed, 12 Feb 2025 12:48, Valtteri Vuorikoski said:

> 100% agree with Vincent here. The prefix (or another DNS-based indirection
> mechanism from the domain apex) is absolutely required to deploy this kind of

I agree too.  Maybe I forgot to mention that the whole trouble started
with browser vendors not support basic DNS lookup features in their
browsers.  Using SRV records would have been the Right Thing.


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: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250214/87e4dafb/attachment.sig>

From klaus+gnupg at ethgen.ch  Fri Feb 14 13:25:36 2025
From: klaus+gnupg at ethgen.ch (Klaus Ethgen)
Date: Fri, 14 Feb 2025 13:25:36 +0100
Subject: [mailop] OpenPGP WKD URL
In-Reply-To: <871pw1dn4w.fsf@jacob.g10code.de>
References: <20250202123550.056f7f7a@bonifac.skk> <Z6CsBxm4kboirsUJ@ikki.ket>
 <87bjv8fyx4.fsf@jacob.g10code.de>
 <a8ff6ad4-2068-4909-8b64-2af663da47f1@my.amazin.horse>
 <877c5wfob4.fsf@jacob.g10code.de>
 <4e128235-50b3-4e0f-9146-35387070eab1@my.amazin.horse>
 <fq3imb5er4jc3xtsk23dm67snzmx7gdr4z5t6trdlo5dn2rstd@bhie3e57tcu7>
 <871pw1dn4w.fsf@jacob.g10code.de>
Message-ID: <Z682QMjOR2t20TZl@ikki.ket>

Hi,

Am Fr den 14. Feb 2025 um  8:02 schrieb Werner Koch via Gnupg-users:
> with browser vendors not support basic DNS lookup features in their
> browsers.  Using SRV records would have been the Right Thing.

Do I get something wrong? That WKS system is used by Gnupg and not by a
Browser...?

Browsers have made many bad decissions with DNS in the past. The worst
is to not support TLSA records. But the CAs seems to have too much
interest in browsers not supporting TLSA.

That is one reason why I have only Cacert in use for my domain(s). On
the other hand, that makes Gnupg not been able to use WKS to resolve my
keys. That is why I use the delegated subdomain.

Gru?
   Klaus
-- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus at Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 688 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250214/e4047fd5/attachment.sig>

From andrewg at andrewg.com  Fri Feb 14 20:23:12 2025
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Fri, 14 Feb 2025 19:23:12 +0000
Subject: [mailop] OpenPGP WKD URL
In-Reply-To: <Z682QMjOR2t20TZl@ikki.ket>
References: <Z682QMjOR2t20TZl@ikki.ket>
Message-ID: <A657E106-06E3-47AD-A9E9-ED18EC236CFF@andrewg.com>

On 14 Feb 2025, at 13:12, Klaus Ethgen <klaus+gnupg at ethgen.ch> wrote:
> 
> Do I get something wrong? That WKS system is used by Gnupg and not by a
> Browser...?

It?s used by many openpgp clients, some of which do run in the browser. 

A

From bernhard at intevation.de  Wed Feb 19 16:59:33 2025
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 19 Feb 2025 16:59:33 +0100
Subject: WKD new online-checker and suggestion for the WKD spec
Message-ID: <202502191659.40247.bernhard@intevation.de>

Hi,

there is a new online checker by Freddie Leeman

  https://webkeydirectory.com

The source code is not public and in a test I've found out that
the SHOULD content-type is indicated in red, but I've also learned
that my policy file had a defect. So it is useful. :)

As long as your email address is public anyway... happy checking! 

@Werner,

the checker also recommends to set
  The Access-Control-Allow-Origin: * header is needed to allow OpenPGP clients 
  to fetch the policy from a different domain, bypassing CORS restrictions.

sounds like a good idea to me, to support clients running as webpage.
Shouldn't this be added to the WKD specification?

(I've suggested it already in Message-Id: 
<201806051641.34344.bernhard at intevation.de> I believe). :)

Best,
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/20250219/2adf6fcb/attachment-0001.sig>

From andrewg at andrewg.com  Wed Feb 19 19:15:40 2025
From: andrewg at andrewg.com (andrewg)
Date: Wed, 19 Feb 2025 18:15:40 +0000
Subject: WKD new online-checker and suggestion for the WKD spec
In-Reply-To: <202502191659.40247.bernhard@intevation.de>
References: <202502191659.40247.bernhard@intevation.de>
Message-ID: <36c4cb2af747825991d38582599cd4c0@andrewg.com>

On 2025-02-19 15:59, Bernhard Reiter via Gnupg-users wrote:
> 
> there is a new online checker by Freddie Leeman
> 
>   https://webkeydirectory.com

I believe this was first announced in 2019: 
https://www.uriports.com/blog/setting-up-openpgp-web-key-directory/

There is however a new checker at https://wkd.chimbosonic.com ...

A


From bernhard at intevation.de  Thu Feb 20 11:44:11 2025
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 20 Feb 2025 11:44:11 +0100
Subject: WKD a second online-checker
In-Reply-To: <36c4cb2af747825991d38582599cd4c0@andrewg.com>
References: <202502191659.40247.bernhard@intevation.de>
 <36c4cb2af747825991d38582599cd4c0@andrewg.com>
Message-ID: <202502201144.18738.bernhard@intevation.de>

Am Mittwoch 19 Februar 2025 19:15:40 schrieb andrewg via Gnupg-users:
> On 2025-02-19 15:59, Bernhard Reiter via Gnupg-users wrote:
> > there is a new online checker by Freddie Leeman
> >
> >   https://webkeydirectory.com
>
> I believe this was first announced in 2019:
> https://www.uriports.com/blog/setting-up-openpgp-web-key-directory/

Just got an email from Freddie yesterday, so it is on
  https://wiki.gnupg.org/WKD#Online_checkers
for the first time.

> There is however a new checker at https://wkd.chimbosonic.com ...

Added there as well, thanks.

Bernhard
-------------- 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/20250220/47df1899/attachment.sig>

From rjh at sixdemonbag.org  Thu Feb 20 21:33:41 2025
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 20 Feb 2025 15:33:41 -0500
Subject: A FAQ
Message-ID: <c86a9255-a66c-4645-b250-c3f6e500b966@sixdemonbag.org>

Q: Why did you stop maintaining the official GnuPG FAQ?
A: Inappropriate pressure from RMS, as well as to protest FSF's
    decision to reappoint him to the Board.

Q: So if you're writing this, that means things are changing?
A: Nope. Still not going to maintain the official FAQ.

Q: So what's this email about?
A: I'm going to write an unofficial FAQ. If the core team
    wants to later on bless it as an official resource, they
    can, but as far as I'm concerned it will be 100% unofficial.

Q: Why now?
A: Because I'm sick and tired, and tired and sick, of doing
    nothing as my country tears itself apart.  I can't do much
    but I can explain things well. Maybe that will make GnuPG
    more useful to people who are deeply concerned about the
    trend of Western democracies towards surveillance capitalism
    and authoritarian rule.

Q: How can I help?
A: Let me know what questions you've always had.

Q: What will the format be?
A: HTML, PDF, and ePUB.

Q: Are you accepting contributions?
A: No. I want there to be one authorial voice.

Q: Good luck, man.
A: That's not a question, but thanks. We all need it.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250220/b0701cae/attachment.sig>

From bernhard at intevation.de  Mon Feb 24 12:20:02 2025
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 24 Feb 2025 12:20:02 +0100
Subject: A FAQ
In-Reply-To: <c86a9255-a66c-4645-b250-c3f6e500b966@sixdemonbag.org>
References: <c86a9255-a66c-4645-b250-c3f6e500b966@sixdemonbag.org>
Message-ID: <202502241220.13506.bernhard@intevation.de>

Hi Robert,

thanks for starting an unofficial FAQ and for explaning
more about GnuPG and LibrePGP to people!

Am Donnerstag 20 Februar 2025 21:33:41 schrieb Robert J. Hansen via 
Gnupg-users:
> Q: How can I help?
> A: Let me know what questions you've always had.

Note that some questions are already be answered in wiki.gnupg.org.
You would be welcome to add your take for things there if you want.
Do you have an account?

> Q: What will the format be?
> A: HTML, PDF, and ePUB.

> Q: Are you accepting contributions?
> A: No. I want there to be one authorial voice.

Otherwise I would say use the wiki, but of course, it is Robert's FAQ
so it is your choice. 

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/20250224/ac72f1cf/attachment.sig>

From tschweikle at gmail.com  Mon Feb 24 13:24:38 2025
From: tschweikle at gmail.com (Thomas Schweikle)
Date: Mon, 24 Feb 2025 13:24:38 +0100
Subject: adding uid to key
Message-ID: <CA+rGx5f1L8GnPrvHjV70QWetQOzftLjG9tEq022T27tF7wVkXw@mail.gmail.com>

 Hi!

I'm having some problem adding an uid to a key. What I am doing:
1. list all keys
2. select one of the active keys
3. gpg --edit-key <key-id>
4. adduid
   answer the questions: name, mail6
5. type in keys secret

do 2 to 5 for the second key.

6. save

 Now "gpg --list-secret-keys" lists (shortened):
sec   ed25519 2020-11-18 [SC] [verf?llt: 2026-12-31]
      565931F52CE768F643389BABA9CA236BDBEC9779
uid        [ ultimativ ] name <mail6>
uid        [ ultimativ ] name <mail4>
uid        [ ultimativ ] name <mail1>
uid        [ ultimativ ] name <mail2>
uid        [ ultimativ ] name <mail5>
uid        [ ultimativ ] name <mail3>
ssb   cv25519 2020-11-18 [E] [verf?llt: 2026-12-31]
      97F6060D825C74CA8A7E49CFA0F506A815F9DDAD

sec   ed25519 2020-11-18 [SC] [verf?llt: 2026-12-31]
      565931F52CE768F643389BABA9CA236BDBEC9779
uid        [ ultimativ ] name <mail4>
uid        [ ultimativ ] name <mail1>
uid        [ ultimativ ] name <mail2>
uid        [ ultimativ ] name <mail5>
uid        [ ultimativ ] name <mail3>

sec   ed25519 2020-11-18 [SC] [verf?llt: 2026-12-31]
      565931F52CE768F643389BABA9CA236BDBEC9779
uid        [ ultimativ ] name <mail4>
uid        [ ultimativ ] name <mail1>
uid        [ ultimativ ] name <mail2>
uid        [ ultimativ ] name <mail5>
uid        [ ultimativ ] name <mail3>

sec   ed25519 2020-11-18 [SC] [verf?llt: 2026-12-31]
      565931F52CE768F643389BABA9CA236BDBEC9779
uid        [ ultimativ ] name <mail4>
uid        [ ultimativ ] name <mail1>
uid        [ ultimativ ] name <mail2>
uid        [ ultimativ ] name <mail5>
uid        [ ultimativ ] name <mail3>

sec   brainpoolP512r1 2022-07-13 [SCA] [verf?llt: 2026-12-31]
      ACDFB1AF82CF084B948ECB5D27AE2304B4974851
uid        [ ultimativ ] name <mail6>
uid        [ ultimativ ] name <mail1>
uid        [ ultimativ ] name <mail4>
uid        [ ultimativ ] name <mail5>
uid        [ ultimativ ] name <mail2>
uid        [ ultimativ ] name <mail3>
ssb   brainpoolP512r1 2022-07-13 [E] [verf?llt: 2026-12-31]
      0A5D749D75F3D847CEC42CFF737D00DCF417C669

sec   brainpoolP512r1 2022-07-13 [SCA] [verf?llt: 2026-12-31]
      ACDFB1AF82CF084B948ECB5D27AE2304B4974851
uid        [ ultimativ ] name <mail1>
uid        [ ultimativ ] name <mail4>
uid        [ ultimativ ] name <mail5>
uid        [ ultimativ ] name <mail2>
uid        [ ultimativ ] name <mail3>

The added "mail6" is only seen at two places. Is this ok?
Or should it show up within every block?

Kleopatra does not show the added "mail6" anywhere. Any ideas? Anything I
should do but forgot to do adding a new email address?

-- 
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250224/eb52b2fe/attachment.html>

From pillerpiraten at proton.me  Mon Feb 24 14:38:23 2025
From: pillerpiraten at proton.me (pillerpiraten)
Date: Mon, 24 Feb 2025 13:38:23 +0000
Subject: Cant use my passphare for sec key
Message-ID: <e3LhOYltNv1qg63Ry0y6fo5aSOMFlcsLK-5hZFlhh3TNeZDI3kT4-jFrtRgSRtEgUofMjYBoEzQakegiyG4-7HsZPmyARaY3UiolTlFLATc=@proton.me>

Hey i cant use my passphare for sec key only says this when i type in gpg --decrypt backup_2024-08-31.sec.pgp | gpg --import
gpg: unknown armor header: Passphrase-Format: numeric9x4
gpg: unknown armor header: Passphrase-Begin: 98
gpg: AES256.CFB encrypted data
gpg: gcry_kdf_derive failed: Invalid data
gpg: encrypted with 1 passphrase
gpg: decryption failed: No secret key
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
please help / Pingvingen

Sent with [Proton Mail](https://proton.me/mail/home) secure email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250224/6cb91d6d/attachment-0001.html>

From jb at wisemo.com  Tue Feb 25 04:46:27 2025
From: jb at wisemo.com (Jakob Bohm)
Date: Tue, 25 Feb 2025 04:46:27 +0100
Subject: [mailop] OpenPGP WKD URL
In-Reply-To: <A657E106-06E3-47AD-A9E9-ED18EC236CFF@andrewg.com>
References: <Z682QMjOR2t20TZl@ikki.ket>
 <A657E106-06E3-47AD-A9E9-ED18EC236CFF@andrewg.com>
Message-ID: <806d6a0e-7ac7-45eb-986a-d37bcf7ee425@wisemo.com>

On 2/14/2025 20:23:12, Andrew Gallagher via Gnupg-users wrote:
> On 14 Feb 2025, at 13:12, Klaus Ethgen<klaus+gnupg at ethgen.ch> wrote:
>> Do I get something wrong? That WKS system is used by Gnupg and not by a
>> Browser...?
> It?s used by many openpgp clients, some of which do run in the browser.
>
> A
WKS is an oddity in DNS that (besides this random inclusion in PGP) 
seemed to be
entirely limited to certain Enterprise deployments of various software 
suites.

Many other protocols have worked very well with naming conventions like
"ftp.department.foo.edu" and "mail.foo.edu" .? But yeah, browser-focused DNS
implementations tend to even lack the ability to look up MX records .

-- 
Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10 
<tel:+4531131610>
This message is only for its intended recipient, delete if misaddressed.
WiseMo - Remote Service Management for PCs, Phones and Embedded
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250225/8ce21463/attachment.html>

From fg.gnupg at shimps.de  Tue Feb 25 19:07:45 2025
From: fg.gnupg at shimps.de (Frank Guthausen)
Date: Tue, 25 Feb 2025 19:07:45 +0100
Subject: Removal of compile time path info
Message-ID: <20250225190745.6c5628c5@incubator.example.net>

Hello.

I did a few checks with the command ``strings'' on the self compiled
binaries of 2.5.4 and noticed remainders of compile time and/or install
time path info.

1. Method "make; make install" with default Makefile

The chosen PREFIX path at configuration time might necessarily be
hardcoded in one way or another, that would be not the main problem.
In this setup there are mainly install time paths visible.

2. Method with ``build-aux/speedo.mk'' and target ``native''

The install command can be provided with a SYSROOT target path setting,
thus no compile time paths are needed anymore. But there are lots of
those paths visible with ``strings''. My understanding is that all
important information regarding any path is taken from the file
gpgconf.ctl where a rootdir is defined. By adjusting this I can even
move the binaries to a completely different location than the previously
chosen SYSROOT. Thus I do not need the compile time path information
because it is not useful in any way. The compile environment is deleted
once the install has happened.

Is there an option to get rid of the
path strings in the compiled binaries?
-- 
kind regards
Frank
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250225/cae4624c/attachment.sig>

From tschweikle at gmail.com  Thu Feb 27 09:13:05 2025
From: tschweikle at gmail.com (Thomas Schweikle)
Date: Thu, 27 Feb 2025 09:13:05 +0100
Subject: Problem with adding a name to a key
Message-ID: <CA+rGx5fSN_qAvsUNKCtDVkUVJ0d=4kdOFGZ1=PRNoWgLWt723g@mail.gmail.com>

 Hi!

I'm having some problem adding an uid to a key. What I am doing:
1. list all keys
2. select one of the active keys
3. gpg --edit-key <key-id>
4. adduid
   answer the questions: name, mail6
5. type in keys secret

do 2 to 5 for the second key.

6. save

 Now "gpg --list-secret-keys" lists (shortened):
sec   ed25519 2020-11-18 [SC] [verf?llt: 2026-12-31]
      565931F52CE768F643389BABA9CA236BDBEC9779
uid        [ ultimativ ] name <mail6>
uid        [ ultimativ ] name <mail4>
uid        [ ultimativ ] name <mail1>
uid        [ ultimativ ] name <mail2>
uid        [ ultimativ ] name <mail5>
uid        [ ultimativ ] name <mail3>
ssb   cv25519 2020-11-18 [E] [verf?llt: 2026-12-31]
      97F6060D825C74CA8A7E49CFA0F506A815F9DDAD

sec   ed25519 2020-11-18 [SC] [verf?llt: 2026-12-31]
      565931F52CE768F643389BABA9CA236BDBEC9779
uid        [ ultimativ ] name <mail4>
uid        [ ultimativ ] name <mail1>
uid        [ ultimativ ] name <mail2>
uid        [ ultimativ ] name <mail5>
uid        [ ultimativ ] name <mail3>

sec   ed25519 2020-11-18 [SC] [verf?llt: 2026-12-31]
      565931F52CE768F643389BABA9CA236BDBEC9779
uid        [ ultimativ ] name <mail4>
uid        [ ultimativ ] name <mail1>
uid        [ ultimativ ] name <mail2>
uid        [ ultimativ ] name <mail5>
uid        [ ultimativ ] name <mail3>

sec   ed25519 2020-11-18 [SC] [verf?llt: 2026-12-31]
      565931F52CE768F643389BABA9CA236BDBEC9779
uid        [ ultimativ ] name <mail4>
uid        [ ultimativ ] name <mail1>
uid        [ ultimativ ] name <mail2>
uid        [ ultimativ ] name <mail5>
uid        [ ultimativ ] name <mail3>

sec   brainpoolP512r1 2022-07-13 [SCA] [verf?llt: 2026-12-31]
      ACDFB1AF82CF084B948ECB5D27AE2304B4974851
uid        [ ultimativ ] name <mail6>
uid        [ ultimativ ] name <mail1>
uid        [ ultimativ ] name <mail4>
uid        [ ultimativ ] name <mail5>
uid        [ ultimativ ] name <mail2>
uid        [ ultimativ ] name <mail3>
ssb   brainpoolP512r1 2022-07-13 [E] [verf?llt: 2026-12-31]
      0A5D749D75F3D847CEC42CFF737D00DCF417C669

sec   brainpoolP512r1 2022-07-13 [SCA] [verf?llt: 2026-12-31]
      ACDFB1AF82CF084B948ECB5D27AE2304B4974851
uid        [ ultimativ ] name <mail1>
uid        [ ultimativ ] name <mail4>
uid        [ ultimativ ] name <mail5>
uid        [ ultimativ ] name <mail2>
uid        [ ultimativ ] name <mail3>

The added "mail6" is only seen at two places. Is this ok?
Or should it show up within every block?

Kleopatra does not show the added "mail6" anywhere. Any ideas? Anything I
should do but forgot to do adding a new email address?

-- 
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250227/a04e6458/attachment.html>

From kloecker at kde.org  Thu Feb 27 11:13:20 2025
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Thu, 27 Feb 2025 11:13:20 +0100
Subject: Problem with adding a name to a key
In-Reply-To: <CA+rGx5fSN_qAvsUNKCtDVkUVJ0d=4kdOFGZ1=PRNoWgLWt723g@mail.gmail.com>
References: <CA+rGx5fSN_qAvsUNKCtDVkUVJ0d=4kdOFGZ1=PRNoWgLWt723g@mail.gmail.com>
Message-ID: <2100232.YKUYFuaPT4@daneel>

When asking for help you should always start by telling us the version(s) of
the program(s) you are using, i.e. in this case of gnupg (`gpg --version`) and
of Kleopatra (in Help->About Kleopatra).

On Donnerstag, 27. Februar 2025 09:13:05 Thomas Schweikle via Gnupg-users 
wrote:
> I'm having some problem adding an uid to a key. What I am doing:
> 1. list all keys
> 2. select one of the active keys
> 3. gpg --edit-key <key-id>
> 4. adduid
>    answer the questions: name, mail6
> 5. type in keys secret
> 
> do 2 to 5 for the second key.
> 
> 6. save
> 
>  Now "gpg --list-secret-keys" lists (shortened):
> sec   ed25519 2020-11-18 [SC] [verf?llt: 2026-12-31]
>       565931F52CE768F643389BABA9CA236BDBEC9779
> uid        [ ultimativ ] name <mail6>
> uid        [ ultimativ ] name <mail4>
> uid        [ ultimativ ] name <mail1>
> uid        [ ultimativ ] name <mail2>
> uid        [ ultimativ ] name <mail5>
> uid        [ ultimativ ] name <mail3>
> ssb   cv25519 2020-11-18 [E] [verf?llt: 2026-12-31]
>       97F6060D825C74CA8A7E49CFA0F506A815F9DDAD
> 
> sec   ed25519 2020-11-18 [SC] [verf?llt: 2026-12-31]
>       565931F52CE768F643389BABA9CA236BDBEC9779
> uid        [ ultimativ ] name <mail4>
> uid        [ ultimativ ] name <mail1>
> uid        [ ultimativ ] name <mail2>
> uid        [ ultimativ ] name <mail5>
> uid        [ ultimativ ] name <mail3>
> 
[Last "sec" listing repeated two more times]

> sec   brainpoolP512r1 2022-07-13 [SCA] [verf?llt: 2026-12-31]
>       ACDFB1AF82CF084B948ECB5D27AE2304B4974851
> uid        [ ultimativ ] name <mail6>
> uid        [ ultimativ ] name <mail1>
> uid        [ ultimativ ] name <mail4>
> uid        [ ultimativ ] name <mail5>
> uid        [ ultimativ ] name <mail2>
> uid        [ ultimativ ] name <mail3>
> ssb   brainpoolP512r1 2022-07-13 [E] [verf?llt: 2026-12-31]
>       0A5D749D75F3D847CEC42CFF737D00DCF417C669
> 
> sec   brainpoolP512r1 2022-07-13 [SCA] [verf?llt: 2026-12-31]
>       ACDFB1AF82CF084B948ECB5D27AE2304B4974851
> uid        [ ultimativ ] name <mail1>
> uid        [ ultimativ ] name <mail4>
> uid        [ ultimativ ] name <mail5>
> uid        [ ultimativ ] name <mail2>
> uid        [ ultimativ ] name <mail3>

This looks wrong. Each key should be listed only once.

> The added "mail6" is only seen at two places. Is this ok?

I think that's okay. The other "copies" of your two keys shouldn't even exist.

> Or should it show up within every block?

The other "blocks" shouldn't be there in the first place.

> Kleopatra does not show the added "mail6" anywhere. Any ideas?

I suppose you looked in the Certificate Details. My guess is that Kleopatra
picked up the bogus copies of your keys. You could verify this by looking at
the subkeys for those keys. If only one subkey is listed then Kleopatra
didn't pick up the correct copy of your key.

> Anything I should do but forgot to do adding a new email address?

What you did looks correct, but your keyring seems to be corrupt. I would try
the following:
* Make a backup of ~/.gnupg and of everything in this folder.
* Export the first key (including the secret key) with
gpg --export-secret-keys 565931F52CE768F643389BABA9CA236BDBEC9779 
>565931F52CE768F643389BABA9CA236BDBEC9779.gpg
* Delete the first key (including the secret key). This is a destructive 
operation!
I hope you have created a backup.
gpg --delete-secret-and-public-keys FINGERPRINT_OF_YOUR_FIRST_KEY
* List your secret keys to verify that your first key (and all of its bogus
copies) has been removed from your keyring. Also list the public keys.
gpg --list-secret-keys 565931F52CE768F643389BABA9CA236BDBEC9779
and
gpg --list-keys 565931F52CE768F643389BABA9CA236BDBEC9779
should both print an error "No secret key" or "No public key".
* Import the exported key
gpg --import 565931F52CE768F643389BABA9CA236BDBEC9779.gpg
* List your secret keys. If everything worked according to my plan you should
now see only one "block" for your first key, i.e. you should see
> sec   ed25519 2020-11-18 [SC] [verf?llt: 2026-12-31]
>       565931F52CE768F643389BABA9CA236BDBEC9779
> uid        [ ultimativ ] name <mail6>
> uid        [ ultimativ ] name <mail4>
> uid        [ ultimativ ] name <mail1>
> uid        [ ultimativ ] name <mail2>
> uid        [ ultimativ ] name <mail5>
> uid        [ ultimativ ] name <mail3>
> ssb   cv25519 2020-11-18 [E] [verf?llt: 2026-12-31]
>       97F6060D825C74CA8A7E49CFA0F506A815F9DDAD

If this worked then repeat this for your second key.

Let me repeat: Before you start make a backup of ~/.gnupg !!!

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/20250227/acc6b5b7/attachment.sig>

From tschweikle at gmail.com  Thu Feb 27 15:18:17 2025
From: tschweikle at gmail.com (Thomas Schweikle)
Date: Thu, 27 Feb 2025 15:18:17 +0100
Subject: Problem with adding a name to a key
In-Reply-To: <2100232.YKUYFuaPT4@daneel>
References: <CA+rGx5fSN_qAvsUNKCtDVkUVJ0d=4kdOFGZ1=PRNoWgLWt723g@mail.gmail.com>
 <2100232.YKUYFuaPT4@daneel>
Message-ID: <CA+rGx5fhbay4Gt1=_bsv5O3Op7id9vX+-0j0rN9y2maeqtVdJg@mail.gmail.com>

On Thu, Feb 27, 2025 at 12:29?PM Ingo Kl?cker <kloecker at kde.org> wrote:

> When asking for help you should always start by telling us the version(s)
> of
> the program(s) you are using, i.e. in this case of gnupg (`gpg --version`)
> and
> of Kleopatra (in Help->About Kleopatra).
>
> On Donnerstag, 27. Februar 2025 09:13:05 Thomas Schweikle via Gnupg-users
> wrote:
> > I'm having some problem adding an uid to a key. What I am doing:
> > 1. list all keys
> > 2. select one of the active keys
> > 3. gpg --edit-key <key-id>
> > 4. adduid
> >    answer the questions: name, mail6
> > 5. type in keys secret
> >
> > do 2 to 5 for the second key.
> >
> > 6. save
> >
> >  Now "gpg --list-secret-keys" lists (shortened):
> > sec   ed25519 2020-11-18 [SC] [verf?llt: 2026-12-31]
> >       565931F52CE768F643389BABA9CA236BDBEC9779
> > uid        [ ultimativ ] name <mail6>
> > uid        [ ultimativ ] name <mail4>
> > uid        [ ultimativ ] name <mail1>
> > uid        [ ultimativ ] name <mail2>
> > uid        [ ultimativ ] name <mail5>
> > uid        [ ultimativ ] name <mail3>
> > ssb   cv25519 2020-11-18 [E] [verf?llt: 2026-12-31]
> >       97F6060D825C74CA8A7E49CFA0F506A815F9DDAD
> >
> > sec   ed25519 2020-11-18 [SC] [verf?llt: 2026-12-31]
> >       565931F52CE768F643389BABA9CA236BDBEC9779
> > uid        [ ultimativ ] name <mail4>
> > uid        [ ultimativ ] name <mail1>
> > uid        [ ultimativ ] name <mail2>
> > uid        [ ultimativ ] name <mail5>
> > uid        [ ultimativ ] name <mail3>
> >
> [Last "sec" listing repeated two more times]
>
> > sec   brainpoolP512r1 2022-07-13 [SCA] [verf?llt: 2026-12-31]
> >       ACDFB1AF82CF084B948ECB5D27AE2304B4974851
> > uid        [ ultimativ ] name <mail6>
> > uid        [ ultimativ ] name <mail1>
> > uid        [ ultimativ ] name <mail4>
> > uid        [ ultimativ ] name <mail5>
> > uid        [ ultimativ ] name <mail2>
> > uid        [ ultimativ ] name <mail3>
> > ssb   brainpoolP512r1 2022-07-13 [E] [verf?llt: 2026-12-31]
> >       0A5D749D75F3D847CEC42CFF737D00DCF417C669
> >
> > sec   brainpoolP512r1 2022-07-13 [SCA] [verf?llt: 2026-12-31]
> >       ACDFB1AF82CF084B948ECB5D27AE2304B4974851
> > uid        [ ultimativ ] name <mail1>
> > uid        [ ultimativ ] name <mail4>
> > uid        [ ultimativ ] name <mail5>
> > uid        [ ultimativ ] name <mail2>
> > uid        [ ultimativ ] name <mail3>
>
> This looks wrong. Each key should be listed only once.
>
> > The added "mail6" is only seen at two places. Is this ok?
>
> I think that's okay. The other "copies" of your two keys shouldn't even
> exist.
>
> > Or should it show up within every block?
>
> The other "blocks" shouldn't be there in the first place.
>
> > Kleopatra does not show the added "mail6" anywhere. Any ideas?
>
> I suppose you looked in the Certificate Details. My guess is that Kleopatra
> picked up the bogus copies of your keys. You could verify this by looking
> at
> the subkeys for those keys. If only one subkey is listed then Kleopatra
> didn't pick up the correct copy of your key.
>
> > Anything I should do but forgot to do adding a new email address?
>
> What you did looks correct, but your keyring seems to be corrupt. I would
> try
> the following:
> * Make a backup of ~/.gnupg and of everything in this folder.
> * Export the first key (including the secret key) with
> gpg --export-secret-keys 565931F52CE768F643389BABA9CA236BDBEC9779
> >565931F52CE768F643389BABA9CA236BDBEC9779.gpg
> * Delete the first key (including the secret key). This is a destructive
> operation!
> I hope you have created a backup.
> gpg --delete-secret-and-public-keys FINGERPRINT_OF_YOUR_FIRST_KEY
> * List your secret keys to verify that your first key (and all of its bogus
> copies) has been removed from your keyring. Also list the public keys.
> gpg --list-secret-keys 565931F52CE768F643389BABA9CA236BDBEC9779
> and
> gpg --list-keys 565931F52CE768F643389BABA9CA236BDBEC9779
> should both print an error "No secret key" or "No public key".
> * Import the exported key
> gpg --import 565931F52CE768F643389BABA9CA236BDBEC9779.gpg
> * List your secret keys. If everything worked according to my plan you
> should
> now see only one "block" for your first key, i.e. you should see
> > sec   ed25519 2020-11-18 [SC] [verf?llt: 2026-12-31]
> >       565931F52CE768F643389BABA9CA236BDBEC9779
> > uid        [ ultimativ ] name <mail6>
> > uid        [ ultimativ ] name <mail4>
> > uid        [ ultimativ ] name <mail1>
> > uid        [ ultimativ ] name <mail2>
> > uid        [ ultimativ ] name <mail5>
> > uid        [ ultimativ ] name <mail3>
> > ssb   cv25519 2020-11-18 [E] [verf?llt: 2026-12-31]
> >       97F6060D825C74CA8A7E49CFA0F506A815F9DDAD
>

This worked:
"gpg --list-secret-keys" after importing the exported keys shows:sec
ed25519 2020-11-18 [SC] [verf?llt: 2026-12-31]
      565931F52CE768F643389BABA9CA236BDBEC9779
uid        [vollst?ndig] name <mail6>
uid        [vollst?ndig] name <mail4>
uid        [vollst?ndig] name <mail1>
uid        [vollst?ndig] name <mail2>
uid        [vollst?ndig] name <mail5>
uid        [vollst?ndig] name <mail3>
ssb   cv25519 2020-11-18 [E] [verf?llt: 2026-12-31]
      97F6060D825C74CA8A7E49CFA0F506A815F9DDAD

sec   brainpoolP512r1 2022-07-13 [SCA] [verf?llt: 2026-12-31]
      ACDFB1AF82CF084B948ECB5D27AE2304B4974851
uid        [ ultimativ ] name <mail6>
uid        [ ultimativ ] name <mail1>
uid        [ ultimativ ] name <mail4>
uid        [ ultimativ ] name <mail5>
uid        [ ultimativ ] name <mail2>
uid        [ ultimativ ] name <mail3>
ssb   brainpoolP512r1 2022-07-13 [E] [verf?llt: 2026-12-31]
      0A5D749D75F3D847CEC42CFF737D00DCF417C669

But now one key is only trusted "vollst?ndig" not "ultimativ".

And since it was asked:
Kleopatra: 3.2.4 (Windows), 5.0.0b103 (Windows), 3.1.4 (Ubuntu 24.04.2)
gpg: 2.2 (Windows), 2.4 (Windows, Ubuntu 24.04.2), 2.5 (Windows, Ubuntu
24.04.2)
libcrypt: 1.11.0 (Windows,Ubuntu 24.04.2)

-- 
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250227/a7ee43e9/attachment-0001.html>

From tschweikle at gmail.com  Thu Feb 27 16:32:29 2025
From: tschweikle at gmail.com (Thomas Schweikle)
Date: Thu, 27 Feb 2025 16:32:29 +0100
Subject: Environment variable GNUPGHOME with Windows + MSYS2
Message-ID: <CA+rGx5eOh+e_WBmsseEEwcpNtg-iy0ybEkyzOCtZFE2PR415pg@mail.gmail.com>

Hi!

Within Windows gnupg uses "%APPDATA%\gnupg" for its keyring and
configurations.
MSYS2 gpg uses "/c/msys/home/%USERNAME%/.gnupg". Now I had the idea to set
GNUPGHOME so both could work with the same directory:

set GNUPGHOME=%APPDATA%\gnupg

This worked for gnupg from the gnupg-package. It worked for Gpg4Win
included gpg as well, but the MSYS included version gave

gpg: keyblock resource
'/c/Users/<user>/AppData/Roaming/gnupg/C:\\Users\\<user>\\AppData\\Roaming\\gnupg/pubring.kbx':
No such file or directory
gpg: Fatal:
/c/Users/<user>/AppData/Roaming/gnupg/C:\\Users\\<user>\\AppData\\Roaming\\gnupg:
directory does not exist!

from an MSYS shell. Any idea how to overcome this problem?

gnupg: 2.2, 2.4, 2.5

-- 
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250227/37d3114d/attachment.html>

From kloecker at kde.org  Thu Feb 27 19:35:08 2025
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Thu, 27 Feb 2025 19:35:08 +0100
Subject: Problem with adding a name to a key
In-Reply-To: <CA+rGx5fhbay4Gt1=_bsv5O3Op7id9vX+-0j0rN9y2maeqtVdJg@mail.gmail.com>
References: <CA+rGx5fSN_qAvsUNKCtDVkUVJ0d=4kdOFGZ1=PRNoWgLWt723g@mail.gmail.com>
 <2100232.YKUYFuaPT4@daneel>
 <CA+rGx5fhbay4Gt1=_bsv5O3Op7id9vX+-0j0rN9y2maeqtVdJg@mail.gmail.com>
Message-ID: <2861679.DJkKcVGEfx@daneel>

On Donnerstag, 27. Februar 2025 15:18:17 Mitteleurop?ische Normalzeit Thomas 
Schweikle via Gnupg-users wrote:
> On Thu, Feb 27, 2025 at 12:29?PM Ingo Kl?cker <kloecker at kde.org> wrote:
> > What you did looks correct, but your keyring seems to be corrupt. I would
> > try
> > the following:
> > * Make a backup of ~/.gnupg and of everything in this folder.
> > * Export the first key (including the secret key) with
> > gpg --export-secret-keys 565931F52CE768F643389BABA9CA236BDBEC9779
> > >565931F52CE768F643389BABA9CA236BDBEC9779.gpg
> > 
> > * Delete the first key (including the secret key). This is a destructive
> > operation!
> > I hope you have created a backup.
> > gpg --delete-secret-and-public-keys FINGERPRINT_OF_YOUR_FIRST_KEY
> > * List your secret keys to verify that your first key (and all of its
> > bogus
> > copies) has been removed from your keyring. Also list the public keys.
> > gpg --list-secret-keys 565931F52CE768F643389BABA9CA236BDBEC9779
> > and
> > gpg --list-keys 565931F52CE768F643389BABA9CA236BDBEC9779
> > should both print an error "No secret key" or "No public key".
> > * Import the exported key
> > gpg --import 565931F52CE768F643389BABA9CA236BDBEC9779.gpg
> > * List your secret keys. If everything worked according to my plan you
> > should
> > now see only one "block" for your first key, i.e. you should see
> > 
> > > sec   ed25519 2020-11-18 [SC] [verf?llt: 2026-12-31]
> > > 
> > >       565931F52CE768F643389BABA9CA236BDBEC9779
> > > 
> > > uid        [ ultimativ ] name <mail6>
> > > uid        [ ultimativ ] name <mail4>
> > > uid        [ ultimativ ] name <mail1>
> > > uid        [ ultimativ ] name <mail2>
> > > uid        [ ultimativ ] name <mail5>
> > > uid        [ ultimativ ] name <mail3>
> > > ssb   cv25519 2020-11-18 [E] [verf?llt: 2026-12-31]
> > > 
> > >       97F6060D825C74CA8A7E49CFA0F506A815F9DDAD
> 
> This worked:
> "gpg --list-secret-keys" after importing the exported keys shows:sec
> ed25519 2020-11-18 [SC] [verf?llt: 2026-12-31]
>       565931F52CE768F643389BABA9CA236BDBEC9779
> uid        [vollst?ndig] name <mail6>
> uid        [vollst?ndig] name <mail4>
> uid        [vollst?ndig] name <mail1>
> uid        [vollst?ndig] name <mail2>
> uid        [vollst?ndig] name <mail5>
> uid        [vollst?ndig] name <mail3>
> ssb   cv25519 2020-11-18 [E] [verf?llt: 2026-12-31]
>       97F6060D825C74CA8A7E49CFA0F506A815F9DDAD
> 
> sec   brainpoolP512r1 2022-07-13 [SCA] [verf?llt: 2026-12-31]
>       ACDFB1AF82CF084B948ECB5D27AE2304B4974851
> uid        [ ultimativ ] name <mail6>
> uid        [ ultimativ ] name <mail1>
> uid        [ ultimativ ] name <mail4>
> uid        [ ultimativ ] name <mail5>
> uid        [ ultimativ ] name <mail2>
> uid        [ ultimativ ] name <mail3>
> ssb   brainpoolP512r1 2022-07-13 [E] [verf?llt: 2026-12-31]
>       0A5D749D75F3D847CEC42CFF737D00DCF417C669
> 
> But now one key is only trusted "vollst?ndig" not "ultimativ".

To make your own keys trusted "ultimate" after import you have to set the 
ownertrust to ultimate. You can do this with the "trust" command of `gpg --
edit-key 565931F52CE768F643389BABA9CA236BDBEC9779`.

I assume that Kleopatra now shows the new name. Correct?

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/20250227/5ebeaf1e/attachment.sig>

From kloecker at kde.org  Thu Feb 27 19:41:58 2025
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Thu, 27 Feb 2025 19:41:58 +0100
Subject: Environment variable GNUPGHOME with Windows + MSYS2
In-Reply-To: <CA+rGx5eOh+e_WBmsseEEwcpNtg-iy0ybEkyzOCtZFE2PR415pg@mail.gmail.com>
References: <CA+rGx5eOh+e_WBmsseEEwcpNtg-iy0ybEkyzOCtZFE2PR415pg@mail.gmail.com>
Message-ID: <3538898.sQuhbGJ8Bu@daneel>

On Donnerstag, 27. Februar 2025 16:32:29 Mitteleurop?ische Normalzeit Thomas 
Schweikle via Gnupg-users wrote:
> Hi!
> 
> Within Windows gnupg uses "%APPDATA%\gnupg" for its keyring and
> configurations.
> MSYS2 gpg uses "/c/msys/home/%USERNAME%/.gnupg". Now I had the idea to set
> GNUPGHOME so both could work with the same directory:
> 
> set GNUPGHOME=%APPDATA%\gnupg
> 
> This worked for gnupg from the gnupg-package. It worked for Gpg4Win
> included gpg as well, but the MSYS included version gave
> 
> gpg: keyblock resource
> '/c/Users/<user>/AppData/Roaming/gnupg/C:\\Users\\<user>\\AppData\\Roaming\\
> gnupg/pubring.kbx': No such file or directory
> gpg: Fatal:
> /c/Users/<user>/AppData/Roaming/gnupg/C:\\Users\\<user>\\AppData\\Roaming\\g
> nupg: directory does not exist!
> 
> from an MSYS shell. Any idea how to overcome this problem?

I doubt that it helps but try
set GNUPGHOME=%APPDATA%/gnupg
i.e with a forward slash instead of a backslash. Or try
set GNUPGHOME=C:/Users/<user>/AppData/Roaming/gnupg

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/20250227/8d58233d/attachment.sig>

From ThSchweikle at bfs.de  Fri Feb 28 09:59:20 2025
From: ThSchweikle at bfs.de (Thomas Schweikle)
Date: Fri, 28 Feb 2025 08:59:20 +0000
Subject: Environment variable GNUPGHOME with Windows + MSYS2
In-Reply-To: <3538898.sQuhbGJ8Bu@daneel>
References: <CA+rGx5eOh+e_WBmsseEEwcpNtg-iy0ybEkyzOCtZFE2PR415pg@mail.gmail.com>
 <3538898.sQuhbGJ8Bu@daneel>
Message-ID: <ba3ebaba-a8a8-4d3e-ad7a-fd58d73b3998@bfs.de>

Am 27.02.2025 um 19:41 schrieb Ingo Kl?cker:
> On Donnerstag, 27. Februar 2025 16:32:29 Mitteleurop?ische Normalzeit Thomas
> Schweikle via Gnupg-users wrote:
>> Hi!
>>
>> Within Windows gnupg uses "%APPDATA%\gnupg" for its keyring and
>> configurations.
>> MSYS2 gpg uses "/c/msys/home/%USERNAME%/.gnupg". Now I had the idea to set
>> GNUPGHOME so both could work with the same directory:
>>
>> set GNUPGHOME=%APPDATA%\gnupg
>>
>> This worked for gnupg from the gnupg-package. It worked for Gpg4Win
>> included gpg as well, but the MSYS included version gave
>>
>> gpg: keyblock resource
>> '/c/Users/<user>/AppData/Roaming/gnupg/C:\\Users\\<user>\\AppData\\Roaming\\
>> gnupg/pubring.kbx': No such file or directory
>> gpg: Fatal:
>> /c/Users/<user>/AppData/Roaming/gnupg/C:\\Users\\<user>\\AppData\\Roaming\\g
>> nupg: directory does not exist!
>>
>> from an MSYS shell. Any idea how to overcome this problem?
> 
> I doubt that it helps but try
> set GNUPGHOME=%APPDATA%/gnupg
> i.e with a forward slash instead of a backslash. Or try
> set GNUPGHOME=C:/Users/<user>/AppData/Roaming/gnupg

Your doupts where correct it just lead to paths like:
C:\\Users\\<user>\\AppData\\Roaming\\/gnupg

The only way was to redefine the variable for MSYS -- but then:
$ set GNUPGHOME=%APPDATA%\gnupg
2025-02-28 09:34:27 gpg[9252] enabled debug flags: memstat
2025-02-28 09:34:27 gpg[9252] enabled compatibility flags:
2025-02-28 09:34:27 gpg[9252] verwende Vertrauensmodell pgp
[...]
2025-02-28 09:34:28 gpg[9252] keydb: handles=1 locks=0 parse=0 get=692
2025-02-28 09:34:28 gpg[9252]        build=0 update=0 insert=0 delete=0
2025-02-28 09:34:28 gpg[9252]        reset=1 found=692 not=1 cache=0 not=0
2025-02-28 09:34:28 gpg[9252] kid_not_found_cache: count=0 peak=0 flushes=0
2025-02-28 09:34:28 gpg[9252] sig_cache: total=47 cached=47 good=47 bad=0
2025-02-28 09:34:28 gpg[9252] objcache: keys=0/0/0 chains=0,0..0 
buckets=0/0 attic=0
2025-02-28 09:34:28 gpg[9252] objcache: uids=0/0/0 chains=0,0..0 buckets=0/0
2025-02-28 09:34:28 gpg[9252] random usage: poolsize=600 mixed=0 
polls=0/0 added=0/0
               outmix=0 getlvl1=0/0 getlvl2=0/0
2025-02-28 09:34:28 gpg[9252] rndjent stat: collector=0x0000000000000000 
calls=0 bytes=0
2025-02-28 09:34:28 gpg[9252] secmem usage: 0/32768 bytes in 0 blocks

And within MSYS (bash):
$ export GNUPGHOME=/c/Users/<user>/AppData/Roaming/gnupg
$ gpg --debug-all --list-secret-keys
gpg: reading options from '/c/Users/<user>/AppData/Roaming/gnupg/gpg.conf'
gpg: reading options from '[cmdline]'
2025-02-28 09:47:28 gpg[464] enabled debug flags: memstat
2025-02-28 09:47:28 gpg[464] enabled compatibility flags:
2025-02-28 09:47:28 gpg[464] using pgp trust model
2025-02-28 09:47:28 gpg[464] no running gpg-agent - starting 
'/usr/bin/gpg-agent'
2025-02-28 09:47:28 gpg[464] invalid size of lockfile 
'/c/Users/<user>/AppData/Roaming/gnupg/gnupg_spawn_agent_sentinel.lock'
2025-02-28 09:47:28 gpg[464] cannot read lockfile
[...]
2025-02-28 09:47:34 gpg[464] can't connect to the gpg-agent: Invalid 
argument
2025-02-28 09:47:34 gpg[464] keydb: handles=1 locks=0 parse=0 get=692
2025-02-28 09:47:34 gpg[464]        build=0 update=0 insert=0 delete=0
2025-02-28 09:47:34 gpg[464]        reset=1 found=692 not=1 cache=0 not=0
2025-02-28 09:47:34 gpg[464] kid_not_found_cache: count=0 peak=0 flushes=0
2025-02-28 09:47:34 gpg[464] sig_cache: total=0 cached=0 good=0 bad=0
2025-02-28 09:47:34 gpg[464] objcache: keys=0/0/0 chains=0,0..0 
buckets=0/0 attic=0
2025-02-28 09:47:34 gpg[464] objcache: uids=0/0/0 chains=0,0..0 buckets=0/0
2025-02-28 09:47:34 gpg[464] random usage: poolsize=600 mixed=0 
polls=0/0 added=0/0
               outmix=0 getlvl1=0/0 getlvl2=0/0
2025-02-28 09:47:34 gpg[464] rndjent stat: collector=0x0000000000000000 
calls=0 bytes=0
2025-02-28 09:47:34 gpg[464] secmem usage: 0/65536 bytes in 0 blocks

Looks like the configuration files have to be different to, to make it 
work. ;-(

MSYS (bash, GNUPGHOME=/c/Users/<user>/AppData/Roaming/gnupg):
$ gpg --version
gpg (GnuPG) 2.4.7
libgcrypt 1.11.0-unknown
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: /c/Users/<user>/AppData/Roaming/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

Windows (cmd.exe, GNUPGHOME=C:\Users\<user>\AppData\Roaming\gnupg):
$ gpg --version
gpg (GnuPG) 2.5.4
libgcrypt 1.11.0
Copyright (C) 2025 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: C:\Users\<user>\AppData\Roaming\gnupg
Unterst?tzte Verfahren:
?ff. Schl?ssel: RSA, Kyber, ELG, DSA, ECDH, ECDSA, EDDSA
Verschl?.: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
            CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Komprimierung: nicht komprimiert, ZIP, ZLIB, BZIP2
-- 
Thomas

From ThSchweikle at bfs.de  Fri Feb 28 09:08:33 2025
From: ThSchweikle at bfs.de (Thomas Schweikle)
Date: Fri, 28 Feb 2025 08:08:33 +0000
Subject: Problem with adding a name to a key
In-Reply-To: <2861679.DJkKcVGEfx@daneel>
References: <CA+rGx5fSN_qAvsUNKCtDVkUVJ0d=4kdOFGZ1=PRNoWgLWt723g@mail.gmail.com>
 <2100232.YKUYFuaPT4@daneel>
 <CA+rGx5fhbay4Gt1=_bsv5O3Op7id9vX+-0j0rN9y2maeqtVdJg@mail.gmail.com>
 <2861679.DJkKcVGEfx@daneel>
Message-ID: <28250558-939f-4080-9796-545dd4e4f905@bfs.de>

Am 27.02.2025 um 19:35 schrieb Ingo Kl?cker:
> To make your own keys trusted "ultimate" after import you have to set the
> ownertrust to ultimate. You can do this with the "trust" command of `gpg --
> edit-key 565931F52CE768F643389BABA9CA236BDBEC9779`.
> 
> I assume that Kleopatra now shows the new name. Correct?

Yes, it does. Solved the problem!
-- 
Thomas