[Slackbuilds-users] MD5 hash sums

[Richard Ellis]

On Fri, Aug 24, 2018 at 01:59:59AM +0300, thyr at airmail.cc wrote:
> >What are all of those .asc files in the repository?
> >
> >Those files are GPG signatures. They can be used to verify that the
> >SlackBuild script tarball is exactly the one that we placed on the site.
> 
> So, one can verify the authenticity of the SlackBuild script, 

The .asc files protect the entire slackbuild package.  They verify
that the entire *.tar.gz file has not been modified since the SBo
admins posted the *.tar.gz file to the site.

> but the authenticity of the source tarball itself used by the
> aforementioned script is uncertain?

No.  The MD5 sum being discussed in *inside* the SBo *.tar.gz file in
the *.info file contained therein.  The *.asc file authenticating the
*.tar.gz SBo package allows you (assuming you check the GPG
signature) to determine that the *.tar.gz was not modified, which by
extension means the *.info inside was also not modified since the
package was posted.

Now you know that the *.info was not modified (due to the GPG *.asc
file).  If the *.info file was not modified, then the MD5 sum inside
was also not modified and represents exactly what the maintainer
placed inside the *.info file when they created it.

So with a MD5 sum that you know to have been unmodified (due to
checking the *.asc on the whole bundle) you can verify that the
package source you download from the download link matches the
unmodified MD5 sum in the *.info file.  If they match, you have
verified that the downloaded source package you received is identical
to that which was used by the SBo package maintainer when they
created the SBo *.info file.

The reason this works is that to break this (substitute a different
download package for the origional download package) the attacker has
to perform a second pre-image attack, which remains computationaly
infeasable today even for MD5.

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

The authenticity verification is so you can be sure someone did not
substitute a different copy of myapp.tar.gz from the copy used by the
SBo maintainer when they created the buildscript and *.info file.  An
attacker might try to insert "evil virus" into the download package,
hoping someone would download it in the future and without checking
the hashes compile it up, install it, and now the attacker has a
victim.