From owner-freebsd-stable@FreeBSD.ORG Wed Jun 11 19:36:29 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9EC2106567B; Wed, 11 Jun 2008 19:36:29 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (in-addr.broker.freenet6.net [IPv6:2001:5c0:8fff:fffe::214d]) by mx1.freebsd.org (Postfix) with ESMTP id 8BCFD8FC1E; Wed, 11 Jun 2008 19:36:29 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1K6W7Q-000Bcm-Jy; Wed, 11 Jun 2008 15:36:28 -0400 Date: Wed, 11 Jun 2008 15:36:28 -0400 From: Gary Palmer To: Robert Watson Message-ID: <20080611193628.GC998@in-addr.com> References: <484FA07E.60103@lozenetz.org> <3cc535c80806110536w1c8af6efq8d5470ce6de8cb38@mail.gmail.com> <20080611165009.O40102@fledge.watson.org> <4E2C3BF30A4BC75D1D837828@utd65257.utdallas.edu> <20080611193123.N40102@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080611193123.N40102@fledge.watson.org> Cc: freebsd-stable@freebsd.org Subject: Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3 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: Wed, 11 Jun 2008 19:36:30 -0000 On Wed, Jun 11, 2008 at 07:36:28PM +0100, Robert Watson wrote: > > On Wed, 11 Jun 2008, Paul Schmehl wrote: > > >From a security standport, backporting fixes to previous versions of ports > >creates a difficulty. It's much harder to tell, for example, if a RedHat > >"port" is vulnerable or not, because RedHat uses their own proprietary > >versioning system to define "where" a particular "port" is at. > > > >So, while your system might *say* it's running php version 5.2, it's > >really *not* vulnerable because in RedHatese it's version > >5.2.1.6.92000.p-2.1 (I'm just making that up.) > > > >If this idea ever gets off the ground, I *hope* the folks involved with > >find a rational, logical way to define the versioning so that it's not > >hieroglyphics to the average person. > > I hope not to offend the ports folks in saying this, but it seems clear to > me that the narrower scope and better-defined components of the base system > have (over time) lead to a much easier incremental upgrade path than ports > and packages. > > It's not clear to me how you could apply the same level of attention to > something as large as the ports collection, except perhaps to select a > subset of ports you care "more" about, and provide a higher quality of > service for them. In effect, try to find a semantically richer middle > ground between "it's someone else's problem, our role is primarily to > bundle" and "it's entirely our problem and in revision control". We > already do this for some ports, in that the people involved in adapting and > maintaining some of the larger/more critical parts, such as X.org, KDE, > Gnome, and quite a few others, spend vast amounts of time ensuring that > things work well, but largely without the help of revision control in the > ports tree. I'm not proposing we incorporate X.org into CVS (SVN?) or the > like, but perhaps there is a way we could better present the choices > reflected there. That doesn't help users of random tiny software packages, > and I'm not sure anything can, but perhaps we can provide a smoother > incremental maintenance path for some key packages. > > Mind you, ports really isn't my area, so I am at significant risk > speculating in this area. Experience with the base system shows that the > real work is always in the details, and hardly ever in the big ideas, and > so only by truly implementing a system and trying it out can you determine > whether it really works in practice. It's easy to wave ones hands at a > high level (as I've done), but it's the proof-of-concept that matters. I think a large part of the shortcomings of the ports infrastructure when it comes to security releases could be mitigated if there was a rapid building and availability of packages on FTP mirrors to prevent everyone from doing "portupgrade -P" and then having to wait for the build as the packages don't show up for days, and people can't wait that long for the fix. I know a discussion was recently started about package distribution and how to address its shortcomings and hopefully the need for rapid security package distribution will be taken into account Regards, Gary