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

Re: (inc. note from dpkg developers) Re: Bug#XXXXXX: (far too many packages) needs rebuilt for prelinking



On Mon, Jan 13, 2003 at 09:42:01AM -0600, Adam Heath wrote:
> On Mon, 13 Jan 2003, Jack Howarth wrote:
> 
> > Adam,
> >     Well, if you consider setting off tripwire to be very bad then
> > all of sid built on ppc before binutils 2.13.90.0.14 needs to be
> > rebuilt against the current binutils. Those older binaries will all
> > have non-zero *r_offsets in the unprelinked form which will prevent
> > prelink from being able to unprelink a prelinked binary back to the
> > original form.
> >     This is all somewhat theoretical anyway as no one has modified
> > tripwire to be able to cope with a prelinked system yet. Jakub had
> > discussed this briefly here...
> 
> Er, huh?  What does that have to do with *modifying the binaries at all*?
> 
> Running prelink *itself*, which modifies the binary, is the problem, not that
> some field is set incorrectly.
> 
> And I certainly hope tripwire is *not* modified to support such a broken as
> designed system.
> 
> (the reason this is broken, is because one must run an untrusted binary to
> check if the file has been modified)

Oh, Adam, that's blatantly ridiculous.  Think about it.  You take
whatever you do to dpkg and libc6 and tripwire in order to trust them
and do it with prelink also.  Then it's a trusted binary.

> As a dpkg developer, I will NOT support anything in dpkg that invovles
> modification of original files.  Not even if it is reversible.
> 
> <Official Notice>
> Any such prelinking done to any system managed by dpkg may and possibly will
> break in the future.  We(Wichert and I) reserve the right to implement such
> sanity checking features as checksum verification, and any file modified
> outside of dpkg itself will be suspect, and flagged as such.
> </Official Notice>
> 
> ps: I passed this by Wichert first, before sending

I tried to get Wichert's attention before answering, but he's gone to
sleep, so I'll just say it here:

Your position as a dpkg developer does not give you a godlike hat of
policy setting, and is the wrong forum from which to make such
decisions about technologies you've demonstrated that you do not
understand properly.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer



Reply to: