Re: A new ambiguity
On Sun, 09 May 2010 20:05:45 +0200 Florian Weimer wrote:
> I have found what appears to be a previously unknown ambiguity in the
> tracker input data. Consider these two DSAs:
>
> [01 May 2009] DSA-1785-1 wireshark - several vulnerabilities
> {CVE-2009-1210 CVE-2009-1268 CVE-2009-1269}
> [lenny] - wireshark 1.0.2-3+lenny5
>
> [29 Nov 2009] DSA-1942-1 wireshark - several vulnerabilities
> {CVE-2009-1829 CVE-2009-1268 CVE-2009-2560 CVE-2009-2562 CVE-2009-3241 CVE-2009-3550 CVE-2009-3829}
> [etch] - wireshark 0.99.4-5.etch.4
> [lenny] - wireshark 1.0.2-3+lenny7
>
> data/DSA/list:977: warning: annotation on DSA-1785-1 overridden
> data/DSA/list:363: warning: by annotation on DSA-1942-1 via CVE-2009-1268
>
> There are two possible interpretations:
>
> DSA-1785-1 was not issued for etch. CVE-2009-1268 is mentioned in
> DSA-1942-1 because the fix for etch, and the fix lenny was already
> in DSA-1785-1. Thus, "[lenny] - wireshark 1.0.2-3+lenny5" is the
> correct annotation.
>
> The fix in DSA-1785-1 was incorrect, and it was corrected in
> DSA-1942-1. Thus, "[lenny] - wireshark 1.0.2-3+lenny7" is the
> correct annotation.
>
> Without more data, it is impossible to decide which interpretation is
> the correct one.
>
> I'm open for suggestions how to add more information to the input data
> to disambiguate this situation. One potential fix is to change {} to
> apply only to the following package annotation, until the next {},
> instead of merging all entries. With this convention, the DSA-1942-1
> entry would look like this:
>
> [29 Nov 2009] DSA-1942-1 wireshark - several vulnerabilities
> {CVE-2009-1829 CVE-2009-1268 CVE-2009-2560 CVE-2009-2562 CVE-2009-3241 CVE-2009-3550 CVE-2009-3829}
> [etch] - wireshark 0.99.4-5.etch.4
> {CVE-2009-1829 CVE-2009-2560 CVE-2009-2562 CVE-2009-3241 CVE-2009-3550 CVE-2009-3829}
> [lenny] - wireshark 1.0.2-3+lenny7
>
> There is a certain amount of repetition involved. Another approach,
> also involving repetition, would be to manually copy
> "[etch] - wireshark 0.99.4-5.etch.4" into the CVE-2009-1268 entry in
> data/CVE/list.
this has actually come up every now and then, and we have just had to
accept the wrongness. i was actually planning to implement the above
solution at some point, but hadn't found the time. i don't think the
additional repetition is too burdensome since the CVE info is (usually)
automatically filled in by the dsa2list script.
mike
Reply to: