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

Reply via email to