Closed tjungblu closed 3 years ago
/assign @jhrozek
I'd like to echo the comment @JAORMX had about testing, but (and maybe I just don't see the full picture), doesn't this approach of writing the ReasonForError into the body have the possibility to affect rules that just check for an existence of some yamlpath? I'm not sure we have any honestly and we should be defensive and check that the object fetched is what we intended to fetch, but writing errors into the object result makes me nervous.
A test would make things clearer.
I'd like to echo the comment @JAORMX had about testing, but (and maybe I just don't see the full picture), doesn't this approach of writing the ReasonForError into the body have the possibility to affect rules that just check for an existence of some yamlpath? I'm not sure we have any honestly and we should be defensive and check that the object fetched is what we intended to fetch, but writing errors into the object result makes me nervous.
A test would make things clearer.
As far as I can tell, this shouldn't really affect existing rules. But that's exactly why I asked you to take a look as well. Wanted a second opinion on this and if you could think of any rules that would be affected by this (I couldn't). I personally like the approach, as it would end up in an empty YAML file with merely a comment that contains the status.
added a test @JAORMX @jhrozek
just check for an existence of some yamlpath?
do you guys have an understanding of what rules might be impacted by this? I remember @JAORMX explaining that the rules mostly test whether metadata.Name exists (which requires a proper k8s object). Those shouldn't be impacted at all.
just check for an existence of some yamlpath?
do you guys have an understanding of what rules might be impacted by this? I remember @JAORMX explaining that the rules mostly test whether metadata.Name exists (which requires a proper k8s object). Those shouldn't be impacted at all.
It seems that we are safe. I did a git grep -A25 yamlfile_value
in the CaC repo and looked at the rules and all either have a yamlpath (like metadata.name
you mentioned) and all seem to have at least one value
to check for at the yamlpath.
We do have a bunch of regexes that match against .*
but those also match against an exact yamlpath. On the other hand, we do use several permissive yamlpaths ([:]
) but those are used in combination with a very specific JQ-filter in the yamlpath.
So we should be safe. Sorry, I should have checked before writing the earlier comment.
LGTM (explicitly not using the gitopsy lgtm so that Ozz also has the time to look at the test)
On Tue, Sep 28, 2021 at 08:41:39AM -0700, Jakub Hrozek wrote:
We do have a bunch of regexes that match against
.*
note: most of them would probably be better looking for .+
, not that
it makes much difference in this case where we hopefully have a
yamlpath..
@JAORMX wdyt? Shall we merge? Anything I can add here?
@tjungblu sorry for the silence. I'm doing a little bit of research first before merging this. e.g. how does OpenSCAP's YAML probe react with empty YAML files, and how this could affect future rules. I don't think this will take me too long.
@JAORMX cool no worries. I'm not in a rush, but I'll be out next week. Merge at your own leisure or ping me if anything needs to be changed :) :rocket:
I think this change is fine. The YAML path will still issue a FAIL even if the file exists but the path isn't available.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: JAORMX, tjungblu
The full list of commands accepted by this bot can be found here.
The pull request process is described here
/label tide/merge-method-squash