[Secure-testing-team] "FIXES:" and "FIXED-BY:" directives

[Florian Weimer]

* Moritz Muehlenhoff:

> I think the basic principle is useful and needed. IMO the fix for
> sid should be exclusively kept in CAN/list and not further
> duplicated in DSA/list, as these tend to get out of sync, when
> people forget to adapt them in DSA/list as well.

And the fix for etch should be kept in lists/DTSA.

In my local branch, I try to keep this distinction, although sometimes
an etch entries creeps into CAN/list.

> You proposed FIXES:, but I think as it's already present in {}, I
> don't see much advantage, but I don't have a real opinion on it.

There are a couple of cases where I do not use FIXES:, but an ordinary
cross-reference:

[September 15th, 2005] DTSA-16-1 linux-2.6 - various
	{CAN-2005-2098 CAN-2005-2099 CAN-2005-2456 CAN-2005-2617 CAN-2005-1913 CAN-2005-1761 CAN-2005-2457 CAN-2005-2458 CAN-2005-2459 CAN-2005-2548 CAN-2004-2302 CAN-2005-1765 CAN-2005-1762 CAN-2005-2555}
	NOTE: Just a pointer to the security update in testing.

AFAICT, there wasn't a real testing-security upload associated with
this DTSA.  I also removed the package annotation (because the
implicit etch annoation for the DTSA file resulted in an ordering
constraint violation).  So in this case, an implicit FIXES:
constructed from {...} wouldn't actualy hurt.

The next one is:

[28 Sep 2005] DSA-797-2 zsync - buffer overflow
	{CAN-2005-1849 CAN-2005-2096}
	NOTE: An upload to fix a build failure on i386

This is just a fix-the-fix, for a package which didn't install on i386
only.

[21 Aug 2005] DSA-779-1 mozilla-firefox - several
	{CAN-2005-2260 CAN-2005-2261 CAN-2005-2262 CAN-2005-2263 CAN-2005-2264 CAN-2005-2265 CAN-2005-2266 CAN-2005-2267 CAN-2005-2268 CAN-2005-2269 CAN-2005-2270}
	[sarge] - mozilla-firefox 1.0.4-2sarge2 (medium)
	NOTE: not fixed in testing at time of DSA (build and deps)

This DSA was later supersed with:

[21 Aug 2005] DSA-779-2 mozilla-firefox - several
	NOTE: Essentially 1.0.6 with rolled-back version number, backported version had regressions
	FIXES: CAN-2005-2260 CAN-2005-2261 CAN-2005-2262 CAN-2005-2263 CAN-2005-2264 CAN-2005-2265 CAN-2005-2266 CAN-2005-2267 CAN-2005-2268 CAN-2005-2269 CAN-2005-2270
	[sarge] - mozilla-firefox 1.0.4-2sarge3 (medium)
	NOTE: not fixed in testing at time of DSA (waiting on dependencies)
	NOTE: Fixed in DTSA, which will have the same regressions, should be checked/reverted

I think in such cases, we could remove the package annotation for the
broken DSA.

Or I could tweak the FIXES: propagation code so that it merges
conflicting version annotations.  However, this would mean less
checking.

> Wrt your other suggestion, to track the versions of the fixes for
> sarge and woody as well; IMO this would be quite a lot of additional
> work and it would only be fruitful if done in coordination with the
> stable security team.

It's just two more lines per DSA.  You only have to remember that the
DSAs don't give the epoch part of package versions.  Apart from that,
it's straightforward.  I've reconstructed the status of sarge based on
the DSAs issued so far.  woody is slowly progressing as well.

>> ("FIXED-BY:" is needed because you cannot reference the FAKE-* entries
>> in the other direction; they haven't got a real name.)
>
> The only direction is from DSA->CAN/list, isn't it?

Not quite, there's also the DTSA->CAN direction:

CAN-2005-XXXX [cgiwrap: Minimum UID does not include all system users]
	FIXED-BY: DTSA-6-1
	- cgiwrap 3.9-3.1 (bug #316881; low)
CAN-2005-XXXX [cgiwrap: CGIs can be used to disclose system information]
	FIXED-BY: DTSA-6-1
	- cgiwrap 3.9-3.1 (bug #316901; low)

If you assign a CVE name before you issue a DTSA (technically, SPI has
already agreed on your behalf that you will do that, BTW 8-), this
kludge won't be needed anymore.

So, to sum it up: You are probably right that FIXES:/FIXED-BY: is
unnecessary.  But I don't agree with you that tracking sarge is much
extra work.