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

Joey Hess joeyh at debian.org
Tue Aug 30 15:44:42 UTC 2005


Moritz Muehlenhoff wrote:
> 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.

The big problem with this is that it cannot be autobuilt since etch
still has all the different kernel source packages.

> > 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 :-/

Yes, just closed it though. I'll also hint it as urgent since it's
already had sufficient testing.

> >  - 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).

My testing has varied. I have at least tested that each package
installs, but if I don't use the package it is hard to do any kind of
complete testing. 

In cases like these where I am only rebuilding a package from unstable
on testing with no changes, the opportuities for breakage should not be
much more than those occuring during normal autobuilding though.

One nice opportunity we have though, is to let developers do uploads and
testing, so I do encourage that.

> 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 ;-)

Heh, sure, any idea where to list them?

> >  - 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.

Would you like to do a DTSA for it?

-- 
see shy jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20050830/f3b8c264/attachment.pgp


More information about the Secure-testing-team mailing list