Description of problem: libguestfs builds a minimal appliance for manipulating disk images. It uses openssl for various things, eg. LUKS (see bug 2133768). This worked fine until recently when openssl broke: ><rescue> openssl help FATAL: Startup failure (dev note: apps_startup()) for openssl 004EF21A347F0000:error:80000002:system library:process_include:No such file or directory:crypto/conf/conf_def.c:805:calling stat(/etc/crypto-policies/back-ends/opensslcnf.config) 004EF21A347F0000:error:07000075:configuration file routines:ssl_module_init:ssl command section empty:crypto/conf/conf_ssl.c:96:name=system_default, value=crypto_policy 004EF21A347F0000:error:0700006D:configuration file routines:module_run:module initialization error:crypto/conf/conf_mod.c:270:module=ssl_conf, value=ssl_module retcode=-1 We don't have /etc/crypto-policies/back-ends/opensslcnf.config inside the appliance because that requires Python (or Lua maybe) to rebuild. When openssl is used as a library it sort of half works. It starts up but sha256 digest is missing, breaking cryptsetup. (It's possible that all digests are missing, that's the one we need.) Anyway openssl should be robust and work without this file, or else build normal configuration files and don't do voodoo in %post that needs scripting languages. Version-Release number of selected component (if applicable): openssl-3.0.5-2.fc37.x86_64 (working in 3.0.3) How reproducible: 100% Steps to Reproduce: $ virt-rescue --scratch ><rescue> openssl help (fails as above)
ok, thanks! so this bug cover the mlockall issue, once we have new release it will be closed. And cryptsetup should not require openssl conf (at least that was a plan), it uses own library context... but perhaps something internally in openssl changed. It can be heavy Red Hat OpenSSL package patching that introduces such policy change, though.
Workaround for this bug added to libguestfs: https://github.com/libguestfs/libguestfs/commit/d6ba398825bfdd67daf57bac0a4d8bcb281a62a8
> We don't have /etc/crypto-policies/back-ends/opensslcnf.config > inside the appliance because that requires Python (or Lua maybe) > to rebuild. Python should only be required for update-crypto-policies/crypto-policies-scripts. To cater to small image cases like yours, /etc/crypto-policies/back-ends/opensslcnf.config can instead be generated by crypto-policies %post scriptlet, written in Lua: https://src.fedoraproject.org/rpms/crypto-policies/blob/60e4beabe5fe506091793217d458bbda417187b3/f/crypto-policies.spec#_117 This way there's no dependency on Python. If even that's not acceptable for you, you can create a /etc/crypto-policies/backends/opensslcnf.config -> /usr/share/crypto-policies/(DEFAULT|FIPS)/opensslcnf.txt symlink by hand. What do you want me to do on the crypto-policies package side? (And why not just install the package properly with a Lua-capable RPM?)
We don't run %post scripts because we need to run everything as non-root in an environment where we are creating an ext2 disk image (so there's not even chroot access to the disk). I will try the symlink method, but I really do think the way these configuration changes are done is wrong. In systemd they've settled on a method where the default configuration is placed in /usr/lib (eg. /usr/lib/systemd/system/*) which are managed as normal by RPM and is never touched by the user. For local changes to configuration there are corresponding files under /etc (eg. /etc/systemd/system/*). This would mean there's no need at all for any %post stuff, and probably make the implementation of update-crypto-policies far simpler.
If I'm translating it right, that'd mean patching openssl and all the other back-ends to read and merge two sets of configuration files, and pointing the fallback ones to /usr/share/crypto-policies/FIPS/$backend.txt (or, otherwise, we'll end up with early-install and other weird environments attempting operations that are prohibited in FIPS mode). And the %post logic in crypto-policies will still have to stay to select DEFAULT instead in a non-FIPS case. Strategically, I'm rather baffled about the direction your take. (Any distribution that allows scriptlets grows horribly reliant on it. Fedora is so down that path it's unsalvageable.) While you can go on a crusade to extend all the crypto-policies config consumers with support for config merging and set the right fallback paths, and then proceed to strip all the other packages of %post scriptlets they're using for all the various reasons, I can't help but wonder that'd be a much less meaningful crusade than just installing the packages properly with a package manager they're meant to be installed with. I don't even see why would one need chroot here given that package managers should be able to customize all the paths involved, but if you need one, there are unprivileged user mount namespaces or even proot. Installing the system the intended way and then injecting the resulting files over into your image sounds like an all around lower effort/maintenance strategy to me. Otherwise you'd have to maintain a database of workarounds to keep up with all the relevant scriptlets in the distribution. So, sorry, but I still find your request in its current form both at odds with current Fedora scriptlet practices and unactionable on my side.
You probably want to look at "bazel", used to build containers in OpenShift. It also doesn't run %post scripts. So this is going to be trouble at some point in the future.
If you happen to have specific pointers to where in https://github.com/bazelbuild (or elsewhere?) they skip running %post scripts, I can report that approach to them as broken =) If you have specific suggestions on how crypto-policies can improve, and yet comply with the requirement of choosing between DEFAULT and FIPS within the seminal RPM transaction, I'll be glad to hear them. If you, instead, want openssl to "fail open" and use some default configuration when an included configuration file is missing, please move the bug to openssl or open a new one.
I'm not actually sure of the specific tool that runs, but the observed behaviour is that if you use quay.io (some conatainer registry thing) it doesn't run RPM scriptlets. This is apparently for reproducibility reasons - ie they want bit for bit identical output for a given Containerfile input. I don't know all the details. Anyhow the direction of travel for RPM packaging is definitely towards removing scriptlets as far as possible (see for example: https://devconfcz2019.sched.com/event/Jcma/eliminating-scriptlets-for-fun-and-profit) Apart from the problems with applying them as non-root or in similar situations, another problem is that RPM cannot reason about scriptlets, for example to understand the exact effects they have on the filesystem or to ensure everything is cleaned up. It also prevents rpm installs from being reproducible as above. I don't want openssl to "fail open", just to do the least complicated thing in RPM.
Oh, you don't have to convince me that scriptlets are a patently bad idea and the future of distro-building is scriptletless and pure like NixOS. But here I am in Fedoraland of 2022, where I've inherited a scriptlet, and the only thing I can imagine replacing it with (#c5) is a worse, more convoluted scriptlet that'd also bring RPM validation problems with it. I'm afraid that we're, unfortunately, falling into a territory where I'd have to ask you to propose patches and I'd try to anticipate issues with them while keeping in mind FIPS, Anaconda, system upgrades and other weird cases, and then we'd iterate. It's not the change or idea I resist here, I just don't see how any of the suggested recipes fits. Feel free to summon the fine folks behind the presentation and their noble goal of scriptletlessness to pitch in =)
For your information, I also ran into an issue with cryptsetup not working after upgrading from Ubuntu 22.04 to 22.10 it turns out, OpenSSL was missconfigured. it had some FIPS config leftover that appears incomplete. I commented out the two lines and support for sha256 was back and cryptsetup works like a charm again. https://gitlab.com/cryptsetup/cryptsetup/-/issues/782 https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1993944
Just throwing ideas around, can we compromise somehow? I don't believe one can currently just unpack Fedora, execute no scriptlets and get a usable system, IIRC even libc shouldn't work. Do you already have some workarounds that replicate what the most crucial scriptlets do? Could agreeing to have this scriptlet behaviour stable and replicating it on your side be an acceptable compromise?
From our point of view we've added a fix for openssl upstream which seems to work fine: https://github.com/libguestfs/libguestfs/blob/26940f64a740676103b0ee49bf0ca5ac4e297841/appliance/init#L69 It is indeed not possible to entirely get rid of scriptlets (unfortunately) although we're working towards it. To see what needs to be done to bring up a minimal appliance this way you can take a look at this: https://github.com/libguestfs/libguestfs/blob/master/appliance/init#L3 Not all of it is necessary for modern distros and some is libguestfs specific.
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. 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 'version' of '37'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 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 Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 37 entered end-of-life (EOL) status on None. Fedora Linux 37 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 Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.