Thank you for the proposal, Bill.
----- Original Message -----
> From: "Bill Nottingham" <nott...@splat.cc>
> Vratislav Podzimek (vpodz...@redhat.com) said:
> > Thanks for your feedback, it definitely is constructive! I've recorded a
> > video preview demostrating the feature's functionality. Hope that
> > answers at least some of your and others' questions.
> >
> > https://vimeo.com/89243587
>
> So, having watched the video, I think I'm pretty clearly against this from a
> interactive install standpoint, given what is presented.
>
> Here's what I see in that video. I'm not a UI/UX professional, so additional
> review from someone more along those lines would be great (and info on where
> I'm barking up the wrong tree - can always learn more.)
>
> INTEGRATION
> ===========
>
> Current toplevel is localization, software, and system. 'Security policy'
> doesn't fit as a toplevel along with that. If we wanted it as an additional
> item under 'System', des that mean it can't be done as an addon?
Will leave reply to this item to Vratislav (since I am not familiar with
Anaconda
plug-ins internals). Vratislav, can you clarify if this would be possible to
implement by changing the current design?
>
> INITIAL SCREEN
> ==============
>
> - You've got three active items:
>
> 1 - 'Change content' (button)
> 2 - 'Apply security policy' (toggle)
> 3 - 'Select profile' (button)
>
> If someone isn't familar with the specific terminology in use here, you're
> using three separate nouns here which all can be similar in meaning (policy,
> profile, content). If the user isn't familiar with all three terms, all
> three of these items could be seen as doing the same thing! That's not
> good.
Fair enough. To be consistent I would recommend we to stick just with the
security policy (and forget about the other possibly confusing terms) [*]
>
> If I were to whiteboard some proposed improvements of the screen you have
> (note: not saying this is the way to go vs. a full rework), it would be
> something like:
> rename "Choose another policy source..." button to read "Load external
security policy..."
Let me try to iterate on your proposal. Just a note (small correction) --
within policy we aren't selecting sub-policies, but rather profiles
(just question of naming convention).
FWICT I like your proposal in general, with small possible enhancements:
* have SCAP security guide policy loaded / selected by default,
* mention policy name in the middle of "Apply ..." toggle,
* provide description for each profile at the right side (as you proposed)
>
> Apply a security policy [ YES | NO ] (1)
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
> Policy 1 | (if we want details on the selected
> description 1 | policy, they go here on selection)
> |
> Policy 2 |
> description 2 |
> ... |
> -------------------------------------------------------------------------
>
> [ Choose another policy source ... ] (2)
>
> (1) If 'no' is selected, rest of screen is inactive
Agree with this item.
> (2) If this is still desired
As pointed out by other people in this thread too, having a way to select which
policy to apply is good (just for the case the more experienced user might want
to supply own modified policy).
But agree with that point, that for example on https:// URLs the certificate
should
be verified for validity (didn't try if it actually is already).
>
> There would be no 'select profile' button - it would be selected by just
> selecting the profile, similar to other anaconda actions.
+1. Agree that "Select Profile" button is redundant (not needed) here.
The slight modification of your proposal is listed below:
Apply SCAP Security Guide security policy [ YES | NO ]
---------------------------------------------------------------------------
| (Maybe description of the whole policy here?) |
| |
| |
---------------------------------------------------
Choose security profile: [**]
---------------------------------------------------------------------------
Common Profile | Longer description of the profile
Summary of the profile | shown upon selection
---------------------------------------------------------------------------
Server Profile | Longer description -||-
Summary of the Server profile |
---------------------------------------------------------------------------
.. | ..
.. |
---------------------------------------------------------------------------
[ Load external security policy ... ]
After click on "Load external security policy" button the other screen allowing
to download content would be displayed. The "Fetch" button would be renamed to
"Download policy".
[**] Probably with the tooltip text detailing that double-click on the profile
name is sufficient to select a profile.
>
> URL SCREEN
> ==========
>
> - Why is 'Use SCAP Security Guide' (presumably a predefined URL) a selection,
> if it is not the normal source of the choices in the initial screen? If
> we're shipping with predefined content sources, it should be reflected on
> the initial screen; if we're not using that predefined data, I'm not sure
> why it's an option here.
Agree here. SCAP Security Guide should be selected as default on the first
screen and it's not needed to be listed here again. If the user wanted to
switch, they would just click "Done" and no change would be made wrt to
default selection.
>
> - 'Enter data stream content or archive URL here'. Again, too jargon-y.
>
> Is there a reason 'Enter URL to security policy' isn't good enough? (Or
> whatever terminology is used in the software spoke.)
"Enter URL to a security policy" seem to be sufficient. The security policy
itself can come within different formats (XCCDF file, datastream, ARF etc.)
(Assuming) The original name 'Enter data stream content or archive URL here'
tried to be self-explaining wrt to list of currently supported formats,
security
policy can be provided in. But agree it's more confusing, than explaining.
So just "Enter URL to a security policy" would do the trick (the allowed
formats could be displayed as the tooltip text when the user moves with the
mouse over the text entry).
>
> PROFILE DETAILS
> ===============
>
> It's best when describing details (if we want to do so) that we don't use
> different terminology or concepts than what is used in the rest of the
> installer, if at all possible.
>
> In your example, we have:
> - 'logical volume'
>
> This only shows up in custom partitioning, and even then not very
> foregrounded (unless I'm missing something).
>
> - 'mount options'
>
> Not used anywhere.
>
> - 'package', 'list of installed packages', 'list of excluded packages'
>
> Packages are not exposed in the installer UI as user-interactable objects -
> the only place they show up (outside of error messages) is as part of the
> installation progress bar.
Will leave Vratislav to reply to above section.
>
> Above and beyond that:
>
> - We should not be showing things as warnings. If the policy says a password
> must meet certain parameters, and we let the user later set it up in a way
> that violates that without additional warnings or automatic remediation,
> that's a bug.
IIRC WRT to root password setting Vratislav mentioned it's a bit special
case - the policy might require root password to have certain length, but it's
not possible to enforce it before the start of the installation. So (assuming)
warning is here to notify the user some rule requires some condition, that
condition is not met, and Anaconda does not (yet?) have a way how to ensure that
condition would be met after the install (thus "somehow" notifies the user that
condition needs to be re-verified and possibly after the install again yet).
Vratislav, pls correct me if I didn't describe this use case correctly.
>
> - The error situation is even worse. It's really bad form to show them
> an error in spoke A *that they inherently have to know how to fix in spoke
> B*. Otherwise, you're giving them an easy way to break their system that
> they won't know how to get out of, with no indication of where they have
> to go to fix it.
>
> Selecting the error should take them to the screen where they can fix it,
> and it should be a 'normal' installer screen that they've seen and can get
> documentation on, not something 5 layers deep in a custom workflow that
> they wouldn't know how to get to again.
Agree with this section.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
>
> ...
>
> Given that, I think the interactive UI could use some significant rework
> before we put it in Fedora's installation images by default.
[*] Just for posterity - security policy is a set of (security hardening) rules,
security profile is subset from that set identified by its name. To refer
to all data (security policy, various particular profiles that can be
inherited from
it and other information [like common platform enumeration {CPE} data
for example etc.]), the term "security content" or just "content" is used.
>
> Bill
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
