On Mar 14, 2014, at 1:06 PM, "Eric H. Christensen" <sparks@xxxxxxxxxxxxxxxxx> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > 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? This is usually what kickstart installs are for. > > 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. 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. The next question I have is how this spoke can affect other spokes, as well as affect the installation process itself? What I'm looking for is some assessment of impact on QA resources needed to test this feature, if any resources are needed at all. If there's no default but the user must interact with this spoke to proceed with installation, that's definitely a QA impact. There's maybe one or two toothbrush wrappers of spare resources in QA (and I'm already imagining Adam feverishly writing a reply, "UMMM, I don't think so, where?!") So if it's even remotely possible for a security policy to be chosen that later causes some sort of install, or even a first boot failure to happen - that's too much QA impact right now, short of a recruitment drive. Chris Murphy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
