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. 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
