Why do we not mark vulnerable ports DEPRECATED?

[Doug Barton]

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/