On Fri, Feb 14, 2003 at 12:48:03AM -0600, Manoj Srivastava wrote:
> >>>>> In article <[🔎] 20030214061134.GB20555@gwyn.tux.org>, Timothy Ball <timball@tux.org> writes:
> > I'm of the firm mindset that you should have to pass some sort of
> > test or get a license to write code that a) runs as root b)
> > interacts w/ the kernel. By the same token it seems logical that a
> > deb maintainer should at least test the pkg before it's put in
> > incoming.
> But is the person in question tested it, it would have
> worked -- the 'xploit was clever enough to test for the presence
More particularly, it had a delayed activation. The package was working
fine until about a week after it was uploaded to Debian, and almost
three weeks since it was release upstream.
> All One can really ask a maintainer is that the auses opckage is
> installable, and they ran the apckage through a test
> suite.
I'm still not seeing any real reason why we can't ask the maintainer to
look through the upstream changes. Sure, you mightn't be able to do it
for the kernel, or bind, but most packages aren't remotely that difficult
to hunt through.
> Unstable is an integral part of testing an QA process for
> debian -- the precise user base that the micq trojan targeted.
Note that malware that has delayed activation can easily pass through
all the tests we have -- unstable, testing, RC bugs, autobuilding, etc.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``Dear Anthony Towns: [...] Congratulations --
you are now certified as a Red Hat Certified Engineer!''
Attachment:
pgpxRmLzD8hAo.pgp
Description: PGP signature