Date: Mon, 29 Mar 2004 14:19:26 -0600 From: "Jacques A. Vidrine" <nectar@FreeBSD.org> To: Oliver Eikemeier <eikemeier@fillmore-labs.com> Cc: FreeBSD Security <security@FreeBSD.org> Subject: Re: cvs commit: ports/multimedia/xine Makefile Message-ID: <20040329201926.GA88529@madman.celabo.org> In-Reply-To: <40687E18.9060907@fillmore-labs.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 29, 2004 at 09:50:48PM +0200, Oliver Eikemeier wrote: > Jacques A. Vidrine wrote: > >The vulnerability database is meant to be comprehensive and > >informational. It is not a policy document. > > I guess it is supposed to be processed by automated tools? It needs a > clearly defined policy, an informal document is useless for portaudit. (BTW, that's ``informational'' not ``informal''.) I'm sorry, but I don't understand what you mean. Seems to me like portaudit is doing a great job for its users based on the current information. > >>>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 :-) In short (and to repeat), I do not believe that ports should be automatically marked FORBIDDEN upon entry into the VuXML document. > FORBIDDEN is black-and-white, like an entry in the VuXML database > is. FORBIDDEN means: do not install this port, or you are on your > own. What is the meaning of an entry in the VuXML database? It means that there are security issues associated with this port, and that you should be aware of them. > You could argue that xine port isn't vulnerable if both scripts > aren't used. OTOH, why are they installed in the first place? It is > simple to fix the port: don't install these scripts. Yeah, that would be an appropriate action for the port maintainer to take. Just like I do not mark every port with any security issue FORBIDDEN, I do not romp over port maintainers committing changes unless the issue is `serious' enough in my opinion. There are several reasons for this: if it isn't `serious', I'm not likely to find time or interest to repair it; and it is impossible to be familiar with every application, and I work under the assumption that `maintainer knows best'. > >>>>http://people.freebsd.org/~eik/portaudit/fde53204-7ea6-11d8-9645-0020ed76ef5a.html > >>> > >>>By the way, I'd appreciate it if you'd point to the VuXML site instead > >>>(the URLs are `permanent'). > >>> > >>> http://vuxml.freebsd.org/ > >>> http://vuxml.freebsd.org/fde53204-7ea6-11d8-9645-0020ed76ef5a.html > >> > >>These are generated by the same script that generates the portaudit > >>database, so they will never go out of sync. > > > >I'm not sure how to take that response :-) I'd prefer to use the > >permanent FreeBSD URL, which points to the VuXML site which is near > >real-time updated and where I'll be focusing browsing experience > >enhancements. Is there something in particular missing? (contributions > >welcome!) > > No, but the former URLs are permanent too, have > <http://people.freebsd.org/~eik/portaudit/1ed556e6-734f-11d8-868e-000347dd607f.html>; > which is mentioned in > <http://www.freebsd.org/cgi/mid.cgi?db=mid&id=200403111145.i2BBjQfa088098@repoman.freebsd.org>, > are guaranteed to be synchronized with the portaudit database and contain > the same information. I have to generate them anyway, so what's the point? Well, I feel references that will be in our archives and in our commit logs are better not pointing to personal web sites (as people...~eik clearly is). I guess you have some reason to disagree but are unwilling to state it. *shrug* Of course you can do whatever you like. Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040329201926.GA88529>