about keeping a checksums table in a separate file

[Clemens Lang]

On Tue, Feb 02, 2016 at 10:32:23AM +0100, René J.V. Bertin wrote:
> How important is the whole checksumming feature really?

Checksumming is a critical security feature. It must stay.


> Anything goes wrong during transmission (fetch), and the archive is
> very likely not to unpack successfully.

That only applies if the attacker is not malicious, i.e. the file format
itself provides safety, not security. Additionally, a lot of the archive
formats actually to extract files even if they are, e.g., truncated.


> Significant malicious changes to the code (supposing there are real
> odds for that) could lead to the (MacPorts) build or destroot failing.

No. Well-drafted malicious changes would result in a malicous binary
being installed and/or run with root rights without you noticing.


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

You are assuming the hacker controls the server that provides the files.
However, an attacker may only be in the position to forge network
traffic to a single user (think public wifi), where this does not apply
because the checksums are already on the users machine, are signed and
use a different path through the network.

If anything, this attack vector is actually an argument to extend our
current checksums by actual cryptographic signatures (e.g. using GPG,
signify, and similar tools) to reduce the trust level needed in mirror
operators.


> I'm not saying that checksumming is without interest for all ports
> (it's probably justified for security-related ports like openssl and
> family)

A single port that isn't checksummed can leave your system compromised,
no matter whether it is "security-related" or not. The make install step
of said port is run with root privileges (in a sandbox, but still) and
gives an attacker arbitrary command execution.


TL;DR: Checksumming isn't going away.
-- 
Clemens