Date: Wed, 11 Jun 2008 22:50:34 +0200 From: "Andy Kosela" <andy.kosela@gmail.com> To: freebsd-stable@freebsd.org Cc: pschmehl_lists@tx.rr.com, rwatson@freebsd.org Subject: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3 Message-ID: <3cc535c80806111350x237e2a4ewe1429b7a3f5b720@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
On Wed, Jun 11 2008, 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. Egyptian hieroglyphics was a very noble system the secret of which was, in the days of old, in the possession only of the Hierogrammatists, or initiated Egyptian priests. Many occult alphabets and ciphers derived its origin from egyptian sacred ciphers, as also everything we know as cryptography today. I guess our english alphabet would be equally strange and uknown to them. But reading widely available documentation on Redhat's versioning system would definetly help in understanding its details. Everything after second - (dash) like in ftp-0.17-33 is Redhat's release version. In this case this is thirty third release or patch. It is similar to FreeBSD's naming convention. You can check changelog and see what has changed since release 1 by issuing: $ rpm -q --changelog <package> So the system is very clear and precise, just like FreeBSD system. The only difference is that upstream version of the package changes a lot more often than on redhat/centos. > 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. I think that most system administrators who maintain many FreeBSD servers in data center environments do not really care about "X.org, KDE, Gnome" and other desktop applications having those -SECURITY patches backported. The real concern here is about common server applications. I think that cutting edge users who run FreeBSD on their workstations are perfectly aware that things can sometimes break, and to a degree they accept that risk. But system administrators running mission critical nonstop systems 24/7 cannot accept such risk with the server ports they are using. So if anything can be improved in ease of upgrading, backporting etc. this is the main area to investigate, so as to make FreeBSD the most stable and reliable Unix operating system out there. -- Andy Kosela ora et labora
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3cc535c80806111350x237e2a4ewe1429b7a3f5b720>