unable to sign dkms modules due to libssl1 dependency

I got the following error when compiling dkms drivers on the latest surface kernel:

/lib/modules/6.1.6-surface/build/scripts/sign-file: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file

I use debian testing, and indeed they no longer ship this library. I solved it by installing libssl1.1_1.1.1n-0+deb11u3_amd64.deb as ships with bullseye.

I am not sure where sign-file comes from, but I would assume it would be best to make it compatible with libssl3.

Kernels are currently built on Ubuntu 20.04. We can't switch to 22.04 because that causes similar problems, just for older systems (in fact we only recently reverted such a change). At some point I'll probably have to look into building individual kernels for specific distributions, but it might take a while until I can find the time to do that.

Are there any CI jobs that build the .deb packages? I didn't see anything in the root directory that looks like it, but I'm only familiar with GitLab's CI system, not GitHub's implementation, so I may just be looking in the wrong place.

I'd be willing to contribute towards updating the automation if that would be helpful. I also run an apt repo that supports multiple versions of Debian and have some notes on that which I could share if it'd make things easier for you.

So our setup is a bit weird, because we only host the repository metadata ourselves, the actual packages are hosted on GitHub releases to take some load off the server.

The kernel packages are built on linux-surface. Once thats done, the CI uploads them as a GitHub release and then pushes placeholder files that link to the newly created release to the repo.

On the repo, a CI job that runs on a schedule then downloads the packages, generates / updates the repository metadata, and pushes it to a different branch. That branch is then automatically downloaded by the server and served as pkg.surfacelinux.com.

Bluetooth: ISO: do not emit new LE Create CIS if previous is pending

Hi,
Is there a solution that doesn't require downgrading a security-related package ?
Thanks

Can't this be solved by linking sign-file statically?
E.g.:

diff --git a/scripts/Makefile b/scripts/Makefile
index fe56eeef09dd..b487bb3c7c9c 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -29,7 +29,7 @@ HOSTCFLAGS_sorttable.o = -I$(srctree)/tools/include
 HOSTLDLIBS_sorttable = -lpthread
 HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
 HOSTCFLAGS_sign-file.o = $(shell $(HOSTPKG_CONFIG) --cflags libcrypto 2> /dev/null)
-HOSTLDLIBS_sign-file = $(shell $(HOSTPKG_CONFIG) --libs libcrypto 2> /dev/null || echo -lcrypto)
+HOSTLDLIBS_sign-file = -Wl,-Bstatic $(shell $(HOSTPKG_CONFIG) --static --libs libcrypto 2> /dev/null || echo -lcrypto) -Wl,-Bdynamic
 
 ifdef CONFIG_UNWINDER_ORC
 ifeq ($(ARCH),x86_64)

@quo

@quo Good idea, thanks! I'll give it a go in the next release.

pkg/debian: Add patch to link sign-file statically

Look like it's causing a build failure unfortunately. :(
https://github.com/linux-surface/linux-surface/actions/runs/9998610572/job/27637889211#step:7:1163

Not sure why, because it works for me locally on Debian. Maybe try removing -ldl from pkg-config output? Or adding static -lc?

Yeah, unfortunately I haven't had the time to look into how it could be fixed yet.

I think adding -lc fixed it... There's still warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking which has me worrying that the workaround doesn't work out in the end, but at least a v6.9.9 build is now running.

Edit: -lc breaks the final executable. I'll try statically linking everything for sign-file next.

@quo

For some reason statically linking everything works in my test container but not on github actions... there sign-file crashes with a segfault when trying to sign modules...

@quo Do you have any ideas what's going wrong?

Explicitly linking libdl dynamically seems to work. Didn't do a thorough test, but at least it seems to fix the dlopen errors when building on Ubuntu 20.04, and the resulting executable runs on 20.04, and on recent Debian.

HOSTLDLIBS_sign-file = -Wl,-Bstatic $(shell $(HOSTPKG_CONFIG) --static --libs libcrypto | sed 's/-ldl//' 2> /dev/null || echo -lcrypto) -Wl,-Bdynamic -ldl

I think the reason my original patch works on current systems but not on 20.04, is because glibc 2.34 merged libdl into libc, and 20.04 still has 2.31.

Ahh, for some reason I was also testing on 22.04 and not 20.04... On 20.04 I'm able to reproduce the crash and can confirm that your patch works. Fingers crossed it works on GitHub actions now as well. Thanks!

pkg/debian: Statically link libcrypto for sign-file

I think this can be closed?

Can confirm that this works on Debian 12 with libssl3. Thank you. ❤

It doesn't solve the problem with /sbin/vboxconfig not signing their kernel module after they compile it, but that seems to be a problem with virtualbox because running /usr/lib/linux-kbuild-6.1/scripts/sign-file produces the usage text as expected.

scsi: sg: Resolve soft lockup issue when opening /dev/sgX

Navigation Menu

Repository navigation

unable to sign dkms modules due to libssl1 dependency #134

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

unable to sign dkms modules due to libssl1 dependency #134

Description

Activity

qzed commented on Feb 1, 2023

hax0rbana-adam commented on Aug 27, 2023

StollD commented on Aug 27, 2023

KaKi87 commented on Apr 28, 2024

quo commented on Jun 18, 2024

qzed commented on Jun 30, 2024

quo commented on Jul 27, 2024

qzed commented on Jul 27, 2024

qzed commented on Aug 3, 2024

qzed commented on Aug 4, 2024

quo commented on Aug 4, 2024

qzed commented on Aug 4, 2024

qzed commented on Mar 8, 2025

hax0rbana-adam commented on Mar 22, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions