Launchpad rejects valid CVE numbers

[Thierry Carrez]

When trying to add a CVE-2014-2237 reference to https://bugs.launchpad.net/ossa/+bug/1260080, Launchpad rejects it with the following error:

2014-2237 is not a known CVE sequence number.

As http://openwall.com/lists/oss-security/2014/02/28/10 shows, it's coming from MITRE CVE assignment team, which, hmm, knows what a valid CVE number looks like.

[Jamie Strandboge (jdstrand)]

I can confirm this. I tried to add 2014-2237, CVE-2014-2237 (known invalid, but checked just to see if things changed to this format) and 2014-2238 to this bug and was unable to.

[Colin Watson (cjwatson)]

I was able to add this CVE number without problems, so it's something more subtle. Perhaps a browser is substituting some similar-looking character for "-", or adding trailing whitespace, or something like that?

[Jamie Strandboge (jdstrand)]

It seems to be an intermittent failure. I was able to add 2014-2237 and 2014-2238 by entering manually (ie, not copying and pasting). But then removed them and tried again and could not add 2014-2238, but then tried again and could add it. Now I am unable to remove 2014-2238 by typing it in manually.

[Colin Watson (cjwatson)]

Actually I think it's not the regex check, it's the lookup in the CVE import. If you see this again, please check whether https://bugs.launchpad.net/bugs/cve/2014-2237 (etc.) exists at the same time.

[Jamie Strandboge (jdstrand)]

It may very well be part of the CVE import-- 2014-2237 exists now but 2014-2238 does not, yet I was able to add the CVE but could not remove it. Perhaps so long as the CVE exists in LP, there is no problem, in which case, the priority of this can be reduced since our security processes typically deal with only public CVEs. However, there seems to be a bug when the CVE does not exist in LP, since sometimes you are able to remove/add a non-imported CVE, and sometimes you are not.

[Jamie Strandboge (jdstrand)]

Please disregard what I said about 2014-2238. It looks like I typoed and added 2014-2038 (which is imported) but tried to delete 2014-2238 (which is not imported). I tried several times to add 2014-2238 just now (which is still not imported) and it wouldn't add-- so I guess that is correct behavior for a non-imported CVE.

I'm now thinking that the comments surrounding 2014-2237 was just bad timing. Eg, perhaps it is as simple as when Thierry tried to add it, it hadn't imported yet; when I tried a couple of times, it hadn't imported yet, so I confirmed it; then some time later when Colin and I were looking at it, it was imported (perhaps db replication hadn't happened perfectly in there which led to more confusion?).

At this point I don't think there is a critical or high priority bug. There might be a race when the import is happening, but I can't reproduce that now.