From owner-freebsd-stable@FreeBSD.ORG Wed Jun 11 20:50:36 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 67B8B1065673 for ; Wed, 11 Jun 2008 20:50:36 +0000 (UTC) (envelope-from andy.kosela@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id 37E028FC21 for ; Wed, 11 Jun 2008 20:50:35 +0000 (UTC) (envelope-from andy.kosela@gmail.com) Received: by wa-out-1112.google.com with SMTP id j4so2417901wah.3 for ; Wed, 11 Jun 2008 13:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition; bh=Zb9/L4v9Nb4+yyC9t/lNAGdF7R23l5aFNyMsnKZY5Lg=; b=anIOgRmMZIIOJQm8EChEZhOFrLIJi0Ep99hu1u2LPJfmHoJNRbUwPvUIUUkKaasD84 JixuqN+v1jHk4100TSq35sA8W4YjEh4bYfu6JdD0sQshugrQlLTMBP/JSM4WRtEQbdwn DRul0UmL+1tJjXe0U7xpIrKO67vm0IBkXXLmI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition; b=M9+i8C01NVYLYqAdNQN5h03Ly9s9HPD0WPi7lURujCMBBGBEmoUpUOe2fCY2N3QMrJ 6a0EhlkKTN69iJbQWL+pxpVox0vrcvF0KkAnHv8scI5r9G/iGweYOvEJFO26/u8qT9kv +YJbL9wQxzyK+JtZoLQVsENUn1UE/DTDBbB7Y= Received: by 10.114.159.6 with SMTP id h6mr509670wae.65.1213217435043; Wed, 11 Jun 2008 13:50:35 -0700 (PDT) Received: by 10.114.112.6 with HTTP; Wed, 11 Jun 2008 13:50:34 -0700 (PDT) Message-ID: <3cc535c80806111350x237e2a4ewe1429b7a3f5b720@mail.gmail.com> Date: Wed, 11 Jun 2008 22:50:34 +0200 From: "Andy Kosela" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: pschmehl_lists@tx.rr.com, rwatson@freebsd.org Subject: 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 20:50:36 -0000 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 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