public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Kenton Groombridge <concord@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing
Date: Mon, 27 Jun 2022 15:18:41 -0400	[thread overview]
Message-ID: <20220627191841.sojmigoiiglrkyrh@fuuko> (raw)
In-Reply-To: <CAJ0EP410KN6BhtiiTWfd99pX4748zCS32DUNR5Fu8nM95LL_XA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]

On 22/06/27 02:56PM, Mike Gilbert wrote:
> On Mon, Jun 27, 2022 at 2:35 PM Kenton Groombridge <concord@gentoo.org> wrote:
> > > so looks like we need to combine both methods and do the following:
> > >  - if signing requested without compression - sign in pkg_preinst.
> > >  - if signing requested with compression - sign in src_install
> > >
> >
> > Why can't we do both in pkg_preinst? I am thinking it would be best if
> > we drop the current compression implementation and rework your old code
> > to handle both compression and signing since the signing code is more or
> > less already complete.
> 
> Signing modules in pkg_preinst seems like a bad idea to me. That means
> you need to copy your private keys around to every host where the
> package might be installed.
> 
> If you sign in src_compile or src_install, you only need private keys
> on the system building your binpkg.
> 

Ah that makes sense. I think the question then is whether or not
building binpkgs for kernel modules where the target system has its own
signing keys is something we want to support.

With that in mind I realize that doing compression in pkg_preinst means
that target systems can use different compression methods (or no
compression at all) if desired without much complication.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

  reply	other threads:[~2022-06-27 19:18 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-21 18:19 [gentoo-dev] [PATCH] linux-mod.eclass: support module signing Kenton Groombridge
2022-06-21 18:21 ` Kenton Groombridge
2022-06-23 12:51   ` Mike Pagano
2022-06-23 14:30     ` Kenton Groombridge
2022-06-26 10:52 ` Georgy Yakovlev
2022-06-26 11:15   ` Georgy Yakovlev
2022-06-27 18:35     ` Kenton Groombridge
2022-06-27 18:56       ` Mike Gilbert
2022-06-27 19:18         ` Kenton Groombridge [this message]
2022-06-27 19:42         ` Georgy Yakovlev
2022-06-27 19:49           ` Mike Gilbert
2022-06-27 21:11             ` Georgy Yakovlev
2022-06-27 21:50               ` Mike Gilbert
2022-06-27 23:42                 ` Georgy Yakovlev
2022-07-05 19:02                   ` Georgy Yakovlev
2022-07-05 19:55                     ` Kenton Groombridge
2022-07-05 20:11                     ` Mike Gilbert
2022-06-27 19:46       ` Georgy Yakovlev
2022-06-27 20:02         ` Kenton Groombridge
2022-06-27 21:25           ` Georgy Yakovlev
  -- strict thread matches above, loose matches on Subject: below --
2018-04-14 21:25 Georgy Yakovlev
2018-04-15 18:13 ` NP-Hardass

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220627191841.sojmigoiiglrkyrh@fuuko \
    --to=concord@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox