On 3/3/14, 5:51 AM, Jan Lieskovsky wrote:
> Hello Vratislav,
>
> ----- Original Message -----
> > > From: "Lee Kinser" <lkinser(a)redhat.com>
> > > To: "SCAP Security Guide"
<scap-security-guide(a)lists.fedorahosted.org>
> > > Cc: "oscap-anaconda-addon"
<oscap-anaconda-addon(a)lists.fedorahosted.org>, "open-scap-list"
> > > <open-scap-list(a)redhat.com>
> > > Sent: Wednesday, February 26, 2014 2:53:24 PM
> > > Subject: Re: Ignoring SCAP content in the OAA
> > >
> to share my vote / opinion - I also like the second option (ON / OFF) more.
+1
> > > Personally, I like the look of option 2, but would go with wording like
> > > "Select Security Policy" and "Apply Security Policy".
> "Select Security Policy / Apply Security Policy" proposed by Lee look fine
to me.
>
> Thank you && Regards, Jan.
> --
> Jan iankko Lieskovsky / Red Hat Security Technologies Team
>
> > > Just my .02.
> > >
> > >
> > > --
> > > Lee Kinser
> > > Solutions Architect
> > > Navy & Marine Corps
> > > Red Hat Federal
> > > 843-868-1024 (Mobile)
> > > lkinser(a)redhat.com
> > >
> > >
> > > ----- Original Message -----
> > > > > From: "Vratislav Podzimek"
<vpodzime(a)redhat.com>
> > > > > To: "oscap-anaconda-addon"
<oscap-anaconda-addon(a)lists.fedorahosted.org>
> > > > > Cc: "scap-security-guide"
<scap-security-guide(a)lists.fedorahosted.org>,
> > > > > "open-scap-list" <open-scap-list(a)redhat.com>
> > > > > Sent: Wednesday, February 26, 2014 4:07:02 AM
> > > > > Subject: Ignoring SCAP content in the OAA
> > > > >
> > > > > Hello everybody,
> > > > > I'd like to ask you for a favour. In the development cycle
of the
> > > > > release 0.5 of the OSCAP Anaconda Addon, I've added an
autodetection of
> > > > > the SCAP Security Guide content which means that if the
> > > > > scap-security-guide package is installed in the compose and no
other
> > > > > content is specified in the kickstart file, the addon
automatically
> > > > > loads SSG content. I believe this brings us a big improvement in
UX for
> > > > > testing and finally moves us closer to including the OAA+SSG in
the
> > > > > default composes for next Fedora (and others) release.
> > > > > However, this also brings the need to allow user changing the
content
> > > > > used by the addon (to switch from autodetected SSG to some
different
> > > > > content) and "not applying" content to the system (to
easily turn of the
> > > > > functionality once it gets included in the default composes).
Turns out
> > > > > it's quite hard to come up with the right widgets and proper
labels
> > > > > (wording) that would explain user what's going on.
> > > > > The two mockup suggestions I've made so far are:
> > > > > 1.
http://vpodzime.fedorapeople.org/OAA_control_buttons.png
> > > > > 2.
http://vpodzime.fedorapeople.org/OAA_control_buttons2.png
> > > > >
> > > > > The 1. uses a GtkToggleButton that can be pushed down and stays
in that
> > > > > state and I think it should have some better wording catching
the
> > > > > process -- something like "Applying security
rules"/"Ignoring security
> > > > > rules" -- that would change when the button is toggled.
> > > > >
> > > > > The 2. uses a switch which relies on the related label next to
it and
> > > > > again even in this case, the right wording of the label is the
key, I
> > > > > think. What about "Apply security rules"?
> > > > >
> > > > > Please keep in mind the fact, that we would like this screen to
be shown
> > > > > even to unexperienced users who have no idea about SCAP and the
special
> > > > > terms/keywords it uses. We don't want to confuse users and
we want to
> > > > > give them an easy way to opt out.
> > > > >
> > > > > Any suggestions welcome! I'd like to release OAA 0.5 by the
end of this
> > > > > week, so it will come with the best layout and wording we will
be able
> > > > > to come up till that time.
In regards to content autodetection, IIRC, Grubb wanted content to be
placed into /usr/share/xml/scap/. Are you hard
coding /usr/share/xml/scap/ssg/content, or recursively searching
through /usr/share/xml/scap/?
Would be great to recursively search /usr/share/xml/scap/{content
provider}, which would reenforce to content developers to properly
place their files (or atleast symlinks) on the system.
For now, I'm hard coding
the SSG's paths and consider the SSG a special
content type. To be honest, I'd like to avoid doing any additional magic
for various contents. The addon already supports RPMs, so I'd really
prefer those contents be provided and referenced as RPMs. SSG is the
only exception because it could be included in the standard composes
officially provided for "our" projects.
--
Vratislav Podzimek
Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic