Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 Jun 2000 14:50:24 -0700 (PDT)
From:      Kris Kennaway <kris@FreeBSD.org>
To:        Brian Fundakowski Feldman <green@FreeBSD.org>
Cc:        "David E. O'Brien" <obrien@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: ports/comms/minicom/files md5
Message-ID:  <Pine.BSF.4.21.0006091437510.83208-100000@freefall.freebsd.org>
In-Reply-To: <Pine.BSF.4.21.0006091716370.59266-100000@green.dyndns.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 9 Jun 2000, Brian Fundakowski Feldman wrote:

>    The diffing-to-find-what-makes-an-md5-change practice is a good
> thing, but how good is it really when the MD5 from a new version is
> generated and we act on blind trust? That happens more often than
> bouncing md5 hashes, so isn't there even _more_ of a chance of a trojan
> coming in?

At David's request I'm finally going to write up the policy for the
handbook which until now has only been documented by email - my opinion is
that ideally, committers should read diffs for all version updates, but in
practice that's far too much work to ask committers to do, of course.

The best advice I have is to make sure you only obtain new versions from
official sources (i.e. if you see a "new version" which is hosted on a
different website and the old distribution location still exists, be more
suspicious).

Ultimately we have to draw the line somewhere, because our resources are
finite, and I think the far greater risk is of an attacker slipping a
bogus change into a distfile without renaming it (like tcp_wrappers, and
rzsz (in this case it was the author who slipped a malicious change into
his software without releasing a new official version)) than of an
attacker making a bogus new version which is then picked up by FreeBSD
ports (e.g. 1.2 -> 1.3), which is more likely to be noticed by the
legitimate author in short order.

To be honest, IMO the biggest risk is of an author deliberately inserting
malicious or insecure code into their software and getting the port into
FreeBSD - we don't have any safeguards against that sort of thing and
short of auditing all ports submissions prior to addition it's not
feasible to do so.

Kris

--
In God we Trust -- all others must submit an X.509 certificate.
    -- Charles Forsythe <forsythe@alum.mit.edu>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0006091437510.83208-100000>