Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 3 Jul 2015 07:34:21 -0700
From:      David Wolfskill <david@catwhisker.org>
To:        freebsd-ports@FreeBSD.org
Subject:   Re: Please help un-confuse me about vuxml
Message-ID:  <20150703143421.GN1472@albert.catwhisker.org>
In-Reply-To: <55968FC5.5010503@FreeBSD.org>
References:  <20150703130103.GM1472@albert.catwhisker.org> <55968FC5.5010503@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--bebzX59uVWocTrAI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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]=20


> 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.)
>=20
> This is what the vuxml says:
>=20
>       <package>
>         <name>netpbm</name>
>         <range><lt>10.35.96</lt></range>
>       </package>
>=20
> 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.
>=20
> 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.
>=20
> 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
--=20
David H. Wolfskill				david@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.

--bebzX59uVWocTrAI
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQJ8BAEBCgBmBQJVlp1tXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4
QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7RGIP/0UlcHzvYJHkK4U3bbphyCKH
n1VZXBFGuRNrVocH41M4v83H1thFQYcraXvD7qb3PULKbeuyyMTlq8gOqpJApMJO
Q6H2iQ09emz/NDH5wtIuGGrir8B0PrsqkkCmQek04t7HBpCOgM4NkQwnSyxo25KJ
k7btxcQcX3L5nVhsxEtQvOk1HBysKNPoTl3U6gUyfzINHcw/x/5Fc2zGMYagJhrM
SujlKosqTbokCwViVVFb+CXUc4Sx58FriFewGsJ9H4ocO6rWwHS3J3f8QcSJ5zOb
nUd8cx+FcNHobP2exCLIqHdPu6VSvm1uVLXrLIIIM1mSyA7+RFXF5WmDcuZKF5Eg
goKzygACGh8LqY32ucfzBTqCv10dI4nYnBbMtjqgJGj+4JzEY6woEU2MjfbOsExZ
OOqN7Ee2NpLje8M8okYP2k0fhOyW37OA8PKdQjKwwZHo/p9x04BgouqONA8Xp6vd
zltpF/xP42YUXwsPeCn/4aVZTKIP6J0kbaWQOMp6/zXI1KdJVeVs8KO6ZdI4UJBj
NgrEF9Z/bx6EiRRzHq0p49zorSvFnjJoKrHyyC79eip/kGF+ydCTSIF5xdn4QFcW
rDh6dRXX9A2WBWCg4jQYWVUbKxhFiWUZsSTL9tq+XaZLgDFUkofWARQBZrFoDPo0
Vh5vrXXt6e4KLiWvbosa
=OQMW
-----END PGP SIGNATURE-----

--bebzX59uVWocTrAI--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150703143421.GN1472>