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

[Bobbie Sellers]

On 11/22/2017 06:35 PM, Rick Moen wrote:
> 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.
         Well it is an old habit of mine to max the memory if I can on 
my main machine.  This is from the days of megabytes on
the Amiga.  I had my A2000b with 68060 up to 64 megabytes.
>
>
>> 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.

     I don't really get it either but a version of Open Mandriva was 
published on Distrowatch that
did not have the proper checksum posted.  I attempted to contact the 
poster at the Open Mandriva
site.  I never got a response.   I notified the Distrowatch and they 
were unable to contact the
poster of that version either.
>
> 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.

     The latest example is MultibootUSB-live which was supplied without 
checksum and I went to the site
and pointed this out.  The person answering me said

"Will put it in on the site from next release onwards...."

	As though he had never heard of such a thing
before.

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

     And you can read what Maestro had to say on the list and I am sorry 
that I may have
conveyed a misunderstanding to the rest of the readers of the list.
> 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.
         Bobbie Sellers