-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Fri, Mar 14, 2014 at 04:25:48PM -0600, Chris Murphy wrote: > On Mar 14, 2014, at 1:06 PM, "Eric H. Christensen" <sparks@xxxxxxxxxxxxxxxxx> wrote: > > On Fri, Mar 14, 2014 at 06:59:18PM +0000, Matthew Garrett wrote: > >> On Fri, Mar 14, 2014 at 02:57:33PM -0400, Steve Grubb wrote: > >>> On Friday, March 14, 2014 06:53:42 PM Matthew Garrett wrote: > >>>> Having separate server, workstation and cloud products means we can > >>>> apply separate defaults without requiring user interaction. Beyond that, > >>>> why would an end user want to choose common criteria during an > >>>> interactive install? Isn't that something that should be imposed on them > >>>> by their local admin? > >>> > >>> Yes, and I believe the kick start would do that. I would also even see a case > >>> where an admin takes the base policy and tailors it with site specific settings > >>> and puts that into effect instead of the default one we provide. I like the > >>> idea of choice. > >> > >> Exactly, this is functionality that makes sense for enterprise and > >> automated deployments. I don't see it making sense for an interactive > >> install. > > > > You're making an assumption that I wouldn't want my personal box to be hardened at install or that the enterprise has an automated way of doing a deployments. Why make it harder to use the operating system when a simpler way of configuration has been suggested? > > I think Matthew is making a reasonable assumption that many (probably even most) other users will become confused to the point of being disturbed by something that seems to require their attention, has a UI with terms they aren't likely familiar with, while suggesting choices, yet at the moment there's only one policy (?) so why is a UI needed for this right now? Today there are three policies. Tomorrow there will likely be many more. I can name off probably a dozen policies that might be useful. > > The feature isn't going to be a massive change to the UI and only adds to the awareness that users have a choice on how hardened their system is at install time. Whether you chose to use it is your business. > > At this point it doesn't appear to need a UI. There's no off or on switch, or opt in or opt out. There's one policy. I'd say even with three policies available I'm much better off with a slider that says Standard Security - More Secure - Most Secure. I mean, that's sufficiently dumbed down I still don't know what those things actually mean in terms of policy or behaviors, but relative to each other I've made a more informed decision than what I'm currently presented with. I mean honestly how complicated does an OS install need to be? It's like piling on the user. Because it's much more than None <-> More <-> Most. This tool can configure a system in many different ways to meet a policy. > It does need a default, like Timezone spoke, even though sometimes that too is set wrong for a particular user. The default avoids the requirement the user enter the spoke. It should be a minimum recommended security policy. Right, there are things in anaconda that do not require me to make any selection right now. This policy selection should be similar (the visual markups that I've already seen seemed to show this being optional). Only venturing inside will the user be presented with a choice where I suspect "None" will also be an option. - -- Eric - -------------------------------------------------- Eric "Sparks" Christensen Fedora Project sparks@xxxxxxxxxxxxxxxxx - sparks@xxxxxxxxxx 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQGcBAEBCgAGBQJTI4enAAoJEB/kgVGp2CYveMAL/17K2PwhrvMc7kdRaL8n65qv 6UM9cp9LrbKd/Ah8ZQFuSBdgWor+cdDQhB3GRDa/dnT5qsZAtSCCnHXbMVNseRcR QgU66JIgwoUMkSdQ7tSM9CRLf8enXgbqY1qYRguVnRL7I7AihMu9xX29PCd+ws6q sNlAmSPLUZZ2znGDWTcTmt8FJavt5NQD0+DadLy0PL1v6YpOxtHyoc9Y1/4L6xY+ t014QFWuHKlIagGzLLYHZeUsyNx4yXaI3VVfTbIkqyVEQ5F/bbvFhmHSScUXf4I5 CI+RTb5MzC0WrATMz8v2hoeUDdYzUb3jwH2OpQnwepoYUZ0+u5GCurWpNkDTENDI CPLkMcUyh86s5LTyi1pP2+ExblFb59FUe9fVZs+LPIAqgWeEE2Hocx7Mkt5xAlI+ b9vljj++GdE0xTEzckX66XNFVPgIHW1zD/UTvLVGRE9qIUtewuYnNY5y/B0Vu78j kyz14zToCMQZh15o6xjoXzfoi2/LGrzoBV0sjfVkGg== =ULWV -----END PGP SIGNATURE----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
