Gentoo Archives: gentoo-dev

From: Kenton Groombridge <concord@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing
Date: Mon, 27 Jun 2022 19:18:50
Message-Id: 20220627191841.sojmigoiiglrkyrh@fuuko
In Reply to: Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing by Mike Gilbert
1 On 22/06/27 02:56PM, Mike Gilbert wrote:
2 > On Mon, Jun 27, 2022 at 2:35 PM Kenton Groombridge <concord@g.o> wrote:
3 > > > so looks like we need to combine both methods and do the following:
4 > > > - if signing requested without compression - sign in pkg_preinst.
5 > > > - if signing requested with compression - sign in src_install
6 > > >
7 > >
8 > > Why can't we do both in pkg_preinst? I am thinking it would be best if
9 > > we drop the current compression implementation and rework your old code
10 > > to handle both compression and signing since the signing code is more or
11 > > less already complete.
12 >
13 > Signing modules in pkg_preinst seems like a bad idea to me. That means
14 > you need to copy your private keys around to every host where the
15 > package might be installed.
16 >
17 > If you sign in src_compile or src_install, you only need private keys
18 > on the system building your binpkg.
19 >
20
21 Ah that makes sense. I think the question then is whether or not
22 building binpkgs for kernel modules where the target system has its own
23 signing keys is something we want to support.
24
25 With that in mind I realize that doing compression in pkg_preinst means
26 that target systems can use different compression methods (or no
27 compression at all) if desired without much complication.

Attachments

File name MIME type
signature.asc application/pgp-signature