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 / [email protected] / [email protected] / [email protected] _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"