[Secure-testing-team] Security update for fuse

[Joey Hess]

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

Yes, I agree we need something like that, perhaps to color code the
list. Picking out remote shell exploits or the like (very high priority
stuff) would also be handy.

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

Right, this is always an interesting line to tread when doing NMUs,
especially now that sarge is released and people may not be expecting
zero day NMUs.

> I'd suggest to start an experimental service for i386 for now, if it works
> out it can be extended.

Works for me. I'm araid that Neuro is probably going to have to
prioritise getting the security system working again for stable over us,
since that is apparently not working at all right now. Sigh.

Anyway, an experimental apt repo for this is easy enough to set up. I
wonder where we should mail the announcements? We might also want to do
announcements for holes that get fixed in testing via regular testing
propigation.

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

Couldn't we just get a pipe to mitre and submit those? I assume we have
other data sources for them that mitre could point to, such as the
debian BTS.

> Oh, and we should keep in mind the
> upcoming naming change in MITRE's processes (I think it starts in august?)

Yes, it's in august and I won't be suprised if some scripts break.

> Additionally I'd already started to write a tool that provides a system specific
> overview of vulnerabilities affecting a system (generated from CAN/list)

That's a great idea!

-- 
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/20050615/f91ca9f2/attachment.pgp