Date: Fri, 14 Dec 2007 20:40:20 -0800 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Modulok" <modulok@gmail.com> 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... Message-ID: <BMEDLGAENEKCJFGODFOCMEDICFAA.tedm@toybox.placo.com> In-Reply-To: <64c038660712141728h7fe4d10bt2fbe148533f6707e@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----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... > > > <rant> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BMEDLGAENEKCJFGODFOCMEDICFAA.tedm>