Comments
clang
provided feedback
on tmux-3.3a-7.20230918gitb202a2f.fc39
9 months ago
fips-mode-setup --enable generates an incorrect kernel command line if /boot and / are the same filesystem.
On a positive note, I can confirm https://github.com/containers/storage/commit/07ed7f4b7f544b62d5dd37d07e31edbd59d0a395 works.
This seems to break overriding of the storage driver in /etc/container/storage.conf.
I have
[storage]
driver = "zfs"
in my /etc/containers/storage.conf. I did not modify /usr/share/containers/storage.conf, which contains the default driver "overlay".
With a clean system, the storage gets set to overlay:
# podman info -f '{{.Store.ConfigFile}}'
/etc/containers/storage.conf
# podman info -f '{{.Store.GraphDriverName}}'
overlay
With a system that has been previously initialized to use ZFS, any podman command fails with
ERRO[0000] User-selected graph driver "overlay" overwritten by graph driver "zfs" from database - delete libpod local files ("/var/lib/containers/storage") to resolve. May prevent use of images created by other tools
# strace -o openat podman info tells me that /etc/containers/storage.conf is read, followed by /usr/share/containers/storage.conf. And indeed, if I change the driver to zfs in /usr/share/containers/storage.conf, it is used as expected. However, /etc/containers/storage.conf should be the file that has the final say on things, not the one in /usr/share.
This may or may not be related to https://github.com/containers/storage/pull/1468 (which went into storage v1.45.1, but isn't used in this version of podman). See also https://github.com/containers/storage/issues/1469.
Note that --openssl-legacy-provider will probably not solve your issue. See https://www.redhat.com/en/blog/legacy-cryptography-fedora-36-and-red-hat-enterprise-linux-9 on the difference between the OpenSSL legacy provider and the LEGACY crypto-policy, and why the legacy provider is unlikely to be what you need.
This update has been unpushed.
Revoked, since it seems pushing it is broken and the fixes included in this build are also present in subsequent builds that have already been pushed to stable.
Tested with https://bodhi.fedoraproject.org/updates/FEDORA-2022-a8f5b75194 and
usdt:/usr/lib64/libssl.so.3:fedora_ssl_security_cert_sig_1,
usdt:/usr/lib64/libssl.so.3:fedora_tls12_check_peer_sigalg_1,
usdt:/usr/lib64/libssl.so.3:fedora_tls12_sigalg_allowed_1,
usdt:/usr/lib64/libcrypto.so.3:fedora_check_sig_level_1,
usdt:/usr/lib64/libcrypto.so.3:fedora_do_sigver_init_1,
usdt:/usr/lib64/libcrypto.so.3:fedora_evp_pkey_ctx_set_md_1,
usdt:/usr/lib64/libcrypto.so.3:fedora_ossl_digest_get_approved_nid_with_sha1_1,
usdt:/usr/lib64/libcrypto.so.3:fedora_ossl_digest_is_allowed_1,
usdt:/usr/lib64/libcrypto.so.3:fedora_ossl_digest_rsa_sign_get_md_nid_1
{
printf("%s(%d) uses mdnid=%d in probe %s\n%s\n", comm, pid, arg0, probe, ustack(perf));
}
which successfully prints
Attaching 9 probes...
openssl(931) uses mdnid=64 in probe usdt:/usr/lib64/libcrypto.so.3:libcrypto:fedora_ossl_digest_rsa_sign_get_md_nid_1
7f435fc157e8 0x7f435fc157e8 ([unknown])
14 0x14 ([unknown])
when running openssl pkeyutl -inkey key.pem -sign -in key.pem.sha1 -out key.pem.sig -pkeyopt digest:sha1