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 _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev