-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merging develop branch (aka 5.12) into Master for official release #197
Conversation
Schematron updates ported from OVALProject/Language PR#303
Added new OSX pwpolicy-based test to account for new command format (using -getaccountpolicies and XML output) and deprecated options (-getpolicy)
Added allowable empty string enumeration value for Entity(State|Item)FileAttributeType, per standard for other OVAL enumeration types.
Changed "target_user" element to "username" Changed "username" element to "authenticator" Changed "userpass" element to "authenticator_password"
Modified original proposal. Removed lsmod and modprobe, replaced with single kernelmodule construct. 2nd test is the sestatus check.
Added a new unix sshd test to collect and evaluate named sshd parameters
added default email text
Created new enumeration type describing possible values for SELinux status (enabled, disabled) and associated `selinux_status` element to that new type in both definitions and system characteristics schemas.
Added a field for "policy_from_config_file"
Update Consensus Building Information
Updated proposal; Add 2 new Linux Tests
Change for issue #92
Schematron Updates
File Attribute Type
Proposal: Addition of the pwpolicy (5.12) test to Mac OSX schema
#108) * Fix typo which was invalidating the schema! * Fixed a second submission error -- macos-def:disabledservice/domain entity was mis-named. Co-authored-by: David Solin <solin@farnamhallventures.com>
Modified the 'type' for the 'ip_address' element in an interface from 'xsd:string' to oval-sc:EntityItemIPAddressType'. This entity type already contains the needed 'datatype' attribute.
Modified shellcommand item so that each line of STDOUT produces a new item 'stdout_line' element and each line of STDERR produces a new item 'stderr_line' element. Corrected some documentation and min and max occurs to reflect these changes.
Changed to reflect that each line of STDOUT will produce an item 'stdout_line' element and each line of STDERR will produce an item 'stderr_line' element.
…te URL from CIS to github
Fixed shell to use be ShellType Added platform specific default shell Added Zsh for macOS (and some linux) Fixed subexpression notes from 'file' to 'output'
…o-512-for-all-xsd-files-and-set-date-to-11292024 Update version to 5.12, updated date to 11/29/2024 and updated obsolete CIS URL to use Github
…est-to-support-running-shell-commands-called-shellcommand Add new independent test to support running shell commands called shellcommand
…and-ipv6-both-to-interfacestype Update ip address field to use IPAddressType to include ipv4 vs ipv6 data
…mous_name_lookup-clarification Added alternate name from MS documentation for all password policy items
There is one conflict that is noteworthy IMHO on this, and it's the unix sshd test. Given that the updates on the develop branch are 3 months newer than updates committed to the master, (and I'm not sure why anything was committed to the master), I'm leaning towards saying develop is 'correct', but I'd like a second opinion. https://github.com/OVAL-Community/OVAL/pull/197/conflicts @wmunyan do you have any backstory on this? Was the commit to the master just accidental before we created a develop branch for pre-release updates of OVAL? |
I'm not @wmunyan but I remember there was a desire to add a filepath to this test/object so that you could target a particular sshd_config file. |
Thanks @solind, that lends more credibility to the updates of sshd on the develop branch vs master. Unless I hear otherwise from @wmunyan, (or anyone else with other issues concerns), I'm hoping to complete this merge later today if possible, so we can get 5.12 done and clean up the master before we branch for 6.0 work. |
@solind and others, I just realized that I mis-read the merge conflict in the linux schemas, there is a new LSMOD test in the master that isn't in develop branch. There is quite a bit of discussion on it with #74 Just want to makes sure that what is committed to master is ready for production use. If my understanding of @wmunyan comment on #74, the LSMOD test was to be pulled, and not merged into master? |
Oh, indeed, it looks like those were supposed to be replaced by a single kernelmodule_test. They should not have been merged into master; that must have been a mistake! |
There were several commits to Master for Linux/UNIX defs it appears back in 2019, here's the primary commit that seems to be causing the current issues. 301c9ed I'm currently planning to resolve the conflict, with the develop version being the 'correct' one for all instances. |
OK, I've committed what I think resolves that conflict, with develop being current. Definitely would like a sanity check on all of it though. Thanks! |
Proceeding with merging develop into master, I've personally reviewed it and it seems safe. If we had more time, I'd wait for additional reviews. But I need to move on to OVAL 6.0 efforts. |
OVAL 5.12 is ready for release