On 12. 08. 20 1:39, Gabe Alford wrote:
On Tue, Aug 11, 2020 at 6:00 AM Watson Sato <[email protected]
<mailto:[email protected]>> wrote:
On Tue, Aug 11, 2020 at 1:24 AM Shane Boulden <[email protected]
<mailto:[email protected]>> wrote:
I like that the proposal adds "policy_hub", "version" and
"comes_into_force" into the profile file (with the assumption
that this will not make it into XCCDF). Having this
information directly in the .profile file makes it simpler for
users and partners to see the current state.
The more I think about it, the more I am against comes_into_force.
This isn't something that should be maintained or used upstream and is
easily misconstrued (even if documented) for when an organization
enforces policy and policy changes.
The more correct way is to open a milestone upstream and associate
tickets with that milestone which would include the policy reference
and version.
This provides an accurate picture and would easily show and tell users
what needs to be done to help complete tickets for closing out gaps in
the profiles.
It also shows that security analysis has been performed for what has
to be done to a profile for a product version.
By creating tickets, you mean something like this?
https://github.com/ComplianceAsCode/content/labels/New%20rule%2Fprofile
We have a long history of tickets that nobody asked for, and that were
perhaps created in good faith, but they are still there, and there is a
lot of them (almost 1/3 of all open tickets). I would like to avoid a
situation of creating more tickets that at the end, nobody finds useful.
Adding keys that are only used upstream don't provide as much value as
keys that are used in the downstream validated content.
The "policy_hub" should become "reference" and both "reference" and
"version" can be added to <xccdf:Profile> when the content is generated
This would provide more value in the long run and can be easily
discoverable in official reports.
The original idea is exactly about allowing new profile metadata to
profile files. This means that it is a backward-compatible extension of
the input format which requires almost no implementation. Some profile
authors already found think that it is useful, and that's good sign for
us - we target profile stakeholders and content authors, and it is good
enough if only some of them are interested. If it doesn't work out, no
problem - upstream-only metadata can be removed or altered without
causing substantial issues to other ComplianceAsCode users.
What you propose is something else - embedding the information into the
datastream would, among other things, require support for XCCDF1.2 in
our build system, which is a significant development effort. I don't
disagree with that, I just why not to start small?
I see an issue with maintainers - we can mix up at least GH
usernames and e-mails - what about considering it a list of dicts,
so we could have e.g.
maintainers:
- github: redhatrises
- github: yuumasato
email: [email protected] <mailto:[email protected]>
Could we use coThe idea to use cocdeowners
<https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners>
instead to track profile maintainers? This way the profile owners will
be immediately notified when a PR is opened for a .profile file, and
avoids having to maintain dicts of username->email mappings (it's
simply tied to the GH username)
The automatic notifications of codeowners make it very interesting.
I have two remarks though:
1. maintenance of the codeowners file, which needs to be done by
admins or owners;
2. permissions, codeowners need to have write permission for the
repo;
This centralizes the management of Profile "ownership" and
increases requirements on the codeowners.
I actually really like this idea of using codeowners to track profile
maintainers and think it is a more elegant solution than keeping track
in the profile.
Again, why not to track things in the profile, and introduce the
codeowners concept once it's established? Maybe not all profile
stakeholders want to approve every PR that touches their profile.
Moreover, the codeowners is a slightly separate thing - it should target
reference compiled profiles, as a profile composition may change as a
result of a change in extended profile.
For example Ted is a STIG stakeholder, but not an OSPP stakeholder, so
we would incline to have his name in the STIG profile file, but not in
the OSPP one. But in RHEL8, the STIG currently inherits from OSPP, so he
should be notified of OSPP changes that propagate to STIG, and that's
where the codeowners system could help.
_______________________________________________
scap-security-guide mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
