On Tue, May 27, 2008 at 3:33 PM, Julie [email protected] wrote:
As a noob to Linux I found these articles somewhat "interesting":
-->Not Invented Here has no place in open source development IT Security TechRepublic.com
http://blogs.techrepublic.com.com/security/?p=460&tag=nl.e036
-->Detect and replace vulnerable SSH keys on Debian IT Security TechRepublic.com
http://blogs.techrepublic.com.com/security/?p=459&tag=nl.e036
wahdooya'l think? Jus' curyuss........
I think it's silly what little effort it takes to call yourself a tech Journalist these days. He paints in broad strokes a bit with the traditional anti-patterns identified in corporate development. Debian developers did get in touch with upstream OpenSSL, despite OpenSSL's best efforts to hide. A member of the core team did get in touch, and suggested "if it makes debugging easier, I'm all for it". Since it wasn't the main list, few other developers saw it, and the Debian developer pushed the patch out. Upstream even agrees today with half of the patch in Debian, but the other half is clearly the wrong fix. Rather than remove the access to uninitialized memory, the reasonable thing seems be to initialize it.
And the other example, I don't know as much about, but I do know that often one works around bugs in OSX simply because you have to. What's even crazier is when they change functionality in a major release, placing the burden on you to stop supporting older releases (the article's "right way") or forever carry a version #ifdef for the workaround.
Calling this "NIH" is downright stupid and contradictory to everything Debian does. NIH is about rewriting everything from scratch because obviously anyone not in the organization is an idiot and can't be trusted. Here we had a developer who noticed something, created a fix, and failed to get enough eyes at it when he went looking for it. I think the important lesson here, and one Debian could do well to memorize, is to make sure your development process is open and accessible.
Justin
So how about cases like FreeSWITCH where they fork (almost) every library they use (about 10 or so) and create their own "superior" (and incompatible) version to static link with?
Doesn't the gentoo project often do that as well? Sorry that was a reflex.
Eventually Anthony Minessale is going to run out of waking hours, or space in his svn repository, or both.
Including the library version that you link against in your project's source code has the very real practical result of making your project immune to surprise problems stemming from library version incompatibilities. Maybe freeswitch will clean up its interfaces (if it is in fact using unsupported interfaces to libraries instead of simply repairing bugs for own use) when they get around to it.
I don't think freeswitch has a not-made-here problem -- look at how heavily they use APR?
On Thu, May 29, 2008 at 2:57 PM, Luke -Jr [email protected] wrote:
So how about cases like FreeSWITCH where they fork (almost) every library they use (about 10 or so) and create their own "superior" (and incompatible) version to static link with?
On Thursday 29 May 2008, David Nicol wrote:
Eventually Anthony Minessale is going to run out of waking hours, or space in his svn repository, or both.
Or realize he's missing out on upstream fixes and such too.
Including the library version that you link against in your project's source code has the very real practical result of making your project immune to surprise problems stemming from library version incompatibilities. Maybe freeswitch will clean up its interfaces (if it is in fact using unsupported interfaces to libraries instead of simply repairing bugs for own use) when they get around to it.
In particular, FreeSWITCH uses internal headers (eg, NOT installed on systems even with the -devel packages) from xmlrpc-c, srtp, and sqlite. I can see the justification of the xmlrpc-c stuff-- they have issues with breaking compatibility on a regular basis anyway, but especially the SQlite stuff is a problem. They're using Sqlite not only as a database engine, but also the internal hash implementation (which exists only in the 3.3 versions, nothing older or newer). Anthony has stated that Sqlite is "too slow" (I wonder if 3.5 is?) so they will be trying to drop it altogether now that 1.0 is out.
For what it's worth, despite their complaints, I do have a branch of FreeSWITCH (in their repository, and available in my Gentoo overlay) that will use the regular system libraries (with dependencies on the compatible versions, so it will downgrade your sqlite to 3.3). Report bugs with it to them at your own peril/kick/ban, though.
-
David Nicol -
Justin Dugger -
Luke -Jr