[Slackbuilds-users] MD5 hash sums

[Habs]

On Thu, 23 Aug 2018, Erik Hanson wrote:
> On 8/23/18 5:59 PM, thyr at airmail.cc wrote:
>
>> So, one can verify the authenticity of the SlackBuild script, but the
>> authenticity of the source tarball itself used by the aforementioned
>> script is uncertain? If that's the case then why would one bother with
>> verifying authenticity at all? (Something authentic) x (Something that
>> may or may not be authentic) == (Something that may or may not be
>> authentic), right?
>
> It's been mentioned in this thread enough times that MD5 has not fallen
> to the attack you think it has, so I won't repeat that talking point,
> but I will try and clarify something..
>
> The checksums are not there to verify authenticity. Everyone seems to be
> putting far too much stock in the MD5 sums in the .info files. I can't
> stress this enough: they're not there for security.
>
> You could almost think of it as a version number. If the file you
> download matches the MD5 sum provided, then you know it's the same file
> the maintainer used, and the same file the SlackBuild was tested against
> by a SlackBuilds.org admin. This helps to ensure the SlackBuild will
> work as intended, creating a valid package.
>
> What the MD5 sum can, and does do on a regular basis, is raise a red
> flag when it mismatches. Possibly the source has gone missing, or been
> replaced by upstream without a change to the file name. These things
> happen often enough that it's important we have a checksum, and that
> people use it rather than complain that a SlackBuild is broken.
>
> However, you absolutely cannot assume that because the MD5 sum matches
> that the file is in any way "safe" or was not tampered with /before/ the
> maintainer got to it. Auditing or policing upstream sources is far
> beyond the scope of this project. We could use the strongest hashing
> algorithm available, but telling people it's a mark of authenticity
> would be nothing but theater.
>
>
> -- 
> Erik
>
>

It seems clear enough to me and has done since it was explained to me a
while back.

Effectively, if the maintainer unfortunately has used an 'unsafe' source, 
created its checksum for that source and then uploaded the build package, 
then all the checksum is doing when use it, is validating it was that 
original unsafe source (assuming it hasn't again been altered); or more 
preferably and likely the 'safe' source - as said, there is nothing SBo 
can do about unsafe sources and updating to better checksums etc won't 
help that it seems to me.

I think the current approach is 'safe enough' once one accepts the above
to prove nothing was tampered with when we get it - or at least will let
us know.

I stand to be corrected, however.

Habs

--- Sent using Alpine/Pine, a text based MUA ---