Deprecated tests

[cpoma]

Added skip_deprecated_test attribute to allow for skipping of tests removed from the STIG over time.
Currently the following have been removed from the Latest STIG RHEL7 V2R4

• V-71895 - The operating system must set the idle delay setting for all connection types.
• V-71981 - The operating system must prevent the installation of software, patches, service packs, device drivers, or operating system components of packages without verification of the repository metadata.
• V-72143 - The operating system must generate audit records for all successful/unsuccessful account access count events.
• V-72169 - All uses of the sudoedit command must be audited.
• V-72181 - All uses of the pt_chown command must be audited.
• V-72193 - All uses of the rmmod command must be audited
• V-72195 - All uses of the modprobe command must be audited.
• V-72215 - The system must update the virus scan program every seven days or more frequently
• V-72435 - The operating system must implement smart card logons for multifactor authentication for access to privileged accounts.
• V-78995 - The operating system must prevent a user from overriding the screensaver lock-enabled setting for the graphical user interface.

[aaronlippold]

I think we would like to handle this via the right tags. I would like to tag the repo with the correct STIG release versions and have the right controls for each release number.

So, v1r4 with the older controls and v2r2 etc with this PR.

We should try to have 'master' at the latest STIG release and if for some reason someone needs the older release we can just checkout that tag.

[trevor-vaughan]

@aaronlippold I agree with this, but I also think that the deprecation notices are good so that we can easily jump between versions. You should have the ability to add the appropriate tag if you wish.

[aaronlippold]

Roger. Let's setup a quick call to discuss this week. What's your schedule like? Thanks Aaron

…

On Mon, Oct 14, 2019, 1:49 PM Trevor Vaughan ***@***.***> wrote: @aaronlippold <https://github.com/aaronlippold> I agree with this, but I also think that the deprecation notices are good so that we can easily jump between versions. You should have the ability to add the appropriate tag if you wish. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#114?email_source=notifications&email_token=AALK42HFCGS34ZJRH4WXHELQOSWL7A5CNFSM4JAED6V2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBFYYUY#issuecomment-541822035>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALK42CEGTSCKLWZYIUSUWLQOSWL7ANCNFSM4JAED6VQ> .

[djhaynes]

This PR looks good to merge in, but, we will hold off until we create the v1r2 tag #119.

[djhaynes]

I think these changes are good to go once we tag the release.

[aaronlippold]

It looks like this has some conflicts now.

Also, we are pulling all the 'skip_deperacated_tests' logic in favor of the two tagged codebases correct?

[ljkimmel]

I think we would like to handle this via the right tags. I would like to tag the repo with the correct STIG release versions and have the right controls for each release number.

So, v1r4 with the older controls and v2r2 etc with this PR.

We should try to have 'master' at the latest STIG release and if for some reason someone needs the older release we can just checkout that tag.

Unless I misunderstand tags they only relate to a specific commit. A specific STIG version will likely encompass a number of commits from the first commit that makes this project compatible with that version to the commit prior to making changes to become compatible with the next version of the STIG. It might make sense to tag twice: once when we initially support that STIG version (e.g. 'v2r2 initial') and then tag the last commit before moving to a new version (e.g. 'v2r2 final'). That way if someone wants the 'best' code to support v2r2, for example, they would actually grab 'v2r2 final' instead of just 'v2r2' which wouldn't have benefited from possible bug fixes etc.

In any case I don't think we should keep deprecated tests around and just add a switch to turn them off. This just adds bloat for something that people aren't likely to want (no one wants to run any controls that aren't necessary) and it gives them another configuration point that they may or may not be aware of.

[aaronlippold]

This is an old PR and we're not going to be using it

…

On Thu, Mar 26, 2020, 7:57 AM ljkimmel ***@***.***> wrote: I think we would like to handle this via the right tags. I would like to tag the repo with the correct STIG release versions and have the right controls for each release number. So, v1r4 with the older controls and v2r2 etc with this PR. We should try to have 'master' at the latest STIG release and if for some reason someone needs the older release we can just checkout that tag. Unless I misunderstand tags they only relate to a specific commit. A specific STIG version will likely encompass a number of commits from the first commit that makes this project compatible with that version to the commit prior to making changes to become compatible with the next version of the STIG. It might make sense to tag twice: once when we initially support that STIG version (e.g. 'v2r2 initial') and then tag the last commit before moving to a new version (e.g. 'v2r2 final'). That way if someone wants the 'best' code to support v2r2, for example, they would actually grab 'v2r2 final' instead of just 'v2r2' which wouldn't have benefited from possible bug fixes etc. In any case I don't think we should keep deprecated tests around and just add a switch to turn them off. This just adds bloat for something that people aren't likely to want (no one wants to run any controls that aren't necessary) and it gives them another configuration point that they may or may not be aware of. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#114 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALK42G2J7VP42ORGRCFKETRJM7KZANCNFSM4JAED6VQ> .