oh, okay, I see you are changing it to match the XCCDF.
change the XCCDF ID instead. its ID is more precise.
On 03/29/2013 08:29 PM, Shawn Wells wrote:
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 4/2/13 6:02 PM, Jeffrey Blank wrote:
oh, okay, I see you are changing it to match the XCCDF.
change the XCCDF ID instead. its ID is more precise.
(responding to all the NACKs, since the reasoning is the same).
I was making my way through the OVAL (in preparation to create remediation scripts), and several OVAL checks don't match the XCCDF rule name. In the past our stated goal was to have XCCDF == OVAL == remediation in regards of naming. Do you feel that no longer makes sense?
On 04/02/2013 06:07 PM, Shawn Wells wrote:
On 4/2/13 6:02 PM, Jeffrey Blank wrote:
oh, okay, I see you are changing it to match the XCCDF.
change the XCCDF ID instead. its ID is more precise.
(responding to all the NACKs, since the reasoning is the same).
I was making my way through the OVAL (in preparation to create remediation scripts), and several OVAL checks don't match the XCCDF rule name. In the past our stated goal was to have XCCDF == OVAL == remediation in regards of naming. Do you feel that no longer makes sense?
I don't recall that conversation, nor am I convinced of the value of doing so in the short term unless we're planning to remove the OVAL checking reference from the XCCDF shorthand entirely and auto-generate it during the XCCDF-OVAL linking phase. (We'd still need a way to specify variable Value refinements in the shorthand, of course).
On 4/2/13 6:07 PM, Shawn Wells wrote:
On 4/2/13 6:02 PM, Jeffrey Blank wrote:
oh, okay, I see you are changing it to match the XCCDF.
change the XCCDF ID instead. its ID is more precise.
(responding to all the NACKs, since the reasoning is the same).
I was making my way through the OVAL (in preparation to create remediation scripts), and several OVAL checks don't match the XCCDF rule name. In the past our stated goal was to have XCCDF == OVAL == remediation in regards of naming. Do you feel that no longer makes sense?
Jeff and I were chatting over IM, wanted to copy/paste the conversation to the list for transparency:
Jeff 6:11 i want to be able to spot things in a directory listing 6:12 and yes, i'm only interested in bothering with renaming if we're actually going to think about it and have it make sense 6:12 in a complete way 6:13 it's just not worth the time otherwise
6:13 Shawn fair. i'd like to atleast have XCCDF rules match OVAL titles for templated items, though. Example: sysctl
6:13 Blank, Jeff sure, that totally makes sense
So in effect, scrap the random renamings until (if?) a naming standard is developed, but keep those for macro'd content (generated out of RHEL6/input/checks/templates/) as those have a good enough quasi-standard for the project.
On 4/2/13 6:19 PM, Shawn Wells wrote:
On 4/2/13 6:07 PM, Shawn Wells wrote:
On 4/2/13 6:02 PM, Jeffrey Blank wrote:
oh, okay, I see you are changing it to match the XCCDF.
change the XCCDF ID instead. its ID is more precise.
(responding to all the NACKs, since the reasoning is the same).
I was making my way through the OVAL (in preparation to create remediation scripts), and several OVAL checks don't match the XCCDF rule name. In the past our stated goal was to have XCCDF == OVAL == remediation in regards of naming. Do you feel that no longer makes sense?
Jeff and I were chatting over IM, wanted to copy/paste the conversation to the list for transparency:
Jeff 6:11 i want to be able to spot things in a directory listing 6:12 and yes, i'm only interested in bothering with renaming if we're actually going to think about it and have it make sense 6:12 in a complete way 6:13 it's just not worth the time otherwise
6:13 Shawn fair. i'd like to atleast have XCCDF rules match OVAL titles for templated items, though. Example: sysctl
6:13 Blank, Jeff sure, that totally makes sense
So in effect, scrap the random renamings until (if?) a naming standard is developed, but keep those for macro'd content (generated out of RHEL6/input/checks/templates/) as those have a good enough quasi-standard for the project.
And some more --
Shawn other stuff an ack?
6:22 Jeff sure
6:23 Shawn wow, what a full endorsement ;)
Yeah, well, it wasn't.
These are certainly undesirable or neutral:
rename RHEL6/input/checks/{yum_gpgcheck_never_disabled.xml => ensure_gpgcheck_never_disabled.xml} rename RHEL6/input/checks/{accounts_nologin_for_system.xml => no_shelllogin_for_systemaccounts.xml}
In many ways the OVAL titles were more desirable than the XCCDF ones from an organization/naming perspective, but it's hardly a big deal. In any event, we should probably have a discussion to hash out some kind of naming strategy, if you think it's important. In any event, I think everyone seriously appreciates the OVAL QA that accompanied this!
Relatedly, is there any use for the description text in the current OVAL definitions? I believe it's just XCCDF description and could be added back in during the linking phase (occupied by a placeholder until then if it's a necessary element for the schema during the unit testing).
I also think changes to the template scripts in checks (which now generate some fixes) should instead have been done is a separate new directory for templated fixes in input/fixes/bash. Or possibly entirely auto-generated from a comment or note field in the OVAL checks. But it's fine for now, and we can improve it later. Refactoring is fun too.
On Tue, Apr 2, 2013 at 6:25 PM, Shawn Wells shawn@redhat.com wrote:
On 4/2/13 6:19 PM, Shawn Wells wrote:
On 4/2/13 6:07 PM, Shawn Wells wrote:
On 4/2/13 6:02 PM, Jeffrey Blank wrote:
oh, okay, I see you are changing it to match the XCCDF.
change the XCCDF ID instead. its ID is more precise.
(responding to all the NACKs, since the reasoning is the same).
I was making my way through the OVAL (in preparation to create remediation scripts), and several OVAL checks don't match the XCCDF rule name. In the past our stated goal was to have XCCDF == OVAL == remediation in regards of naming. Do you feel that no longer makes sense?
Jeff and I were chatting over IM, wanted to copy/paste the conversation to the list for transparency:
Jeff
6:11 i want to be able to spot things in a directory listing 6:12 and yes, i'm only interested in bothering with renaming if we're actually going to think about it and have it make sense 6:12 in a complete way 6:13 it's just not worth the time otherwise
6:13 Shawn fair. i'd like to atleast have XCCDF rules match OVAL titles for templated items, though. Example: sysctl
6:13 Blank, Jeff sure, that totally makes sense
So in effect, scrap the random renamings until (if?) a naming standard is developed, but keep those for macro'd content (generated out of RHEL6/input/checks/templates/) as those have a good enough quasi-standard for the project.
And some more --
Shawn
other stuff an ack?
6:22 Jeff sure
6:23 Shawn wow, what a full endorsement ;)
______________________________**_________________ scap-security-guide mailing list scap-security-guide@lists.**fedorahosted.orgscap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.**org/mailman/listinfo/scap-**security-guidehttps://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide@lists.fedorahosted.org
-
Jeffrey Blank -
Jeffrey Blank -
Shawn Wells -
Shawn Wells