[Secure-testing-team] Security update for fuse

[Moritz Muehlenhoff]

Joey Hess wrote:
> > Additionally, should testing-security provide security notices (such
> > as DSA's)? If so, how would this work?
> 
> I believe that we should do this, but have been waiting for the release
> of sarge for it, since I'm not sure if we can do something to get the
> testing-security (and/or testing-proposed-updates) queues to remain
> functional after sarge is released, to get packages built against etch.
> 
> If those queues do function that way, then we should be able to do full
> DTSAs for all architectures using them. If not, we will still be subject
> to other issues that block security fixes from testing, or will have to
> set up our own queues and autobuilder network (or piggyback on the
> experimental autobuild network). Doable, but kinda a pain.
> 
> There's also the issue of whether we can get upload access to
> security.debian.org, and of who can actually upload packages and sign
> and email the DTSA messages (probably only the official DD's on the
> team).

Don't underestimate the time required for providing a security update.
So, first we should find criteria for issues that should be handled through
secure-testing, ideally in a form suitable for data/CAN/list. Several
of the issues right now listed in newraff.d.o/t-s.h do not really deserve
urgent action (and they begin making the overview a bit crowded). I'm
thinking of some "minor" tag for uncritical tempraces, packages not
vulnerable in the Debian package, and generally obscure issues.

Fixes built against testing are definitely needed, e.g. the fix included
in latest Firefox wouldn't be showing in Etch during the next 2-3 months
otherwise. IMO the best solution for this would be fixes uploaded by the
maintainers themselves, with an option to pass the ball to the secure-testing
team if they're not interested/don't care/don't know whatever (which is a
not too small margin). Ideally there'd be a simple way in which a maintainer
could denote his intentions towards t-s handling in an easy way. Judging from
experiences with reaction times towards security related bug reports reaction
times vary from "fixed within < 1 hr" (e.g. the leafnode maintainer) up to
"no maintainer reaction for months, even with included patch and pending
stable release". The complexity of the vulnerable packages is not to be
forgotten, e.g. the proposed gdb fix looked simple and correct, until Dan
Jacobowitz pointed out that there's a code path that does not initialize
cwdbuf, which isn't really obvious if you are not familiar with the gdb
sources.

I'd suggest to start an experimental service for i386 for now, if it works
out it can be extended.
For s-t purposes the requirements for arch synchronity should be lowered,
it doesn't make sense to withhold security fixes because of slow/buggy
archs. This is needed for a stable release, but for a volatile target like
testing it doesn't make much sense.

DTSA seem like a good idea. For the sake of consistency it seems like a good
idea to issue them from the s-t team. When doing so we should talk to the MITRE
people whether DTSAs would qualify as CVE data sources. There are currently
55 vulnerabilities tracked by us that haven't ever received a CVE assignment,
some of which may as well be in other vendor's products. (MITRE may be only a
dictionary, but in practice it's more). Oh, and we should keep in mind the
upcoming naming change in MITRE's processes (I think it starts in august?)

Additionally I'd already started to write a tool that provides a system specific
overview of vulnerabilities affecting a system (generated from CAN/list), which
should improve the state of testing's security from a user's perspective,
as well, but I'm currently busy with diploma stuff (I hope to get around to it
during the next weeks).

Cheers,
        Moritz