From owner-freebsd-stable@FreeBSD.ORG Mon May 22 06:17:23 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F01FA16A421; Mon, 22 May 2006 06:17:23 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from groat.ugcs.caltech.edu (groat.ugcs.caltech.edu [131.215.176.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6FB843D45; Mon, 22 May 2006 06:17:23 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by groat.ugcs.caltech.edu (Postfix, from userid 3640) id AC5835880B; Sun, 21 May 2006 23:17:22 -0700 (PDT) Date: Sun, 21 May 2006 23:17:22 -0700 From: Paul Allen To: Scott Long Message-ID: <20060522061722.GA28128@groat.ugcs.caltech.edu> References: <4471361B.5060208@freebsd.org> <20060521231657.O6063@abigail.angeltread.org> <44714FBB.4000603@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44714FBB.4000603@samsco.org> Sender: jd@ugcs.caltech.edu Cc: FreeBSD Stable , Colin Percival , Brent Casavant Subject: Re: FreeBSD Security Survey X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2006 06:17:24 -0000 >From Scott Long , Sun, May 21, 2006 at 11:44:27PM -0600: > I share this frustration with you. I was once told that the pain in > upgrading is due largely to a somewhat invisible difference between > installing a pre-compiled package, and building+installing a port. In > theory, if you stick to one method or the other, things will stay mostly > consistent. But if you mix them, and particularly if you update the > ports tree in the process, the end result is a bit more undefined. One > thing that I wish for is that the ports tree would branch for releases, > and that those branches would get security updates. I know that this > would involve an exponentially larger amount of effort from the ports > team, and I don't fault them for not doing it. Still, it would be nice > to have. Huh? Really. What you say makes a certain amount of sense when pkg_add is used, but I haven't seen much evidence for problems with mixing ports and packages via portupgrade -P. The trouble comes not with packages but in the conflicting information between /var/db/pkg/ and the ports themselves. The former does not merely contain a stale version of the port dependency and origin information; it contains many snapshots of small slices of many different port dependency graphs (as the port tree evolves). Consistently using portupgade -rR, portinstall helps keep this under control but each pkg_add or make install in a port directory causes drift. Given that portupgrade is an optional tool and the handbook suggests the other form... well you see the trouble. But the situation is worse than this because of the manual interventions necessary to fixup the portsdb. These fixups easily create dependency graphs that never existed anywhere else before. Most often this happens because of ports being renamed, deleted, combined, etc--the trouble here is that the ports tree reveals no history about these actions. It is left to a program like portupgrade to heuristically guess!?! what has taken place. Now if you go through this process every week (every day?) usually the risk is small and it is obvious what to do, but this is not always so. Some speculation: I've always thought portupgrade did the Wrong Thing(tm) by consulting the dependency graph in /var/db. Better to merely learn which packages were installed and then exclusively use the port information... Maybe someone knows why that would be the wrong thing to do? Paul