On Wed, Aug 11, 2004 at 10:21:06PM +0200, Nicolas Boullis wrote:
> Hi,
>
> On Tue, Aug 10, 2004 at 05:11:18PM -0700, Shaun Jackman wrote:
> >
> > This is my point exactly. Upstream's binaries are technically perfect.
> > There is no technical advantage to rebuilding them. That being the
> > case, I see no need to rebuild them.
>
> How can you be know if upstream is not putting some evil backdoor in the
> binary? It's much easier to hide something evil in a binary than in
> source code.
> (And don't tell me it never happens. Some time ago, a disappointed
> upstream author added ome slightly damaging code against Debian; the
> maintainer did not realize and uploaded the package...)
This isn't particularly relevant; the micq problem occured in (slightly
obfuscated) source code, not in a binary blob. And nobody has said that
it shouldn't be a serious bug if you can't rebuild a working package from
'pure source' which must still be included.
The main question seems to be an issue of whether one favors either:
A) 1) Saving time on the autobuilders (potentially lots of it), and
2) Having a 'pristine' copy of the upstream tarball,
or
B) 1) Ensuring that the security team won't run into a nasty 'gotcha'
that nobody realized was there, and
2) Giving DFSG-free compilers more excercise (in this case).
If the authors hide malware in a binary blob, they're just as likely to
hide it in an obfuscated form in the source; short of actually auditing the
source every time you pull it from upstream, there is little a maintainer
can do about this (and as the micq issue demonstrated, auditing source in
this manner is not a practical thing to do for most Debian packages, unless
we have reason to distrust them).
--
Joel Baker <fenton@debian.org> ,''`.
Debian GNU/kNetBSD(i386) porter : :' :
`. `'
http://nienna.lightbearer.com/ `-
Attachment:
pgph053gx2Rw5.pgp
Description: PGP signature