Please help un-confuse me about vuxml

[David Wolfskill]

On Fri, Jul 03, 2015 at 02:36:05PM +0100, Matthew Seaman wrote:
> On 2015/07/03 14:01, David Wolfskill wrote:
> ...
> vuxml currently states that netpbm versions /less than/ 10.35.96 are
> vulnerable, and has done since about 48h ago.

Hmmmm....

> Given that the latest available version of netpbm is now 10.35.96
> (committed at right about the same time as the vuxml update) you should
> be able to upgrade to that without problems.

My ports working copy is (and was; I use a local private mirror that I
update shortly before I begin the daily update cycle):

g1-254(10.2-P)[1] svn info /usr/ports/
Path: /usr/ports
Working Copy Root Path: /usr/ports
URL: file:///svn/freebsd/ports/head
Relative URL: ^/head
Repository Root: file:///svn/freebsd/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 391226
Node Kind: directory
Schedule: normal
Last Changed Author: olgeni
Last Changed Rev: 391226
Last Changed Date: 2015-07-03 02:34:33 -0700 (Fri, 03 Jul 2015)

g1-254(10.2-P)[2] 


> No idea why portmaster is getting this wrong.

Well, it's a small relief that what I'm seeing & reporting is
considered "wrong" by someone else, at least. :-}

> > - The vuxml entry effectively required human intervention to update
> >   the port.
> >
> > - The most recent update to the port itself claimed that it had a
> >   fix to address said vulnerability.  (This gives one reason to
> >   wonder why *this* version of the port had a vuxml entry, then.)
> 
> This is what the vuxml says:
> 
>       <package>
>         <name>netpbm</name>
>         <range><lt>10.35.96</lt></range>
>       </package>
> 
> Which means that 10.35.95 or anything earlier is vulnerable, but
> 10.35.96 and above is not.

OK.

> > - I had no feasible way to have a clue about any of this until the
> >   artificial failure disrupted the usual update process.
> 
> For a second opinion on what vulnerabilities you may have, try 'pkg
> audit -F' (which will work just fine no matter if you're installing
> pre-compiled pkgs or building your own from ports).

In this case, I was not so much concerned about vulnerabilities per
se, as I was to disruptions in the "normal" course of the ports
update.  (And I quoted 'normal" in acknowledgement that it's a
rather subjective qualifier, at best. :-})

For example, had portmaster looked at the list of prospective updates
and let me know *before* I told it to proceed that there might be an
issue with graphics/netpbm, that would have been workable.  But that's
only one possible implementation approach (and is not mutually exclusive
with other possible approaches): I'm not trying to "specify
implementation(s)" here -- merely trying to illustrate and clarify what
my concern is.

> > - As far as I can tell, there was no value in the existence of the vuxml
> >   entry for this port under these circumstances.  Rather, it was merely
> >   annoying and disruptive, for no gain whatsoever.  There wasn't even an
> >   UPDATING entry to warn a person about what was going on.
> 
> There's no requirement that a fixed version be available from ports
> before vuxml gets updated.  Quite the opposite in fact.  Admins should
> be informed if they are running vulnerable software so they can take
> some sort of ameliorative action even if the official fix is not yet
> published.

Right; I understand (and understood) that.

> Why would you expect an UPDATING entry here?  Documenting every
> vulnerability in the ports isn't what UPDATING is for.  Only if the way
> you would need to fix the vulnerability involved doing more than a
> simple upgrade would that be legitimate UPDATING territory.

In this case, the reason for an UPDATING entry would be the
counterintuitive behavior of portmaster in this particular case --
though better would be to have avoided whatever caused the
confusion/misunderstanding in the first place.  (I don't know if other
ports management tools might also get this one wrong, as I don't use
them currently.)

As ports/UPDATING itself says:

| This file documents some of the problems you may encounter when upgrading
| your ports.  We try our best to minimize these disruptions, but sometimes
| they are unavoidable.

(And yes, I acknowledge that is has "some of," and I don't expect
perfection in human endeavors in any case.  But "improvement" can
still be worth pursuing.)

> ...
> A vuxml entry in general tells you what is vulnerable and gives you the
> chance to do something about it...

Yes; I understand that part.

> Although I have no idea why that particular version of netpbm was being
> flagged as vulnerable for you.
> ....

And that is what left me confused.  I confess (again) that I'm releived
to not be alone in failing to understand why things played out as they
did in my case.

Thanks!  :-)

Peace,
david
-- 
David H. Wolfskill				david at catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20150703/79c4106b/attachment.bin>