Please help un-confuse me about vuxml
david at catwhisker.org
Fri Jul 3 14:34:23 UTC 2015
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.
> 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) svn info /usr/ports/
Working Copy Root Path: /usr/ports
Relative URL: ^/head
Repository Root: file:///svn/freebsd/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Node Kind: directory
Last Changed Author: olgeni
Last Changed Rev: 391226
Last Changed Date: 2015-07-03 02:34:33 -0700 (Fri, 03 Jul 2015)
> 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:
> Which means that 10.35.95 or anything earlier is vulnerable, but
> 10.35.96 and above is not.
> > - 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
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
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.
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
Size: 949 bytes
Desc: not available
More information about the freebsd-ports