FreshPorts News

News and announcements regarding FreshPorts, The Place For Ports.

Updates to vuxml ranges fails

 Bug fixes, Development, PostgreSQL, vuxml  Add comments
Jan 152013
 

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:

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

differs from this:

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:

[sourcecode language=”sql”]
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=#
[/sourcecode]

Whereas vuln.xml has:

[sourcecode]
<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>
[/sourcecode]

Then, looking at the dates:

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

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:

[sourcecode]
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=#
[/sourcecode]

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.

[sourcecode]
freshports.org=# begin;
BEGIN
freshports.org=# delete from vuxml where vid = ‘16846d1e-f1de-11e1-8bd8-0022156e8794′;
DELETE 1
freshports.org=# commit;
COMMIT
[/sourcecode]

Then I processed the vuln and checked the ranges:

[sourcecode]
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)
[/sourcecode]

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

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

 Posted by Dan Langille at 9:23 pm

  One Response to “Updates to vuxml ranges fails”

  1. spacer
    Dan Langille says:
    January 16, 2013 at 10:39 am

    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.

    Log in to Reply

 Leave a Reply Cancel reply

You must be logged in to post a comment.

gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.