From owner-freebsd-security@FreeBSD.ORG Mon Mar 29 17:35:15 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 244E716A4CE; Mon, 29 Mar 2004 17:35:15 -0800 (PST) Received: from postman.arcor.de (postman4.arcor-online.net [151.189.0.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8570643D5A; Mon, 29 Mar 2004 17:35:14 -0800 (PST) (envelope-from eikemeier@fillmore-labs.com) Received: from fillmore.dyndns.org (port-212-202-51-138.reverse.qsc.de [212.202.51.138]) (authenticated bits=0)i2U1ZCD2010658 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 30 Mar 2004 03:35:13 +0200 (MEST) Received: from [172.16.0.2] (helo=fillmore-labs.com) by fillmore.dyndns.org with esmtp (Exim 4.30; FreeBSD) id 1B889m-000P4w-6z; Tue, 30 Mar 2004 03:35:10 +0200 Message-ID: <4068CECD.8070300@fillmore-labs.com> Date: Tue, 30 Mar 2004 03:35:09 +0200 From: Oliver Eikemeier Organization: Fillmore Labs GmbH - http://www.fillmore-labs.com/ MIME-Version: 1.0 To: "Jacques A. Vidrine" References: <200403282344.i2SNi6Hq047722@repoman.freebsd.org> <20040329163309.GA81526@madman.celabo.org> <40686785.7020002@fillmore-labs.com> <20040329185347.GB87233@madman.celabo.org> <40687E18.9060907@fillmore-labs.com> <20040329201926.GA88529@madman.celabo.org> In-Reply-To: <20040329201926.GA88529@madman.celabo.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: FreeBSD Security Subject: Re: cvs commit: ports/multimedia/xine Makefile X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2004 01:35:15 -0000 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?