Ubuntu
libgcrypt20 package

[FFe] sync libgcrypt20 1.10.2-3 from Debian to mantic

Bug #2036724 reported by Shengjing Zhu
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libgcrypt20 (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

To sync libgcrypt20 1.10.2-3 instead of merging, it will drop 2 remaining changes:

1. d/p/12_lessdeps_libgcrypt-config.diff: refresh patch offsets

   It's same as the debian package, and it can be applied successfully without
   this delta.

2. d/p/disable_fips_enabled_read.patch
   Disable the library reading /proc/sys/crypto/fips_enabled file
   and going into FIPS mode.
   libgcrypt is not a FIPS certified library.

   I want to request FFe for this one. libgcrypt is FIPS certified library
   nowadays. So this patch is obsoleted.

Changelog entries since current mantic version 1.10.2-2ubuntu1:

libgcrypt20 (1.10.2-3) unstable; urgency=medium

 [ Simon Josefsson ]
 * Update Homepage: URL.

 [ Andreas Metzler ]
 * Drop --insert-timestamp linker option on mingw*, binutils 2.41 should use
   SOURCE_DATE_EPOCH automatically and the Debian package has dropped the
   patch to add the --insert-timestamp option. Closes: #1052219

 -- Andreas Metzler <email address hidden> Tue, 19 Sep 2023 13:48:32 +0200¬

This new version fixes libgcrypt20 FTBFS.

See original description
Shengjing Zhu (zhsj)
description: updated
description: updated
Revision history for this message
Adrien Nader (adrien) wrote :

You should probably get the FIPS team to ack this change here.

Revision history for this message
Shengjing Zhu (zhsj) wrote (last edit ):

@tobhe are you the right person to ack this FIPS change?

Revision history for this message
Tobias Heider (tobhe) wrote :

I think it is fine to drop it if it makes your job easier.

When enabling FIPS or FIPS Updates on Ubuntu the pro client adds a separate FIPS only archive that ships the certified package versions (including a kernel enabling the proc flag). There is no supported FIPS setup that ship the regular archive libgcrypt version so it shouldn't be a problem for us.

Revision history for this message
Paride Legovini (paride) wrote :

By reading Tobias' comment on the FIPS archive, looks like that dropping disable_fips_enabled_read.patch doesn't actually make a difference in practice, as on FIPS systems a different libgcrypt20 will be used. Is this the case?

Technically I think this FFe is safe, but if the above is correct then the justification for the FFe is basically missing, and should wait for the NN cycle to sync the library. If OTOH there is a justification for the FFe then please help us better understand it. Thanks!

Revision history for this message
Tobias Heider (tobhe) wrote :

> By reading Tobias' comment on the FIPS archive, looks like that dropping disable_fips_enabled_read.patch doesn't actually make a difference in practice, as on FIPS systems a different libgcrypt20 will be used. Is this the case?

Yes. This wasn't the case when the patch was added, so back then it helped make the archive version usable with a FIPS kernel. Nowadays we ship our own libgcrypt20 so it doesn't make a difference.

Revision history for this message
Shengjing Zhu (zhsj) wrote :

FTR, the disable_fips_enabled_read.patch is introduced in https://bugs.launchpad.net/ubuntu/+source/libgcrypt20/+bug/1748310

Revision history for this message
Steve Langasek (vorlon) wrote :

> Yes. This wasn't the case when the patch was added, so back then
> it helped make the archive version usable with a FIPS kernel.
> Nowadays we ship our own libgcrypt20 so it doesn't make a difference.

The original reason for this patch being added was LP: #1748310. Do we really want to risk reintroducing such a bug? A FIPS customer who has the FIPS archive enabled SHOULD be using the libgcrypt20 from the FIPS archive; but if they make a mistake and have the libgcrypt20 from the main Ubuntu archive installed, with this patch reverted, will this misbehave on boot?

FIPS is not supported on non-LTS releases so I don't actually care about this from a feature freeze POV, consider the exception granted. But we still need to be sure that dropping this change is the correct thing to do from the perspective of 24.04 LTS.

Revision history for this message
Graham Inggs (ginggs) wrote :

It seems this was solved by a merge in 1.10.2-3ubuntu1 instead (LP: #2036527)

Changed in libgcrypt20 (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.