That's one interesting request. As you might have noticed, this file predates custom policies and subpolicies and needs updating.

> As custom policies are also supported policies are also supported

Truncated sentence?

One more complication I see is what's gonna be the contract of `update-crypto-policies --list`.
From the invocation alone I'd expect that it lists every discoverable policy and subpolicy; yet there are some that we'd prefer not exposing to that list of yours, such as OSPP internal-usage subpolicy or even the FIPS policy. FIPS policy isn't really something one enables directly, there's a separate `fips-mode-setup` doing more than just that (and the advised way to get to it is installing with fips=1, actually).

How fine would you be with:
* going with static generic descriptions of LEGACY/DEFAULT/FUTURE in cockpit and pointing to other docs for more?
* shipping these descriptions as an extra file in crypto-policies?
* ...
* extending the policy/subpolicy files format to support optional short descriptions and visibility toggles to allow generating such a list, then adding an undocumented-internal-only-but-tested --list-examples?

Asking because your request is for a command and not static descriptions, while extending the format feels like overengineering the solution.

(In reply to Alexander Sosedkin from comment #1)
> That's one interesting request. As you might have noticed, this file
> predates custom policies and subpolicies and needs updating.
> 
> > As custom policies are also supported policies are also supported
> 
> Truncated sentence?
> 
> One more complication I see is what's gonna be the contract of
> `update-crypto-policies --list`.
> From the invocation alone I'd expect that it lists every discoverable policy
> and subpolicy; yet there are some that we'd prefer not exposing to that list
> of yours, such as OSPP internal-usage subpolicy or even the FIPS policy.
> FIPS policy isn't really something one enables directly, there's a separate
> `fips-mode-setup` doing more than just that (and the advised way to get to
> it is installing with fips=1, actually).

Yes, that's true we could maintain a blacklist I suppose in cockpit but that requires constant updating.
 
> How fine would you be with:
> * going with static generic descriptions of LEGACY/DEFAULT/FUTURE in cockpit
> and pointing to other docs for more?

That's now done in the POC https://github.com/cockpit-project/cockpit/pull/16860

> * shipping these descriptions as an extra file in crypto-policies?
> * ...

That's acceptable.

> * extending the policy/subpolicy files format to support optional short
> descriptions and visibility toggles to allow generating such a list, then
> adding an undocumented-internal-only-but-tested --list-examples?

That sounds like the --list option I was suggesting or am I mistaken.

>> * going with static generic descriptions of LEGACY/DEFAULT/FUTURE in cockpit
>> and pointing to other docs for more?
>
> That's now done in the POC https://github.com/cockpit-project/cockpit/pull/16860

I meant turning it even more generic and stable across releases and distros, like
"LEGACY: aims at higher interoperability at the cost of an increased attack surface"
"DEFAULT: aims at secure settings for current threat models"
"FUTURE: aims at protecting from anticipated near-term future attacks at the expense of interoperability"
and a link to the distro's equivalent of [1] instead of specifics.
So, generalizing it to something that'd hold true for both RHEL-8 and Fedora 36 alike.

>> adding an undocumented-internal-only-but-tested --list-examples?
>
> That sounds like the --list option I was suggesting or am I mistaken.

I meant two differences from how I happen to read the original request:

1. Original --list sounds like it aims to
   somehow list either everything usable with --set
   or at least all the base policies discovered in the system.
   Hypothetical --list-examples will list just some subset of such possible values.
2. Original --list would have a public-facing --help entry and a manpage entry
   defining what exactly does it do
   (e.g., lists the base policies but not subpolicies
    in the order defined by etc. etc.).
   Hypothetical --list-examples would be for cockpit usage only,
   with its interface enforced only by some automated regression tests
   on both crypto-policies and cockpit sides.

[1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening