Jeremy C. Reed wrote:
> 
> On Thu, 23 Mar 2006, Johnny Lam wrote:
> 
> 
>>I don't think having a "security" depends is a good idea, and I would rather
>>see the practice of bumping dependencies for security-related reasons go away.
>>We should manage security-related issues externally instead of shoehorning
>>them into a package dependency graph.
> 
> 
> I also do not like the idea of bumping RECOMMENDED for each security fix. 
> That is one reason someone may choose to use IGNORE_RECOMMENDED, but the 
> Todd's suggested BUILDLINK_SECURITY_DEPENDS and a corresponding 
> IGNORE_SECURITY_DEPENDS could fix that.
> 
> I think audit-packages is good enough. But having a 
> BUILDLINK_SECURITY_DEPENDS/IGNORE_SECURITY_DEPENDS might be good to 
> automatically encourage security updates. Maybe IGNORE_SECURITY_DEPENDS 
> could be disabled by default?

If we're going down this route, I want us (pkgsrc) to be very explicit 
about what it means to have a package "depend" on another package.  Are 
we saying that a dependency is the minimum package needed to satisfy a 
requirement?  Or we are saying that it's the minimum, *non-vulnerable* 
package needed to satisfy a requirement?  I simply don't think the 
latter is a good definition.  You won't find that definition anywhere in 
software READMEs ("requires zlib>=1.0, but make sure you use a 
non-vulnerable version of zlib!").  Let's just have dependencies have 
their usual meanings, and stop (ab)using them for security reasons.

I think we should make users more aware of audit-packages, and to push 
that as the security-check mechanism for pkgsrc.  We've already 
integrated audit-packages into the pkgsrc build so that we can tell if 
we're building vulnerable packages -- now we just need to make users 
aware of how use audit-packages to tell if they're running vulnerable 
packages on their systems.

	Cheers,

	-- Johnny Lam <jlam@pkgsrc.org>