Bug 1936379

Generating these files is the primary purpose of crypto-policies and we don't support direct modifications of these outputs.
Could you please apply the needed modifications through crypto-policies themselves, by using a custom policy or a subpolicy?
You can start with FEDORA32 policy and change it towards DEFAULT until you figure out the change you're after.

Also, if you really just want to edit existing config files and basically switch-off all the policy config-generation/update mechanism you can follow the instructions in the HISTORY section of the crypto-policies(7) manual page.

(In reply to Alexander Sosedkin from comment #1)
> Generating these files is the primary purpose of crypto-policies and we
> don't support direct modifications of these outputs.

sorry, but I do not understand your reply

it doesn't align with reality

the file on my system is not _generated_ (by my system), it is _installed_ by crypto-policies-20200918-1.git85dccc5.fc33.noarch and according to rpm verification it hasn't been modified

what seems to be "generated" is the symlink, but even if we'd agree that 'everything is a file' and call the link as such, still it is no "output"

now this is terribly wrong ...

it is a good habit of programs to keep their default config in /usr, which may be overriden by contents of /etc and $HOME/.config eventually; they read all those locations

take udev for an example - any rule set in /usr/lib/udev/rules.d/ can be overriden by the contents of /etc/udev/rules.d/

now if a program reads only one location, it is the packagers duty to prepare the default config in that location - and while it might make sense to symlink the default instead of copying it, it doesn't make sense to enforce the default by removing any user changes on random ocassions, not even on package update only (or as user-confirmed action)

there's a plethora of tooling to handle configfile updates, e.g. rpmconf to name one that the user can run after updates

then, if the config wouldn't be simply installed by the package, but truly generated as your reply suggests, it still can be subject to those manual updates

of course, you might want to make the updates automatic for some reason and leave the space for user modifications elsewhere

but in that case, if the actual configfile read by the program gets overwritten, there is another VERY GOOD habit of leaving a note about this in a comment

take GRUB for an example ...

[root@kvolny ~]# cat /boot/grub2/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
set pager=1
...

(In reply to Tomáš Mráz from comment #2)
> Also, if you really just want to edit existing config files and basically
> switch-off all the policy config-generation/update mechanism you can follow
> the instructions in the HISTORY section of the crypto-policies(7) manual
> page.

thankyou for the pointer

however, there are 416 packages on my system that own something in /etc

now imagine that all those 416 packages behave the way like described in this and the linked bugreports - silently change settings for a library, so that the change makes an application essential to my work unusable, an application which is seemingly totally unrelated to the package that made the change

so I am expected to read docs of 400+ packages in advance to prevent such changes and protect my configuration from being broken randomly

does that sound realistic to you to demand all the users to follow development of all the things under the hood of their systems? do you even follow closely projects outside the scope of your team?

I've already spent some hours, not minutes, figuring out that ":!DH" at the end of CipherString is all I need to make kmail work; figuring out how to protect that CipherString setting from being destroyed is just over the top

hence I reopen to make this at least a documentation issue - please put a big fat warning at the beginning of every file that gets destroyed by your package stating where to make changes that don't get removed, in similar way like for example the abovementioned GRUB does it

if the things are the way they are - and I do not expect you to change it, despite I find it very unfortunate - this is at least what I'd expect to find, based on experience with other packages, just like I expect to find the brake pedal next to the accelerator pedal, based on experience with other cars, not having to read complete manual for each

p.s. also, putting files into /usr (/share/crypto-policies/policies) that are outside control of the package manager doesn't seem to be like a good idea (not to mention setups where /usr is read only, e.g. network mounted, and cannot contain any config specific to the respective workstation)

p.p.s. and now, after skimming over man crypto-policies, I do not see anything that would suggest that the things should happen like they happen:

       Policy file placement and naming:

       The policy files shipped in packages are placed in /usr/share/crypto-policies/policies and the policy modules in /usr/share/crypto-policies/policies/modules.

       The locally configured policy files are placed in /etc/crypto-policies/policies and the policy modules in /etc/crypto-policies/policies/modules.

...

FILES
       /etc/crypto-policies/back-ends
           The individual cryptographical back-end configuration files. Usually linked to the configuration shipped in the crypto-policies package unless a configuration from local.d
           is added.



"Usually linked" doesn't imply anything about files being deleted and replaced with symlinks ...

> the file on my system is not _generated_ (by my system), it is _installed_ by crypto-policies-20200918-1.git85dccc5.fc33.noarch and according to rpm verification it hasn't been modified

True, and this is a conscious decision. If you apply a custom policy, it will turn into a generated one. We could generate it, but that'd mean that minimal installs would have to include Python.


> now imagine that all those 416 packages behave the way like described in this and the linked bugreports - silently change settings for a library, so that the change makes an application essential to my work unusable, an application which is seemingly totally unrelated to the package that made the change

Again, this is totally the very purpose of the project: changing cryptographic defaults without other libraries / apps being none the wiser.
I understand your frustration on invisible dependencies, but this is just how it goes in RPM world, where package updates are expensive.
Maybe you'll find consolation in the fact that there are distros [1] where it's impossible for a non-dependency to alter the behaviour of the dependent.


> if the actual configfile read by the program gets overwritten, there is another VERY GOOD habit of leaving a note about this in a comment

That's a good idea - more so for the actual /etc/ files, to a lesser extent for /usr/ files. But that still can be done if it helps.


> also, putting files into /usr (/share/crypto-policies/policies) that are outside control of the package manager doesn't seem to be like a good idea

Yes. What prompts you to do that? Put yours in /etc.


> I've already spent some hours, not minutes, figuring out that ":!DH" at the end of CipherString is all I need to make kmail work; figuring out how to protect that CipherString setting from being destroyed is just over the top

This is the root of our misunderstanding. Changing byte 2013472 of /lib/libcrypto.so.1.1 to 0xe3 might've also solved your problem, but you should not overwrite files coming from packages. Use proper configuration facilities, in case of Fedora - crypto-policies.


Please turn the discussion into a more constructive line of reasoning. I'd be happy to consider any user experience suggestions you have, but with the proposals to asking crypto-policies to stop performing its intended purpose won't fly. What else can we do besides adding comments to not modify the (build- and run-)time generated files?


[1] https://nixos.org/~eelco/pubs/phd-thesis.pdf

> so I am expected to read docs of 400+ packages in advance to prevent such changes and protect my configuration from being broken randomly

Compare that to the OS system security needing to check 400+ packages to present a global security policy to the administrator. The effort of the system wide security policy is so that administrators don't have to go through 400+ packages to get it set to the proper modern levels.

Remember, whatever packages are now broken, are broken because they have a very outdated policy you are depending on. That is the real problem that needs fixing. The system wide crypto policies provide you with an early warning on this, where you can still enable a LEGACY setting  to get temporarily fallback to while you fix your software and/or its configuration. The next step is for the OS to completely remove this fallback option at compile time of the packages.

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.