Secure testing team - Mar 2006 - "FIXES:" and "FIXED-BY:" directives

I''ve added new FIXES: and FIXED-BY: directives to the Python code (but
not to the list files, of course -- this is up to you).

This allows you to write:

[September 15th, 2005] DTSA-17-1 lm-sensors - insecure temporary file
	FIXES: DSA-814-1
	- lm-sensors 1:2.9.1-6etch1

in DTSA/list, and

[15 Sep 2005] DSA-814-1 lm-sensors - insecure temporary file
	FIXES: CAN-2005-2672
	[sarge] - lm-sensors 1:2.9.1-1sarge2
	[woody] - lm-sensors not-affected (woody not affected according to DSA)

in DSA/list.  CAN/list just contains:

CAN-2005-2672 (pwmconfig in LM_sensors before 2.9.1 creates temporary files ...)
	- lm-sensors 1:2.9.1-7 (bug #324193; medium)

You can see the result on the web at:

  <http://idssi.enyo.de/tracker/CAN-2005-2672>

(See the "Origin" column in the table at the bottom.)

What do you think?  Is this feature useful?  It helps to avoid data
duplication.

("FIXED-BY:" is needed because you cannot reference the FAKE-* entries
in the other direction; they haven''t got a real name.)

If you fear that this makes the list files less readable, here''s an
Emacs macro that opens a browser window for the issue at the cursor
position.

(defvar idssi-url-base "http://idssi.enyo.de/tracker/"
  "Base URL for the IDSSI security tracker.")

(defun fw/open-debian-bug ()
  (interactive)
  (save-excursion
    (save-match-data
      (while 
	  (and
	   (condition-case ()
	       (progn
		 (backward-char)
		 t)
	     (error nil))
	   (if (looking-at "[a-zA-Z0-9.+-]")
	       t
	     (forward-char))))
      (cond
       ;; CAN/CVE reference
       ((looking-at 
	 "\\(CAN\\|CVE\\)-[0-9][0-9][0-9][0-9]-[0-9][0-9][0-9][0-9]")
	(browse-url (concat idssi-url-base
			    (buffer-substring (match-beginning 0)
					      (match-end 0)))))
       ;; package name
       ((looking-at "[a-z][a-z0-9.+-]+")
	(browse-url (concat idssi-url-base
			    (buffer-substring (match-beginning 0)
					      (match-end 0)))))
       ;; bug number, "_REDIR" means "redirect to Debian BTS if
unavailable
       ((looking-at "[0-9]+")
	(browse-url (concat idssi-url-base
			    (buffer-substring (match-beginning 0)
					      (match-end 0))
			    "_REDIR")))))))

I''m sure something similar could be created for VIM. 8-)

* Moritz Muehlenhoff:
> Or we could as well leave the {} entry blank.
Sure.
>> 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
I''ve been doing this in a few cases.
>> It''s just two more lines per DSA.
>
> Well yes, but collection the information for these lines is the
time-consuming
> part :-)
Don''t think so.  For current DSAs, the .dsc files are still on
security.debian.org, so it''s probably possible to automate this to
some extent.  Only for historic DSAs, things get a bit messy.

In general, the "will be fixed soon" part for testing/unstable is much
harder. 8-)

The main question is whether the [sarge]/[woody] entries in DSA/list
will bother you.  I''m sure someone else besides me will be willing to
add them once a new DSA has been released, so they should just
magically appear from your POV.
> 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?
They are all flagged as vulnerable in woody because the woody version
number is lower than the fixed version.  In other words, we err on the
safe side.

I plan to merge the sarge non-vulnerability list soon (and maybe even
the woody non-vuln list).  But I expect that there are pretty few
surprises, at least for sarge.
> 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?
I''m not sure if I understand your question, but here''s an
example.

The top of DSA/list looks like this.

[13 Oct 2005] DSA-865-1 hylafax - insecure temporary files
	FIXES: CAN-2005-3069
	[woody] - hylafax 1:4.1.1-3.2
	[sarge] - hylafax 1:4.2.1-5sarge1
	NOTE: not fixed in testing at time of DSA (missing arm)

The corresponding entry in CAN/list is:

CAN-2005-3069 (xferfaxstats in HylaFax 4.2.1 and earlier allows local users to
...)
	{DSA-865-1}
	- hylafax 1:4.2.2+rc1 (bug #329384; low)

(IOW, it''s the same one you use.)

My tracker evaluates the FIXES: part, and we have (see
<http://idssi.enyo.de/tracker/CAN-2005-3069>):

| Source Package     Release          Version       Status
| hylafax (PTS)  woody            1:4.1.1-3.1     vulnerable
|                woody (security) 1:4.1.1-3.2     fixed
|                sarge            1:4.2.1-5       vulnerable
|                sarge (security) 1:4.2.1-5sarge1 fixed
|                etch             1:4.2.1-7       vulnerable
|                sid              2:4.2.2-1       fixed
| 

| Package  Type   Release    Fixed Version  Urgency  Origin   Debian Bugs
| hylafax source (unstable) 1:4.2.2+rc1     low               329384
| hylafax source sarge      1:4.2.1-5sarge1 unknown DSA-865-1
| hylafax source woody      1:4.1.1-3.2     unknown DSA-865-1

Simple enough, I think.

If look at the DSA on the web, you''ll notice that we don''t
have
vulnerability status information for testing/unstable anymore, you
have to look at the corresponding CVE entry.  I don''t think this is a
problem.  (I tried to move relevant NOTE:s from the DSA to the CAN
file.)

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

[This must''ve slipped through]

Florian Weimer wrote:
> I''ve added new FIXES: and FIXED-BY: directives to the Python code
(but
> not to the list files, of course -- this is up to you).
>
> This allows you to write:
> 
> [September 15th, 2005] DTSA-17-1 lm-sensors - insecure temporary file
> 	FIXES: DSA-814-1
> 	- lm-sensors 1:2.9.1-6etch1
> 
> in DTSA/list, and
> 
> [15 Sep 2005] DSA-814-1 lm-sensors - insecure temporary file
> 	FIXES: CAN-2005-2672
> 	[sarge] - lm-sensors 1:2.9.1-1sarge2
> 	[woody] - lm-sensors not-affected (woody not affected according to DSA)
> 
> in DSA/list.  CAN/list just contains:
> 
> CAN-2005-2672 (pwmconfig in LM_sensors before 2.9.1 creates temporary files
...)
> 	- lm-sensors 1:2.9.1-7 (bug #324193; medium)
>
> What do you think?  Is this feature useful?  It helps to avoid data
> duplication.
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.

This somehow already exists (the part in the curly brackets), but IMO we should
apply it to the list files as well and patch checklist if necessary.
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.

So, a DSA/list entry would only consist of e.g.:

[13 Oct 2005] DSA-835-1 hylafax - insecure temporary files
        {CAN-2005-3069}
        NOTE: not fixed in testing at time of DSA (missing arm)

The format of the DTSA entries wouldn''t need to be changed, as it
already
only references the etch fixes anyway.

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.
> ("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? For it this
shouldn''t
matter, as all DSAs (with backup-manager being the one exception of the rule)
have CVE assignments and for DTSAs we should hold to the same rule.
 
Cheers,
        Moritz

Florian Weimer wrote:
> >> It''s just two more lines per DSA.
> >
> > Well yes, but collection the information for these lines is the
time-consuming
> > part :-)
> 
> Don''t think so.  For current DSAs, the .dsc files are still on
> security.debian.org, so it''s probably possible to automate this to
> some extent.  Only for historic DSAs, things get a bit messy.
> 
> In general, the "will be fixed soon" part for testing/unstable is
much
> harder. 8-)
Ahh, I thought you wanted to add manual Sarge/Woody tracking for all
the entries in CAN/list.
 
> The main question is whether the [sarge]/[woody] entries in DSA/list
> will bother you.
For me, not at all.
 
> > 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?
> 
> I''m not sure if I understand your question, but here''s an
example.
> 
> The top of DSA/list looks like this.
> 
> [13 Oct 2005] DSA-865-1 hylafax - insecure temporary files
> 	FIXES: CAN-2005-3069
> 	[woody] - hylafax 1:4.1.1-3.2
> 	[sarge] - hylafax 1:4.2.1-5sarge1
> 	NOTE: not fixed in testing at time of DSA (missing arm)
> 
> The corresponding entry in CAN/list is:
> 
> CAN-2005-3069 (xferfaxstats in HylaFax 4.2.1 and earlier allows local users
to ...)
> 	{DSA-865-1}
> 	- hylafax 1:4.2.2+rc1 (bug #329384; low)
> 
> | Package  Type   Release    Fixed Version  Urgency  Origin   Debian Bugs
> | hylafax source (unstable) 1:4.2.2+rc1     low               329384
> | hylafax source sarge      1:4.2.1-5sarge1 unknown DSA-865-1
> | hylafax source woody      1:4.1.1-3.2     unknown DSA-865-1
> 
> Simple enough, I think.
Absolutely.
 
> If look at the DSA on the web, you''ll notice that we
don''t have
> vulnerability status information for testing/unstable anymore, you
> have to look at the corresponding CVE entry.  I don''t think this
is a
> problem.  (I tried to move relevant NOTE:s from the DSA to the CAN
> file.)
I agree, the canonical information should come from security.debian.org
anyway and the few cases where our information differs are negligible
IMO.

Cheers,
        Moritz

* Moritz Muehlenhoff:
>> In general, the "will be fixed soon" part for
testing/unstable is much
>> harder. 8-)
>
> Ahh, I thought you wanted to add manual Sarge/Woody tracking for all
> the entries in CAN/list.
Most of them are either unfixed, or there is a DSA for them.  In some
cases, the vulnerable code may have been added after the stable
release, and I would supply a

  [sarge] - PACKAGE <not-affacted> (vulnerable code was added
post-release)

when I come across such a case.  But I don''t expect many instances.
> I agree, the canonical information should come from security.debian.org
> anyway and the few cases where our information differs are negligible
> IMO.
Okay.

Shall I undo my local FIXES/FIXED-BY changes, add the propagation code
for {...}, and merge back my local changes for tracking sarge/woody,
then?

Florian Weimer wrote:
> Shall I undo my local FIXES/FIXED-BY changes, add the propagation code
> for {...}, and merge back my local changes for tracking sarge/woody,
> then?
Fine with me.

Cheers,
        Moritz

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