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.
I have a fix. It involves not updating a vuln, but rather, deleting it entirely, then inserting.
It turns out that updates in place, while entirely possible, are more complicated. Let’s keep things simple.
The fix is now in dev, prod, and beta.