Jeff,
Thanks for the confirmation. I agree about the macro idea -- I ran that by my folks here as well, and I was told that for the time being we'll shelve it, and move forward. I'm glad that I'm not the only one that sees it that way.
As for me, what I thought of doing was matching what OVAL is actually doing at the OS level for its checks, and align it with the description text that the user will see. As you already know, so many people (in the arenas who'll use this product) may/may not trust the check scripts, and they may want to do their own checks.
Will commit per this reply of yours.
Thanks.
Mike
Thanks -- please commit.
It'll probably get some re-write (during a copy editing stage) and re-formatted likely even sooner than that (along with lots of other text). We may also want to create some macros for repetitive text patterns such as partiton checking, such as was done for the sysctl-desc-macro.
This is a good reminder that I need to determine and document where we want to put:
- manual audit instructions ("check" -- though has sometimes been in
the description tag) 2) manual remediation instructions (in "description" or "fixtext") 3) rationale (what DISA calls "Vuln Discussion")
I need to do a quick survey and determine how best to migrate the content to this type of granularity while still achieving all the desired outputs. That said, it's very important that in many cases already the_information_is_there, it's just a matter of formatting.
It is not terribly important if we choose one place or the other for these, though a definite preference will be to place them where the SCAP specifications indicate is most appropriate. For users who need the information in a different tag, there's always XSLT to transform it.
The manual audit instructions will be evolved into OCIL when it is adequately mature, which may inform its placement. In general for instructive text, it is highly desirable to use broadly-acceptable, concise style that is re-usable by a wide audience. Peculiar or Dalek-style speech should be avoided, though it is currently permitted in alternate titles files. Such special needs can be worked on a case-by-base basis.
In general regarding tone (and I think your commit respects this principle well), the project's goal is to provide security technical implementation guidance (in a literal sense) for system administrators. While the project is likely to be useful in creating documentation for a C&A package, it absolutely must be meaningful to system administrators.
Thanks for the commit!
On 09/05/2012 03:07 PM, Michael J. McConachie wrote:
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide