[conspire] People suck at key management (was: Siduction ... trust path to ISOs?)

[Rick Moen]

As part of followup, I checked gpg-signing and key trust path for all
current ISOs in CABAL's collection.  Here's my current catalogue, as
summarised in README.txt:

---<begin>---

Maximum file size on FAT32 is 4,294,967,295 bytes.

Collection:

antiX 17,3.1:  i386, amd64:  full.  Credentials demo, demo  root, root.
Blue Collar Linux initial release:  Probably amd64.  Credentials liveuser, liveuser.  No gpg verification.
Bodhi Linux 5.0.0:  amd64.  No gpg verification.
CentOS 7.6.1810:  amd64:  Minimal, netinstall.
Debian-unofficial-with-nonfree-firmware 9.8.0 'stretch':  i386, amd64:  GNOME DVD, netinst,  LXDE live, XFCE live.
Devuan ascii 2.0.0:  amd64:  DVD, netinst.
Fedora 29:  amd64:  Workstation Live, Workstation netinst, Server, Server netinst.
GParted Live 0.33.0-1:  amd64
Kubuntu 18.04.2 LTS 'Bionic Beaver':  i386, amd64:  Desktop.
Linux Mint 19.1 'Tessa':  amd64:  XFCE, Cinnamon
Lubuntu (w/LXQt) 18.10 'Cosmic Cuttlefish':  i386, amd64
Lubuntu (w/LXDE) 18.04.2 LTS 'Bionic Beaver':  i386, amd64:  Desktop
Lubuntu (w/LXDE) 10.04 LTS 'Bionic Beaver':  i386, amd64:  Alternate
Manjaro 18.0.3 Stable:  amd64:  XFCE
MX Linux 18.1:  i386, amd64:  XFCE.  Credentials demo, demo  root, root
Refracta 9 20190206-1724:  i386, amd64:  XFCE.  Credentials root, root  user, user
Siduction 18.0.3 201805132142 'patience':  amd64:  LXQt.  No gpg verification.
SystemRescueCd 6.0.0:  amd64.  No gpg verification.
SystemRescueCd 5.3.2:  i386.  No gpg verification.
Ubuntu 18.04.2 LTS 'Bionic Beaver':  amd64:  GNOME Desktop, Live Server
Ubuntu 18.10 'Cosmic Cuttlefish':  amd64:  GNOME Desktop, Live Server
Xubuntu 18.04.2 LTS 'Bionic Beaver':  i386, amd64:  Desktop

---<end>---

Note tag 'no gpg verification' on Blue Collar Linux, Bodhi Linux,  
Siduction, and SystemRecueCd.  Tsk-tsk!  They're either not trying, or,
as with Siduction, appear to lately have a broken signing process.

For all others, I cryptographically verified checksums, and documented
the exact steps required for each, in an accompanying *.verification
file.  This seemed worthwhile because there's a _lot_ of variation.
Which is part of my point.  Another I'll get to later is problems in the
verification scheme.

(Notice the bit about 'Credentials' for some?  Those are live distros
where you'll need to know their burned-in username/passwords to use them
at all.)




Problem:  No Standard Verification Method
-----------------------------------------

(a) Sometimes the developer gpg signs the ISO directly.
(b) Sometimes there's a separate .sig file with the gpg signature 
    for an SHA256 file.
(c) Sometimes the gpg signature wraps around an included copy of 
    the sha256sum lines for the ISOs (within a single file).
(d) Sometimes the gpg information is binary; other times, it's
    ASCII-armoured.
(e) Some projects document the gpg-verification procedure on or
    near the download page.  Most do not.
(f) In a few cases, verification fails unless the ISO and SHA256SUMS
    files still have the filenames listed for downloading.

The latter point is particularly annoying for me, because I enforce a
uniform filename scheme:  $DISTRO-$VERSION-$ARCH-$FLAVOUR in all
lowercase.  I like to be able to easy spot what I want in a long list,
and to not have AntiX*, Fedora-Workstation*, etc. sort to top in 'ls -l'
output, just because of capital letters.  (Yes, I know I could adjustset
shell variables to compensate, but would rather not.)  For uniformity, I
use hyphen delimiters between those fields -- not periods, not underscores.

Here's one small example, 'mx-linux-18.1-i386.verification':

---<begin>---

# Source: http://mirror.math.princeton.edu/pub/mxlinux-iso/MX/Final/MX-18.1/

$ mv mx-linux-18.1-i386.sha256.original MX-18.1_386.iso.sig
$ ln -s mx-linux-18.1-i386.iso MX-18.1_386.iso

$ gpg --keyserver hkp://keys.gnupg.net --recv-keys B9B6375C 0679EE98 892C32F1
gpg: key 13C74A22892C32F1: public key "Steven Pusser <stevep at mxlinux.org>" imported
gpg: key 70938C780679EE98: public key "Adrian <adrian at mxlinux.org>" imported
gpg: key 9B68A1E8B9B6375C: "Dolphin Oracle (mxlinux) <dolphinoracle at gmail.com>" not changed
gpg: Total number processed: 3
gpg:               imported: 2
gpg:              unchanged: 1

$ gpg --verify MX-18.1_386.iso.sig
gpg: assuming signed data in 'MX-18.1_386.iso'
gpg: Signature made Sat Feb  9 06:10:28 2019 PST
gpg:                using RSA key F62EDEAA3AE70A9C99DAC4189B68A1E8B9B6375C
gpg: Good signature from "Dolphin Oracle (mxlinux) <dolphinoracle at gmail.com>" [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: F62E DEAA 3AE7 0A9C 99DA  C418 9B68 A1E8 B9B6 375C

$ mv MX-18.1_386.iso.sig mx-linux-18.1-i386.sha256.original
$ unlink MX-18.1_386.iso
$ 

---<end>---

Contains:
o  Files' origin.
o  Checksum verification.
o  Authenticity verification or lack thereof.
 

The filename shuffling is because 'gpg --verify' fails in this case
unless the signature and ISO files still have the release filenames,
instead of filenames I prefer.


I'll skip more *.verification examples to save length, but suffice to
say the methods required are diverse, and usually the distro documents
this _poorly_ if at all.


Problem:  ISO Verification Is Close to a Sham
---------------------------------------------

Validating a checksum file (or in some cases a signed ISO) requires
knowing the developer's public key -- as with Steve and Adrian for 
MX Linux, above.  And how do I know what keys are theirs?  Ah, that's
the problem.

In the case of MX Linux, I looked on their wiki:
https://mxlinux.org/wiki/system/signed-iso-files .  (Does the download
page tell you to look there?  Hell no.   I found that wiki page after 
some determined searching.)  It says ask a public keyserver for a
certain key identity, and that will get you 'dolphin_oracle's key for
the official releases, Adrian's key for the monthly updates, and Stevo's
for the KDE and core remasters.'  Okie-doke.  But how do I know that
Moriarty the Napoleon of Crime hasn't put false tips on that wiki?  
Maybe what the keyserver is going to send me is the key of Someone Who's
Not an MX Linux Developer, but Hopes I Believe Otherwise.

So, I don't know that it's the genuine key, so I don't know these are
genuine SHA256SUMs or genuine ISOs, either.  At best, I know only
that it's signed by a key that seems plausible, has been around
unchanged for a while, and has been in my keyring for a while.

Doing better would involve establishing web of trust connections, as for
example exist among all Debian developers, but in the general case and
for practically all ISO verification, this is missing.


Short of attending keysigning events with all of these distro people,
AFAIK this as as well as one can do, and my point is that it kind of
sucks.


Current ISOs:

Liten-Datamaskin:isos rick$ ls -lh *.iso | awk '{ print $5 "  " $9 }'
952M  antix-17.3.1-amd64-full.iso
987M  antix-17.3.1-i386-full.iso
2.7G  blue-collar-linux-initial-release.iso
706M  bodhi-linux-5.0.0-amd64.iso
918M  centos-7-1810-amd64-minimal.iso
507M  centos-7-1810-amd64-netinstall.iso
2.2G  debian-live-9.8.0-lxde+nonfree-amd64.iso
2.2G  debian-live-9.8.0-lxde+nonfree-i386.iso
2.2G  debian-live-9.8.0-xfce+nonfree-amd64.iso
2.2G  debian-live-9.8.0-xfce+nonfree-i386.iso
3.4G  debian-unofficial-with-nonfree-firmware-9.8.0-amd64-gnome-dvd1.iso
327M  debian-unofficial-with-nonfree-firmware-9.8.0-amd64-netinst.iso
3.5G  debian-unofficial-with-nonfree-firmware-9.8.0-i386-gnome-dvd1.iso
413M  debian-unofficial-with-nonfree-firmware-9.8.0-i386-netinst.iso
647M  devuan-2.0.0-ascii-amd64-cd1.iso
298M  devuan-2.0.0-ascii-amd64-netinst.iso
2.9G  fedora-server-29-1.2-amd64-dvd.iso
593M  fedora-server-29-1.2-amd64-netinst.iso
1.8G  fedora-workstation-29-1.2-amd64-livedvd.iso
593M  fedora-workstation-29-1.2-amd64-netinst.iso
318M  gparted-live-0.33.0-1-amd64.iso
1.8G  kubuntu-18.04.2-lts-desktop-amd64.iso
1.8G  kubuntu-18.04.2-lts-desktop-i386.iso
1.8G  linuxmint-cinnamon-19.1-amd64.iso
1.8G  linuxmint-xfce-19.1-amd64.iso
717M  lubuntu-18.04-lts-alternate-amd64.iso
715M  lubuntu-18.04-lts-alternate-i386.iso
1.1G  lubuntu-18.04.2-lts-desktop-amd64.iso
1.1G  lubuntu-18.04.2-lts-desktop-i386.iso
1.6G  lubuntu-18.10-lts-desktop-amd64.iso
1.6G  lubuntu-18.10-lts-desktop-i386.iso
1.9G  manjaro-18.0.3-stable-xfce-amd64.iso
1.3G  mx-linux-18.1-amd64.iso
1.4G  mx-linux-18.1-i386.iso
708M  refracta9-20190206-1724-xfce-amd64.iso
717M  refracta9-20190206-1724-xfce-i386.iso
1.7G  siduction-18.3.0-201805132142-patience-lxqt-amd64.iso
559M  systemrescuecd-5.3.2-i386.iso
888M  systemrescuecd-6.0.0-amd64.iso
1.9G  ubuntu-18.04.2-lts-desktop-amd64.iso
834M  ubuntu-18.04.2-lts-live-server-amd64.iso
1.9G  ubuntu-18.10-desktop-amd64.iso
881M  ubuntu-18.10-live-server-amd64.iso
1.4G  xubuntu-18.04.2-lts-i386.iso
1.4G  xubuntu-18.04.2-lts.amd64.iso
1.4G  xubuntu-18.10-amd64.iso
1.4G  xubuntu-18.10-i386.iso
Liten-Datamaskin:isos rick$