It was written:
>The major use I have for source code is adding minor new functions and
>altering old functions to provide different logging, slightly different
>functionality, adaption to a changing environment, etc.
>
>I think that source code is far more common and necessary in an
>environment without captive vendors. For example, Windows source is
>essentially unnecessary because Microsoft monopolizes the market. If
>source was out there, it wouldn't help because they would change it all
>in the next generation to keep the vendors in line. IBM mainframe
>source is similarly closely held in much the same way, and it is not
>really an impediment to mainframe operations.
>
>In the Unix environment, source is needed because there are so many
>different development lines that compiling everything for every version
>is very expensive. Since there is no dominant market force, vendors
>cannot force you to take their software, and source code provides the
>only means of doing maintenence on many of the development lines. I run
>a bunch of obscure Unix packages that I have run for 15+ years,
>compiling them for 3B2s, Suns, Interactive Unix, FreeBSD, and SCO Unix
>at various times, and porting them as OS versions came out with other
>advantages.
>
>Source code is far more useful in performing security-related and
>systems administration functions than in many other fields. For
>example, adding special logging to most applications is done in the user
>code, while adding logging to a network interface for security purposes
>is an OS modification that cannot be done at the user code level. About
>7 years ago, I modified a version of the Unix shell to add integrity
>features - impossible to do practically without the source, but
>something a normal user would never need or wish to do. I made a
>special version of the Find command for some reason or another, again an
>important change for systems administration, but not the sort of thing a
>user would ever need to do.
>
>In other words, normal users don't do many things that require source
>code, while systems admins and info-sec experts do. That's why we want
>source code all the time, and those users don't get it.
I find the fact that people want to modify source code interesting. I
might be able to forgive changing code for logging or adding additional
logging, but the fact does remain that this code is used to secure a
site. And even if you read the code and think that you understand the
code and have considered the codes interaction with other subsystem--you
could still introduce a new bug. (This is not saying that the code
writes might not do the same--but they are responsible for their work).
But this does propose a problem, what if the designers redesign the
security code, what do you do then? Who is responsible if your change
causes a security problem? Or better yet, what if your changes have some
ripple effect to some other subsystem and an issue that was not a
problem before now becomes a security hole. Trying to support changes like
this can become a real problem. I have seen many people who try to modify
code of this nature and make a real mess of things. Mostly because their
understanding was not complete.
Even though we include source code with our distribution, I would not suggest
that anyone make changes. It gets real hard to try to support a product
and changes as well. I can not guarantee that any changes that are
made will work in the next version. And we really don't have the time
to debug people's code. If there are changes needed, I would rather
have that information placed in the engineering process so we can
include the functionality in the next release. That way there is true
support for the change and if there are problems we can deal with them.
Frank
Follow-Ups:
|
|
