More precise modified time comparison in "configure_crypto_policy" #6437
Conversation
Calculating the time difference of both files against current time and comparing them is imprecise, as both calculations of the time difference can not be done simultaneously. One of the files will always appear to be a bit older than the other. If both files were generated one right after the other (i.e. on the same second), but calculation of difference against current time was done in different units of "second". The test will result in a false negative. Lets just compare their age in seconds since epoch directly.
yuumasato
changed the title
|
Changes identified: Show detailsRule configure_crypto_policy: Recommended tests to execute: |
| #!/bin/bash | ||
| # platform = Red Hat Enterprise Linux 8 | ||
|
|
||
| # This is false negative scenario |
There was a problem hiding this comment.
@matusmarhefka @mildas Do you see value in this test scenario?
Strictly speaking, this should be a fail scenario. But AFAIK, there is no way to detect this, as smallest time unit in OVAL is one second.
There was a problem hiding this comment.
I see, if we want to fake the files to have the same modification timestamps I would do the following trick:
update-crypto-policies --set "DEFAULT"
CDATE=$(date +%Y%m%d%H%M)
touch -a -m -t "$CDATE" /etc/crypto-policies/config /etc/crypto-policies/state/current
There was a problem hiding this comment.
This is strictly to just test the situation when file modification time is the same, but I understand that this is OVAL limitation and we cannot really catch situations when modification time difference is less than 1s.
There was a problem hiding this comment.
Thanks for the tip for the timestamp, I'll add this to the test scenario.
But my concern was more about whether we should keep a test like this, to illustrate the situation we cannot cover well.
There was a problem hiding this comment.
I don't know what you mean with false negative scenario in this case (shouldn't it be false positive? but probably I'm just confused). However, I like this test scenario and I see value in it because we can test that this specific case is passing and not causing failures from <1sec roundings.
The next comment about precision of seconds is very important there and probably I would add to it something like WARNING: or IMPORTANT: just to emphasize its importance.
There was a problem hiding this comment.
@mildas Hmm, I think it is a false negative, as it reports a no-issue situation where there is one.
However, I like this test scenario and I see value in it because we can test that this specific case is passing and not causing failures from <1sec roundings.
I think the rounding issue is solved in 3df3833, it was caused by comparing the timestamp of the file to the current time.
In this test scenario, the <1sec difference is an actual issue.
In this scenario, the test should return fail, but returns pass. The smallest unit of time in OVAL is one second, there is no way to differentiate files that were changed less than one second appart from each other.
yuumasato
force-pushed
the
more_precise_time_diff_in_crypto_policies
branch
from
1291277
to
48e2b97
Compare
|
/test e2e-aws-ocp4-cis-node |
1 similar comment
|
/test e2e-aws-ocp4-cis-node |
Description:
/etc/crypto-policies/configand/etc/crypto-policies/state/currentto be a bit more precise.configfile is greater (i.e.configfile was changed beforecurrentfile).configtimestamp is less thancurrenttimestamp.Rationale:
time_differenceagainst the same moment in time.