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. |