about keeping a checksums table in a separate file

[Rainer Müller]

On 2016-02-02 10:32, René J.V. Bertin wrote:
> How important is the whole checksumming feature really? We're talking
> here about source archives that already have a form in built-in
> checksum, plus an external check. Anything goes wrong during
> transmission (fetch), and the archive is very likely not to unpack
> successfully. Significant malicious changes to the code (supposing
> there are real odds for that) could lead to the (MacPorts) build or
> destroot failing. The transmission/unpack argument applies to binary
> build tarballs too ... and if a hacker would ever be interested to
> introduce something into one of those tarballs he'd surely update the
> online checksum too (supposing there is a checksumming feature).

The distfiles come from different servers than the Portfiles in the
ports tree, which means there are separate attack vectors.

When syncing with rsync or the ports tarball, the whole ports tree is
also signed and verified. The checksum also ensures the file you get is
the one the maintainer used and tested. Often enough we see problems
with fetching distfiles [1,2], that are caught early by the checksum
mismatch.

All pre-compiled binaries produced and distributed by MacPorts have a
detached rmd160 signature. This is technically similar to a checksum,
but it cannot be forged without access to the private key. Some
information on how that works can be found in the HOWTO section of the
wiki [3].

Rainer

[1] https://trac.macports.org/wiki/MisbehavingServers
[2] https://trac.macports.org/wiki/PortfileRecipes#stealth-updates
[3] https://trac.macports.org/wiki/howto/ShareArchives2