Re: cvs commit: ports/multimedia/xine Makefile

From: Jacques A. Vidrine (nectar_at_FreeBSD.org)
Date: 03/30/04

  • Next message: Oliver Eikemeier: "Re: cvs commit: ports/multimedia/xine Makefile" 
    Date: Mon, 29 Mar 2004 16:40:12 -0600
To: Oliver Eikemeier <eikemeier@fillmore-labs.com>

    On Mon, Mar 29, 2004 at 11:21:07PM +0200, Oliver Eikemeier wrote:
    > Jacques A. Vidrine wrote:
    > >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.

    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.

    > >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.

    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.)

    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.

    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.

    > >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.

    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.

    Not to mention, ports maintainers can be touchy. As can we all :-)

    > It seems like there are criteria that have consequences (marking
    > a port FORBIDDEN or not), please note this somewhere in the VuXML
    > document.

    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 :-)

    > >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.

    By all means, there's certainly nothing wrong with hosting your
    project on your own page. But Oliver, when one visits the URLs
    that you've posted, one is presented with content that, in the vast
    majority of cases, was not authored by you and has little association
    with `portaudit'. So, I ask again that you please consider using the
    vuxml.freebsd.org URLs when displaying URLs for VuXML entries.

    Cheers, 

    -- 
Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
  • Next message: Oliver Eikemeier: "Re: cvs commit: ports/multimedia/xine Makefile"

    Relevant Pages

    • RE: How often portupgrades?
      ... >> complete gnome port which took a couple days! ... > uninstall) if a given port has a security fix for it. ... > Did a smidge of research and I think it is portaudit ... > worried about it then upgrade (perhaps have portaudit ...
      (freebsd-questions)
    • Re: cvs commit: ports/multimedia/xine Makefile
      ... > the portaudit database when you won't mark the port as FORBIDDEN. ... To me it makes no sense anymore to mark ports FORBIDDEN for security reasons ... portaudit to forbid access to packages or just warn about them from a set of ...
      (FreeBSD-Security)
    • Re: gaim or aim on 5.4 amd64 ?
      ... > some security issues, thus portaudit prevents You from installing it. ... Portaudit merely reports on security vulnerabilities in the ports. ... Portaudit will not prevent the install of a vulnerable port. ...
      (freebsd-questions)
    • Re: cvs commit: ports/multimedia/xine Makefile
      ... >>if users install portaudit, then they will be warned daily about ports ... > the portaudit database is excatly the same as marking a port as ... entering an issue into the FreeBSD VuXML document. ...
      (FreeBSD-Security)
    • Re: cvs commit: ports/multimedia/xine Makefile
      ... The criteria for marking a port ... The problem here is that the portaudit database is generated from the ... VuXML document, and the criteria to add a package to the portaudit ...
      (FreeBSD-Security)