Hi all, a test email from my mutt client. You should be receiving this on the
mailing list, from my @redhat email, with an attachment containing the single
patch (named in the title).
Intially, I thougtht it would be prudent to do several at a time,
passing them all into one patch file, but that can prove hard to read at
times, and hard to follow.
After some thought it might be better to do one at a time (so that we can track
he changes per the subj: line of each email). If need be, we can adjust
the desired frequency at a later date.
Back on September 4th you submitted a patch that commented out the xsltproc for generating the fixes. The commit message wasn't clear on the rationale for this removal. The change set in question is here:
I'm referring to the change in line 17/18. Was there a problem with the transform?
Per My conversation with Jeff today, I instantiated some new <ocil> tags
I cleaned up a little verbiage in the Fix Text Areas.
I also added some SELinux checking material(s).
I'll continue where I left off tomorrow,
Red Hat Consulting
Michael J. McConachie, RHCE
Consultant - Red Hat, Inc.
These commits should permit creation of manual checking text that can appear as
the made-up checksystem "ocil-transitional" (inline with the XCCDF), and can
also be automatically generated into proper OCIL. Well, valid OCIL. Addition
of a "clause" attribute is still needed in order to permit generation of a
question (or to make a statement about whether something is a "finding"). But
the support is now there to enable this to occur in earnest.
Jeffrey Blank (3):
additions to Makefile to create OCIL output from inline manual check
new transforms to create OCIL from manual checks, change inline
content to references
support for generating OCIL, synchronizing/generating OCIL IDs
RHEL6/Makefile | 6 +-
RHEL6/transforms/constants.xslt | 4 +-
RHEL6/transforms/cpe_generate.py | 4 +-
RHEL6/transforms/idtranslate.py | 206 +++++++++++++++++-----------
RHEL6/transforms/relabelids.py | 151 ++++++++++++---------
RHEL6/transforms/xccdf-create-ocil.xslt | 67 ++++++++++
RHEL6/transforms/xccdf-ocilcheck2ref.xslt | 35 +++++
7 files changed, 324 insertions(+), 149 deletions(-)
create mode 100644 RHEL6/transforms/xccdf-create-ocil.xslt
create mode 100644 RHEL6/transforms/xccdf-ocilcheck2ref.xslt
I appreciate all the work being done to develop RHEL6 content. Thanks to everyone!
My question is based on this.... I'll be reaching a point of testing a number of RHEL5/6 systems in bulk with openscap. Initially of course they'll be offline, development and/or non-production systems. OS versions would be a diverse smattering of RHEL 5.7, 5.8, 5.9 (when it comes out), 6.1, 6.2, 6.3 and 6.4 (when it comes out). Architecture would be both intel 32 and 64 bits. Most (if not all?) of these hosts would not have openscap.rpms already installed. I can readily envision full customer production systems expressly NOT having openscap.rpms installed on them at all, ever.
- Can a single edition (preferably the latest) of openscap combined with the latest content be 'brought' into the RHEL test/dev hosts and be successful in executing for scoring/assessment?
- Has anyone tried this yet?
This 'bringing in' would not be via RPM nor yum, but as an expanded gzipped tar file that is made available on an NFS share, so it was centrally available (for example). At that point execution could bring the benefits of modern openscap to site/host assessment, while not perturbating the customers' environment. Proving this works in test/dev, gives value to going forward with application against production systems that customers will not want changed, to the greatest extent possible. Another reason is that one cannot assume much less ensure any given 'environment to be tested' will have a yum repo available, nor that it would have the correct/right edition of openscap to install, via RPM, if the system owners would even permit it at the time of assessment.
rhn_gpgkey but the real Red Hat release signing key package name is
gpg-pubkey. The version and release strings must be used since they
specify the key ID and there are usually several versions of
gpg-pubkey installed at the same time.
Unless create_package_installed.py and template_package_installed are
refactored to support specifying RPM version and release strings this
test can't use templating.
Given that the only two packages that can have multiple versions
installed are gpg-pubkey and kernel is it worth modifying the
templating code to support these special cases?
per Peter's email ... more fixes to come
Jeffrey Blank (1):
correcting checktypes used in test for accounts_nologin_for_system
fix accidental addition of argument to testcheck's oscap
invocation...we get ovalresults anyway
RHEL6/input/checks/accounts_nologin_for_system.xml | 4 ++--
RHEL6/input/checks/testcheck.py | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)