cvs commit: ports/multimedia/xine Makefile
Oliver Eikemeier
eikemeier at fillmore-labs.com
Mon Mar 29 13:21:15 PST 2004
Jacques A. Vidrine wrote:
> 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''.)
Sorry, you're right.
> 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.
Thanks for the compliments, the point is that portaudit is designed to
be a non-brainer, telling people to stop using vulnerable ports
immediately. On the long run I want to integrate support in pkg_add,
so that you could even mark ports as vulnerable on release discs (given
that sysinstall gets a current portaudit database). There is not such
thing like `it might be ok if you are careful' here.
>>>>>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.
Essentially this means that I should not automatically add every entry
of the VuXML document to the portaudit database, since being listed there
means `do not use this port', which is the equivalent to `FORBIDDEN'.
>>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.
Ok, I either need a way to filter out the `unimportant' entries automatically
then, or I have to do this by hand.
>>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'.
Since you are the FreeBSD Security Officer, you are the ultimate authority
what issues are serious. It seems like there are criteria that have
consequences (marking a port FORBIDDEN or not), please note this somewhere
in the VuXML document.
> [...]
>
> 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). [...]
It is an server of the FreeBSD project, not a personal one, and a long
standing FreeBSD tradition that people have their projects on their FreeBSD
web page, so consider this to be a project page.
-Oliver
More information about the freebsd-security
mailing list