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

Groups > linux.debian.project > #9856 > unrolled thread

UEFI Secure Boot sprint report

Back to article view | Back to linux.debian.project

Contents

  UEFI Secure Boot sprint report Tollef Fog Heen <tfheen@debian.org> - 2018-04-29 21:50 +0200
    Re: UEFI Secure Boot sprint report Ian Jackson <ijackson@chiark.greenend.org.uk> - 2018-04-30 14:20 +0200
      Re: UEFI Secure Boot sprint report Tollef Fog Heen <tfheen@err.no> - 2018-04-30 17:30 +0200
    Re: UEFI Secure Boot sprint report Hideki Yamane <henrich@iijmio-mail.jp> - 2018-05-07 15:40 +0200
      Re: UEFI Secure Boot sprint report Tollef Fog Heen <tfheen@err.no> - 2018-05-13 16:20 +0200
        Re: Re: UEFI Secure Boot sprint report Hideki Yamane <henrich@iijmio-mail.jp> - 2018-05-14 15:10 +0200
          Re: Re: UEFI Secure Boot sprint report Ben Hutchings <ben@decadent.org.uk> - 2018-05-14 16:40 +0200
            Re: UEFI Secure Boot sprint report Hideki Yamane <henrich@iijmio-mail.jp> - 2018-05-15 04:10 +0200
              Re: UEFI Secure Boot sprint report Ben Hutchings <ben@decadent.org.uk> - 2018-05-15 04:40 +0200
                Re: UEFI Secure Boot sprint report Hideki Yamane <henrich@iijmio-mail.jp> - 2018-05-15 04:50 +0200
                  Re: UEFI Secure Boot sprint report Colin Watson <cjwatson@debian.org> - 2018-05-15 05:20 +0200
                    Re: UEFI Secure Boot sprint report Steve McIntyre <steve@einval.com> - 2018-05-15 11:50 +0200
                      Re: UEFI Secure Boot sprint report Philipp Hahn <hahn@univention.de> - 2018-05-16 10:30 +0200
                        Re: UEFI Secure Boot sprint report Ben Hutchings <ben@decadent.org.uk> - 2018-05-17 01:30 +0200
                        Re: UEFI Secure Boot sprint report Hideki Yamane <henrich@iijmio-mail.jp> - 2018-06-19 01:00 +0200
                          Re: UEFI Secure Boot sprint report Colin Watson <cjwatson@debian.org> - 2018-06-19 10:30 +0200
                            Re: UEFI Secure Boot - GRUB WIP report Philipp Hahn <hahn@univention.de> - 2018-06-19 11:20 +0200
                              Re: UEFI Secure Boot - GRUB WIP report Colin Watson <cjwatson@debian.org> - 2018-06-19 15:00 +0200
    Re: UEFI Secure Boot sprint report Hideki Yamane <henrich@iijmio-mail.jp> - 2018-10-02 14:40 +0200

#9856 — UEFI Secure Boot sprint report

People from the FTP team, kernel team and DSA, as well as other
interested individuals met in Fulda, Germany for a sprint with the goal
of deciding and implementing the workflow for Secure Boot.

Participants
------------
* Ansgar Burchardt
* Joerg Jaspert
* Luke W. Faraone
* Ben Hutchings
* Tollef Fog Heen
* Helen Koike
* Philipp Hahn
* Julien Cristau [remote]
* Steve McIntyre [remote]

We had a long discussion about what requirements we had for the
signing process, whether that could happen inline in the regular build
process, if a human needed to be involved in the signing and how to
best handle embargoed builds.

In the end, we decided to have a signing service which will construct
a source package based on a "template" package and a list of files to
sign and upload this to be processed by the normal buildd and dak
processes. The signing service will also have an audit log which makes
it public what was signed and when.

Once this was agreed and various corner cases ironed out, we started
implementing the signing service, and the necessary changes in the
Linux kernel package, dak, fwupdate, shim and grub. The source for the
signing service can be found at
https://salsa.debian.org/ftp-team/code-signing.

By the end of the sprint, we were able to:
- generate a signing template for Linux kernel modules
- generate a signing template for shim
- generate a signing template for fwupdate
- have DAK detect such signing template packages automatically and
  generate a request for signing
- run the code of the signing box by hand to generate the source code
  packages containing the generated signatures

We're still missing (partially or completely):
- generate a signing template for GRUB2
- have DAK accept those generated source-only uploads

Acknowledgements
-------------------------
the sprint has been possible thanks to:
- the Office Factory for hosting us,
- donations to the Debian project for covering travel and
  accommodation costs for the sprint,
- Dropbox for sponsoring Luke's travel and accomodations,
- Technische Universität Dresden for sponsoring Ansgar's travel and
  accomodations, and
- Univention GmbH for sponsoring Philipp's travel and accomodations,

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

[toc] | [next] | [standalone]

#9857

Tollef Fog Heen writes ("UEFI Secure Boot sprint report"):
> In the end, we decided to have a signing service which will construct
> a source package based on a "template" package and a list of files to
> sign and upload this to be processed by the normal buildd and dak
> processes. The signing service will also have an audit log which makes
> it public what was signed and when.

Thanks for the update.

> Once this was agreed and various corner cases ironed out, we started
> implementing the signing service, and the necessary changes in the
> Linux kernel package, dak, fwupdate, shim and grub. The source for the
> signing service can be found at
> https://salsa.debian.org/ftp-team/code-signing.

One small point: Do you think tht the source for the signing service
is part of the source for the signed output ?  If so it probably needs
to be in the Debian archive, not just on salsa.  Sorry if this is
inconvenient.

> By the end of the sprint, we were able to:
> - generate a signing template for Linux kernel modules
> - generate a signing template for shim
> - generate a signing template for fwupdate
> - have DAK detect such signing template packages automatically and
>   generate a request for signing
> - run the code of the signing box by hand to generate the source code
>   packages containing the generated signatures

Thanks for your work.

Regards,
Ian.

[toc] | [prev] | [next] | [standalone]

#9858

]] Ian Jackson 

> > Once this was agreed and various corner cases ironed out, we started
> > implementing the signing service, and the necessary changes in the
> > Linux kernel package, dak, fwupdate, shim and grub. The source for the
> > signing service can be found at
> > https://salsa.debian.org/ftp-team/code-signing.
> 
> One small point: Do you think tht the source for the signing service
> is part of the source for the signed output ?  If so it probably needs
> to be in the Debian archive, not just on salsa.  Sorry if this is
> inconvenient.

Not any more than sbuild, buildd and wanna-build is part of the source
for buildd-signed packages in the archive, so my initial answer is no.
That said, it would be trivial to package, so somebody could easily
upload it to the archive.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

[toc] | [prev] | [next] | [standalone]

#9874

Hi,

> In the end, we decided to have a signing service which will construct
> a source package based on a "template" package and a list of files to
> sign and upload this to be processed by the normal buildd and dak
> processes. The signing service will also have an audit log which makes
> it public what was signed and when.

 I'm curious how this works.

 * source package was modified to generate <package>-$ARCH-signed-template
   binary package
 * dput it to repo and dak would pass to code sign service?
 * sign binary package??


 Please let know it or give an URL for it to help me to understand it,
 since I want to explain it on an article on Japanese tech magazine.


-- 
Regards,

 Hideki Yamane     henrich @ debian.org/iijmio-mail.jp

[toc] | [prev] | [next] | [standalone]

#9878

]] Hideki Yamane 

> Hi,
> 
> > In the end, we decided to have a signing service which will construct
> > a source package based on a "template" package and a list of files to
> > sign and upload this to be processed by the normal buildd and dak
> > processes. The signing service will also have an audit log which makes
> > it public what was signed and when.
> 
>  I'm curious how this works.
> 
>  * source package was modified to generate <package>-$ARCH-signed-template
>    binary package
>  * dput it to repo and dak would pass to code sign service?
>  * sign binary package??

The signing service is a source package builder.

I'll use linux as an example package.  It's uploaded to experimental and
builds the normal set of linux-image-* packages.  In addition, it builds
a package named linux-image-amd64-signed-template.  This matches a
filter on the dak side, so it is exposed in
https://incoming.debian.org/debian-buildd/project/external-signatures/requests.json
(+ .gpg for the signature) as «this needs to be signed».

The signing service polls that URL regularly, and when there is a new
package available, it is downloaded and unpacked into a temporary
directory.  It includes a manifest of what files from what packages need
to be signed.  Those packages are downloaded, the files in the manifest
are signed and the source package is built, signed and uploaded, to be
built by the regular buildds.

This allows us to both keep the key in a central place, having
reproducible builds, having an automated process and not having to
execute any code from the template package as part of the build.

I hope this explains it well enough, let me know if there's anything
unclear, I'm happy to explain further.

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

[toc] | [prev] | [next] | [standalone]

#9879

Hi,

 Thanks, your explanation is really helpful.


> The signing service is a source package builder.

 It build source package but its source package is based on built binary package?
 As I understand, singing to binary is necessary step.

1. source package
2. -> upload to dak
3. -> passed to buildd
4. -> binary package built
5. -> singing service pull those
6. -> source package built
7. -> dak, again
8. -> buildd, again
9. -> dak passes those to repo 


 And in previous report 

> We're still missing (partially or completely):
> - generate a signing template for GRUB2
> - have DAK accept those generated source-only uploads

 This is 7th step in above, right? 


-- 
Regards,

 Hideki Yamane     henrich @ debian.org/iijmio-mail.jp

[toc] | [prev] | [next] | [standalone]

#9880

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

On Mon, 2018-05-14 at 22:05 +0900, Hideki Yamane wrote:
> Hi,
> 
>  Thanks, your explanation is really helpful.
> 
> 
> > The signing service is a source package builder.
> 
>  It build source package but its source package is based on built binary package?
>  As I understand, singing to binary is necessary step.

Right.

> 1. source package
> 2. -> upload to dak
> 3. -> passed to buildd
> 4. -> binary package built

And one of those binary packages is a "template" for the source
package.  This is documented on the Etherpad, but in short it contains
an unpacked source package with everything except the signatures, plus
a configuration file specifying which binaries in which packages need
to be signed.

> 5. -> singing service pull those
> 6. -> source package built

This is the template source package plus all the (detached) signatures
that were specified in the configuration.

> 7. -> dak, again
> 8. -> buildd, again

Here there are build-dependencies on the previously built binaries, and
the build process adds the detached signatures to those binaries.

> 9. -> dak passes those to repo 
> 
> 
>  And in previous report 
> 
> > We're still missing (partially or completely):
> > - generate a signing template for GRUB2
> > - have DAK accept those generated source-only uploads
> 
>  This is 7th step in above, right? 

The second point (have DAK accept ...) is part of step 7, yes.  It
seems to have been implemented now.

Ben.

-- 
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison

[toc] | [prev] | [next] | [standalone]

#9882

Hi,

 Thanks for the clarification, Ben. Very helpful.

On Mon, 14 May 2018 15:35:50 +0100
Ben Hutchings <ben@decadent.org.uk> wrote:
> The second point (have DAK accept ...) is part of step 7, yes.  It
> seems to have been implemented now.

 Then, remaining blocker is only template for GRUB2?


-- 
Regards,

 Hideki Yamane     henrich @ debian.org/iijmio-mail.jp

[toc] | [prev] | [next] | [standalone]

#9883

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

On Tue, 2018-05-15 at 11:07 +0900, Hideki Yamane wrote:
> Hi,
> 
>  Thanks for the clarification, Ben. Very helpful.
> 
> On Mon, 14 May 2018 15:35:50 +0100
> Ben Hutchings <ben@decadent.org.uk> wrote:
> > The second point (have DAK accept ...) is part of step 7, yes.  It
> > seems to have been implemented now.
> 
>  Then, remaining blocker is only template for GRUB2?

For testing purposes, I think so.  I don't know whether GRUB implements
the policy we want at the moment.

We'll still need a "flag day" on which the signing service, and all
packages that get signed, switch to production signing keys.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.

[toc] | [prev] | [next] | [standalone]

#9884

Hi,

On Tue, 15 May 2018 03:32:26 +0100
Ben Hutchings <ben@decadent.org.uk> wrote:
> > > The second point (have DAK accept ...) is part of step 7, yes.  It
> > > seems to have been implemented now.
> > 
> >  Then, remaining blocker is only template for GRUB2?
> 
> For testing purposes, I think so.  I don't know whether GRUB implements
> the policy we want at the moment.

 Is there any issue to apply such policy to grub2 package, or just not
 discussed yet?

-- 
Regards,

 Hideki Yamane     henrich @ debian.org/iijmio-mail.jp

[toc] | [prev] | [next] | [standalone]

#9886

On Tue, May 15, 2018 at 11:46:00AM +0900, Hideki Yamane wrote:
> On Tue, 15 May 2018 03:32:26 +0100
> Ben Hutchings <ben@decadent.org.uk> wrote:
> > > > The second point (have DAK accept ...) is part of step 7, yes.  It
> > > > seems to have been implemented now.
> > > 
> > >  Then, remaining blocker is only template for GRUB2?
> > 
> > For testing purposes, I think so.  I don't know whether GRUB implements
> > the policy we want at the moment.
> 
>  Is there any issue to apply such policy to grub2 package, or just not
>  discussed yet?

Either nobody's tried to discuss it with me yet or I missed the email.
Feel free to (preferably in the form of a patch I can review :-) ).

-- 
Colin Watson                                       [cjwatson@debian.org]

[toc] | [prev] | [next] | [standalone]

#9887

On Tue, May 15, 2018 at 04:16:22AM +0100, Colin Watson wrote:
>On Tue, May 15, 2018 at 11:46:00AM +0900, Hideki Yamane wrote:
>> On Tue, 15 May 2018 03:32:26 +0100
>> Ben Hutchings <ben@decadent.org.uk> wrote:
>> > > > The second point (have DAK accept ...) is part of step 7, yes.  It
>> > > > seems to have been implemented now.
>> > > 
>> > >  Then, remaining blocker is only template for GRUB2?
>> > 
>> > For testing purposes, I think so.  I don't know whether GRUB implements
>> > the policy we want at the moment.
>> 
>>  Is there any issue to apply such policy to grub2 package, or just not
>>  discussed yet?
>
>Either nobody's tried to discuss it with me yet or I missed the email.
>Feel free to (preferably in the form of a patch I can review :-) ).

At / shortly after the sprint, Philipp (in CC) had patches basically
ready for grub2, but he seems to have gone quiet. <prod>

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me 

[toc] | [prev] | [next] | [standalone]

#9890

Moin,

Am 15.05.2018 um 11:41 schrieb Steve McIntyre:
> On Tue, May 15, 2018 at 04:16:22AM +0100, Colin Watson wrote:
>> On Tue, May 15, 2018 at 11:46:00AM +0900, Hideki Yamane wrote:
>>> On Tue, 15 May 2018 03:32:26 +0100 Ben Hutchings <ben@decadent.org.uk> wrote:
>>>>>> The second point (have DAK accept ...) is part of step 7, yes.  It
>>>>>> seems to have been implemented now.
>>>>>
>>>>>  Then, remaining blocker is only template for GRUB2?
>>>>
>>>> For testing purposes, I think so.  I don't know whether GRUB implements
>>>> the policy we want at the moment.

@benh: you meat to *only* boot signed stuff and not fall back to
disabling SB before booting an unsigned kernel?
That should be addressed by
<https://salsa.debian.org/pmhahn/grub/commit/fe06193ff5a36ee6aa6a6cab12f4651b6290d91b>

>>>  Is there any issue to apply such policy to grub2 package, or just not
>>>  discussed yet?
>>
>> Either nobody's tried to discuss it with me yet or I missed the email.
>> Feel free to (preferably in the form of a patch I can review :-) ).
> 
> At / shortly after the sprint, Philipp (in CC) had patches basically
> ready for grub2, but he seems to have gone quiet. <prod>

I was busy working on our release, which took all my time.
And I'm not subscribed to debian-project.

My last work it at <https://salsa.debian.org/pmhahn/grub/tree/signing>.
In the week after the sprint I worked on GRUB2 and got it so far to have
the signed amd64 package - so at the time of writing the sprint report
GRUB2 was already ready.

I haven't yet found time to setup an UEFI-SB test environment to check
that everything works.

I haven't yet tested any other architecture != amd64.

@Colin: Please have a look at said repository above.
What I'm currently unsure about is that amd64 has those ia32 packages as
well - it should work but also untested.
My reading is that those are required for dual booting?

Philipp

[toc] | [prev] | [next] | [standalone]

#9891

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

On Wed, 2018-05-16 at 10:05 +0200, Philipp Hahn wrote:
> Moin,
> 
> Am 15.05.2018 um 11:41 schrieb Steve McIntyre:
> > On Tue, May 15, 2018 at 04:16:22AM +0100, Colin Watson wrote:
> > > On Tue, May 15, 2018 at 11:46:00AM +0900, Hideki Yamane wrote:
> > > > On Tue, 15 May 2018 03:32:26 +0100 Ben Hutchings <ben@decadent.org.uk> wrote:
> > > > > > > The second point (have DAK accept ...) is part of step 7, yes.  It
> > > > > > > seems to have been implemented now.
> > > > > > 
> > > > > >  Then, remaining blocker is only template for GRUB2?
> > > > > 
> > > > > For testing purposes, I think so.  I don't know whether GRUB implements
> > > > > the policy we want at the moment.
> 
> @benh: you meat to *only* boot signed stuff and not fall back to
> disabling SB before booting an unsigned kernel?
> That should be addressed by
> <https://salsa.debian.org/pmhahn/grub/commit/fe06193ff5a36ee6aa6a6cab12f4651b6290d91b>

I think that's what we agreed, yes.

[...]
> I haven't yet found time to setup an UEFI-SB test environment to check
> that everything works.
[...]

It's fairly easy to do with OVMF; this blog entry summarises the
process:
https://www.decadent.org.uk/ben/blog/experiments-with-signed-kernels-and-modules-in-debian.html

Ben.

-- 
Ben Hutchings
Teamwork is essential - it allows you to blame someone else.

[toc] | [prev] | [next] | [standalone]

#9910

Hi,

 Just a ping question, is there any progress for grub2 package?
 If not, what's the blocker for it?

On Wed, 16 May 2018 10:05:21 +0200
Philipp Hahn <hahn@univention.de> wrote:
> Moin,
> 
> Am 15.05.2018 um 11:41 schrieb Steve McIntyre:
> > On Tue, May 15, 2018 at 04:16:22AM +0100, Colin Watson wrote:
> >> On Tue, May 15, 2018 at 11:46:00AM +0900, Hideki Yamane wrote:
> >>> On Tue, 15 May 2018 03:32:26 +0100 Ben Hutchings <ben@decadent.org.uk> wrote:
> >>>>>> The second point (have DAK accept ...) is part of step 7, yes.  It
> >>>>>> seems to have been implemented now.
> >>>>>
> >>>>>  Then, remaining blocker is only template for GRUB2?
> >>>>
> >>>> For testing purposes, I think so.  I don't know whether GRUB implements
> >>>> the policy we want at the moment.
> 
> @benh: you meat to *only* boot signed stuff and not fall back to
> disabling SB before booting an unsigned kernel?
> That should be addressed by
> <https://salsa.debian.org/pmhahn/grub/commit/fe06193ff5a36ee6aa6a6cab12f4651b6290d91b>
> 
> >>>  Is there any issue to apply such policy to grub2 package, or just not
> >>>  discussed yet?
> >>
> >> Either nobody's tried to discuss it with me yet or I missed the email.
> >> Feel free to (preferably in the form of a patch I can review :-) ).
> > 
> > At / shortly after the sprint, Philipp (in CC) had patches basically
> > ready for grub2, but he seems to have gone quiet. <prod>
> 
> I was busy working on our release, which took all my time.
> And I'm not subscribed to debian-project.
> 
> My last work it at <https://salsa.debian.org/pmhahn/grub/tree/signing>.
> In the week after the sprint I worked on GRUB2 and got it so far to have
> the signed amd64 package - so at the time of writing the sprint report
> GRUB2 was already ready.
> 
> I haven't yet found time to setup an UEFI-SB test environment to check
> that everything works.
> 
> I haven't yet tested any other architecture != amd64.
> 
> @Colin: Please have a look at said repository above.
> What I'm currently unsure about is that amd64 has those ia32 packages as
> well - it should work but also untested.
> My reading is that those are required for dual booting?
> 
> Philipp


-- 
Regards,

 Hideki Yamane     henrich @ debian.org/iijmio-mail.jp

[toc] | [prev] | [next] | [standalone]

#9911

On Tue, Jun 19, 2018 at 07:50:15AM +0900, Hideki Yamane wrote:
>  Just a ping question, is there any progress for grub2 package?
>  If not, what's the blocker for it?

I had an email conversation with Philipp Hahn about this.  The main
substance of my reply was:

  I can't easily review this as it stands because it's just so different
  from how I manage the master branch.  Could you please rebase this onto
  the master branch of the repository above?  Furthermore, could you make
  sure to use git-dpm any time you're manipulating patches against
  upstream (i.e. anything outside debian/)?  You should never need to edit
  quilt metadata in the grub2 packaging directly.  Let me know if you need
  help using git-dpm that isn't answered by the docs - I'm happy to
  advise.
  
  Once it's in a suitable shape, I'd be happy to review by way of a merge
  request on salsa.

I haven't yet heard back, so I assume it's taking Philipp a while to
sort out the rebase ...

-- 
Colin Watson                                       [cjwatson@debian.org]

[toc] | [prev] | [next] | [standalone]

#9912 — Re: UEFI Secure Boot - GRUB WIP report

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

Hello,

Am 19.06.2018 um 10:25 schrieb Colin Watson:
> On Tue, Jun 19, 2018 at 07:50:15AM +0900, Hideki Yamane wrote:
>>  Just a ping question, is there any progress for grub2 package?
>>  If not, what's the blocker for it?
> 
> I had an email conversation with Philipp Hahn about this.  The main
> substance of my reply was:
> 
>   I can't easily review this as it stands because it's just so different
>   from how I manage the master branch.  Could you please rebase this onto
>   the master branch of the repository above?  Furthermore, could you make
>   sure to use git-dpm any time you're manipulating patches against
>   upstream (i.e. anything outside debian/)?  You should never need to edit
>   quilt metadata in the grub2 packaging directly.  Let me know if you need
>   help using git-dpm that isn't answered by the docs - I'm happy to
>   advise.
>   
>   Once it's in a suitable shape, I'd be happy to review by way of a merge
>   request on salsa.
> 
> I haven't yet heard back, so I assume it's taking Philipp a while to
> sort out the rebase ...

I just worked on it yesterday and have pushed my new WIP branch to salsa
just now: <https://salsa.debian.org/pmhahn/grub/tree/signing3>

My current problem is that I wanted to test the full chain: self-signed
certificates, shim, grub, Linux kernel. It uses Qemu/KVM using OVMF with
SecureBoot.
I've attached my shell script which works on my Laptop only, as my GIT
repositories are located in many places, but maybe it's useful for other
to get started.

The good news: It works: It loads the signed SHIM and GRUB.

The bad news: GRUB still falls back to loading an unsigned Linux kernel.
I suspect
<https://salsa.debian.org/pmhahn/grub/commit/448311e7374076fbd53e4c8b0f92accd04e07920>
@Luca: Any idea?

This is on my TODO list for this week, but it's not the only one.

@Colin: Please have a look if the new branch is in a suitable shape for
your consumption. Please don't merge yet until the issue mentioned above
is resolved. Thanks.

Philipp

[toc] | [prev] | [next] | [standalone]

#9913 — Re: UEFI Secure Boot - GRUB WIP report

On Tue, Jun 19, 2018 at 11:00:44AM +0200, Philipp Hahn wrote:
> @Colin: Please have a look if the new branch is in a suitable shape for
> your consumption. Please don't merge yet until the issue mentioned above
> is resolved. Thanks.

This seems like a much better shape, thanks.  I've left a few
preliminary comments on individual commits; I'll do a more complete
review once you're at the point of having a working merge request.

-- 
Colin Watson                                       [cjwatson@debian.org]

[toc] | [prev] | [next] | [standalone]

#9972

Hi,

> We're still missing (partially or completely):
> - generate a signing template for GRUB2
> - have DAK accept those generated source-only uploads

 Grub2 support was finished, and how about DAK?
 Currently, what is the blocker for secure boot support?


-- 
Regards,

 Hideki Yamane     henrich @ debian.org/iijmio-mail.jp

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.project

csiph-web