From owner-freebsd-ports@freebsd.org Fri Jul 3 14:34:23 2015 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9611F994D9F for ; Fri, 3 Jul 2015 14:34:23 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6056F1654 for ; Fri, 3 Jul 2015 14:34:22 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t63EYML0076719 for ; Fri, 3 Jul 2015 07:34:22 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t63EYL5x076718 for freebsd-ports@FreeBSD.org; Fri, 3 Jul 2015 07:34:21 -0700 (PDT) (envelope-from david) Date: Fri, 3 Jul 2015 07:34:21 -0700 From: David Wolfskill To: freebsd-ports@FreeBSD.org Subject: Re: Please help un-confuse me about vuxml Message-ID: <20150703143421.GN1472@albert.catwhisker.org> References: <20150703130103.GM1472@albert.catwhisker.org> <55968FC5.5010503@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bebzX59uVWocTrAI" Content-Disposition: inline In-Reply-To: <55968FC5.5010503@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 14:34:23 -0000 --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 > > netpbm > 10.35.96 > >=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--