Skip to content
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

Merged
merged 112 commits into from
Dec 3, 2024

Conversation

vanderpol
Copy link
Member

OVAL 5.12 is ready for release

Bill M and others added 30 commits May 8, 2019 08:56
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
Proposal:  Addition of the pwpolicy (5.12) test to Mac OSX schema
…, #106.

These are all needed for NIST to implement complete FISMA benchmarks for macOS.
Pull request for MacOS Issues: #19, #52, #84, #95, #99, #100, #101, #102, #103, #104, #105 and #106.
#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>
johnulmer-oval and others added 15 commits November 22, 2024 16:16
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.
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
@vanderpol vanderpol requested review from solind and A-Biggs December 2, 2024 12:51
@vanderpol vanderpol self-assigned this Dec 2, 2024
@vanderpol vanderpol added this to the 5.12 milestone Dec 2, 2024
@vanderpol
Copy link
Member Author

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?

@solind
Copy link

solind commented Dec 2, 2024

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.

@vanderpol
Copy link
Member Author

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.

@vanderpol
Copy link
Member Author

vanderpol commented Dec 2, 2024

@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?

@solind
Copy link

solind commented Dec 2, 2024

@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!

@vanderpol
Copy link
Member Author

@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.

@vanderpol
Copy link
Member Author

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!

@vanderpol
Copy link
Member Author

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.

@vanderpol vanderpol merged commit 73eb5da into master Dec 3, 2024
@vanderpol vanderpol deleted the develop branch December 5, 2024 12:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants