[Secure-testing-team] Security update for fuse

[Joey Hess]

Moritz Muehlenhoff wrote:
> Ok, what about this:
> 
> CAN-2005-XXXX [buffer overflow in foo]
>         - foo 3.1.4
> 
> CAN-2005-XXXX [foo is DoSable when used in full moon and it's PID is a mersenne prime]
>         _ foo 3.1.4
> 
> As said in another mail I think very high priority stuff would best be
> prioritized by fixing it faster than the rest and that this is really hard
> to classify, but of course we could add something like:
> 
> CAN-2005-XXXX [remote root exploit in foo]
>         ^ foo 3.1.4

I like the levels, but the punctuation seems non-obvious. How about
this, which allows for future expansion:

CAN-2005-XXXX [remote root exploit in foo; also present but not built in bar's source]
	- foo 3.1.4 (high)
	- bar (unfixed; bug #101010; low)
 
I have a probably not quite working patch for this which I can commit
which will add the notes to the web page, we could also use this to
colorise it with shades of red or something.

> And it would be nice if our provisional vulnerability summaries were overwritten
> with MITRE's once this are issued, right now the script doesn't touch these.

This untested patch should do it:

Index: updatelist
===================================================================
--- updatelist	(revision 1231)
+++ updatelist	(working copy)
@@ -93,7 +93,11 @@
 		my $desc=$2;
 		docan($can) if $can;
 		$can=$1;
-		$cans{$can}{description}=$desc if length $desc && $desc !~ /^\(.*\)$/;
+		if (length $desc && $desc !~ /^\(.*\)$/ &&
+		    (! exists $cans{$can}{description} ||
+		     ! length $cans{$can}{description})) {
+			$cans{$can}{description}=$desc;
+		}
 	}
 	elsif (/^\s+NOTE:\s*(reserved|rejected)\s*$/) {
 		# skip it

> What about an additional Alioth ML for now? If it works out after the experimental
> phase it can still be promoted to a regular d.o list.

Good idea, I will set that up next time I'm online.

> > We might also want to do
> > announcements for holes that get fixed in testing via regular testing
> > propigation.
> 
> Yes, but I guess that's also for the not-experimental-anymore phase, as it's
> quite a lot of work.

Getting the list should be automatable, then the work is only a matter
of writing descriptions of the vulnerabilities. If we decide not to
offer a lot of detail it seems doable.

> And we need to track testing propagation, so that the specific fix is purged
> once the regular fix has propagated.

We need to make sure our fixes have a version number which allows the
regular fix to replace them on upgrade. Another problem is we need to
make sure that a new vulnerable version doesn't come in from unstable
and replace our fix. So I think limiting ourselves to security holes
that have RC bugs is a good idea (why do any more work that that
anyway), but still an RC bug could conceivably be downgraded or ignored
and so we'll have to make sure to catch these cases and relase a new
fix.

-- 
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/20050619/bf8001a9/attachment.pgp