This request from the Crypto team to enable a new mechanism for enabling FIPS-compatible operation on Fedora looks sensible to me, but as it's technically a violation of the rule above, it requires approval by FESCo before we add it to the systemd presets.

Is there a link missing here?

I know the Crypto team was planning on making this change for RHEL 10, replacing fips-mode-setup with a kernel command line option, but I haven't seen a similar proposal made for Fedora yet.

/me confused this ticket mentions a systemd service preset, fips-mode-setup (whatever that is), and a kernel command line option. What is the relationship between these three, and why is a preset needed for the latter?

I'm inclined to request that the crypto team propose a Change for Fedora 42 for us to consider.

+1

Indeed, please request them to submit a Change.

This request from the Crypto team to enable a new mechanism for enabling FIPS-compatible operation on Fedora looks sensible to me, but as it's technically a violation of the rule above, it requires approval by FESCo before we add it to the systemd presets.

Is there a link missing here?

Yes, I've now amended the description.

I know the Crypto team was planning on making this change for RHEL 10, replacing fips-mode-setup with a kernel command line option, but I haven't seen a similar proposal made for Fedora yet.

/me confused this ticket mentions a systemd service preset, fips-mode-setup (whatever that is), and a kernel command line option. What is the relationship between these three, and why is a preset needed for the latter?

fips-mode-setup is a CLI tool that was used to switch a running system into FIPS mode. As I understand it, this was always a bit of a lie, as not everything could actually be put into FIPS mode while live. The service is, I think, put in place to update other bits of the system to recognize the new kernel command-line argument.

I'm inclined to request that the crypto team propose a Change for Fedora 42 for us to consider.

+1

+1 this sounds like it should require an approved system-wide change proposal

I don't understand FESCo's concerns on this.

First, FIPS mode is pointless on Fedora. FIPS is for compliance, but that compliance requires that the cryptographic modules in use are actually submitted to NIST's Cryptographic Module Validation Program and end up certified. We don't do that for Fedora, so running FIPS mode cannot fulfill compliance requirements on Fedora.

There may be users out there running Fedora in FIPS mode. Those fall into two categories: (1) RHEL developers who use Fedora as upstream. They don't care about compliance, but the RHEL crypto team also consistently tells them that FIPS mode on Fedora may be broken. (2) Users who think FIPS mode provides better security. These users are misguided, FIPS is for compliance, it does not improve security (and it in fact disables some of the best algorithms we have or limits others to worse choices, e.g. Argon2, Curve25519, ChaCha20-Poly1305, …)

If a user opened a ticket tomorrow telling us about something in Fedora that isn't FIPS-compliant, we would not address that ticket, because it is not a goal for us to make Fedora FIPS-compliant.

Second, we are not removing fips-mode-setup from Fedora at this time. I have plans to eventually do that, and I'll write a Fedora Change before I do, but that's not what's happening here.

Third, a change in dracut has already landed that will make sure that systems booted with the fips=1 kernel command line flag will use the FIPS crypto-policy by adding two bind-mounts

• /usr/share/crypto-policies/default-fips-config -> /etc/crypto-policies/config
• /usr/share/crypto-policies/back-ends/FIPS -> /etc/crypto-policies/back-ends

This isn't a change in how FIPS mode behaves on Fedora, though — it merely fixes a potential misconfiguration where users have enabled FIPS mode, but for some reason did not switch the crypto policy along with it (this should be impossible, because fips-mode-setup does both).

Fourth, the systemd service I asked for only does what the dracut module already does. In other words:

• For systems not in FIPS mode (which no Fedora systems should be, see above), it does nothing
• For systems in FIPS mode that have the crypto-policy already set to FIPS, as automatically done by fips-mode-setup, the service does nothing
• For systems in FIPS mode that don't have the crypto-policy already set to FIPS, but booted with dracut, the bind-mounts have already been added and the service does nothing
• For systems in FIPS mode that don't have the crypto-policy already set to FIPS, but not booted with dracut, the service adds the two bind-mounts to fix the crypto-policy.

I really don't think that is "chang[ing] the behavior of any other service running (or potentially running) on the system". The only reasonable configuration in which this would occur is if you run a Fedora container with systemd on a host in FIPS mode, but not with podman (which would also already have made those bind mounts). It's an extreme corner case.

I don't understand FESCo's concerns on this.

Speaking for myself, my concerns were mainly because there was so little information, and what informations I got was very confusing.

With your explanation ("this is necessary to fix a potentially buggy edge case in an unsupported niche use case", if I understand correctly), I am fine with doing this.

Though I am still slightly confused why the infrastructure for using FIPS mode is present on Fedora at all if it's not supported and / or useful.

IIUC, this is being enabled in Fedora to reduce the difference between Fedora and derivatives and to make development easier. I think this is reasonable.

I also don't think we should ask for a Change for this. In fact, I think we shouldn't, for the reasons I describe below. It's fine that we enable this without advertisement.

(I think the approach of overmounting /etc with a bind mount is the wrong way to do things. It smells of a hacky solution being applied in the wrong place because the right place is not easy to change. 1. The overmount requires /etc to be modifiable so that the directory can be created. 2. The overmount goes against the development trend where /etc should be minimal and only contain configuration created by the user. 3. The overmount is potentially confusing if the admin tries to modify the configuration there and changes /usr.

I also dislike the approach of the initrd "reaching into" the target system and mounting things there. It's a layering violation.

But meh, this isn't the place to talk about this. It seems that the maintainers of dracut/fips/openssl want to go that way. But as discussed, FIPS mode doesn't really work on Fedora anyway, so let's at least not advertise this.)

I'll put this on the agenda for tomorrow so that we can hammer out some resolution.

IIUC, this is being enabled in Fedora to reduce the difference between Fedora and derivatives and to make development easier. I think this is reasonable.

Correct. Meanwhile I've written the Change to remove fips-mode-setup, which can be seen at https://fedoraproject.org/wiki/Changes/RemoveFipsModeSetup, and I made that exact point in response to "Alignment with the Fedora Strategy"

(I think the approach of overmounting /etc with a bind mount is the wrong way to do things. It smells of a hacky solution being applied in the wrong place because the right place is not easy to change. 1. The overmount requires /etc to be modifiable so that the directory can be created.

The directories already exist, this is not an issue.

1. The overmount goes against the development trend where /etc should be minimal and only contain configuration created by the user.

I'm aware of this development trend, but plenty of libraries do not follow this trend, our crypto libraries included. Unless somebody comes of with a patch to OpenSSL upstream to make it not expect its configuration in a single location in /etc by default, this trend is a non-goal for us for now. Once that's fixed, we can still move the bind-mount elsewhere.

1. The overmount is potentially confusing if the admin tries to modify the configuration there and changes /usr.

These files should not be edited manually. update-crypto-policies, which is the correct interface to modify these files knows about the bind mounts and will remove them.

I also dislike the approach of the initrd "reaching into" the target system and mounting things there. It's a layering violation.

I don't see a different alternative that would allow us to automatically switch the crypto-policy when fips=1 is on the kernel command line, which was an explicit goal of what we're doing here to avoid the potential for inconsistent configurations. Read-only /etc is precisely why we cannot just change a file in /etc instead.

I'll put this on the agenda for tomorrow so that we can hammer out some resolution.

Unfortunately I won't be able to join today because I'm traveling. If there are any open questions, I'm happy to answer them async after the meeting, though.

The directories already exist, this is not an issue.

The whole point is that they don't in all cases. For example, on a usr-only system, where / is created anew for each boot. Or after a "factory reset". Or when the user removes some directories in /etc to get rid of broken configuration.

I'm aware of this development trend, but plenty of libraries do not follow this trend, our crypto libraries included.

You're essentially saying "let's dig a deeper hole". The crypto libraries that we use are making many bad choices. In the past we had the debacle with constructor functions being used for heavy state initialization and breaking boot. We still have the ongoing debacle with no way conveniently override configuration for different programs. We also have the constant struggle with algorithms being deprecated and not being able to provide good feedback to users what is being rejected and why. So the fact that the libraries are doing something should not be used as an unavoidable absolute. When those libraries are doing stupid things, we as the distro maintainers need to push back.

These files should not be edited manually. update-crypto-policies, which is the correct interface to modify these files knows about the bind mounts and will remove them.

update-crypto-policies is fine for manual configuration. But people do many things which will not invoke an interactive tool. For example configuration mgmt (e.g. ansible) or backups. We really want to a) have as little configuration in /etc as necessary, and b) have simple static files that act independently and robustly. We are not there yet, but adding new functionality with a design that goes in a completely opposite direction is wrong.

I don't see a different alternative that would allow us to automatically switch the crypto-policy when fips=1 is on the kernel command line

Yeah, some novel approach is needed. Ideally, the crypto libraries should allow conditionalization of the policy in a way that allows fips to be enabled/disabled at will.

The directories already exist, this is not an issue.

The whole point is that they don't in all cases. For example, on a usr-only system, where / is created anew for each boot. Or after a "factory reset". Or when the user removes some directories in /etc to get rid of broken configuration.

In all of those cases, crypto-policies will be broken, though. The directories we use as bind-mount targets are part of the crypto-policies package; I'd consider that package not properly installed if its /etc contents are missing.

In any case, the bind-mounting only happens when the target directories exist, so if they don't, this unit will just silently do nothing.

I'm aware of this development trend, but plenty of libraries do not follow this trend, our crypto libraries included.

You're essentially saying "let's dig a deeper hole". The crypto libraries that we use are making many bad choices. In the past we had the debacle with constructor functions being used for heavy state initialization and breaking boot. We still have the ongoing debacle with no way conveniently override configuration for different programs. We also have the constant struggle with algorithms being deprecated and not being able to provide good feedback to users what is being rejected and why. So the fact that the libraries are doing something should not be used as an unavoidable absolute. When those libraries are doing stupid things, we as the distro maintainers need to push back.

I don't agree that some of the things you list are bad choices, but feel free to contribute solutions for those issues upstream, then. For example, I'm sure OpenSSL would welcome a way to override configuration for different programs (and I think parts of that already exist upstream, too). Improving the user-visible messages on algorithm deprecation is a large effort because it requires in many cases modifications to the clients of those crypto libraries. I'm all ears for an all-out push to get that changed across all of them, but I don't have time or developers I could delegate to that, especially considering the endless discussions that will cause on whether we really need to consider those algorithms obsolete with every single upstream project.

These files should not be edited manually. update-crypto-policies, which is the correct interface to modify these files knows about the bind mounts and will remove them.

update-crypto-policies is fine for manual configuration. But people do many things which will not invoke an interactive tool. For example configuration mgmt (e.g. ansible) or backups. We really want to a) have as little configuration in /etc as necessary, and b) have simple static files that act independently and robustly. We are not there yet, but adding new functionality with a design that goes in a completely opposite direction is wrong.

Ansible has a crypto-policies module that deals with this correctly.

If your configuration management system manually modifies files in /etc/crypto-policies not using the documented interfaces to manage cryptographic policies and that mechanism breaks due to a change made by crypto-policies, that's a bug in the configuration management system, not in cyrpto-policies. We do not and cannot guarantee compatibility with every mis-guided tool out there.

If you want crypto-policies to provide and support a different interface to configure it, file an RFE ticket describing what you want. You cannot just decide that the whole distribution now does this without actually asking for the feature from one of its core packages. Where's the Change Proposal for that?

I don't see a different alternative that would allow us to automatically switch the crypto-policy when fips=1 is on the kernel command line

Yeah, some novel approach is needed. Ideally, the crypto libraries should allow conditionalization of the policy in a way that allows fips to be enabled/disabled at will.

Yeah, that doesn't exist upstream in the crypto libraries, nor would it be compatible with some of FIPS' requirements w.r.t. self-testing and integrity checks on startup, so it's a wish, not a solution.

In all of those cases, crypto-policies will be broken, though. The directories we use as bind-mount targets are part of the crypto-policies package; I'd consider that package not properly installed if its /etc contents are missing.

I think this is the crux of the misunderstanding. In the new world, one shouldn't assume that anything in /etc can be relied to exist. It is obviously a departure from the traditional setup where /etc is used as a dumping ground for configuration, scripts, static pseudo-configuration, documentation, permanent writeable store, cache, and who knows what else.

In any case, the bind-mounting only happens when the target directories exist, so if they don't, this unit will just silently do nothing.

This is not great. Silent failure.

I don't agree that some of the things you list are bad choices, but feel free to contribute solutions for those issues upstream, then.

I have my plate full already and I cannot realistically contribute a major feature to openssl. Also, I think this is not a realistic proposal at all, since it's a feature that'd require changing core parts of the design of the library. Things like that can only be done by core contributors to a project. A person coming in from the outside with a major feature like this would almost certainly be rejected.

For example, I'm sure OpenSSL would welcome a way to override configuration for different programs (and I think parts of that already exist upstream, too).

That is good to hear.

Improving the user-visible messages on algorithm deprecation is a large effort because it requires in many cases modifications to the clients of those crypto libraries.

I don't see this as a big problem on the client side. Normally this would be done by provide a hook to inject a logging call back function, so a very small patch in the library is needed, possibly just a few lines. Maybe the library side is harder.

Ansible has a crypto-policies module that deals with this correctly.

If your configuration management system manually modifies files in /etc/crypto-policies not using the documented interfaces to manage cryptographic policies and that mechanism breaks due to a change made by crypto-policies, that's a bug in the configuration management system, not in cyrpto-policies. We do not and cannot guarantee compatibility with every mis-guided tool out there.

It's great that crypto-policies has integration with ansible. But asking everybody to exclusively use this interface is not realistic. You cut out my example of a backup tool. Surely, asking all backup tools to "know" about crypto-policies is not realistic.

The basic design that I want is a bunch of text files or symlinks in /etc, simple syntax that can be manipulated using specialized tools (ansible, but also systemctl and update-crypto-policies), but also with cat, ln, echo, and sed. Also, this configuration should be simple enough to be initialized sensibly by systemd-tmpfiles "factory" at boot if necessary.

If you want crypto-policies to provide and support a different interface to configure it, file an RFE ticket describing what you want. You cannot just decide that the whole distribution now does this without actually asking for the feature from one of its core packages. Where's the Change Proposal for that?

I hope I described what "I want" well enough above. This is something that is not subject to a Change proposal. It's more of a general change in how things are done… At least the systemd crowd thinks that this is the direction to go in, with fairly wide support from various other projects, see https://github.com/uapi-group/specifications/issues/76. That is why in my first comment I explicitly approved the requested change and put my review of the design in parentheses.

I think this is the crux of the misunderstanding. In the new world, one shouldn't assume that anything in /etc can be relied to exist. It is obviously a departure from the traditional setup where /etc is used as a dumping ground for configuration, scripts, static pseudo-configuration, documentation, permanent writeable store, cache, and who knows what else.

Sure, but then you need to find a way to prevent packages from actually shipping anything in /etc. That hasn't happened, so for now I assume that when a package is installed, the files it contains are actually present — unless of course a user has manually removed them, which leads to tickets getting closed with wontfix, because we don't support users shooting their own feet.

You want to change this, that's OK. But then please do it the right way, at the package level, not the hard way by just deleting files that are expected to be present for correct operation.

In any case, the bind-mounting only happens when the target directories exist, so if they don't, this unit will just silently do nothing.

This is not great. Silent failure.

Just pointing out that this is actually required by the Fedora Guidelines for this service to be enabled on boot:

The service MUST NOT, under normal operating conditions, exit with an error causing systemd to mark the unit as failed. A service which is started by default is permitted to fail under exceptional conditions.
https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/

You're arguing that /etc missing are normal operating conditions, but you want the service to fail when it cannot create the bind-mount. You can't have your cake and eat it, too. Please decide for one or the other.

This situation is easily detectable at runtime by comparing cat /proc/sys/crypto/fips_enabled and update-crypto-policies --show, so it's not fully silent.

I have my plate full already and I cannot realistically contribute a major feature to openssl. Also, I think this is not a realistic proposal at all, since it's a feature that'd require changing core parts of the design of the library. Things like that can only be done by core contributors to a project. A person coming in from the outside with a major feature like this would almost certainly be rejected.

I'm not a core contributor to the project either. Nonetheless, I don't think program-specific configuration would be complicated. This could be as simple as using the program basename to read additional settings from openssl.cnf, which would hardly be a major feature, and parts of that are AFAIK already present upstream.

Improving the user-visible messages on algorithm deprecation is a large effort because it requires in many cases modifications to the clients of those crypto libraries.

I don't see this as a big problem on the client side. Normally this would be done by provide a hook to inject a logging call back function, so a very small patch in the library is needed, possibly just a few lines. Maybe the library side is harder.

I think a generic logging call back may already exist, but applications don't widely use it — so we're back to changing all applications again.

It's great that crypto-policies has integration with ansible. But asking everybody to exclusively use this interface is not realistic. You cut out my example of a backup tool. Surely, asking all backup tools to "know" about crypto-policies is not realistic.

They don't need to. The state in /etc/crypto-policies will be consistent when restored. It doesn't suddenly have incompatible changes just because it was added to a backup and restored. The issue is users (or configuration management systems) making changes to files in /etc/crypto-policies directly to achieve different behavior.

The basic design that I want is a bunch of text files or symlinks in /etc, simple syntax that can be manipulated using specialized tools (ansible, but also systemctl and update-crypto-policies), but also with cat, ln, echo, and sed. Also, this configuration should be simple enough to be initialized sensibly by systemd-tmpfiles "factory" at boot if necessary.

Sure, please file a ticket against crypto-policies to request that, and we'll see whether that's something we can do.

If you want crypto-policies to provide and support a different interface to configure it, file an RFE ticket describing what you want. You cannot just decide that the whole distribution now does this without actually asking for the feature from one of its core packages. Where's the Change Proposal for that?

I hope I described what "I want" well enough above. This is something that is not subject to a Change proposal. It's more of a general change in how things are done… At least the systemd crowd thinks that this is the direction to go in, with fairly wide support from various other projects, see https://github.com/uapi-group/specifications/issues/76. That is why in my first comment I explicitly approved the requested change and put my review of the design in parentheses.

I believe this is subject to a change proposal. This is a system-wide change that affects how packages in Fedora can ship their configuration, and as such does affect many packages. You link to an upstream discussion, but made an earlier point that distributions should push back against upstream proposals if they are bad, which I think is the case here. Consensus does clearly not exist here, so the proper way to resolve that is to have a Change Proposal listing the upsides, downsides, required changes and impact and have a discussion.

Regardless, I believe this discussion has gone so far off the rails of the topic that we should probably end it here, since it isn't relevant to the fips-crypto-policy-overlay.service this ticket is about.

Sure, but then you need to find a way to prevent packages from actually shipping anything in /etc.

No, I don't think we do. This would only be true if we were building a black-box system, i.e. a proprietary system where we don't have access to the code. In Fedora we can look "into" everything and we can try to convince our upstreams to DTRT, one at a time.

Also, we don't really care about all packages. We are interested in the base subset that is installed on most systems. "Application packages" that are installed as leafs are out of scope at this point. But openssl and other crypto packages are in this base subset where we can require particular care in how the package is put together.

That hasn't happened, so for now I assume that when a package is installed, the files it contains are actually present — unless of course a user has manually removed them, which leads to tickets getting closed with wontfix, because we don't support users shooting their own feet.

"Empty /etc" (also called "hermetic /usr") is a goal for many people. It is necessary for features like factory resets and immutable deployments, but also helps with making systems easier to configure and the configuration much easier to introspect. You're defending the messy "design" (really just an accident of history) that we have now and which we need to improve.

You want to change this, that's OK. But then please do it the right way, at the package level, not the hard way by just deleting files that are expected to be present for correct operation.

Well, yes. Exactly. At the package level: I'm asking for a package to DTRT.

In any case, the bind-mounting only happens when the target directories exist, so if they don't, this unit will just silently do nothing.

This is not great. Silent failure.

Just pointing out that this is actually required by the Fedora Guidelines for this service to be enabled on boot:

The service MUST NOT, under normal operating conditions, exit with an error causing systemd to mark the unit as failed. A service which is started by default is permitted to fail under exceptional conditions.
https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/

No, that's a misrepresentation of the goal of that rule. The rule certainly doesn't mean that all errors should be ignored. Instead, programs must be written in a robust way. (Those which are enabled by default certainly, but in general others too.)

You're arguing that /etc missing are normal operating conditions, but you want the service to fail when it cannot create the bind-mount. You can't have your cake and eat it, too. Please decide for one or the other.

The very first thing I said is that the bind mount is the wrong approach. The following discussion just proved that.

This situation is easily detectable at runtime by comparing cat /proc/sys/crypto/fips_enabled and update-crypto-policies --show, so it's not fully silent.

If that is the only way this is surfaced, I'd qualify that as "silent".

Improving the user-visible messages on algorithm deprecation is a large effort because it requires in many cases modifications to the clients of those crypto libraries.

I don't see this as a big problem on the client side. Normally this would be done by provide a hook to inject a logging call back function, so a very small patch in the library is needed, possibly just a few lines. Maybe the library side is harder.

I think a generic logging call back may already exist, but applications don't widely use it — so we're back to changing all applications again.

Yeah, there's ERR_error_string(). Maybe it needs to be used in more places.

It's great that crypto-policies has integration with ansible. But asking everybody to exclusively use this interface is not realistic. You cut out my example of a backup tool. Surely, asking all backup tools to "know" about crypto-policies is not realistic.

They don't need to. The state in /etc/crypto-policies will be consistent when restored. It doesn't suddenly have incompatible changes just because it was added to a backup and restored. The issue is users (or configuration management systems) making changes to files in /etc/crypto-policies directly to achieve different behavior.

Well, no. If the state is restored, it'd modify (or try to modify) the bind-mounted location, i.e. /usr. This is not what we want.

The basic design that I want is a bunch of text files or symlinks in /etc, simple syntax that can be manipulated using specialized tools (ansible, but also systemctl and update-crypto-policies), but also with cat, ln, echo, and sed. Also, this configuration should be simple enough to be initialized sensibly by systemd-tmpfiles "factory" at boot if necessary.

Sure, please file a ticket against crypto-policies to request that, and we'll see whether that's something we can do.

Thanks. But please consider the discussion here as a notification as an RFE.

If you want crypto-policies to provide and support a different interface to configure it, file an RFE ticket describing what you want. You cannot just decide that the whole distribution now does this without actually asking for the feature from one of its core packages. Where's the Change Proposal for that?

I hope I described what "I want" well enough above. This is something that is not subject to a Change proposal. It's more of a general change in how things are done… At least the systemd crowd thinks that this is the direction to go in, with fairly wide support from various other projects, see https://github.com/uapi-group/specifications/issues/76. That is why in my first comment I explicitly approved the requested change and put my review of the design in parentheses.

I believe this is subject to a change proposal. This is a system-wide change that affects how packages in Fedora can ship their configuration, and as such does affect many packages. You link to an upstream discussion, but made an earlier point that distributions should push back against upstream proposals if they are bad, which I think is the case here. Consensus does clearly not exist here, so the proper way to resolve that is to have a Change Proposal listing the upsides, downsides, required changes and impact and have a discussion.

This was fairly widely discussed last year on fedora-devel:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/UCVYQVWHYPGYRB7U47WJWJP5CRLFSLCZ/#E5VASCPCZQC3H34IYB4ETXCFL6EPU676.
Fedora Changes are more for user-visible features or singular packaging changes. "Hermetic /usr" is a cross-distro effort and not something that we can do in Fedora alone. We're in contact with various upstreams and distro maintainers.

Regardless, I believe this discussion has gone so far off the rails of the topic that we should probably end it here, since it isn't relevant to the fips-crypto-policy-overlay.service this ticket is about.

Agreed.

"Empty /etc" (also called "hermetic /usr") is a goal for many people. It is necessary for features like factory resets and immutable deployments,

Not at all.

but also helps with making systems easier to configure and the configuration much easier to introspect.

My NixOS impermanence-powered machines begin each boot with no /etc whatsoever, yet even that doesn't bring me any closer to understanding how what's currently achieved with /etc/crypto-policies, /etc/pki or even just /etc/yum.repos.d is supposed to work in this daring new world of yours without introducing an actual proper configuration system in return.

You're defending the messy "design" (really just an accident of history) that we have now and which we need to improve.

Well, so do you, so that makes you even?

But please consider the discussion here as a notification as an RFE.

Notification? OK. But please file a separate proper RFE, where I could question you at length on where else is crypto-policies supposed to place dynamically generated configuration files on a 20th century system with no better configuration mechanism than the "accident of history" way of dropping files onto the local filesystem at well-known paths. Once I grasp the answer to that, be prepared to file ten more RFEs for the affected components that consume it. Or is it actually those ten components that are supposed to get modified do the right thing with the empty /etc? Would be nice if you explained it to me there.

You cannot just decide that the whole distribution now does this without actually asking for the feature from one of its core packages. Where's the Change Proposal for that?

I hope I described what "I want" well enough above. This is something that is not subject to a Change proposal. It's more of a general change in how things are done…

I believe this is subject to a change proposal.

This was fairly widely discussed last year on fedora-devel:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/UCVYQVWHYPGYRB7U47WJWJP5CRLFSLCZ/#E5VASCPCZQC3H34IYB4ETXCFL6EPU676. Fedora Changes are more for user-visible features or singular packaging changes.

Gentlemen. We just so happen to be derailing a thread where clang is being asked to file a Fedora Change to enable a systemd unit that is literally 100% dormant unless you have a fips=1 in your cmdline; then, for it to have any effect, a matching dracut module also has to fail to do its job; and even then all it does is correcting an obvious misconfiguration.

If that warrants a Fedora Change, you just don't get to argue your "hermetic /usr" idea doesn't need one. Without confirmed commitment from across the entire distribution, it looks more like an "I rm -rf'd my /etc and I don't like that things broke, here's a thread on fedora-devel where several other people agree it'd be neat if the world was a better place", not a coordinated effort to institute and enforce a new groundbreaking distribution-wide policy that seems to go against the fundamental accident of history you intend to preserve. If you want this half-measure to materialize, please actively file RFEs with very specific suggestions on how to achieve your vision.

This was discussed during the meeting today:
AGREED: APPROVED (+6, 0, 0)