Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #59146

Re: Secure boot signing infrastructure - feedback request

From Ben Hutchings <ben@decadent.org.uk>
Newsgroups linux.debian.kernel
Subject Re: Secure boot signing infrastructure - feedback request
Date 2017-10-09 15:10 +0200
Message-ID <uyFYJ-3Yt-9@gated-at.bofh.it> (permalink)
References <uxj4e-6xD-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

On Thu, 2017-10-05 at 14:57 -0300, Helen Koike wrote:
> Hello all,
> 
> As you probably already know, Debian doesn't support the Secure Boot
> chain yet.
> To support it we need to sign Grub and the Kernel with our key, so we
> are discussing the best infrastructure for this workflow.
> 
> The first approach we had was to add a by-hand script in Dak as
> described here
> https://wiki.debian.org/SecureBoot#First_option:_by-hand_script_in_dak
> But this option wasn't well received by the ftpteam

I would like to know what the objection was.

> The second approach we have is to add some debhelper scripts (e.g
> dh_sign...) that will access a signing service which will sign the
> binaries with Debian's key.  We would use the dh_sign... helpers when
> making an extra binary package. buildd would then publish the -signed
> version of the package in the archives.
> Please see a more detailed explanation here
> https://wiki.debian.org/SecureBoot#Second_option:_use_buildd_.2B-_debhelper_instead_of_dak
> A current known issue with this approach is the NEW queue: it requires
> the maintainer to also upload binaries for an architecture on first
> upload, and these binaries are not rebuilt by the buildd ( see
> https://wiki.debian.org/SecureBoot#Issues ).

It also makes all these packages unreproducible, which is a policy
violation.

It also appears to mean that buildds can get anything signed on demand
with no human intervention at all, without all the checks that dak does
on uploads.  This seems to be to substantially raise the risk of
signing evil code and needing to revoke those signatures (or the
signing key).

Plus the reliability issues you pointed out on the wiki.

> I would like to know everyone's opinions about these approaches, if you
> agree to go forward with the second approach described above and how do
> we solve the NEW queue policy issue.

So far as I can see, the second approach is difficult, risky,
unreliable and leads to policy violations.

On the other side... there is an FTP team objection with no documented
explanation.

Ben.

-- 
Ben Hutchings
Humour is the best antidote to reality.

Back to linux.debian.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Secure boot signing infrastructure - feedback request Helen Koike <helen.koike@collabora.com> - 2017-10-05 20:30 +0200
  Re: Secure boot signing infrastructure - feedback request Helen Koike <helen.koike@collabora.com> - 2017-10-09 03:20 +0200
  Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-10-09 15:10 +0200
    Re: Secure boot signing infrastructure - feedback request Steve McIntyre <steve@einval.com> - 2017-10-09 18:40 +0200
      Re: Secure boot signing infrastructure - feedback request Julien Cristau <jcristau@debian.org> - 2017-10-09 18:50 +0200
      Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-10-09 20:10 +0200
        Re: Secure boot signing infrastructure - feedback request Ansgar Burchardt <ansgar@debian.org> - 2017-10-13 00:10 +0200
          Re: Secure boot signing infrastructure - feedback request Helen Koike <helen.koike@collabora.com> - 2017-10-13 00:20 +0200
            Re: Secure boot signing infrastructure - feedback request Steve McIntyre <steve@einval.com> - 2017-10-31 17:00 +0100
              Re: Secure boot signing infrastructure - feedback request Helen Koike <helen.koike@collabora.com> - 2017-11-15 14:50 +0100
                Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-11-23 00:20 +0100
                Re: Secure boot signing infrastructure - feedback request Steve McIntyre <steve@einval.com> - 2017-11-23 17:30 +0100
              Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-11-23 00:10 +0100
            Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-11-23 00:10 +0100
              Re: Secure boot signing infrastructure - feedback request Steve McIntyre <steve@einval.com> - 2017-11-23 17:30 +0100
          Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-11-22 23:10 +0100
            Re: Secure boot signing infrastructure - feedback request Tollef Fog Heen <tfheen@err.no> - 2017-11-24 21:00 +0100
        Re: Secure boot signing infrastructure - feedback request Steve McIntyre <steve@einval.com> - 2017-10-13 00:50 +0200
          Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-11-22 23:20 +0100

csiph-web