On Fri, Sep 18, 2015 at 07:43:31 -0400,
Jan Lieskovsky <jlieskov(a)redhat.com> wrote:
----- Original Message -----
> From: "Bruno Wolff III" <bruno(a)wolff.to>
Two points here:
* what it means to be updated wrt to Fedora -- all updates from 'fedora' repo
are installed? All updates from 'fedora-updates' or even all updates from
'fedora-updates-testing' repo are installed?
I think we would care if security updates weren't getting applied.
* second maybe even more crucial being OVAL as a language forbids to
run some
shell command to perform the check. And since yum / dnf doesn't provide a system
flag e.g. in /etc/yum.conf or /etc/dnf/dnf.conf if system is updated (read as
the only way to check if system is updated or not is to run 'yum | dnf
check-update'),
I didn't realize that. That makes things harder.
> Update checking in Fedora also has problems that RHEL
> doesn't, as soname bumps can block some updates, particularly when running
> rawhide, branched or updates-testing.
Is this possible also for security updates? Or "just" for feature updates?
Yes, security updates can be blocked by this. This would mostly happen in
branched and rawhide where the update could easily become available before
all dependents of a library have been rebuilt. It is less likely to happen
with updates, as soname bumps are to be avoided if possible for updates.
One check wrt to "However it would be nice to be able to continue
to run Fedora."
statement above -- currently content for Fedora provides just 'Common' profile
(trying to be universal). But that universality means a lot of rules need to
be ported yet before the profile can be considered complete.
It looks like scap-workbench makes it pretty easy to turn on features to make
modified profiles as long as the features are in the xccdf file.
Would it make sense to create more specific ('Server',
'Cloud', or even 'Workstation')
profiles, possibly containing less rules && therefore being complete sooner?
I would think that it would make sense to eventually have profiles for
each of those. I think this would be more for prioritizing what order
tests might be developed. It's possible that some people from the cloud or
server groups might want this and find some resources to work on it.
Thanks for your comments about the current and future state of scap support.