[sf-lug] Take 2: Re: A study in trying to verify a signature
Michael Paoli
Michael.Paoli at cal.berkeley.edu
Tue Apr 27 02:19:39 PDT 2021
And ...
Take 2:
or, how to typically establish trust path and validate the date, e.g.
ISO, to for that data for your non-special snowflake distro that can't
be bothered with caring.
So ...
So, ... verifications ... I've got a lot 'o ISO images ...
https://www.wiki.balug.org/wiki/doku.php?id=balug:cds_and_images_etc
Maybe not as extensive a collection as Bobbie Sellers or Rick Moen,
but ... fair number. Let's see, ... have ...
391 distinct ISO files. Most listed at the URL above, but not
all of them, e.g. some not verified, or some not freely redistributable,
etc. But most freely redistributable and verified.
find /var/local/ISOs -type f -exec ls -id \{\} \; 2>>/dev/null
if I separate out the unverified ones ...
12 ... 12 unverified, so ...
(391-12)/391*100
about 96.93% of 'em verified.
For the unverified, by flavor 'n count, we have (some are very old):
2 linuxmint
2 systemrescuecd
1 antiX
1 debian
1 KNOPPIX
1 lxcr
1 siduction
1 SuSE
1 wattOS
1 xenialpup
All the other ISOs verified by some trust path.
Let's see, by count and flavor of the verified, have ...:
204 debian
88 *buntu
20 centos
17 fedora
10 knoppix
8 gentoo
8 solaris
6 finnix
4 linuxmint
2 antix
2 archlinux
2 freebsd
2 suse
1 clonezilla
1 devuan
1 manjaro
1 openbsd
1 sparkylinux
1 tails
So ... most flavors pretty easy to verify.
And many of those I couldn't verify were much older - and in any case,
those that couldn't be verified ... a small percentage.
Let's try a random current of the flavors I was able to verify ...
set -- debian \*buntu centos fedora knoppix gentoo solaris finnix \
linuxmint antix archlinux freebsd suse clonezilla devuan
manjaro openbsd sparkylinux tails
(for r in "$@"; do echo "$r"; done) | sort -R | head -n 1
tails
And we randomly selected tails.
Let's look for current tails ...
https://tails.boum.org/
Get Tails
Download only
ISO image ... DVDs or for virtual machine
we randomly select
echo -e 'DVD\nfor VM' | sort -R | head -n 1
DVD
https://tails.boum.org/install/dvd-download/index.en.html
ISO or bittorrent ... will come back to that ...
verify ...
Verify using OpenPGP
Download the OpenPGP signature for the Tails 4.18 ISO image
wget -q -N https://tails.boum.org/torrents/files/tails-amd64-4.18.iso.sig
Now let's download via bittorrent (what matters is not from where, but
resultant bits ... this will also greatly save load
on the tails resources).
https://tails.boum.org/torrents/files/tails-amd64-4.18.iso.torrent
Well, that sucks ...
------------------------------------------------------------------------------
| Filename Size Download
Upload |
| tails-amd64-4.18-iso 1.1 G 0 B/s
0 B/s |
| ^--- connecting to peers (0.0%) 0.0 M
0.0 M |
| Totals: 0 B/s
0 B/s |
| 0.0 M
0.0 M |
| New torrent: tails-amd64-4.18.iso.torrent
|
------------------------------------------------------------------------------
Gave it over an hour, and not so much as a single byte from one single
peer/seeder.
$ ps uwwwp 8963; date -Iminutes
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
michael 8963 0.4 0.0 242172 16328 pts/23 Sl+ 00:06 0:15
/usr/bin/python /usr/bin/btlaunchmanycurses /var/tmp/tails
--max_upload_rate 305 --max_uploads 12
2021-04-27T01:08-07:00
$
So, guess I do it ye olde fashioned way - since tails is presently
lacking bittorrent seeders.
$ wget -q -N
https://mirrors.dotsrc.org/tails/stable/tails-amd64-4.18/tails-amd64-4.18.iso
Downloaded it ... might as well start to be a seeder and give somethin'
back - after all, did just suck about a GB of data and given none back
... yet.
------------------------------------------------------------------------------
| Filename Size Download
Upload |
| tails-amd64-4.18-iso 1.1 G 0 B/s
0 B/s |
| ^--- download succeeded! 0.0 M
0.0 M |
And already set the file and directory ro before reopening it with
bittorrent, so, on to check it ...
$ ls
tails-amd64-4.18.iso tails-amd64-4.18.iso.sig
$ gpg --verify *.sig *.iso
gpg: Signature made Mon Apr 19 08:29:51 2021 PDT
gpg: using EDDSA key CD4D4351AFA6933F574A9AFB90B2B4BD7AED235F
gpg: Can't check signature: No public key
$
I don't have that (more current) key yet ...
site:https://tails.boum.org/ tails linux signing key
https://tails.boum.org/doc/about/openpgp_keys/index.en.html
Signing key
https://tails.boum.org/doc/about/openpgp_keys/index.en.html#index2h1
download it from this website: tails-signing.key
https://tails.boum.org/tails-signing.key
$ gpg --import <(curl -s https://tails.boum.org/tails-signing.key)
gpg: key DBB802B258ACD84F: 2169 signatures not checked due to missing keys
gpg: Oops: keyid_from_fingerprint: no pubkey
gpg: Oops: keyid_from_fingerprint: no pubkey
gpg: key 0000000000000000 occurs more than once in the trustdb
gpg: key FD1FF7E1DCE6CE21: no public key for trusted key - skipped
gpg: key FD1FF7E1DCE6CE21 marked as ultimately trusted
gpg: key DBB802B258ACD84F: public key "Tails developers (offline
long-term identity key) <tails at boum.org>" imported
gpg: Total number processed: 1
gpg: imported: 1
$ gpg --verify *.sig *.iso
gpg: Signature made Mon Apr 19 08:29:51 2021 PDT
gpg: using EDDSA key CD4D4351AFA6933F574A9AFB90B2B4BD7AED235F
gpg: Good signature from "Tails developers (offline long-term identity
key) <tails at boum.org>" [unknown]
gpg: aka "Tails developers <tails at boum.org>" [unknown]
Primary key fingerprint: A490 D0F4 D311 A415 3E2B B7CA DBB8 02B2 58AC D84F
Subkey fingerprint: CD4D 4351 AFA6 933F 574A 9AFB 90B2 B4BD 7AED 235F
$
That's it, done and verified. In the case of Tails, they directly
signed the ISO, so no need to separately compute hash(es) ... also makes
it less likely users will screw up, and just compute hash(es) and
compare those, but fail to check signature on hash(es).
Anyway, I could'a picked up a DVD laying in the street that said:
"TAILS LINUX, secure, trust me!"
picked it up and used that ... "of course" after I verified it - only
bit that would be different is I would've copied from the DVD, rather
than obtained via wget (or bittorrent, etc.). So long as it properly
verifies, the bits is the same, regardless of how obtained or from
where. Could'a even gotten ISO from Bobbie ... and I think at least
some, probably several in my collection, I have obtained from Bobbie
(and generally verified, at least as feasible).
> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
> Subject: Re: A study in trying to verify a signature
> Date: Mon, 26 Apr 2021 22:31:01 -0700
> Paint me skeptical, but let me see what I get ...
> my bits in-line below ...
>
>> From: Al <awsflug at sunnyside.com>
>> Subject: Re: [sf-lug] (forw) Re: (forw) Re: Something new on
>> Distrowatch and Ubuntu variants.
>> Date: Mon, 26 Apr 2021 21:26:27 -0700
>
>> A study in trying to verify a signature:
>
>> Anyway, long story short I downloaded the ISO file at
>> https://dl.t2-project.org/binary/2021/ by right-clicking in Firefox:
>> t2-21.4-x86-64-minimal-desktop-gcc-glibc.iso 2021-04-23 17:50 722M
>> t2-21.4-x86-64-minimal-desktop-gcc-glibc.sha 2021-04-22 11:11 87
>
> Never heard of dl.t2-project.org that I'm aware ...
> guestimating that's mirror site, or CDN or the like?
> Let's see if I can first figure out what that likely/presumably is ...
> https://dl.t2-project.org/binary/2021/
> Looks like a bunch 'o ISOs 'n such, but dear knows from what project.
> "SSL"/TLS cert appears functional, does that give us a clue?
> cert has some SAN names, ... none I recognize.
> How 'bout some kind 'o sig file ... theoretically that's give us
> clue (if it's legitimate sig). ...
> $ wget -N
> https://dl.t2-project.org/binary/2021/t2-21.4-x86-64-minimal-desktop-gcc-glibc.sha
> --2021-04-26 22:03:40--
> https://dl.t2-project.org/binary/2021/t2-21.4-x86-64-minimal-desktop-gcc-glibc.sha
> Resolving dl.t2-project.org (dl.t2-project.org)... 144.76.154.42
> Connecting to dl.t2-project.org
> (dl.t2-project.org)|144.76.154.42|:443... connected.
> ERROR: The certificate of 'dl.t2-project.org' is not trusted.
> ERROR: The certificate of 'dl.t2-project.org' doesn't have a known issuer.
> $
> Well that's interesting ... wget complains but Chromium doesn't.
> Maybe they did something boneheaded like forgot to include the intermediate
> cert ... many browsers like Chrom{e,ium}, Firefox, are relatively forgiving
> in that, where they'll cache the intermediate, and if it's missing and they
> have it cached, they'll use that ... but wget/curl/lynx/... won't do that.
> And, expectedly to hypothesis, wget, curl, and lynx, all fail on cert
> issues. So we're already dealing with a cite that ain't quite got their
> act together.
> Well, let me try a search on (partial) filename ... maybe get a clue
> what it theoretically would be there ...
> So, searching 'da Interwebs on
> "t2-21.4-x86-64-minimal-desktop-gcc-glibc"
> various search results suggest it's from
> "T2 SDE" ... "an open source system development environment" ... uh huh.
> So, search on "T2 SDE" ...
> https://t2sde.org/
> ... Download ... https://t2sde.org/download/ ... primary server(s) ...
> http://dl.t2-project.org/binary/
> https://dl.t2-project.org/binary/
> Not looin' promising - special snowflake distro?
> site:t2sde.org (gpg OR pgp OR signature OR "GNU privacy guard") -package
> site:t2sde.org signing key
> Yeah, special snowflake distro, use at your own risk, good luck.
>
> I'll skip it, thanks.
>
> Unless *maybe* you want to trust their slight broken TLS/SSL ...
> but first another sanity check:
> $ curl -k -I
> https://dl.t2-project.org/binary/2021/t2-21.4-x86-64-minimal-desktop-gcc-glibc.sha
> HTTP/1.1 200 OK
> Date: Tue, 27 Apr 2021 05:23:39 GMT
> Server: Apache/2.4.39 (Unix) OpenSSL/1.0.2s
> Last-Modified: Thu, 22 Apr 2021 11:11:35 GMT
> ETag: "57-5c08dbe0d07c0"
> Accept-Ranges: bytes
> Content-Length: 87
>
> $ curl -k -I
> https://dl.t2-project.org/binary/2021/t2-21.4-x86-64-minimal-desktop-gcc-glibc.iso
> HTTP/1.1 200 OK
> Date: Tue, 27 Apr 2021 05:23:48 GMT
> Server: Apache/2.4.39 (Unix) OpenSSL/1.0.2s
> Last-Modified: Fri, 23 Apr 2021 17:50:12 GMT
> ETag: "2d22d800-5c0a76d74dd00"
> Accept-Ranges: bytes
> Content-Length: 757258240
> Content-Type: application/x-iso9660-image
>
> $
>
> Notice the Last-Modified: - the .iso is newer than the corresponding .sha
> file. Yeah, incompetent, or compromised, not something I'd want to trust.
More information about the sf-lug
mailing list