From owner-freebsd-security@FreeBSD.ORG Mon Mar 29 20:56:50 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 9F0F016A4CE for ; Mon, 29 Mar 2004 20:56:50 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2006043D2F for ; Mon, 29 Mar 2004 20:56:50 -0800 (PST) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (not verified)) by gw.celabo.org (Postfix) with ESMTP id B9C4754840; Mon, 29 Mar 2004 22:56:49 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id 803D16D467; Mon, 29 Mar 2004 22:56:49 -0600 (CST) Date: Mon, 29 Mar 2004 22:56:49 -0600 From: "Jacques A. Vidrine" To: Oliver Eikemeier Message-ID: <20040330045649.GE5998@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Oliver Eikemeier , FreeBSD Security 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> <40689343.4080602@fillmore-labs.com> <20040329224011.GA94303@madman.celabo.org> <4068B425.1070607@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4068B425.1070607@fillmore-labs.com> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i 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 04:56:50 -0000 On Tue, Mar 30, 2004 at 01:41:25AM +0200, Oliver Eikemeier wrote: > Hooks would be nice, but I guess we should have something in the base, > or at least let sysinstall install it by default before adding other > packages. *nod* Hooks fulfill the role either way, but have the advantage of allowing alternatives. > >Personally, I was quite pleased with the way that you have it set up: > >if users install portaudit, then they will be warned daily about ports > >that they have installed; and attempting to build the port results in > >much the same thing as FORBIDDEN. > > > >(I guess I could have some misunderstanding, though.) > > No, that is precisely the idea: marking a port in portaudit results in > much the same thing as FORBIDDEN, so the criteria to add a package to > the portaudit database is excatly the same as marking a port as > FORBIDDEN because of security reasons. That doesn't logically follow. The criteria for marking a port FORBIDDEN is (currently) quite different than the criteria for entering an issue into the FreeBSD VuXML document. I didn't in particular create VuXML to replace FORBIDDEN--- although I don't object if that is what folks want. > >Without portaudit, we have the current situation. The only ports > >marked FORBIDDEN are those where someone believed that problems are > >serious enough to mark it so. > > This should be the same with portaudit, even on past revisions of the > ports: The only port added in the portaudit database should be those > where someone believed that problems are serious enough to mark it so. > > To cite portaudit(1): > > "If you have a vulnerable package installed, you are advised to update or > deinstall it immediately." OK, I think I understand your viewpoint. I believe you are asking for some connection to be made between VuXML and FORBIDDEN. But portaudit doesn't *in fact* have anything to do with that policy. portaudit is *in fact* a tool for implementing an alternate policy. In other words, you can't equate portaudit's policy with the FreeBSD Ports Collection's FORBIDDEN policy. That's begging the question. > >I often mail folks when I enter their port into VuXML. I intend to > >automate this nagging, but just haven't gotten around to it yet. > > What is the point in not marking those port as FORBIDDEN? It is easy to > remove (so you don't romp over port maintainers, like just committing the > fix, which might be done differently), gives maintainers time to analyze > the issue without piecing together a quick fix and prevents the vulnerable > version from being installed. In my eyes this benefits maintainers (who have > to fix these issues anyways, but have more room to do so) as well as users > (which normally do not want to use vulnerable ports, especially since > exploits get more popular every day), or do I make a mistake here? What are the advantages of this approach versus automated nagging, and prudently applying FORBIDDEN? I've already stated what I think the disadvantages are. But, of course I'm ready to hear more. [...] > >I'd like to take a step before committing myself (and any would-be > >VuXML contributor) into assigning a severity to every issue. If > >there is rough consensus from the ports community (committers and > >maintainers) that any documented security issue is grounds enough to > >mark a port FORBIDDEN, then we'll follow the policy that (entry in > >VuXML document) == (port must be marked FORBIDDEN). > > > >This seems to be your stance, and I do not think it is unreasonable. > >Although I made the comment earlier that I don't share the opinion, it > >is nonetheless attractive because it is simple :-) > > I can live with both. Either VuXML contains only entries that are so > serious that a port should be marked FORBIDDEN, or it contains additional > entries that are not of this importance and are marked as such. I guess we are at contrapoint. I specifically do not wish to constrain VuXML entries to only those which are ``serious'' (by some widely-accepted definition of `serious'). And I specifically want to avoid assigning severity to entries. See my other recent posting for reasons why. > The decision how severe an issue is has already be made with every commit > to the VuXML document (by marking the affected ports as FORBIDDEN or not), > it is only not documented. This is just a question of a clearly stated > policy, not about assigning a severity - that is already done. Well, you do have a point. So, I'm happy with this approach, but also willing to be convinced that other approaches are better. :-) Just in case I haven't stated it enough times yet to be clear, I'll do it once more: If the community wants all ports that become listed in the VuXML document to be marked FORBIDDEN--- well, we can arrange that. Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org