[opensuse-factory] Leap 15.2 update to Build 626.2 causes serious issue
FYI: https://bugzilla.opensuse.org/show_bug.cgi?id=1169588 Regards, Frank -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
16.04.2020 00:59, Frank Krüger пишет:
FYI: https://bugzilla.opensuse.org/show_bug.cgi?id=1169588
Regards, Frank
I do not understand how a) enforcing HMAC check of library at start of each program using libgcrypt b) shipping actual HMAC and library itself in two independent separate packages is ever going to work. You will always have hash mismatch during update unless it is somehow possible to force both packages to be updated at the same time *and* make sure no binary that needs libgcrypt runs during this update. And even if RPM can do it, I am not sure to which extent zypper complies with these requirements (does not it effectively use --nodeps --force and computes installation order itself)? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 16 Apr 2020, Andrei Borzenkov wrote:
16.04.2020 00:59, Frank Krüger пишет:
FYI: https://bugzilla.opensuse.org/show_bug.cgi?id=1169588
Regards, Frank
I do not understand how
a) enforcing HMAC check of library at start of each program using libgcrypt b) shipping actual HMAC and library itself in two independent separate packages
is ever going to work. You will always have hash mismatch during update unless it is somehow possible to force both packages to be updated at the same time *and* make sure no binary that needs libgcrypt runs during this update.
And even if RPM can do it, I am not sure to which extent zypper complies with these requirements (does not it effectively use --nodeps --force and computes installation order itself)?
It's really sad this bogosity went in ... it doesn't buy us anything but a checkmark on some certification - plus these kind of issues. There's no chain of trust involved so ... For Leap this asks for disabling the "feature" IMHO. When we were discussing this "feature" I was suggesting to generate the hmac at RPM install time from within rpm itself (which has done cryptographic signature verification on the RPMs contents) when the feature is enabled. The solution with a separate package (only Suggested by the library(!?)) looks broken to me. Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
Hi! On 4/16/20 8:42 AM, Richard Biener wrote:
When we were discussing this "feature" I was suggesting to generate the hmac at RPM install time from within rpm itself (which has done cryptographic signature verification on the RPMs contents) when the feature is enabled. The solution with a separate package (only Suggested by the library(!?)) looks broken to me.
Any idea on how to fix a system that is affected by this? A friend of mine has a laptop running Leap 15.2 and trying to remove the libcrypt20-hmac package fails both with zypper and rpm -e because the libgcrypt self-test fails. Is there any file that can renamed or removed to fix this issue? PS: He doesn't have a btrfs root partition, so no snapshots. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Apr 16, 2020 at 10:50:46AM +0200, John Paul Adrian Glaubitz wrote:
Hi!
On 4/16/20 8:42 AM, Richard Biener wrote:
When we were discussing this "feature" I was suggesting to generate the hmac at RPM install time from within rpm itself (which has done cryptographic signature verification on the RPMs contents) when the feature is enabled. The solution with a separate package (only Suggested by the library(!?)) looks broken to me.
Any idea on how to fix a system that is affected by this?
A friend of mine has a laptop running Leap 15.2 and trying to remove the libcrypt20-hmac package fails both with zypper and rpm -e because the libgcrypt self-test fails.
Is there any file that can renamed or removed to fix this issue?
PS: He doesn't have a btrfs root partition, so no snapshots.
rm /usr/lib64/.libgcrypt.so.20.hmac Should do the trick. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Apr 16, 2020 at 11:52 AM John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> wrote:
Hi!
On 4/16/20 8:42 AM, Richard Biener wrote:
When we were discussing this "feature" I was suggesting to generate the hmac at RPM install time from within rpm itself (which has done cryptographic signature verification on the RPMs contents) when the feature is enabled. The solution with a separate package (only Suggested by the library(!?)) looks broken to me.
Any idea on how to fix a system that is affected by this?
A friend of mine has a laptop running Leap 15.2 and trying to remove the libcrypt20-hmac package fails both with zypper and rpm -e because the libgcrypt self-test fails.
Is there any file that can renamed or removed to fix this issue?
https://www.gnupg.org/documentation/manuals/gcrypt/Enabling-FIPS-mode.html -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Apr 16, 2020 at 08:42:41AM +0200, Richard Biener wrote:
On Thu, 16 Apr 2020, Andrei Borzenkov wrote:
16.04.2020 00:59, Frank Krüger пишет:
FYI: https://bugzilla.opensuse.org/show_bug.cgi?id=1169588
Regards, Frank
I do not understand how
a) enforcing HMAC check of library at start of each program using libgcrypt b) shipping actual HMAC and library itself in two independent separate packages
is ever going to work. You will always have hash mismatch during update unless it is somehow possible to force both packages to be updated at the same time *and* make sure no binary that needs libgcrypt runs during this update.
And even if RPM can do it, I am not sure to which extent zypper complies with these requirements (does not it effectively use --nodeps --force and computes installation order itself)?
It's really sad this bogosity went in ... it doesn't buy us anything but a checkmark on some certification - plus these kind of issues. There's no chain of trust involved so ...
For Leap this asks for disabling the "feature" IMHO.
When we were discussing this "feature" I was suggesting to generate the hmac at RPM install time from within rpm itself (which has done cryptographic signature verification on the RPMs contents) when the feature is enabled. The solution with a separate package (only Suggested by the library(!?)) looks broken to me.
If the libgcrypt20-hmac package is not installed (and the system not in FIPS mode) it will actually be happily proceeding onwards. So just deinstalling it on Leap will help. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (5)
-
Andrei Borzenkov -
Frank Krüger -
John Paul Adrian Glaubitz -
Marcus Meissner -
Richard Biener