Dan Brodjieski

Thanks for your feedback! The .plist file that is used for exemptions (org.{baseline}.audit.plist) is processed during the execution of the {baseline}_compliance.sh. That .plist is not used by the generate_guidance.py script...

Added an option to enter a "?" during the process, which will display the rule information.

While we do include a note about applicability in the os_firmware_password_require rule, we also tag the rule with a -i386 tag to indicate that is should only apply to Intel...

The rule for sysprefs_wifi_disable is identified as a "manual" control (as listed in the tags: field). This means that there is no automated check or fix generated for the compliance...

Yes, it will make it work... but if you are running the script remotely over Wi-Fi, you will get disconnected when it gets disabled. It's marked as manual as a...

I agree. The way the current check is written, it only accounts for the network interface named "Wi-Fi". If the name of the interface is anything else, it will produce...

Documentation on the manual tag has been added to the wiki.

There seems to be something off here. The expected result in the [pwpolicy_account_lockout_enforce](https://github.com/usnistgov/macos_security/blob/sonoma/rules/pwpolicy/pwpolicy_account_lockout_enforce.yaml) rule is ``` result: string: "yes" ``` The log snippet posted indicates it's looking for "{'string': 'true'}"......

It looks like the issue is if you apply both a configuration profile with the passcode settings along with applying the pwpolicy.xml file as-is from the project. This is causing...

Changes were made to the included pwpolicy.xml on the `dev_sonoma_issue373` branch. This is to alleviate the duplicate policies getting applied when using both a profile and `pwpolicy` to set policies....