Date: Sat, 30 Sep 2000 17:08:37 -0600 From: Warner Losh <imp@village.org> To: Michael Bryan <fbsd-security@ursine.com> Cc: freebsd-security@FreeBSD.ORG Subject: Re: cvs commit: ports/mail/pine4 Makefile (fwd) Message-ID: <200009302308.RAA14067@harmony.village.org> In-Reply-To: Your message of "Sat, 30 Sep 2000 16:06:01 PDT." <39D671D9.62E7148B@ursine.com> References: <39D671D9.62E7148B@ursine.com> <008b01c02a71$6b8938c0$d04379a5@p4f0i0> <200009292349.TAA07263@giganda.komkon.org> <200009302123.PAA13609@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <39D671D9.62E7148B@ursine.com> Michael Bryan writes: : I don't like the idea of a setting that gets set once, then allows all : insecure ports to get installed without additional user confirmation. : I'd much prefer an implementation that provided the following functionality: : : 1) By default, will not install a particular port if it is : marked as potentially dangerous, but will instead provide : a warning to the user/installer. : : 2) The user can do an override for that particular port to go : ahead and install it anyway. That override must not carry : over to other insecure ports, and it probably should not : carry over to future re-installs of the same port. (In other : words, each and every time you go to build/install an insecure : port, you have to do something to override the default lockout.) : That way, the admin/user gets reminded of the potential danger : at every reasonable point. After reading the rest of the thread, I'd have to agree with this. I like Jordan's trust metric. We'd have to come up with a good set of defaults and policies (eg, we don't want all ports to get rated a 10, neither do we want them to get rated a 1). We want something that people can set on their systems easily, and override for each individual port as necessary. Things like delegate and pine would get high numbers (say 8 or 9), while things like zip would get a low number (1 or 2). xlock* likely would need a high number, etc, etc, etc. I think that there's a lot of support for this notion (I could be wrong). Enough that it would be interesting trying to see how hard it would be to come up with an API that is easy to implement in the ports system as well as integrate into our package system. It would be a fair amount of work, but I think in the long run it would be useful. Maybe a strawman proposal is needed. Comments? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009302308.RAA14067>