The existing documentation explicitly claims that not specifying “run” in a waiver is equivalent to specifying “run: false.” It turns out to be the case that the claim is completely false. This commit includes a test for a new control 18_waivered_no_expiry_default_run that behaves exactly like the control 04_waivered_no_expiry_ran_fails. That is, not specifying run in a waiver is the same as specifying “run: true.”
Signed-off-by: David Marshall <dmarshall@gmail.com>
This is technically incorrect YAML, but if you transcode YAML between several tools you may end up with a date/time value being an explicit string.
It would be helpful if InSpec supported any string value that easily translates to a Time.
Signed-off-by: James Stocks <jstocks@chef.io>
Fixes#5037
The YAML parser may parse a waiver timestamp as a Time rather than a Date. Even when the user doesn't care about time, they may be using a tool that outputs YAML with trailing zeroes for hour, minutes, seconds etc.
Signed-off-by: James Stocks <jstocks@chef.io>
In https://github.com/inspec/inspec/issues/4936 the issue was reported that naming an input the same as a control caused an unexpected failure.
In that particular case, the naming was a result of a pre-waivers workaround which is no longer necessary, but ultimately a breakage of that name clash is an unexpected occurrance.
Due to how inputs are named and registered, `__apply_waivers` thinks that an object is a waiver that is not a waiver and tries to process it. On the micro level, it breaks when trying to pass a variable to a string as if it were a Hash.
It is imperative that we preserve 100% of the current featureset, pass our tests, and fix this edge case along with new test coverage for the failure.
This PR updates the code to do a slightly more elegant and small ‘waiver check’ to stop the namespace clash from breaking our code.
Signed-off-by: Nick Schwaderer <nschwaderer@chef.io>
