Updates to vuxml ranges fails

If a vuxml entry is updated, and the ranges change, those changes are not recorded in FreshPorts. This came to my attention from the FreeBSD Security team. They noticed that for the recent Oracla Java vuln FreshPorts had all versions for > 7.

It boiled down to this:

http://www.freshports.org/vuxml.php?vid=16846d1e-f1de-11e1-8bd8-0022156e8794 [1]

differs from this:

http://www.vuxml.org/freebsd/16846d1e-f1de-11e1-8bd8-0022156e8794.html [2]

I have verified that vuln.xml matches [2] but not [1].

Thus, it had to be FreshPorts that’s wrong. Let’s see the ranges it has:

freshports.org=# select * from vuxml_ranges where vuxml_affected_id in (select id from vuxml_affected where vuxml_id = (select id from vuxml where vid = '16846d1e-f1de-11e1-8bd8-0022156e8794')); 
 id    | vuxml_affected_id | operator1 | version1 | operator2 | version2 
---------+-------------------+-----------+----------+-----------+----------
3930306 |           3464268 | ge        | 7.0      | lt        | 7.6.24_1
3930307 |           3464269 | ge        | 7.0      |           | 
3930308 |           3464270 | ge        | 7.0      |           | 
(3 rows)

freshports.org=# 

Whereas vuln.xml has:

     <package>
      <name>openjdk</name>
       <range><ge>7.0</ge><lt>7.6.24_1</lt></range>
     </package>
     <package>
       <name>linux-sun-jdk</name>
       <range><ge>7.0</ge><lt>7.7</lt></range>
     </package>
     <package>
       <name>linux-sun-jre</name>
       <range><ge>7.0</ge><lt>7.7</lt></range>
     </package>

Then, looking at the dates:

   <dates>
     <discovery>2012-08-27</discovery>
     <entry>2012-08-30</entry>
     <modified>2012-08-31</modified>
   </dates>

Ay logs FreshPorts has for that date are gone from the server (but available via backup).

My first attempt at fixing this, let’s force an update by clearing the checksum in the db:

freshports.org=# begin;
BEGIN
freshports.org=# update vuxml set checksum = '' where vid = '16846d1e-f1de-11e1-8bd8-0022156e8794';
UPDATE 1
freshports.org=# commit;
COMMIT
freshports.org=# 

And rerunning the vuln parsing:

$ touch ../dynamic/vuxml && touch ../dynamic/job_waiting

No, that did not change the ranges in the database.

Then I went to try this on my dev box by deleting the vuln entirely.

freshports.org=# begin;
BEGIN
freshports.org=# delete from vuxml where vid = '16846d1e-f1de-11e1-8bd8-0022156e8794';
DELETE 1
freshports.org=# commit;
COMMIT

Then I processed the vuln and checked the ranges:

freshports.org=# select * from vuxml_ranges where vuxml_affected_id in (select id from vuxml_affected where vuxml_id = (select id from vuxml where vid = '16846d1e-f1de-11e1-8bd8-0022156e8794')); 
  id    | vuxml_affected_id | operator1 | version1 | operator2 | version2 
---------+-------------------+-----------+----------+-----------+----------
3894927 |           3433732 | ge        | 7.0      | lt        | 7.6.24_1
3894928 |           3433733 | ge        | 7.0      | lt        | 7.7
3894929 |           3433734 | ge        | 7.0      | lt        | 7.7
(3 rows)

Yep. That’s right. Then I fixed up prod and beta now.

I’ll try to fix this up as soon as I can.