[sf-lug] (forw) Re: (forw) Re: Something new on Distrowatch and Ubuntu variants.

[Rick Moen]

Quoting Bobbie Sellers (bliss-sf4ever at dslextreme.com):

>     Well when I started downloading iso files and creating installation and
> live boot disks there were no signature availabe.

Bullshit.  I've been checking them for _most_ distros for 30+ years.
Down below, please find a detailed demonstration I did in early 2019
about how to do this checking.  (The four items that say "No gpg
verification" are the subset of the 24 distro ISOs present whose
developers were still at that date not helping user security by
publishing dev signatures for their ISOs.)

>     I never saw signatures for DSL.

Unfortunately, ever since John Andrews started the project in (I think)
2003, DSL has been one of the negligent distros.  I've personally 
never seen a compelling use case for DSL, but, if I wanted to rely on
it, I would get in touch with Adams et al. and ask them to please start
getting serious and signing the checksum files for their ISOs.





Date: Wed, 27 Feb 2019 21:57:26 -0800
From: Rick Moen <rick at linuxmafia.com>
To: conspire at linuxmafia.com
Subject: People suck at key management (was: Siduction ... trust path to ISOs?)

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 i386.  Credentials liveuser, liveuser.  No gpg verification.
Bodhi Linux 5.0.0:  amd64.  No gpg verification.  Credentials bodhi, [NOPW] (has sudo root).
CentOS 7.6.1810:  amd64:  Minimal, netinstall.
Debian-unofficial-with-nonfree-firmware 9.8.0 'stretch':  i386, amd64: GNOME DVD, netinst,
Debian Live:  i386, amd64.  LXDE, XFCE.  Credentials user, live (has sudo root).
Devuan ascii 2.0.0:  amd64:  DVD, netinst.
Fedora 29:  amd64:  Workstation netinst, Server, Server netinst.
Fedora Live 29:  amd64,  Workstation.  Credentials liveuser, [NOPW], root, [NOPW].
GParted Live 0.33.0-1:  amd64.  Credentials user, live (has sudo root).
Kubuntu 18.04.2 LTS 'Bionic Beaver':  i386, amd64:  Desktop.  Credentials ubuntu, [NOPW] (has sudo root).
Linux Mint 19.1 'Tessa':  amd64:  XFCE, Cinnamon.  Credentials mint, [NOPW] (has sudo root).
Lubuntu (w/LXQt) 18.10 'Cosmic Cuttlefish':  i386, amd64.  Credentials lubuntu, [NOPW] (has sudo root).
Lubuntu (w/LXDE) 18.04.2 LTS 'Bionic Beaver':  i386, amd64:  Desktop.  Credentials lubuntu, [NOPW] (has sudo root).
Lubuntu (w/LXDE) 10.04 LTS 'Bionic Beaver':  i386, amd64:  Alternate.
Manjaro 18.0.3 Stable:  amd64:  XFCE.  Credentials manjaro, manjaro (has sudo root).
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.  Credential siducer, live (has sudo root).
SystemRescueCd 6.0.0:  amd64.  No gpg verification.  Credentials root, [NOPW].
SystemRescueCd 5.3.2:  i386.  No gpg verification.  Credentials root, [NOPW].
Ubuntu 18.04.2 LTS 'Bionic Beaver':  amd64:  GNOME Desktop, Live Server.  Credentials ubuntu, [NOPW] (has sudo root).
Ubuntu 18.10 'Cosmic Cuttlefish':  amd64:  GNOME Desktop, Live Server.  Credentials ubuntu, [NOPW] (has sudo root).
Xubuntu 18.04.2 LTS 'Bionic Beaver':  i386, amd64:  Desktop.  Credentials xubuntu, [NOPW] (has sudo root).

---<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$