Subject: Re: Heads up: suspicious source distribution of OpenSSH 3.4p1 found
To: NetBSD tech-security list <tech-security@netbsd.org>
From: Rogier Krieger <rogier@virgiel.nl>
List: tech-security
Date: 08/02/2002 19:38:20
Previous Correspondence from Steven M. Bellovin (12:21 2-8-02 -0400):
>No -- the most common cause of checksum failures in pkgsrc is a file
> remaining from a partial or interrupted download.  There would be
>far  too many false positives.

Given a regular modem connection, you're probably right on this. It
will - though to a lesser degree - apply to systems on higher-grade
connections. Still, I suspect a reporting capability can work if you
only report a problem after retrying downloads that failed their
checksum tests. Such would provide far more reliable data.

Transfer errors will likely generate a timeout or error condition in
the ftp or other fetching client. Retrying a download in such case
seems a logical thing to do.

Let's suppose no error condition occurs on transfer and, for whatever
reason, the file is still a corrupted download. This would provide a
checksum mismatch - a false positive if reported - on a file that is
already worthless for installation. The file would fail upon
extraction or upon being compiled, if the checksum error is to be
ignored.

You'll need to re-download anyway. I realise that such may seem
daunting to users on slower modem lines. Still, you'll want a working
package. As much as filesize and transfer durations may be a pain on
some packages, there isn't much you can do about it, short of a
pkgsrc-aware download manager.

When experiencing a 'reasonable' amount of consecutive similar
checksum mismatches without transfer errors, would it be
inappropriate to assume something is wrong with the package and
generate a report on this condition? Would this wreak havoc on the
pkgsrc system?


>>I wonder where things went wrong, but the
>>pkgsrc in NetBSD would normally have detected any trouble. Same
>>goes for the FreeBSD ports collection.
>
>Of course, that begs the question of where the checksum information 
>comes from.  If it's on the same Web site and not digitally signed,
>it  won't do a lot of good.

True. A CVS (or supplementary tool) that - upon committing files -
provides signed checksum information seems like a good thing.

Greets,

Rogier Krieger


--
"Eagles fly, but weasels don't get caught in jet engines..."