gpg says no user ID

[Thomas George]

I am still trying to do a fully verified installation of debian-11.5.0.

gpg --verify SHA512SUMS.sign SHA512SUMS responded with DF98...BE9B

gpg --recv-keys DF98...BE9B responded key DF98...BE9B: new key but
contains no user ID - skipped.

Another source suggested gpg --key-server keyring.debian.org --recv-keys
long numeric key

but this responded invalid option --key-server

The gpg man page is beyond me, I need help

[Jude DaShiell]

On debian, have you got a gpg2 executable? If so, that executable may be
more current and if so possibly work better.



Jude <jdashiel at panix dot com> "There are four boxes to be used in
defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)

.

[Henning Follmann]

On Mon, Nov 14, 2022 at 05:17:25PM -0500, Thomas George wrote:
> I am still trying to do a fully verified installation of debian-11.5.0.
>
> gpg --verify SHA512SUMS.sign SHA512SUMS responded with DF98...BE9B
>
> gpg --recv-keys DF98...BE9B responded key DF98...BE9B: new key but contains
> no user ID - skipped.
>
> Another source suggested gpg --key-server keyring.debian.org --recv-keys
> long numeric key
>
> but this responded invalid option --key-server
>

sorry that was a typo.
gpg --keyserver keyring.debian.org --recv-keys ...
would be correct.

> The gpg man page is beyond me, I need help
>

Well,
gpg is very complex software now. And the man page tries to be
all-encompassing. So it seems daunting to look at the man pages.
But I still would encourage anybody to use the manpages to better
understand and use their tools.
Which the will also tell you that --keyserver is deprecated (even though it
still should work as intended for your use case). dirmanager these days is
responsible for managing key/certificate dependencies.

Good luck,

-H

--
Henning Follmann | hfol...@itcfollmann.com

[Thomas George]

Close, almost there.  At the end something goes wrong. Here is the output:

gpg2 keyserver keyring.debian.org --recv DF98...BE9B

   gpg: /root/.gnupg/trustdb.gpg: trust.db created

   gpg: key DA87E80D6294BE9B: public key "Debian CD signing  key
<debi...@lists.debian.org>" imported

   gpg: Total number processed: 1

   gpg: Imported: 1

gpg2 --verify SHA512SUMS.sign SHA512SUMS

   gpg: Signature made Sat 10 Oct 07:00:08 PM EDT

..........using RSA key DF9B9C49EAA9298432589D76DA87E80D6294BE9B

   gpg: Good signature from "Debian CD signing key
<debi...@lists.debian.org>" [unknown]

...gpg: WARNING: This key is not certified with a trusted signature!

......There is no indication that the signature belongs to the owner

...Primary key fingerprint: DF9B9C49EAA9298432589D76DA87E80D6294BE9B

gpg2 --verify SHA512SUMS.sign debian-11.5.0-amd64-netinst.iso

...gpg: Signature made Sat 10 Oct 07:00:08  PM EDT

...gpg:              using RSA DF9B9C49EAA9298432589D76DA87E80D6294BE9B

...gpg: BAD signature from "Debian CD signing key
<deba...@lists.debian.org>"  [unknown]

[Jeffrey Walton]

On Tue, Nov 15, 2022 at 12:22 PM Thomas George <debia...@mailfence.com> wrote:
>
> Close, almost there. At the end something goes wrong. Here is the output:
>
> gpg2 keyserver keyring.debian.org --recv DF98...BE9B
>
> gpg: /root/.gnupg/trustdb.gpg: trust.db created
>
> gpg: key DA87E80D6294BE9B: public key "Debian CD signing key
> <debi...@lists.debian.org>" imported
>
> gpg: Total number processed: 1
>
> gpg: Imported: 1
>
> gpg2 --verify SHA512SUMS.sign SHA512SUMS
>
> gpg: Signature made Sat 10 Oct 07:00:08 PM EDT
>
> ..........using RSA key DF9B9C49EAA9298432589D76DA87E80D6294BE9B
>
> gpg: Good signature from "Debian CD signing key
> <debi...@lists.debian.org>" [unknown]
>
> ...gpg: WARNING: This key is not certified with a trusted signature!
>
> ......There is no indication that the signature belongs to the owner
>
> ...Primary key fingerprint: DF9B9C49EAA9298432589D76DA87E80D6294BE9B
>
> gpg2 --verify SHA512SUMS.sign debian-11.5.0-amd64-netinst.iso
>
> ...gpg: Signature made Sat 10 Oct 07:00:08 PM EDT
>
> ...gpg: using RSA DF9B9C49EAA9298432589D76DA87E80D6294BE9B
>
> ...gpg: BAD signature from "Debian CD signing key
> <deba...@lists.debian.org>" [unknown]

It sounds a lot like https://askubuntu.com/q/1110673 and
https://forums.linuxmint.com/viewtopic.php?t=293108 .

Jeff

[Thomas Schmitt]

Hi,

Thomas George wrote:
> gpg2 --verify SHA512SUMS.sign debian-11.5.0-amd64-netinst.iso

> ...gpg: BAD signature from "Debian CD signing key

Consider to re-read my mail of yesterday:
Date: Mon, 14 Nov 2022 09:19:29 +0100
Subject: Re: No Public Key
https://lists.debian.org/debian-user/2022/11/msg00422.html


Have a nice day :)

Thomas

[Jeffrey Walton]

On Tue, Nov 15, 2022 at 1:01 PM DdB
<debia...@potentially-spam.de-bruyn.de> wrote:
> ...
> i just experienced the same problem, same difficulty understanding the
> man pages. Googling suggested to try a different keyserver.
> I had to try several ... until i found one, that succeeded.
> Apparently, the cause was found to be in the rules in place at the
> servers. Some do no longer allow connections from sources without
> self-signed pubkeys.

Yes, the key server pools are a mess. Part of it is because of Europe
and GPPR. And the GnuPG folks have not done a good job updating the
server code to meet the demands of the current landscape. I just shake
my head in disbelief at what things have come to. It makes me want to
unsubscribe from the GnuPG mailing lists...

For example, from "keyserver receive failed: No name - for gpg
--keyserver hkp://pool.sks-keyservers.net,"
https://lists.gnupg.org/pipermail/gnupg-users/2021-June/065261.html:

The keyserver *pools* at sks-keyservers.net are no longer maintained for
legal reasons. sks-keyservers.net was receiving GDPR requests, e.g. for
RTBF [Right to be Forgotten], that it could not satisfy because the pools
had no formal structure that could compel individual operators to comply
with legal requests.

Or, more discussions at
https://www.google.com/search?q=keyserver+gdpr+site:lists.gnupg.org/pipermail/gnupg-users

> But just adding the corresponding switch did not
> help either. i had to find a server with an older config in place (like
> ubuntu's).

It's not you. The whole key server architecture is a mess nowadays.

Jeff

[Thomas Schmitt]

Hi,

Thomas George wrote:
> I am going to erase every thing I have done and start over.

There's no need for starting over. The SHA512SUM file is meanwhile
authenticated by your run of:

> > gpg2 --verify SHA512SUMS.sign SHA512SUMS
> > [...]
> >   gpg: Good signature from "Debian CD signing key <debi...@lists.debian.org>" [unknown]
> > [...]

> > ...gpg: WARNING: This key is not certified with a trusted signature!
> > ......There is no indication that the signature belongs to the owner
> > ...Primary key fingerprint: DF9B9C49EAA9298432589D76DA87E80D6294BE9B

The warning is normal with the Debian keys and can be ignored.

Important is the key fingerprint, which is published on
https://www.debian.org/CD/verify
as
Key fingerprint = DF9B 9C49 EAA9 2984 3258 9D76 DA87 E80D 6294 BE9B

I would leave it to copy+paste and the computer to compare the strings.
Remove the blanks from the published number:

echo "DF9B 9C49 EAA9 2984 3258 9D76 DA87 E80D 6294 BE9B" | sed -e 's/ //g'

which will respond by

DF9B9C49EAA9298432589D76DA87E80D6294BE9B

Copy+paste the result and the string reported by gpg --verify to a
comparison command:

test DF9B9C49EAA9298432589D76DA87E80D6294BE9B = DF9B9C49EAA9298432589D76DA87E80D6294BE9B && echo MATCH

which responds by

MATCH

----------------------------------------------------------------------

So now you only have to verify the SHA512 checksum of the ISO by

sha512sum -c SHA515SUMS

and watching out for the response

debian-11.5.0-amd64-netinst.iso: OK

[john doe]

If you want a more straightforward output:

$ sha512 sum -c SHA512SUMS --strict --ignore-missing

--
John Doe

[Jeffrey Walton]

Hi Thomas,

Here's some feedback while looking at things from 10,000 feet. There
are several problems with processes and documentation.

On Wed, Nov 16, 2022 at 3:14 AM Thomas Schmitt <scdb...@gmx.net> wrote:
>
> Thomas George wrote:
> > I am going to erase every thing I have done and start over.
>
> There's no need for starting over. The SHA512SUM file is meanwhile
> authenticated by your run of:
>
> > > gpg2 --verify SHA512SUMS.sign SHA512SUMS
> > > [...]
> > > gpg: Good signature from "Debian CD signing key <debi...@lists.debian.org>" [unknown]
> > > [...]
> > > ...gpg: WARNING: This key is not certified with a trusted signature!
> > > ......There is no indication that the signature belongs to the owner
> > > ...Primary key fingerprint: DF9B9C49EAA9298432589D76DA87E80D6294BE9B
>
> The warning is normal with the Debian keys and can be ignored.

This is a security usability problem. How is a non-expert to know that
this warning can be ignored, while others must be tended to?

(The answer is, the non-expert does not know. The system needs to be
fixed to accommodate the user. The user should not have to accomodate
the system).

> Important is the key fingerprint, which is published on
> https://www.debian.org/CD/verify

>From the page:

To ensure that the checksums files themselves are correct,
use GnuPG to verify them against the accompanying signature
files (e.g. SHA512SUMS.sign).

The page does not provide a prescriptive recipe on how to do what it
says to do. The documentation should include a prescriptive recipe. A
prescriptive recipe lays out the exact steps a user should perform,
similar to what you're doing in this email.

> Key fingerprint = DF9B 9C49 EAA9 2984 3258 9D76 DA87 E80D 6294 BE9B
>
> I would leave it to copy+paste and the computer to compare the strings.
> Remove the blanks from the published number:
>
> echo "DF9B 9C49 EAA9 2984 3258 9D76 DA87 E80D 6294 BE9B" | sed -e 's/ //g'

Something needs to be fixed here. The user should be able to use that
string as presented. I don't know where the problem lies (GnuPG
maybe?), but whatever verifies the signature should consume that
representation since it is a common representation.

> which will respond by
>
> DF9B9C49EAA9298432589D76DA87E80D6294BE9B
>
> Copy+paste the result and the string reported by gpg --verify to a
> comparison command:
>
> test DF9B9C49EAA9298432589D76DA87E80D6294BE9B = DF9B9C49EAA9298432589D76DA87E80D6294BE9B && echo MATCH
>
> which responds by
>
> MATCH
>
> ----------------------------------------------------------------------
>
> So now you only have to verify the SHA512 checksum of the ISO by
>
> sha512sum -c SHA515SUMS
>
> and watching out for the response
>
> debian-11.5.0-amd64-netinst.iso: OK

One last thought... https://www.debian.org/CD/verify should probably
be moved to the wiki. The page would already be updated if the world
could edit it. (I can say that as a fact since I would have already
modified it). As a static web page, it is bit-rotting because only the
Debian webmaster can edit it.

Jeff

[Thomas Schmitt]

Hi,

the program gpg writes about the Debian CD signing key DA87E80D6294BE9B :

> > > WARNING: This key is not certified with a trusted signature!

> > > There is no indication that the signature belongs to the owner

I wrote:
> > This is a security usability problem. How is a non-expert to know that
> > this warning can be ignored, while others must be tended to?

Jeffrey Walton wrote:
> This is a security usability problem. How is a non-expert to know that
> this warning can be ignored, while others must be tended to?

Yep. Didactically is is quite unfortunate.

It would be interesting to learn how to connect the key to a web of trust
which would suppress this warning everywhere.
But reading
https://www.gnupg.org/gph/en/manual/x334.html
"Validating other keys on your public keyring"
https://gnupg.org/download/integrity_check.html
(GnuPG's own download integrity check presciptions)
i get the impression that there is no global web of trust to attach to.

> The answer is, the non-expert does not know.

Nearly nobody can judge how safe a gpg signature is. The algorithms are
complicated and the interface towards human users invites for mistakes
and misunderstandings.


> > https://www.debian.org/CD/verify

> The page does not provide a prescriptive recipe on how to do what it
> says to do.

In general one cannot give such a receipe without knowing the system
on which the verification shall happen.
But i agree that a tangible example for an existing Debian old-stable
system could help even those who use something else.

> > Key fingerprint = DF9B 9C49 EAA9 2984 3258 9D76 DA87 E80D 6294 BE9B

> > echo "DF9B 9C49 EAA9 2984 3258 9D76 DA87 E80D 6294 BE9B" | sed -e 's/ //g'

> Something needs to be fixed here.

I meanwhile get the impression that this is not needed in real life, because
my local gpg states the fingerprint with the same blanks as on the Debian web
page:

Primary key fingerprint: DF9B 9C49 EAA9 2984 3258 9D76 DA87 E80D 6294 BE9B

So i assume that Thomas George's reported line

...Primary key fingerprint: DF9B9C49EAA9298432589D76DA87E80D6294BE9B

fell victim to editing or mail client.

(But we see how difficult it is to give a general description of the
procedure.)

> One last thought... https://www.debian.org/CD/verify should probably
> be moved to the wiki.

That would probably not be a good idea.
The page offers the official keys for download and states their official key
fingerprints. Such a page should be editable only by the most authorized
people.

But www.debian.org/CD/verify could point to a public wiki where users
show their favorite ways to do the verification.
Such a wiki would of course need to be constantly observed by users who
dispute and remove any attempt of deception.

[Thomas Schmitt]

Hi,

i managed to produce a rare self-misattribution by copy+paste:

-------------------------------------------------------------------------

the program gpg writes about the Debian CD signing key DA87E80D6294BE9B :
> > > WARNING: This key is not certified with a trusted signature!
> > > There is no indication that the signature belongs to the owner

I wrote:
> > This is a security usability problem. How is a non-expert to know that
> > this warning can be ignored, while others must be tended to?

Jeffrey Walton wrote:
> This is a security usability problem. How is a non-expert to know that
> this warning can be ignored, while others must be tended to?

-------------------------------------------------------------------------

My part should of course have been different from Jeffrey Walton's:

I wrote:
> > The warning is normal with the Debian keys and can be ignored.

[Thomas George]

I am giving up and will proceed with the netinst. Thanks everyone for
the many helpful comments and recommendations.

I stripped the spaces from the fingerprint and equated it RSA key. They
matched. So every thing is correct until the last step

Dragonette:/home/tom/Downloads/debian# gpg2 --verify SHA512SUMS.sign.txt
debian-11.5.0-amd64-netinst.iso
gpg: Signature made Sat 10 Sep 2022 07:00:08 PM EDT
gpg:                using RSA key DF9B9C49EAA9298432589D76DA87E80D6294BE9B
gpg: BAD signature from "Debian CD signing key
<debi...@lists.debian.org>" [unknown]

Note: I used SHA512SUMS.sign.txt and SHA512SUMS.txt in all the previous
successful verifications as that it is the way they were downloaded from
the Debian site.

Tom George

[Jude DaShiell]

Good to let users of gpg know credentials have no web of trust so
verification of credentials will remain limited until further public and
official notice. Public and official notice ought to include an
announcement email to all debian email lists in the event these
credentials are ever added to a web of trust.

[Eduardo M KALINOWSKI]

On 16/11/2022 13:55, Thomas George wrote:
> I am giving up and will proceed with the netinst. Thanks everyone for
> the many helpful comments and recommendations.
>
> I stripped the spaces from the fingerprint and equated it RSA key. They
> matched. So every thing is correct until the last step
>
> Dragonette:/home/tom/Downloads/debian# gpg2 --verify SHA512SUMS.sign.txt
> debian-11.5.0-amd64-netinst.iso
> gpg: Signature made Sat 10 Sep 2022 07:00:08 PM EDT
> gpg:                using RSA key DF9B9C49EAA9298432589D76DA87E80D6294BE9B
> gpg: BAD signature from "Debian CD signing key
> <debi...@lists.debian.org>" [unknown]

That will never work: you're attempting to verify that the ISO file is
signed with the signature in SHA512SUMS.sign.txt. It will never match.

There is no signature for the ISO file. Instead, it's sha512sum is
listed in SHA512SUMS, and that file is signed.

First, verify that the hash matches:

$ sha512sum -c SHA512SUMS

And then verify that the hash file is properly signed:

$ gpg2 --verify SHA512SUMS.sign SHA512SUMS

Actually, the order does not matter.


--
When in doubt, mumble; when in trouble, delegate; when in charge, ponder.
-- James H. Boren

Eduardo M KALINOWSKI
edu...@kalinowski.com.br