Code ownership with both open source and closed source
software, is the norm. There is a slighty difference from
my POV with the two though.. In the closed source model,
it still often lacks peer review (though many closed source
models also include code review before being pushed into
the main trees etc; which also occurs in open source). It
is important though, that in either model, this process is
often flawed, because neither the code owner/maintainer/
developer/reviewer typically catches all the problems; the
open source model allows for external peer review (which
doesnt occur too much in closed source), which often brings
out new problems.

I've worked on closed source software before, and although
code ownership was normal, expected, and necessary; it
also requires people not to be bound by code ownership to
review "other peoples" code. This is sometimes necessary,
because the problem with "your" code, is actually a problem
with "someone elses" code, which only manifests itself,
when you try to implement something that is "expected" to
work, but has never been tested in this new context.

If you do not have the ability to go through mountains of
code to get the damn thing to work, the entire thing
pretty much stops and your product gets into a mess (IMO).
This type of model occurs with opensource by nature.

2 examples..

In recent times, I was using the NTFS kernel code in the
linux kernel to do some "non normal" things.. though,
turned out certain parts of the code were not fully tested
in the context I was trying. Parts of the code were
quite broken since no-one was actually using these
"features" as the norm.. However, I was able of course to
patch what was necessary in that instance. (the problems
i speak of which are quite trivial are just a number
of incorrectly formatted printk's for debugging - requires
some compilation changes to see these though. They are
also resolved in current kernels).

Into userland.. using sigaction under Linux in glibc 2.1
resulted in some cases where it would not correctly return
the right error codes. This made the software using this
to break (although it "should" have worked). Looking
at the glibc sources directly, immediately showed the
problem (2 minutes to find this), and we are able to
implement a small workaround that we knew was safe. This
issue was fixed in later glibc (dont worry anyone).

Now.. these problems were not widely reported by the
community, but they _did_ exist; and then manifested
themselves when I tried to do something that "should" have
worked, but didn't. I was able to get both cases above
working without any slowdown in my normal development -
something which would not have been conceivable with a
closed source model.

oh wait :) The oracle binary only libraries.. I had to
patch the binaries so they would work in some software,
because the symbols were rather broken.. Also the oracle
code was doing some rather annoying things that was
causing our own code to have problems (ie, crash).
These were a PITA to get working with our own code (which
was also closed source), and to be honest, I never really
felt that comfortable with what I was doing (when you
start doing binary patches its a good sign). It caused
annoying headaches for development, and we knew what was
going to come into the next binary releases (previous
versions were also rather buggy, segv'ing on their own
under conditions) - a definate PITA, because at that
point, unless we fully reverse engineered these binaries
back to source - I really couldn't garuantee much
of the internals (symbol patches were mostly interfacing
issues).

so.. when some MS product crashes, and your own software
_depends_ on being stable.. what do you do at that
point in all honesty? You can't do anything except report
it to MS who may decide that its a low priority bug..
In the opensource model.. you can fix this yourself, and
immediately you benefit the entire community (generally
without them even knowing! - but they can if they want
to -->

Random crashes in software using some versions of glibc,
but the open bug mailing lists describe the problem, show
the fixes, show what versions have these fixes, and show
workarounds also :) [i was only a year or so late in
witnessing this bug though - but I was able to have it
knowingly protected here, because the problem was so well
documented.. yes.. you cant just change glibc versions
on production systems because you have a few crashes :(

--
Silvio

[ reply ]

Link to this comment: http://www.securityfocus.com/comments/columns/127/17272#17272