On Tue, Aug 11, 2020 at 1:24 AM Shane Boulden <[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. > > 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] > > 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. > On Mon, Aug 10, 2020 at 8:18 PM Matej Tyc <[email protected]> wrote: > >> I have remarks to Gabe's remarks, but I add them to Watson's reply, so >> the thread doesn't bifurcate. >> On 10. 08. 20 10:22, Watson Sato wrote: >> >> >> On Sat, Aug 8, 2020 at 12:10 AM Gabe Alford <[email protected]> >> wrote: >> >>> Anything that is metadata should conform to the Dublin Core per the >>> XCCDF specification for the .profile files, or it can be a commented out >>> section at the top of the .profile. >>> >> As the purpose is to record key properties of the profile, I am not in >> favor of specifying them as comments - one can't parse them reliably, and >> as we would like this to save us some work, we want to have at most one >> schema that can be approached by computers. >> >> Next, the schema presented by Watson reflects what we think is useful to >> record. I wouldn't compromise here because of the Dublin thing. I >> understand this as a resource for content authors, it could possibly be >> inserted as a table into the profile description, and we could have a test >> that key profiles have this record. Putting this info into profile XCCDF >> metadata makes sense, but I wouldn't use this as a factor that would >> restrict the data set that we would like to record. >> >> I didn't envision this metadata to be included in the built XCCDF >> profile, so I didn't look into the formal syntax. >> And it is laid out as yaml to ease any eventual build system future >> automation. >> >> >>> Alternatively, a single file like maintainers or profile maintainers >>> would be better as a single source of truth. >>> >> >> That could work too, in this case I would make the file per product, to >> keep them simple. >> >> I don't get the single source of truth thing - wouldn't it be the >> respective profile file? Typically, one is interested in who maintains a >> particular profile, not in how many profiles one person maintains. But more >> importantly, I think it is important to see who maintains the profile when >> one edits the profile file, or when one reviews the change. Having two >> files - one with the profile definition, and the other one that may or may >> not contain information about possible profile stakeholders - is cumbersome. >> >> >>> nitpick: I think that "comes_into_force" should be something else like >>> "when", "applicability", or "profile_enforcement". >>> >> >> Thank you for the suggestions, I was not sure what would be a good name >> for the field. >> >> But this also makes me wonder if tracking this is even necessary as >>> technically in all compliance regimes a newly released profile becomes >>> applicable on release. >>> >> >> The core of this field is clarity and understanding how the policy is >> applied in practice, if it is the case that all policies and profiles are >> instantly unusable when a new version is released, >> this field is unnecessary. >> The proposal for "comes_into_force" assumed that the organizations >> implementing and/or enforcing the policy don't update instantly, and have a >> time frame to adapt. >> >> I see this as a possibility to at least loosely define shape of profiles >> - if a stakeholder claims that they expect the profile to be behind at most >> six months, then comparison of a couple of numbers can quickly tell us >> whether the profile is good, on track, or whether it was left behind. >> >> Below is a draft proposal of a set of *optional* metadata to be added to >> the ".profile" file. Everything is pretty much free form and optional. >> >> - policy_hub: (URL pointing to page or organization that publishes >> the policy) >> - version: (version of the policy implemented) >> - comes_into_force: (text stating when a policy starts being >> enforced, in other words, when a policy version is in practice obsolete) >> - maintainers: (contact of policy SME, stakeholder, or person >> responsible for the profile, can be in form of GitHub handle for example) >> >> 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] >> >> >> >>> >> On Fri, Aug 7, 2020 at 9:21 AM Watson Sato <[email protected]> wrote: >>> ... >>> >> -- Watson Sato Security Technologies | Red Hat, Inc
_______________________________________________ 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]
