cvs commit: ports/multimedia/xine Makefile

[Oliver Eikemeier]

Jacques A. Vidrine wrote:

>>>>>I'd prefer to reserve FORBIDDEN for those cases where the ports
>>>>>present some danger.  Those who want a more strict policy can use
>>>>>portaudit or similar, right?
>>>>
>>>>I guess we have to add a severity tag then, to enable `soft'
>>>>vulnerabilities.  I have an automated script that barks on unmarked
>>>>vulnerabilities, and it can't decide which vulnerability is
>>>>`important'.
>>>
>>>Yes, I wanted to avoid this.  Severity is sooo subjective.  I prefer
>>>that people close to the port make the severity judgement--- if the
>>>maintainer or a fellow committer believes the item is severe, then let
>>>them mark it FORBIDDEN.  That is why I said `FWIW' above--- if you
>>>believe it is severe, then please by all means leave it FORBIDDEN.
>>>However, I had the impression that you were marking it only because it
>>>was listed in the VuXML document.
>>
>>Sure. Severity is subjective, and I'm not in the position to decide what
>>is considered severe enough to advise people to not use it.
>>
>>The security team are the people who should judge which vulnerabilites are
>>severe enough to issue a warning, not the users. That is what they are there
>>for. Users can ignore advisories if they decide to do so.
> 
> One could say that the VuXML document *is* the collection of issued
> warnings.  Users can ignore it, they can peruse it `in the raw' or at
> http://vuxml.freebsd.org/, or they can use a tool such as portaudit to
> enforce local policy based on the VuXML document.
> 
> It's a bit harder for users' to ignore it when a port is marked
> FORBIDDEN.  Thus the reason I do not think that *every* issue that
> goes into the VuXML document should cause the corresponding port to be
> marked FORBIDDEN.  Hell, in many cases, the issues depend upon local
> configuration or the options with which the port was built.  Marking
> a port FORBIDDEN unconditionally doesn't make sense if only users who
> build it with `-DGAPING_SECURITY_HOLE' are affected :-)

While we are at it: port www/squid24 is listed in
705e003a-7f36-11d8-9645-0020ed76ef5a.

Is this serious? Isn't it? Who should decide?