[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packages removed from frozen

>>"Craig" == Craig Brozefsky <craig@red-bean.com> 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
 >> issue? 

 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
 thought so.

        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
 Craig> themselves,

        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
 Craig> welcome.

        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   <srivasta@debian.org>  <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

Reply to: