From owner-freebsd-ports@FreeBSD.ORG Sun Sep 4 00:47:31 2011 Return-Path: Delivered-To: freebsd-ports@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id ECFAC1065670; Sun, 4 Sep 2011 00:47:31 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id E3F5B14FEC1; Sun, 4 Sep 2011 00:47:30 +0000 (UTC) Message-ID: <4E62CAA1.40005@FreeBSD.org> Date: Sat, 03 Sep 2011 17:47:29 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.1) Gecko/20110901 Thunderbird/6.0.1 MIME-Version: 1.0 To: Mark Linimon References: <4E5C79AF.6000408@FreeBSD.org> <20110830062541.GA5538@lonesome.com> In-Reply-To: <20110830062541.GA5538@lonesome.com> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: secteam@FreeBSD.org, "freebsd-ports@FreeBSD.org" Subject: Re: Why do we not mark vulnerable ports DEPRECATED? X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2011 00:47:32 -0000 Several people have pointed out something I omitted from my first post on this, if you have portaudit installed you're already prevented from installing a vulnerable port: # make ===> mediawiki-1.15.5_2 has known vulnerabilities: => mediawiki -- multiple vulnerabilities. Reference: http://portaudit.FreeBSD.org/3fadb7c6-7b0a-11e0-89b4-001ec9578670.html => Please update your ports tree and try again. *** Error code 1 So all I'm talking about doing is extending the same protection to *all* of our users without requiring them to install portaudit and keep it up to date. More below ... On 08/29/2011 23:25, Mark Linimon wrote: > On Mon, Aug 29, 2011 at 10:48:31PM -0700, Doug Barton wrote: >> Can someone explain why this would be a bad idea? > > Very early in my committer career, I marked a port BROKEN that kde > depended on. I was quickly chastisted by people trying to install kde :-) > > So, the right answer may be "it depends". For unmaintained leaf or > leaf-ish ports like you're talking about, I think the answer is exactly > correct -- such ports do nothing but cause users problems. But I think > it would be counterproductive to mark e.g. php5 and firefox as such > whenever a new vulnerability is found. It's just simply too common* an > occurrence. We'll have to agree to disagree on the timing issue here. Having talked this through on IRC quite a bit and read the responses to this thread I still think that (absent an update that clears the vulnerability) we should be marking them FORBIDDEN (note, you were kind enough to correct me on this point on IRC, thanks) immediately, and not clear that until the port is updated. This would serve several beneficial purposes, in no particular order: 1. It would solve the problem of us forgetting to do it later. 2. It would help prevent users who do not have portaudit installed (or have it installed but have not updated recently) from installing vulnerable stuff. 3. It would facilitate removal of vulnerable stuff down the road. 4. The more popular the port, the more likely resources will appear to get it fixed if people who want it cannot install it. Meanwhile, I got bit by this problem AGAIN, so I decided to put my money where my mouth is. I did a search of the INDEX ('portaudit -f /usr/ports/INDEX-9') and came up with 54 ports that are in the tree and vulnerable. Of those, 10 are maintained by ports@, so I've marked those all FORBIDDEN, with EXPIRATION_DATE of 2011-09-30. Many of those ports have been vulnerable for years, the oldest since 2005-07-31. One of those was fixed within an hour after my marking it FORBIDDEN. :) For the other 44 I sent e-mail to the maintainers asking them to take action and letting them know about my plan to mark the ports FORBIDDEN this time next week. Two maintainers (out of the 33 unique non-ports@ maintainers) have already responded. Overall I'd say that the response to this idea has been very positive. If we all cannot agree that marking them FORBIDDEN immediately is a good idea, can we at least agree on a guideline for when to mark newly vulnerable ports? Y'all know my vote, but if "immediately" cannot achieve consensus, what do people think is reasonable? > A different but related topic: I don't think we've been sufficiently > rigorous about marking DEPRECATED or BROKEN ports with EXPIRATION_DATEs. > That could be a Junior Committer Task. (I know that Pav has swept some > out in the past.) Well I'm as junior as anyone, and in an axe-swinging mood lately, so I took a look at this. The numbers for BROKEN-without-EXPIRATION_DATE are large'ish, and given how BROKEN is being used in some of those ports it wasn't immediately clear to me that setting EXPIRATION_DATE was the right thing to do, so I left those alone. So if someone else wants to tackle that one, go for it! :) The number of DEPRECATED-without-EXPIRATION_DATEs on the other hand was more manageable, and understandable even by me, so I have taken care of these. There were 8 that have been deprecated for a long time, were clearly hopeless cases, and were not depended on; so those I just removed. Everything else I set EXPIRATION_DATEs for, and in some cases also added DEPRECATED and EXPIRATION_DATE for things that depend on the previously-deprecated ports. So, 2011-09-30 is going to be a fun day. BWAHAHAHAHA The only exception to the above are the lang/gcc[34]4 ports. Gerald seems to have that situation well in hand, and since the intricacies there were not immediately obvious to me I decided to leave well enough alone. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/