Re: cvs commit: ports/multimedia/xine Makefile

From: Oliver Eikemeier (eikemeier_at_fillmore-labs.com)
Date: 03/30/04

  • Next message: Jacques A. Vidrine: "Re: cvs commit: ports/multimedia/xine Makefile" 
    Date: Tue, 30 Mar 2004 03:35:09 +0200
To: "Jacques A. Vidrine" <nectar@FreeBSD.org>

    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?
    _______________________________________________
    freebsd-security@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-security
    To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"

  • Next message: Jacques A. Vidrine: "Re: cvs commit: ports/multimedia/xine Makefile"

    Relevant Pages

    • Re: cvs commit: ports/multimedia/xine Makefile
      ... an informal document is useless for portaudit. ... > enforce local policy based on the VuXML document. ... > goes into the VuXML document should cause the corresponding port to be ... Since you are the FreeBSD Security Officer, ...
      (FreeBSD-Security)
    • Re: cvs commit: ports/multimedia/xine Makefile
      ... It is not a policy document. ... One could say that the VuXML document *is* the collection of issued ... It's a bit harder for users' to ignore it when a port is marked ... What is the meaning of an entry in the VuXML database? ...
      (FreeBSD-Security)
    • Re: cvs commit: ports/multimedia/xine Makefile
      ... the point is that portaudit is designed to ... >>enforce local policy based on the VuXML document. ... >>goes into the VuXML document should cause the corresponding port to be ... >>Just like I do not mark every port with any security issue FORBIDDEN, ...
      (FreeBSD-Security)