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

[Moritz Muehlenhoff]

Florian Weimer wrote:
> > 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.

Yes.

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

Or we could as well leave the {} entry blank.
 
> 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.

I guess so, maybe with a NOTE: that describes the difference towards -1
 
> 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.

Well yes, but collection the information for these lines is the time-consuming
part :-)

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

Did you handle the issues that didn't result in a DSA as well? I.e. collecting
the information from the original advisories, reading the source or similar
sources? E.g. for the plethora of Mozilla issues in Woody this seems nearly
impossible. Or don't you maintain a "not-vulnerable" state for these?
 
> >> ("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.

I guess we should do so. Steven is that responsive that it should never
really block a DTSA.
 
> 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.

If you've already collected a lot of data it should definitely be merged
into the regular CAN/list and at least be maintained on a best-effort
basis. Personally I won't have that much time to maintain the entries for
Sarge and Woody, though, but I think we should keep it in SVN. Maybe
we can merge information easier with the stable security team later on.

What syntax did you use to mark an try as as the Woody or Sarge fix? Do
you track the Sarge/Woody fixes in CAN/list or do you still keep them in
DSA/list?

Cheers,
        Moritz