Re: Packages removed from frozen
Manoj Srivastava <srivasta@debian.org> writes:
> Fine you find my security concern ludicrous (is ti so hard to
> document potential security problems?), I find your devil may care
> attitude about security appalling.
> And, since you are not reading what I write anyway (I have
> never said we throw anything out), there is no point in this
> discussion.
More than one person thought you said that, and looking back thru the
thread it seems that many people thought this because the original
issue was rscheme possibly being removed.
Here is the reason that I, and possible others thought we were
discussing removal of packages initially:
Rob> Granted a Build-Depends would be better, and I'll add that, but I
Rob> don't see why this is release critical, or why it warrants removal.
Rob> I'm downgrading this to wishlist, and I think that rscheme should be
Rob> restored to frozen.
Manoj replies:
Could one reason be that it can't be built from source? I have
considered being able to build from sourfe an important feature (I
really envy the install .src.rpm in a standard place; and rebuild
as simply as rpm --rebuild feature of rpm)
So at THAT point in the thread it appears that the issue is package
removal, not marking packages in a list if they need themselves to
build. You introduced the notion of an exemption list after someone
mentioned GCCs dependence upon itself. That was in a different branch
of the thread I was repsonding too and I did not assume that your
proposal for just listing exceptions was the topic of the branch we
were involved in.
> Craig> Why another list when Build-Depends does this already?
>
> DOes what? Every package has a build depends. How does that
> tell me that some 40 odd packages out of a few thousand have security
> issue?
Because they list themselves in the Build-Depends? But even that does
not really satisfy the paranoid, as a program that is processed by
another program during the build process could have trojans put in
then. Who are we going to trust to make us the gcc binary to compile
the kernel and libc5 to get system booted to compile those? Perhaps
we should look for any program processed by another program as being
suspect. Afterall, the backdoor was put into login, as well as new
compiler binaries.
> Craig> Your security argument is a strawman. The source code is
> Craig> still there, and the binaries are signed by a Debian
> Craig> maintainer.
>
> You have, obviously, no background in security.
Actually, I used to do it for a living, not that getting paid for
something makes one competent. What professional experience in the
field did teach me is that the specifics of hacks are of little
concern, and we should not confuse those trees for the forest if we
want to have a real impact on the security of our systems.
> There hae been trojans propogated in binaroes which depended
> on themseleves wothout ever appearing in source code.
I think you are confusing the moral of the story that Ken Thompson
told (not Pike unless this story appears in multiple places, the most
common attribution I find is "Reflections on Trusting Trust" by Ken
Thompson available at http://www.acm.org/classics/sep95), with the
specific example he gave of how to make someone run untrusted code.
Here is the "Moral" from the story, straight from Ken Thompson:
The moral is obvious. You can't trust code that you did not
totally create yourself. (Especially code from companies that
employ people like me.) No amount of source-level verification or
scrutiny will protect you from using untrusted code. In
demonstrating the possibility of this kind of attack, I picked on
the C compiler. I could have picked on any program-handling
program such as an assembler, a loader, or even hardware
microcode. As the level of program gets lower, these bugs will be
harder and harder to detect. A well installed microcode bug will
be almost impossible to detect.
Note that Thompson states that any program-handling program could have
been used. To pick on the C compiler, or other programs that are
built by themselves seems to miss the point. The point being that
there is no way to protect yourself from running untrusted code
absolutely.
> And the Debian maintainer may have no more experince in
> security matter than the average person, and, looking at the
> responses on this thread, may not even be aware of the risks.
When it comes down to it, those same Debian maintainers are the people
we have to trust, because they are giving us binaries and source. If
you really want to serve the user community then start doing audits of
all packages, regardless of wether they require themselves to build or
not, as that is a truly arbitrary criteria. If it makes you feel
better personally to start with those programs, then feel free, but
requiring Debian to maintain a list of these special programs has no
effect at all on real security, and does nothing but confuse the
issue.
OpenBSD has been auditing their tree since the mid 96, with 12 of the
best auditors in the FS world. I don't see any indication that they
treat programs which depend on themselves, or programs that require
other programs to process them, or programs that process other
programs differently than vi, or emacs, or libgif.
> The special procedure could document whatever security measure
> were taken to audit the code, if any.
Why just these packages? Why not every package that handles other
programs, why not every package for that matter? Again,
distinguishing between rscheme, gcc, and vi makes no sense if our goal
is to serve our users security needs.
> Craig> No more threat than any other package in Debian. One could
>
> You have no idea what you are talking about. I'm sorry, but
> you are letting your inexperience show; there is a difference, unless
> extra steps are taken to break the loop manually.
I think you are focusing on too narrow an issue and should broaden the
horizon of your scrutiny a bit. I don't expect you to retract your
position, but I think the argument I give above is enough to keep it
from becoming policy without the notion of tracking audit status and
the like being expanded to include all packages, a policy that I would
welcome.
--
Craig Brozefsky <craig@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
"Hiding like thieves in the night from life, illusions of
oasis making you look twice. -- Mos Def and Talib Kweli
Reply to: