From owner-freebsd-questions@FreeBSD.ORG Sat Dec 15 04:39:17 2007 Return-Path: Delivered-To: FreeBSD-Questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A6CF16A419; Sat, 15 Dec 2007 04:39:17 +0000 (UTC) (envelope-from tedm@toybox.placo.com) Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [65.75.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id A20EE13C45D; Sat, 15 Dec 2007 04:39:16 +0000 (UTC) (envelope-from tedm@toybox.placo.com) Received: from TEDSDESK (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) by mail.freebsd-corp-net-guide.com (8.13.8/8.13.8) with SMTP id lBF4dENM047428; Fri, 14 Dec 2007 20:39:15 -0800 (PST) (envelope-from tedm@toybox.placo.com) From: "Ted Mittelstaedt" To: "Modulok" Date: Fri, 14 Dec 2007 20:40:20 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 In-Reply-To: <64c038660712141728h7fe4d10bt2fbe148533f6707e@mail.gmail.com> X-Mailman-Approved-At: Sat, 15 Dec 2007 04:43:40 +0000 Cc: samba@lists.samba.org, WD@us-webmasters.com, Timur@freebsd.org, remko@freebsd.org, FreeBSD-Questions@freebsd.org Subject: RE: Yikes! FreeBSD samba-3.0.26a_2, 1 is forbidden: "Remote Code Execution... X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 04:39:17 -0000 > -----Original Message----- > From: Modulok [mailto:modulok@gmail.com] > Sent: Friday, December 14, 2007 5:29 PM > To: Ted Mittelstaedt > Cc: WD@us-webmasters.com; samba@lists.samba.org; remko@freebsd.org; > Timur@freebsd.org; FreeBSD-Questions@freebsd.org > Subject: Re: Yikes! FreeBSD samba-3.0.26a_2, 1 is forbidden: "Remote > Code Execution... > > > > Which is ever so irritating... > > In 40 years of lessons learned from the school of hard knocks in > relation to the design and evolution of both programming languages and > the software designs they implement, one truth has emerged: data > hiding increases the robustness of a program. Functions hide data, > classes hide data, namespaces hide data, the very concept of scope, > hides data. Yet, when we pull back and look at a slightly larger > picture of the interactions of programs themselves, we fail short of > carrying this idea through to a higher level. Package X depends on > package Y, but package Y depends on package Z, but package Z cannot be > installed because of a name conflict with package W. Update program X > and you could break what appears to be an un-related program J. Tough > luck. > > Code re-use is a good thing. Intricate, far-reaching dependencies are > not. While package managers attempt to mitigate the underlying issue, > using code re-use as an excuse for the fragility of a system design, > is unfortunate. I do not pretend to have all of the answers, but I > feel that current state of things could be much improved. The rot started years ago when Sun and others introduced the concept of dynamically loaded libraries. Time was that everything was statically compiled. An update to a library file would break nothing. But at the time, they had a problem - limited ram - available. This solved it with the tradeoff that updating would require recompiling a lot of stuff. Fast forward to today, when 2-4GB of RAM in a computer is standard. There's no penalty to statically linking all your libraries into a binary that isn't going to see more than 2-3 simultaneous instances in memory. But the thinking is still ossified back in the 80's as by default every program you build will dynalink. Ted No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.17.2/1184 - Release Date: 12/14/2007 11:29 AM