A new ambiguity

[Florian Weimer <fw@deneb.enyo.de>]

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.

A similar issue exists for conflicts between data/DSA/list and
data/CVE/list, but there, I simply opted for never overriding entries
in data/CVE/list (which might pamper over some real inconsistencies,
unfortunately).