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

Mon Apr 26 21:26:27 PDT 2021

A study in trying to verify a signature:

Sometimes I like to try the obvious, just for the heck of it.
What I expect is that the checksum on the official website is most 
likely correct, although obviously a  developer's website could get 
hacked by members of the open community.  On the other hand it could 
have messy errors and be poorly maintained instead of being hacked. I 
always believe in incompetence before malevolence.  Someone has that as 
their 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

and got this:
-rwxrwxr--+ 1 al al 757258240 Apr 26 20:01 
t2-21.4-x86-64-minimal-desktop-gcc-glibc.iso

That seems too big, but if M=1024*1024, 722M is 757071872 which is in 
the ballpark.

The file t2-21.4-x86-64-minimal-desktop-gcc-glibc.sha has this:
b0c72bf9bba7c4221f35a4bce0f7c710ecb335d8 
t2-21.4-x86-64-minimal-desktop-gcc-glibc.iso

Too me that's pretty sloppy because it doesn't say which flavor of SHA 
checksum it is, but at 40 characters
it pretty much has to be the 20 byte SHA1 checksum.

However when I run sha1sum on the iso file I get:
df3d8dd16ee47f371f3ea2e656038e43a975833d 
t2-21.4-x86-64-minimal-desktop-gcc-glibc.iso

I tried re-downloading the file with wget and produced the same thing.

It's ironic that I had to use 'wget --no-check-certificate' because the 
https certificate is no good, but of course we always just ignore that 
because we no it's just sloppiness at the developers' site not some real 
evil doings.  But now we've just accepted yet another weakening of the 
credibility of what we're trying to do in the first place.

Now this is all a problem because the checksums don't match.  So the 
usual way to verify checksums off the original source website isn't working.

Just for the heck of it I ran 'file' on the thing and got more or less 
what I would expect:
t2-21.4-x86-64-minimal-desktop-gcc-glibc.iso: DOS/MBR boot sector; GRand 
Unified Bootloader, stage1 version 0x79, boot drive 0xbb, stage2 address 
0x8e70, 1st sector stage2 0xb8db31c3, stage2 segment 0x201

So the iso file is probably ok, but at this point it's probably worth 
posting something to the T2 discussion list and letting the developers 
go fix it if I'm really trying to be careful.  Info on subscribing to 
the developers' list is at https://t2sde.org/contact.  While we're at 
it, we should bring up the certificate problem.  Haven't they heard of 
'letsencrypt'?  I guess not- something else to get around to...

Out of curiosity I decided to also download a few other files.  The 
downloads must be speed controlled as they 722M file took a ridiculous 5m
9s to download, but in the scheme of things I suppose I don't really 
need it faster.

Anyway, from last year:
https://dl.t2-project.org/binary/2020/t2-minimal-desktop-glibc-gcc-x86-64-haswell-20.10.iso 

checks out with the correct checksum
but from this year:
https://dl.t2-project.org/binary/2021/t2-21.4-m68k-minimal-xorg-gcc-glibc.iso
does not.

It might almost make me see the sense behind Rick's comment that older 
files are more likely to have been verified and complained about.

I did end up sending a note to the mailing list.  No reply yet. Crummy 
mailing list software.

So is  Bobbie Seller's T2 ISO file ok?  Well, probably.  I guess. 
Maybe.  Can't say for sure.  Trust based on total ignoring of all 
evidence to the contrary.

Now not to be totally pessimistic and negative, the big sites like 
debian and ubuntu will have (or so I believe) checksums that are 
actually correct.  I checked some once.   Mostly I just download from 
big established well run websites and trust, but there's that Mint 
case... I hadn't even heard of that.

regards
Al

On 4/26/2021 20:15, Rick Moen wrote:
> Bobbie wrote:
>
>> Assuming the stupid hackers have put a trojan in the iso file, and
>> added the checksum for the bad iso file, what is to keep them from
>> falsifying the signature as well?
> The fact that you have established a meaningful trust path to do so.
>
> You acquired the development team PGP signing key in a way that gives
> you meaningful grounds for belief that it is genuine, if only because,
> say, it's now 2021 and you got the keyring directly from what you
> believed to be the developer site in 2015, six years ago, it has been
> unchanged in the developer's Web pages and source code repository all
> the time since then, and you have reasonable faith that over six years
> some alert person would have noticed the fake signing key.
>
> This is not playing-around imitation of the outer appearance of
> security, Bobbie.  This is _actual_, serious security.  The details have
> been gone over by experts in extreme detail with a skeptical eye.
>
> If you decide "Well, it can't actually be serious", then you lose -- and
> so does anyone who makes the mistake of trusting your ISOs (without
> verification).
>
>
>> For many long years signatures were not available and my iso files
>> generally worked.
> Bullshit.
>
> Only extremely rare distro ISOs have failed to provide release
> sigatures, e.g., Linux Mint at first was that lax.  They learned the
> hard way that this was a really bad idea.
>
> Bobbie, kindly do not try to convince me of things that are
> spectacularly wrong about Linux distributions.  I've been at this for a
> very, very long time, and unlike you have actually been part of a team
> of distro maintainers.
>
>
>
>> I have seen viruses on Windows and boot viruses on Amiga.  On Windows
>> I caught them with ClamAV from one or another of the numerous
>> distributions I used to run.  When I first got acquainted with Linux I
>> tried out lots of distributions.  On the Amiga with an Amiga specific
>> anti-Virus software which I downloaded and there were no checksums
>> much less signatures at all in those days.  The virus arrived on the
>> bootblock of an 'on floppy disk' magazine.  I informed the publisher
>> and he corrected the problem.
> That's very nice, but utterly irrelevant and misses the point.
> You would not be able to detect a trojaned distro ISO using AV software
> (in general), for reasons that should be obvious.  Moreover, it's far
> simpler to just validate PGP signatures, which also actually works.
>
> I'm not going to keep debunking irrelevancies, Bobbie.  If you wish to
> keep spewing justifications for an outright negligent blunder, that is
> your problem, not mine, and I am not going to work my fingers to the
> bone trying to teach someone who is refusing to listen.
>
>
>
>> A downloaded Iso may match checksums and signatures and still be
>> unusable due to corrupted install scripts and I have been dealing with
>> such over the past few months.
> This _obviously_ is by definition irrelevant to the discussion.  Neither
> checksums nor developer release signatures aspire to ensure that the
> contents of a distribution is un-buggy, merely that the download is
> uncorrupted in transit and is genuinely what the developer(s) released.
>
> You already knew that, so why are you wasting everyone's time blowing
> smoke that you know is completely irrelevant?
>
>
>> Oh and if members are nervous about the iso files and image files I
>> download then they can get the checksum and the signature files and
>> check the isos themselve.
> They can indeed compensate after the fact for your negligence and lack
> of due diligence.
>
> I merely called your attention to your negligence and lack of due
> diligence.
>
>
>> Have a good afternoon all who are reading...
> But you carelessly sent it offlist in private mail.  Again.
>
>
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
> SF-LUG is at http://www.sf-lug.org/