crypto_policy: validate_policy parameter is declared but never used

[hcaballero2]

Summary

The crypto_policy class declares a validate_policy parameter that is never used. Documenting the module for AGENTS.md (#105) surfaced this, and @silug asked for a follow-up issue.

Details

validate_policy is declared and documented as controlling $ensure validation:

• manifests/init.pp:28 — # @param validate_policy / "Disables validation of the $ensure parameter prior to application"
• manifests/init.pp:52 — Boolean $validate_policy = true,

But nothing in the module references it. The only other match in the whole repo is the declaration itself:

$ grep -rn validate_policy . --include='*.pp' --include='*.rb' --include='*.erb' --include='*.epp'
manifests/init.pp:28:# @param validate_policy
manifests/init.pp:52:  Boolean       $validate_policy     = true,

The validation block at manifests/init.pp:113 is actually gated on the fact being populated, not on $validate_policy:

if $_ensure and $global_policies_available and $sub_policies_available {

So setting validate_policy => false has no effect — validation stays on (gated by the fact) regardless.

Suggested resolution

Decide the intent:

• If validation-toggling is wanted: wire $validate_policy into the init.pp:113 guard (e.g. skip the fail() checks when false).
• If it's intentionally unused: add a deprecation warning now so the parameter can be removed in a future major release (per @silug's suggestion on Add AGENTS.md AI-assistant configuration #105).

Either way the @param docstring should be brought in line with actual behavior.

[hcaballero2]

Correction to the suggested resolution above, found while implementing it.

The issue proposes wiring $validate_policy into the init.pp guard at if $_ensure and $global_policies_available and $sub_policies_available. That guard does not only gate validation — it also wraps class { crypto_policy::update: }, the crypto_policy::subpolicy resources, the /etc/crypto-policies/config file resource, and the install -> update ordering. Gating it on $validate_policy would make validate_policy => false mean "do nothing at all", the opposite of the documented behavior. The two unless ... fail() blocks have to be made conditional individually, leaving enforcement intact.

Also worth recording on the "is it intentionally unused?" question: the escape hatch has a real use case, so deprecation is the wrong call. crypto_policy_state is gathered before the catalog is applied, so it cannot see policies that arrive during the same run — from an RPM, or a file resource in another module dropping a site-local .pol. The module already acknowledges this for its own subpolicies by merging $custom_subpolicies.keys into $sub_policies_available ("in case they have not been picked up by facter yet"), but global policies and externally-provided subpolicies have no equivalent workaround. That is exactly the gap validate_policy => false is documented to close.

PR #118 implements it on that shape.