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

[Rick Moen]

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

> The Dell is running the PCLinuxOS64 KDE5 and is fully updated at that
> time to kernel 4..13.14.  This is now running on the 700 Gibibyte hard
> drive from my toasted Pavilion and with the 8 Gigabyte sodimm added it
> is up to 12 Gibibytes.

Win!  That's even enough RAM for KDE.  ;->

> Well Maestro got into it about a casual remark I had made
> that  some isos that I download are problematic in that the
> checksums given by the uploaders do not match.

Thank you for caring about file download integrity.  I continue to vet
the sha256sums (or prior hash types where those are used), but honestly
can't even remember when a garbled download was last an issue -- except
of course for incomplete downloads.  And the way you prevent those is to 
use 'wget -c' (or --continue) and run it a second time to make sure.

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


> I despite the fact that the download may be bad prefer
> to check the download once it is on my hard disk.

Doing that is the only possible way to accomplish the purpose of the
checksum, to verify that your download was complete and uncorrupted.