cvs commit: ports/multimedia/xine Makefile
eikemeier at fillmore-labs.com
Mon Mar 29 15:41:30 PST 2004
Jacques A. Vidrine wrote:
> Speaking of pkg_add, I was thinking it might make sense to add hooks
> to these utilities, either in the form of loading dynamic objects or
> just invoking shell scripts. It seems that knu@ would be able to
> use these for portupgrade, we could use them for portaudit and VuXML
> related items, and power users could use them to invent their own
> local uses. But, that's a discussion for ports@ I guess.
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
> 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.
> 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."
> 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?
>>Since you are the FreeBSD Security Officer, you are the ultimate authority
>>what issues are serious.
> I'm just a guy. The Security Team are just more guys (but very
> helpful and clueful ones--- thanks guys!!). We want and need
> coordination with the ports maintainers: they (should) have a level
> of expertise with their particular applications that we simply cannot
> have for the 10,000+ ports.
I totally agree, although this doesn't conflict with the sentence above.
> Not to mention, ports maintainers can be touchy. As can we all :-)
I can understand this in the case of functional changes to the port,
things that could have been done differently. A FORBIDDEN line could
only be removed, whether you like it or not. And if the port maintainer
believes that the vulnerability doesn't exist, (s)he could remove the
entry from the VuXML file, or set the severity to minor, so backing out
from a FORBIDDEN is easy too.
Of course I don't like to maintain a vulnerable port... ;P
>>It seems like there are criteria that have consequences (marking
>>a port FORBIDDEN or not), please note this somewhere in the VuXML
> 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.
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.
More information about the freebsd-security