[Secure-testing-team] what else needs a DTSA right now?

[Moritz Muehlenhoff]

Joey Hess wrote:
> Can anyone suggest any more good candidates for DTSAs in the list of
> unfixed holes in testing? I've been trying to cover all the remote
> exploits and bad local exploits and aside from updating the kernel and

I want to have a deeper look at this. Horms has some stuff pending
he hasn't had the time to backport yet and some CVE assignments are
pending, but preparing updated recent 2.6.8 and 2.4.27 packages
for etch seems like a good idea (as they are security/major fix only
anyway), until linux-2.6 has made it into testing.

> I also looked at these:
> 
>  - drupal: should get into testing soon on its own

The maintainer didn't add bug closers to his upload and therefore
the RC security bugs prevented testing migration for the last ten
days :-/

>  - bluez-utils: needs bluez-libs updated too, which could be tricky
>  - pdns: too young in unstable

BTW, To what extent did you test the packages, you've prepared so far?
These seem to be cases, where it would be best if the maintainer would
prepare fixed packages, as testing is rather difficult (requiring
Bluetooth gadgets or the knowledge to setup a relatively obscure DNS
server).

BTW2, in cases where the maintainer has uploaded fixed packages,
we should add them to the DTSA: to prevent ill-feelings/mischief and
also as a direct indicator who's to blame if something goes wrong ;-)

>  - zlib: too young in unstable, would rather not add new upstreams of
>    core libs to the repo until we know what can go wrong

The DSAs contain patches against 1.2.2, so they'd be good alternatives.

OTOH, I can't remember any major code changes, when I reviewed the changes
while preparing the fix for UCS; it was mostly portability fixes and
changes for contrib compression algos.

Cheers,
        Moritz