Re: Packages removed from frozen
>>"Craig" == Craig Brozefsky <firstname.lastname@example.org> writes:
Craig> So at THAT point in the thread it appears that the issue is package
Craig> removal, not marking packages in a list if they need themselves to
Craig> build. You introduced the notion of an exemption list after someone
Craig> mentioned GCCs dependence upon itself. That was in a different branch
Craig> of the thread I was repsonding too and I did not assume that your
Craig> proposal for just listing exceptions was the topic of the branch we
Craig> were involved in.
Goes to show I adapt my views, given arguments that are
convincing. A pity that people do not follow the shifting nuances of
a thread of conversation.
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
Craig> Because they list themselves in the Build-Depends?
Not good enough. I have to go shifting through 4000 odd
package descriptions to see how many refer to themselves (which, I am
given to understant, is around 40 packages -- like, 1%, there are
bound to be misses).
This still needs to be documented separately.
Craig> But even that does not really satisfy the paranoid, as a
Craig> program that is processed by another program during the build
Craig> process could have trojans put in then.
And they can then audit the source, and recompile as
needed. Npw, if they knoew about the circular depends, they
can take special care with those packages, using cross compilations,
running in secure virtual machines for extended periods, or what have
Our job is to make that possible.
Craig> Who are we going to trust to make us the gcc binary to compile
Craig> the kernel and libc5 to get system booted to compile those?
Who is we? Are you one of the paranoid? I would not have
I seldom am, unless wearing certain specific hats.
But there are ways that the paranoid can do this, like cross
compiling on their C2 Secure VMS box with audited gcc sources.
Craig> Perhaps we should look for any program processed by another
Craig> program as being suspect. Afterall, the backdoor was put into
Craig> login, as well as new compiler binaries.
If you think you need that, sure.
Craig> Actually, I used to do it for a living, not that getting paid
Craig> for something makes one competent. What professional
Craig> experience in the field did teach me is that the specifics of
Craig> hacks are of little concern, and we should not confuse those
Craig> trees for the forest if we want to have a real impact on the
Craig> security of our systems.
So in your expert opinion binaries that can only be built with
a version of themselves are merely trees to get lost in? *shakes his
head in wonder*.
Sorry. In my book, that is more of a security risk than code
that can be built straight forwardly frm sources.
Craig> The point being that there is no way to protect yourself from
Craig> running untrusted code absolutely.
That does not mean wi throw up our hands and throw out shadow,
login, pam, and heimedal.
Just because there is no way to be absolutely sure you are
running trusted code is one have ones own semicinductor plant is no
reason not to dicument code that can't be built from source.
Craig> When it comes down to it, those same Debian maintainers are
Craig> the people we have to trust, because they are giving us
Craig> binaries and source. If you really want to serve the user
Craig> community then start doing audits of all packages, regardless
Craig> of wether they require themselves to build or not, as that is
Craig> a truly arbitrary criteria. If it makes you feel better
Craig> personally to start with those programs, then feel free, but
Craig> requiring Debian to maintain a list of these special programs
Craig> has no effect at all on real security, and does nothing but
Craig> confuse the issue.
Never the middle line, is there, as far as you are concerned?
Never the concept of making the barrier hughrer? Of documenting
things that can be a risk? Every argument has to be taken to the
Craig> OpenBSD has been auditing their tree since the mid 96, with 12
Craig> of the best auditors in the FS world. I don't see any
Craig> indication that they treat programs which depend on
I don't want to get into a pissing contest with who has better
experts. Just because OpenBSD does things one way is not really
reason enough to be convincing.
Craig> or programs that require other programs to process
Craig> them, or programs that process other programs differently than
Craig> vi, or emacs, or libgif.
You are the one that proposed that we treat programs that have
been treated by other differently. I just drew the line at
programs that can't be built from source.
Sorry, You can't just keep on putting strawmen, and knocking
them down, hoping you'll prove your case.
>> The special procedure could document whatever security measure
>> were taken to audit the code, if any.
Craig> Why just these packages? Why not every package that handles other
Craig> programs, why not every package for that matter? Again,
Craig> distinguishing between rscheme, gcc, and vi makes no sense if our goal
Craig> is to serve our users security needs.
I see, You are being delibrately obtuse. I am objecting to
programs for whom a simple audit of the source, no matter where I
start, is going to be adequate.
In the case of the other programs, once I convince myself gcc
is safe, all I need look at is the source of the other package, and
incrementally convince myself there are no holes.
Circular dependencies break that sufit path.
Craig> I think you are focusing on too narrow an issue and should broaden the
Craig> horizon of your scrutiny a bit. I don't expect you to retract your
Craig> position, but I think the argument I give above is enough to keep it
Craig> from becoming policy without the notion of tracking audit status and
Craig> the like being expanded to include all packages, a policy that I would
Oh tracking all 5000 packages is definitely noce, but it is
unlikely to happen in a hurry. Tracking 40 package which are at a
higher risk is more feasible, and I shall take your hint and move
this over to -policy.
If something's not worth doing, it's not worth doing well.
Manoj Srivastava <email@example.com> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C