Date: Wed, 11 Jun 2008 19:36:28 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Paul Schmehl <pschmehl_lists_nada@tx.rr.com> Cc: freebsd-stable@freebsd.org, mh@kernel32.de Subject: Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3 Message-ID: <20080611193123.N40102@fledge.watson.org> In-Reply-To: <4E2C3BF30A4BC75D1D837828@utd65257.utdallas.edu> References: <484FA07E.60103@lozenetz.org> <b97c11a8a910057f0ea95f737791d968@localhost> <3cc535c80806110536w1c8af6efq8d5470ce6de8cb38@mail.gmail.com> <20080611165009.O40102@fledge.watson.org> <4E2C3BF30A4BC75D1D837828@utd65257.utdallas.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080611193123.N40102>