On Sat, Dec 1, 2012 at 6:20 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Rich Freeman posted on Sat, 01 Dec 2012 08:46:34 -0500 as excerpted: > >> And if we force some types of packages to be masked all the time, then >> what do we do if we actually need to mask them for removal or security. >> Users won't even realize they have a known flaw, because they had to >> unmask the package just to install it. I think there is a big >> difference between "bundles libs and therefore might have a security >> issue" and "has a known security issue." > > Very good point. > > Being a (somewhat pragmatic) security emphasis person by default, as well > as a freedomware person, I had been leaning toward the "mask it and let > the user decide" viewpoint, but this question changed my mind entirely. > > What about this for a reasonable but still somewhat strict compromise? > > a) A pkg_pretend phase that checks for a set variable (like > I_KNOW_THE_SECURITY_ISSUES), and dies with an appropriate warning if it's > not set. > > b) With (a) in place, keeping the package unmasked (unless (c)) but > forever ~arch, no stable. > > c) Deal with known security issues as normal, that is, mask the package, > with possible eventual removal. > > > It seems to me that this is a reasonable compromise giving both sides > what they want. (a) forces the user into a hard opt-in to actually > install the package, (b) keeps the package at least visible to ordinary > users (those willing to deal with ~arch at least), and (c) means we can > still notify users that have opted-in when there's a known security issue.
Look, if you want to make a policy about the stuff, then make a policy, get council approval, and write it down. Don't make up silly half-solutions. -A > > If this proves to be a reasonable compromise, it's possible there's other > packages for which it can be used as well. > > -- > Duncan - List replies preferred. No HTML msgs. > "Every nonfree program has a lord, a master -- > and if you use the program, he is your master." Richard Stallman > >