http://bugzilla.opensuse.org/show_bug.cgi?id=1169569 http://bugzilla.opensuse.org/show_bug.cgi?id=1169569#c2 Andreas Stieger changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Andreas.Stieger@gmx.de, | |pmonrealgonzalez@suse.com Assignee|screening-team-bugs@suse.de |pmonrealgonzalez@suse.com --- Comment #2 from Andreas Stieger --- Assuming it was this change... https://build.opensuse.org/request/show/791689 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1169569 http://bugzilla.opensuse.org/show_bug.cgi?id=1169569#c4 --- Comment #4 from Yamashita Ren --- Indeed, I had a lot of bad experiences with BTRFS despite how much I love transparent compression. I never really thought the system snapshots would be of any use and was thinking they were just here to justify the use of zstd compression. How wrong I was ! When such a bug happens (granted, it is quite rare), being able to boot the system from a previous state is gold. I tried to `rpm -e libgcrypt20-hmac` but it is required by keepassxc so I kept it locked instead. Works fine enough until the package is fixed ;) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1169569 John Paul Adrian Glaubitz changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adrian.glaubitz@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1169569 http://bugzilla.opensuse.org/show_bug.cgi?id=1169569#c6 Michal Kubeček changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mkubecek@suse.com --- Comment #6 from Michal Kubeček --- I got also hit by this yesterday. "zypper update" started showing errors somewhere in the middle of an update and after that, I couldn't run rpm and some other commands. After replacing /usr/lib64/.libgcrypt.so.20.hmac and /usr/lib64/libgcrypt.so.20.2.2 with copies from an unaffected system (not updated yet), I got this: unicorn:~ # rpm -q libgcrypt20-hmac libgcrypt20-hmac-1.8.2-lp152.12.14.x86_64 unicorn:~ # rpm -q libgcrypt20 libgcrypt20-1.8.2-lp152.13.2.x86_64 So apparently the problem is that the library was updated already but the checksum file was not so that any program using libgcrypt failed the check and refused to start. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1169569 http://bugzilla.opensuse.org/show_bug.cgi?id=1169569#c8 Vítězslav Čížek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS CC| |vcizek@suse.com --- Comment #8 from Vítězslav Čížek --- Here are some details about the issue. The FIPS specification mandates that a cryptographic library must run a set of selftests that ensure sanity and integrity of the library before any actual use of cryptographic operations. One of the tests is binary integrity, where a HMAC-SHA256 checksum of the shared object is compared against a known value, which is stored in /usr/lib64/.libgcrypt.so.20.hmac, provided by the libgcrypt20-hmac subpackage. These self-tests trigger whenever the checksum file is available (meaning libgcrypt20-hmac is installed). The installed checksum and the library got out of sync during the installation and the binary integrity test started to fail, causing an abort() of the crypto library. We faced this situation in the past (bug 1057010), where a package used a crypto library from %post in between installation of the shared library and its checksum. The mitigation was to add a support for weak dependency cycles to rpm (using Suggests and Requires, bug 1077635), which ensured that both packages were installed together. For SLE-15-SP2, rpm has switched from using beecrypt to libgcrypt (jsc#SLE-9552) and the above mentioned trick is, apparently, no longer sufficient. rpm itself now links against libgcrypt and the FIPS selftests are triggered from the libgcrypt library constructor. Why haven't this problem appeared earlier? Incidentally, until the update mentioned in comment 2, libgcrypt contained a bug (bug 1164950) which caused that the FIPS selftests were never run. Once it got fixed this issue showed up. Our solution, which has already been submitted to maintenance (sr#216083), is to bundle the checksum file (/usr/lib64/.libgcrypt.so.20.hmac.) together with the libgcrypt library and change the -hmac subpackage to only contain a trigger file for the FIPS selftests. -- You are receiving this mail because: You are on the CC list for the bug.