(inc. note from dpkg developers) Re: Bug#XXXXXX: (far too many packages) needs rebuilt for prelinking
On Mon, 13 Jan 2003, Jack Howarth wrote:
> Well, if you consider setting off tripwire to be very bad then
> all of sid built on ppc before binutils 22.214.171.124.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
(the reason this is broken, is because one must run an untrusted binary to
check if the file has been modified)
> Currently rpm is probably the only prelink-saavy program that
> knows to try 'prelink --verify' on binaries before checking
> the checksums. Again none of that will help on debian ppc sid
> until all of the binaries are rebuilt against the proper binutils.
Then rpm is busted.
As a dpkg developer, I will NOT support anything in dpkg that invovles
modification of original files. Not even if it is reversible.
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.
ps: I passed this by Wichert first, before sending