On Fri, Feb 14, 2003 at 04:46:10AM +1000, Anthony Towns wrote:
> On Thu, Feb 13, 2003 at 07:37:23PM +0100, Russell Coker wrote:
> > > Personally, "drop any and all packages that these could affect" seems
> > > like a pretty poor solution, both in that it loses the most functionality
> > > of all possible solutions, and in that it can only be done after the fact.
> > In any case we can't take action about something that hasn't happened.
> Sure you can. The common term for doing that is "prevention". As in
> "prevention is better than cure".
> > As for losing the functionality, having a trojan horse in the distribution
> > (which is what mICQ is) is something we can't accept.
> A trojan horse? It prints out something equivalent to "The Debian
> developer sucks, use my .debs instead", and exits. It does so in a way
> that's obfuscated. If it had been written as:
> long Feb11th = 1045000000;
> if (strcmp(me, "madkiss") == 0 && time(NULL) > Feb11th) {
> printf("Please don't use these debs, they're broken.\n");
> exit(99);
> }
> would you still find it so offensive? Do you really think it's outside
> the upstream author's authority to add if statements, printfs and exit's
> to his program? Or to have the considered opinion that the Debian package
> is so broken, no one should use it?
Perhaps owing to the obfuscation employed, you overlooked the fact that
you've reversed the sense of one of the tests above? It does not print
this error when the username DOES match "madkiss", but rather when it
does not. In other words, the upstream deliberately inserted code that
would only activate when people OTHER than the maintainer tried to make
use of the package, apparently in the (fulfilled) hope that Martin would
not notice the change and upload a package that made him (and Debian in
general) look like a fool.
If the generated packages were broken across the board, so that the
maintainer had an opportunity to notice it and address upstream's
concerns, it would not be so much of an issue. If the upstream had
*told* Martin that he was making this change, it would not be so much of
an issue. Under the actual circumstances, however, I think it raises a
very serious question of trust.
> As far as avoiding getting trojan horses in the distribution goes, isn't
> that why we have maintainers?
It is certainly the case that a maintainer is responsible for making sure
the uploaded packages are sound, but I think we need to face facts here:
we don't have so many skilled developers that we can reasonably expect to
audit the diffs of every new upstream release that's uploaded into our
archive. We are very much exposed where upstreams are concerned, and the
best way to protect against that is to make sure we know and trust our
upstreams (and, be able to know and trust the origins of the tarball
we're downloading). When someone knows and does *not* trust their
upstream, well...
--
Steve Langasek
postmodern programmer
Attachment:
pgp4XmZX1vaSt.pgp
Description: PGP signature