[sf-lug] SF-LUG meeting note for Monday November 20, 2017

[Rick Moen]

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

> Exactly but it might do better with 16! Sadly beyond my present means.

Enjoy that incredible wealth of RAM, anyway.  The notion of a desktop
Linux system need anywhere near that much actually boggles me.  I'm used
to much, much more svelte setups, FWIW.


> The up-loaders with no easy means of contact are the real cause. 
> Maybe they just want to cause chaos.

I confess, I don't get this.

When developers post ISOs, they should post checksum files somewhere
alongside those.  Ideally, those checksums or the ISOs themselves would
also be attested by a PGP signature that (at least in theory) you can
vet against a key chain of trust.  But the absolutely bare minimum I
would expect to see is md5sums or sha1sums or sha256sums for and
alongside the downloadable ISOs that were provided at the same time as
the ISOs.

If that is _not_ the case, then you have no way to determine within
reasonable certainty that your download is complete and uncorrupted, and
at that point, don't know about you, but I'd be worried about that point
and wonder if there isn't a better online source.

I'm also just a little worried by your phrase 'the uploaders'.  What
uploaders?  _Any_ old uploaders?  You, me?  Some guy behind a tree?  You
ought to be careful about provenance for system software.  I mean,
there's an obvious security risk if you don't.


> >>He was trying to remotely do the checksum before downloading.
> >If Maestro is claiming that the ISO already doesn't match its listed
> >checksum value at the download site, that would indeed be a big problem,
> >but calculating a fresh checksum _on_ the download site (what I guess
> >you're talking about) would require that Maestro have login (e.g., ssh)
> >access there, which isn't going to be the case.  Moreover, that ignores
> >the larger question of _why_ the ISO doesn't match the listed checksum,
> >which you certainly would want to solve before trusting the ISO to be
> >correct, complete, and not security-compromised.
> 
>     No he is not trying to replace the checksum given but to
> check the iso before downloading.
>      Apparently this is possible but...

Not in any way obvious to me.  (Maybe there's something he knows that we
don't.  Or not.  As mobster-era journalist and short story author Damon
Runyon put it, riffing off Ecclesiastes 9:11, 'The race is not to the
swift, nor the battle to the strong..., but that's the way to bet.')

Think about it from the perspective of process (of what steps are
required).  Maestro would need to initiate calculation of a fresh
checksum of the downloadable ISO file _on_ the download server, which 
basically means having shell access on that server or the functional
equivalent -- which he isn't going to get.  So, this seems a fool's
errand.  Doubly so because it seems to lack a reasonable purpose anyway:

The checksum he would hypothetically calculate would differ from the 
one already listed with the ISO only if the developer posting the
ISO either (a) cannot generate correct ISOs or (b) cannot copy files
and cannot bother to check his/her work.  This stikes me as being at
best extremely far-fetched.  It's frankly rather more likely that he
encounters problems validating checksums because he's screwing up the
(occasional) download.