On Wed, Jul 26, 2023 at 01:21:58PM -0400, Dillon Amburgey wrote:
> I understand and agree the behavior doesn't quite make sense.
> While I know this code has not recently changed inside apt, I believe
> it must have recently started expressing itself when combined with
> some other change on the mi
I understand and agree the behavior doesn't quite make sense.
While I know this code has not recently changed inside apt, I believe
it must have recently started expressing itself when combined with
some other change on the mirrors or in the release process.
I do think this is a regression in a pr
On Mon, Jul 24, 2023 at 10:35:35PM -0400, Dillon Amburgey wrote:
> I have seen this as well. This has recently started breaking apt
> update on bookworm docker images as well as images built off bookworm
> (e.g. python:3.8)
>
> This can be easily reproduced on FIPS-enabled hosts:
> docker run -it
I have seen this as well. This has recently started breaking apt
update on bookworm docker images as well as images built off bookworm
(e.g. python:3.8)
This can be easily reproduced on FIPS-enabled hosts:
docker run -it --rm debian:bookworm apt update
Get:1 http://deb.debian.org/debian bookworm
So I see in the changes to libgcrypt since bullseye that there have
been some changes in the initialization on systems where FIPS is
enabled.
The attached patch has "works for me" status, and I feel that it is the
correct way to continue to have apt function as expected on a FIPS
enabled system.
Package: apt
Version: 2.5.1
Severity: normal
"apt update" fails if the system runs in FIPS mode:
| # apt update
| Hit:2 http://deb.debian.org/debian-debug sid InRelease
| fatal error in libgcrypt, file ../../src/misc.c, line 92, function
_gcry_fatal_error: requested algo not in md context
|
| F
6 matches
Mail list logo
