How do I verify https://files.devuan.org/devuan-devs.gpg

Question

I am running Devuan Jessie. I want to install another Devuan Ascii from scratch. So I downloaded:

• https://files.devuan.org/devuan_ascii/installer-iso/devuan_ascii_2.0.0_amd64_netinst.iso
• https://files.devuan.org/devuan_ascii/installer-iso/SHA256SUMS
• https://files.devuan.org/devuan_ascii/installer-iso/SHA256SUMS.asc
• https://files.devuan.org/devuan_ascii/devuan-devs.gpg
  • Update: it is now available at https://files.devuan.org/devuan-devs.gpg

But I found no way to authenticate devuan-devs.gpg.

Other distros like Debian or Ubuntu or similar allow me to verify the ISO from an existing previous version.

But for Devuan, I did not find any way:

tino@ts:~/ISO/devuan_ascii-2.0.0$ gpg --verify SHA256SUMS.asc
gpg: assuming signed data in `SHA256SUMS'
gpg: Signature made Wed 06 Jun 2018 08:55:55 PM CEST using DSA key ID 0B5F062F
gpg: Can't check signature: public key not found
tino@ts:~/ISO/devuan_ascii-2.0.0$ gpg --no-default-keyring --keyring /usr/share/keyrings/devuan-archive-keyring.gpg --verify SHA256SUMS.asc
gpg: assuming signed data in `SHA256SUMS'
gpg: Signature made Wed 06 Jun 2018 08:55:55 PM CEST using DSA key ID 0B5F062F
gpg: Can't check signature: public key not found
tino@ts:~/ISO/devuan_ascii-2.0.0$ gpg --no-default-keyring --keyring /usr/share/keyrings/devuan-keyring.gpg --verify SHA256SUMS.asc
gpg: assuming signed data in `SHA256SUMS'
gpg: Signature made Wed 06 Jun 2018 08:55:55 PM CEST using DSA key ID 0B5F062F
gpg: Can't check signature: public key not found

tino@ts:~/ISO/devuan_ascii-2.0.0$ gpg --keyring ../devuan-devs.gpg --verify SHA256SUMS.asc
gpg: assuming signed data in `SHA256SUMS'
gpg: Signature made Wed 06 Jun 2018 08:55:55 PM CEST using DSA key ID 0B5F062F
gpg: Good signature from "Vincenzo (KatolaZ) Nicosia <[email protected]>"
gpg:                 aka "Vincenzo Nicosia (KatolaZ) <[email protected]>"
gpg:                 aka "Vincenzo Nicosia (KatolaZ) <[email protected]>"
gpg:                 aka "KatolaZ <[email protected]>"
gpg:                 aka "Enzo Nicosia <[email protected]>"
gpg:                 aka "Enzo Nicosia -- KatolaZ <[email protected]>"
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: 8E59 D6AA 445E FDB4 A153  3D5A 5F20 B3AE 0B5F 062F

As the "key is not certified", there is no indication that the key is not fake. How can this broken trust chain be fixed?

https://devuan.org/os/documentation/dev1fanboy/general-information does not solve this riddle either.

Notes:

devuan-devs.gpg probably is not fake. However this assumption does not help. There must be some way to ensure, it is not fake. The initial Hen-Egg problem is already solved, as Devuan (Jessie) already runs at my side.

There certainly is some better way to authenticate Ascii's ISO than to upgrade Jessie to Ascii. Right?

Answer 1

For the benefit of the reader, I found a small piece of help. It's not much, but it is a small step. (For now I leave the accepted answer as-is, it is still the best answer.)

Here is the output of the "old" key from Devuan:

$ gpg devuan-devs.gpg | head -3
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
pub   rsa4096 2015-11-20 [SC] [expired: 2018-11-20]
      102EFE3BBA4B2E45EBD56C7A27B9FAA4EBAA93A1
uid           Daniel Lambert Reurich <[email protected]>

Here is the output of the "new" key from Devuan:

$ gpg devuan-devs.gpg.1 | head -3
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
pub   rsa4096 2015-11-20 [SC] [expires: 2021-02-24]
      102EFE3BBA4B2E45EBD56C7A27B9FAA4EBAA93A1
uid           Daniel Lambert Reurich <[email protected]>

devuan-devs.gpg.1 is from https://files.devuan.org/devuan-devs.gpg

You can spot two things:

1. The expiration date was updated
2. The key's fingerprint did not change: 102EFE3BBA4B2E45EBD56C7A27B9FAA4EBAA93A1

Hence if you find some old key which you trust, you can check, if the new key is based on the old one, such that you can trust the new one, too. (Well, it's very unlikely somebody hacked the private key, was able to compromize Devuan to upload a fake update on the public key and nobody ever detects this.)

• I did not find a way to automate such an update properly and easily with security in mind, sorry. So all we have is only this very cumbersome and extremely error-prone (humans are not good in checking two long hex strings are really identical) manual way.

• I did not find a way to get rid of the gpg: WARNING: (except ignoring it with 2>/dev/null, but ignoring STDERR is probably the most stupid thing you can do when you want to do things right).

Now that we are convinced enough that the new key is not worse than the old one, we can do:

mv devuan-devs.gpg.1 devuan-devs.gpg

Of course we can create some script which then uses some very crude heuristics in interpreting the gpg output, to update an old key with the new one. But can we really be sure that this process was correct indeed and that we really cannot be tricked due to some edge cases we forgot to implement?
When it comes to security it is a very bad thing to do something yourself, if this is not based on 100% guarantees. gpg might change the output, or somebody might invent some exploit. Both might trick the script to see some identity where no such exists.
The question was not about being quite sure. We are already quite sure nobody hacked Devuan and hence the key there is authentic, right? But there still is this dirty little piece of uncertainity we want to get rid of. So replacing one uncertainity which we know (we know Devuan could be hacked but others will detect that some day) with some false sense of safety (because our script seems to do the job, so we put trust into something which cannot be proven to be correct as it is based on unverified assumptions) acutally is a step backward in security!
Raising the complexity bar with adding some obscure, unproven and unreliable script does not help in security. Security is something which can be lived and is easy to apply. If it gets too complex, security will fail. Always.

Answer 2

Unfortunately, there doesn’t appear to be a better way to authenticate the images:

• all the files involved are downloaded over the same channel;
• the key used to sign the SHA256SUMS file isn’t available in the previous Devuan release;
• the key, as provided in the keyring, isn’t signed by any other key;
• the key, as published to keyservers, is signed, but it isn’t in the strong set, and none of the signatures come from keys which are in the previous Devuan release’s keyring.

The fact that the same key is available from the keyservers and in the published keyring might be construed as providing more guarantees, but I’m not sure it does since we still don’t know that the owner is a legitimate Devuan release signer.