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

Florian Weimer fw at deneb.enyo.de
Mon Oct 17 22:42:22 UTC 2005


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




More information about the Secure-testing-team mailing list