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