On Thu, 18 Jul 2019 15:06:55 -0400
Mathieu Trudel-Lapierre wrote:
> On Thu, Jul 18, 2019 at 10:01 AM Colin Watson
> wrote:
> > On Mon, Jul 08, 2019 at 09:15:49PM +0300, Vladislav Yarmak wrote:
> > > On Mon, 8 Jul 2019 14:57:08 +0100 Colin Watson
> > > wrote:
> [...]
>
> > > @@ -720,7 +7
On Thu, Jul 18, 2019 at 10:01 AM Colin Watson wrote:
> On Mon, Jul 08, 2019 at 09:15:49PM +0300, Vladislav Yarmak wrote:
> > On Mon, 8 Jul 2019 14:57:08 +0100 Colin Watson
> > wrote:
[...]
> > @@ -720,7 +718,16 @@ grub_cmd_linux (grub_command_t cmd __att
> > return GRUB_ERR_NONE;
On Thu, 18 Jul 2019 15:00:44 +0100
Colin Watson wrote:
> This format is difficult to review and apply, not least because later
> versions of the source package have moved on in different ways. For
> the next version, please just send a patch against
> grub-core/loader/i386/linux.c (etc.) dire
[CCing Mathieu, since this will probably interact with Ubuntu's changes
to how SB works, and has some thoughts on future direction.]
On Mon, Jul 08, 2019 at 09:15:49PM +0300, Vladislav Yarmak wrote:
> On Mon, 8 Jul 2019 14:57:08 +0100 Colin Watson
> wrote:
> > I'm not aware of anyone working on i
Hello,
Can I please have some feedback on my patch or hear back about state of
things?
--
Best Regards,
Vladislav Yarmak
On Mon, 8 Jul 2019 14:57:08 +0100 Colin Watson
wrote:
> I'm not aware of anyone working on it at the moment. I won't directly
> revert the patch that introduced this problem because doing so would
> have too much other fallout, but I'd be happy to help you if you're
> interested in working on a p
On Mon, Jul 08, 2019 at 03:24:44PM +0300, Vladislav Yarmak wrote:
> First, I should explain why I consider setup with own EFI keys and PGP
> signatures not as an exotic configuration but, rather, as the only
> feasible use of Secure Boot.
Be all that as it may, since it requires a fair amount of w
Hello,
Today I also stumbled upon this bug right after Debian 10 release.
First, I should explain why I consider setup with own EFI keys and PGP
signatures not as an exotic configuration but, rather, as the only
feasible use of Secure Boot.
Current chain consisting of UEFI SB -> shim -> grub ->
On Fri, Aug 17, 2018 at 05:46:10PM +0200, Somebody else wrote:
> On Fri, Aug 17, 2018 at 4:42 PM Colin Watson wrote:
> > No, that change was added a long time ago. The change that caused the
> > symptoms you observe was the addition of
> > debian/patches/linuxefi_disable_sb_fallback.patch.
>
> O
On Fri, Aug 17, 2018 at 4:42 PM Colin Watson wrote:
>
> On Fri, Aug 17, 2018 at 03:26:36PM +0200, Somebody else wrote:
> > Now, MY setup, which worked up to grub-efi 2.02+dfsg1-4, was such that
> > I removed all Microsoft-owned keys from my system and replaced them
> > with my own keys. Then I sig
On Fri, Aug 17, 2018 at 03:26:36PM +0200, Somebody else wrote:
> Now, MY setup, which worked up to grub-efi 2.02+dfsg1-4, was such that
> I removed all Microsoft-owned keys from my system and replaced them
> with my own keys. Then I signed a GRUB2 standalone image (created via
> grub-mkstandalone)
On Fri, Aug 17, 2018 at 2:25 PM Ian Campbell wrote:
>
> On Fri, 2018-08-17 at 10:22 +0200, Somebody else wrote:
> > Any pointers?
>
> Have you seen https://wiki.debian.org/SecureBoot ? I'm not involved in
> that effort but AIUI it describes the plan for what (and why) is going
> through at the mom
On Fri, 2018-08-17 at 10:22 +0200, Somebody else wrote:
> Any pointers?
Have you seen https://wiki.debian.org/SecureBoot ? I'm not involved in
that effort but AIUI it describes the plan for what (and why) is going
through at the moment WRT enabling secure boot out of the box in Debian
(which, also
Hi,
so reading the source code of the debian/patches included in the
latest package and enabling additional debug logging (linux and
linuxefi, specifically) yielded additional information. It seems that
my setup is now broken because the defaults were changed to require
the "shim protocol". My set
14 matches
Mail list logo
