Thread overview
How to verify DMD download with GPG?
Feb 08, 2022
forkit
Feb 14, 2022
Kagamin
Feb 14, 2022
Era Scarecrow
February 08, 2022

I don't use GPG often, so I probably did something wrong, and failed to get a trusted verification. I do like the idea that a hacker cannot change the signature file if gaining access to the web/file hosts, but how to verify it in secure way?

I did this:

/opt/local/bin/gpg --keyring ./d-keyring.gpg --verify dmd.2.098.1.osx.tar.xz.sig dmd.2.098.1.osx.tar.xz
gpg: Signature made søn 19 des 22:35:47 2021 CET
gpg:                using RSA key 3AAF1A18E61F6FAA3B7193E4DB8C5218B9329CF8
gpg: Good signature from "Martin Nowak <code@dawg.eu>" [unknown]
gpg:                 aka "Martin Nowak <martin.nowak@7learnings.com>" [unknown]
gpg:                 aka "Martin Nowak <martin@dlang.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: F46A 10D0 AB44 C3D1 5DD6  5797 BCDD 73FF C3EB 6146
     Subkey fingerprint: 3AAF 1A18 E61F 6FAA 3B71  93E4 DB8C 5218 B932 9CF8

I also did not find the key listed here:

https://dlang.org/download.html

February 08, 2022
On Tuesday, 8 February 2022 at 10:17:19 UTC, Ola Fosheim Grøstad wrote:
> I don't use GPG often, so I probably did something wrong, and failed to get a trusted verification. I do like the idea that a hacker cannot change the signature file if gaining access to the web/file hosts, but how to verify it in secure way?
> I also did not find the key listed here:
>
> https://dlang.org/download.html

there are two parts to this gpg output:

(1)
"Good signature.." - ok. you can be sure the file is correctly signed.

(2)
"WARNING: This key is not certified with a trusted .." - ok. You have not fully trusted the key, that's fine, and makes sense, since you just downloaded the key, and the key itself might have been tampered with .. in which case you have a good signature from a fraudulent key.

On what basis would you trust the key? Think about it ;-)

btw. the key is listed there - not sure what you mean.

February 08, 2022

On Tuesday, 8 February 2022 at 20:15:50 UTC, forkit wrote:

>

On what basis would you trust the key? Think about it ;-)

Oh well, seems like the keyring has nothing to do with trust. This model with no certification authority is annoying. Now I remember why I never bother with PGP.

February 09, 2022

On Tuesday, 8 February 2022 at 20:15:50 UTC, forkit wrote:

>

btw. the key is listed there - not sure what you mean.

I didn't see "3AAF1A18E61F6FAA3B7193E4DB8C5218B9329CF8" on the listing on the webpage https://dlang.org/gpg_keys.html

That pages is not similar to what I get with "--list-keys --with-subkey-fingerprints".

pub   rsa4096 2014-09-01 [SC] [expired: 2020-03-25]
      AFC7DB45693D62BB472BF27BAB8FE924C2F7E724
uid           [ expired] Martin Nowak (dawg) <me@dawg.eu>
uid           [ expired] Martin Nowak <martin.nowak@plugintheworld.com>
uid           [ expired] Martin Nowak <code@dawg.eu>
uid           [ expired] Martin Nowak <martin@dlang.org>

pub   rsa2048 2016-01-29 [SC]
      BBED1B088CED7F958917FBE85004F0FAD051576D
uid           [ unknown] Vladimir Panteleev <gpg@thecybershadow.net>
sub   rsa2048 2016-01-29 [E]
      AB78BAC596B648B59A41983A3850E93043EBB12C

pub   rsa4096 2015-11-24 [SC] [expires: 2026-03-23]
      8FDB8D357AF468A9428ACE3C2055F76601A36FB0
uid           [ unknown] Sebastian Wilzbach <seb@wilzba.ch>
uid           [ unknown] Sebastian Wilzbach <sebi@wilzbach.me>

pub   rsa4096 2018-03-26 [SC] [expired: 2020-03-25]
      F77158814C19E5E07BA1079A65394AFEF4A68565
uid           [ expired] DLang Nightly (bot) <builder@nightlies.dlang.org>

pub   rsa4096 2020-03-12 [SC] [expires: 2022-03-12]
      F46A10D0AB44C3D15DD65797BCDD73FFC3EB6146
uid           [ unknown] Martin Nowak <code@dawg.eu>
uid           [ unknown] Martin Nowak <martin.nowak@7learnings.com>
uid           [ unknown] Martin Nowak <martin@dlang.org>
sub   rsa4096 2020-03-12 [E] [expires: 2022-03-12]
      B92614C21EC5779DC678468E9A813AD3C11508BC
sub   rsa4096 2020-03-12 [S] [expires: 2022-03-12]
      3AAF1A18E61F6FAA3B7193E4DB8C5218B9329CF8

The last two lines on the webpage are:

sub   rsa4096/0x9A813AD3C11508BC 2020-03-12 [E] [expires: 2022-03-12]
sub   rsa4096/0xDB8C5218B9329CF8 2020-03-12 [S] [expires: 2022-03-12]

That is why I thought something was wrong.

February 14, 2022

3AAF1A18E61F6FAA3B7193E4DB8C5218B9329CF8 is 0xDB8C5218B9329CF8
This shortening was supposed to improve user experience.

February 14, 2022

On Tuesday, 8 February 2022 at 10:17:19 UTC, Ola Fosheim Grøstad wrote:

>

I do like the idea that a hacker cannot change the signature file if gaining access to the web/file hosts, but how to verify it in secure way?

For Linux sources there's MD5 and SHA-1 hashes i believe. If you have two or three hashes for comparison, the likelyhood of someone changing something without those two changing seems VEEEERY low.

February 16, 2022

On Monday, 14 February 2022 at 18:12:25 UTC, Era Scarecrow wrote:

>

For Linux sources there's MD5 and SHA-1 hashes i believe. If you have two or three hashes for comparison, the likelyhood of someone changing something without those two changing seems VEEEERY low.

I usually grab the sources from github, but for binaries I'd like higher resolution SHAs presented on a secured server, different from the one hosting the files. The main concern is that hackers might obtain the access to both the binary and the website that presents the SHA…

PGP is good in theory, but if the keys are presented in a context that isn't secured then what good use it is? There ought to be some central authority for PGP/GPG, it isn't all that difficult to implement either. The central authority could verify the email. Without that SHA is easier to deal with…

February 16, 2022

On Monday, 14 February 2022 at 15:51:59 UTC, Kagamin wrote:

>

3AAF1A18E61F6FAA3B7193E4DB8C5218B9329CF8 is 0xDB8C5218B9329CF8
This shortening was supposed to improve user experience.

Yes, I eventually noticed that the shortened fingerprints were used, but only after posting the OP… It is natural to scan for the start of a string when looking over a larger set to find a match, unless you use GPG more frequently than once every 5 years and remember to look for the tail of the fingerprint…

GPG is a good concept, but the usability lacks that extra polish that could make it attractive to a broader audience. What makes HTTPS so widespread is the usability impact is low once you have a mechanism for distributing the key data for verifying connections. GPG could've done something similar.