All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lucas De Marchi <lucas.de.marchi@gmail.com>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: linux-modules <linux-modules@vger.kernel.org>,
	820010-done@bugs.debian.org,
	Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [PATCH v2] libkmod: Add support for detached module signatures
Date: Sat, 4 Jun 2016 11:13:04 -0300	[thread overview]
Message-ID: <CAKi4VAK-qtLHxwRd8gp78FNU9D9V2crfzxT+8-nGD20_ir8NSA@mail.gmail.com> (raw)
In-Reply-To: <1464526136.2762.84.camel@decadent.org.uk>

On Sun, May 29, 2016 at 9:48 AM, Ben Hutchings <ben@decadent.org.uk> wrote:
> I'm withdrawing this patch for reasons explained in
> http://lists.debian.org/1464525520.2762.80.camel@decadent.org.uk

quoting some parts:

> This is blocked on upstream acceptance in kmod, and it's not clear
> whether that's ever going to happen."

I'm more against the impact of how this is implemented, not against
the idea of reproducible builds you are pursuing. From the points you
raised there:


> 1. Attach module signatures at installation time, in a subdirectory.
>    Change kmod to prefer this subdirectory (this is purely a
>    configuration change).  It would also be possible to check during
>    installation that signatures match the installed unsigned modules,
>    and if not then abort and leave any older signed modules in place.

Yep, this is a mere change to depmod.d config files.

> 2. Attach module signatures at package build time, making the
>    linux-image-signed packages provide/conflict/replace the
>    corresponding linux-image packages.  For architectures with
>    signed modules, udebs would be built from linux-signed and not
>    from linux.

very reasonable, too.


Lucas De Marchi

      reply	other threads:[~2016-06-04 14:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-05  0:16 [PATCH] libkmod: Add support for detached module signatures Ben Hutchings
2016-04-05  0:32 ` [PATCH v2] " Ben Hutchings
2016-04-13  4:05   ` Lucas De Marchi
2016-04-13 10:00     ` Ben Hutchings
2016-05-17 12:51       ` Ben Hutchings
2016-05-21 18:31       ` Lucas De Marchi
2016-05-21 18:40         ` Bug#820010: " Marco d'Itri
2016-05-21 19:01         ` Ben Hutchings
2016-05-29 12:48           ` Ben Hutchings
2016-06-04 14:13             ` Lucas De Marchi [this message]

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=CAKi4VAK-qtLHxwRd8gp78FNU9D9V2crfzxT+8-nGD20_ir8NSA@mail.gmail.com \
    --to=lucas.de.marchi@gmail.com \
    --cc=820010-done@bugs.debian.org \
    --cc=ben@decadent.org.uk \
    --cc=linux-modules@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.