On 2020-08-06 21:49:06 +0200 (+0200), Sven Bartscher wrote:
> Am Thu, 6 Aug 2020 17:24:08 +
> schrieb Jeremy Stanley :
>
> > The idea is that UEFI/BIOS checks the signature for GRUB before
> > executing it, and does so instructing GRUB to verify the signature
> > for its config. GRUB then chec
Hi,
Am Thu, 6 Aug 2020 17:24:08 +
schrieb Jeremy Stanley :
> The idea is that UEFI/BIOS checks the signature for GRUB before
> executing it, and does so instructing GRUB to verify the signature
> for its config. GRUB then checks the signatures on the kernel and
> initrd before handing off con
On 2020-08-06 08:04:56 +0100 (+0100), Nikolaus Rath wrote:
> On Aug 05 2020, Jeremy Stanley wrote:
> > On 2020-08-05 20:30:59 +0100 (+0100), Nikolaus Rath wrote:
> >> On Aug 04 2020, Jeremy Stanley wrote:
> >> > Okay, so for systems to which a malicious party may gain physical
> >> > access (or r
On Aug 05 2020, Jeremy Stanley wrote:
> On 2020-08-05 20:30:59 +0100 (+0100), Nikolaus Rath wrote:
>> On Aug 04 2020, Jeremy Stanley wrote:
>> > Okay, so for systems to which a malicious party may gain physical
>> > access (or remote console access) there's sort of a third risk this
>> > addresse
On 2020-08-05 20:30:59 +0100 (+0100), Nikolaus Rath wrote:
> On Aug 04 2020, Jeremy Stanley wrote:
> > Okay, so for systems to which a malicious party may gain physical
> > access (or remote console access) there's sort of a third risk this
> > addresses. A special case of the second risk really.
On Aug 04 2020, Jeremy Stanley wrote:
> Okay, so for systems to which a malicious party may gain physical
> access (or remote console access) there's sort of a third risk this
> addresses. A special case of the second risk really. *If* you're
> also encrypting the filesystem on which that signing
Hi,
On Tue, 4 Aug 2020 12:31:04 +
Jeremy Stanley wrote:
> Okay, so for systems to which a malicious party may gain physical
> access (or remote console access) there's sort of a third risk this
> addresses. A special case of the second risk really. *If* you're
> also encrypting the filesyste
Hey,
Jeremy Stanley:
> Okay, so for systems to which a malicious party may gain physical
> access (or remote console access) there's sort of a third risk this
> addresses. A special case of the second risk really. *If* you're
> also encrypting the filesystem on which that signing key resides
> (vi
On Tue, 2020-08-04 at 12:31 +, Jeremy Stanley wrote:
> On 2020-08-04 13:52:04 +0200 (+0200), Thomas Goirand wrote:
> > A few months ago, it took me a long long time to figure out how to do
> > this and write it in this wiki page:
> > https://wiki.debian.org/SecureBoot#MOK_-_Machine_Owner_Key
>
On 2020-08-04 13:52:04 +0200 (+0200), Thomas Goirand wrote:
> A few months ago, it took me a long long time to figure out how to do
> this and write it in this wiki page:
> https://wiki.debian.org/SecureBoot#MOK_-_Machine_Owner_Key
>
> This works very well, but I wonder if we could automate this b
Hi,
A few months ago, it took me a long long time to figure out how to do
this and write it in this wiki page:
https://wiki.debian.org/SecureBoot#MOK_-_Machine_Owner_Key
This works very well, but I wonder if we could automate this by having a
hook in DKMS, so that any DKMS rebuild would also sign
11 matches
Mail list logo
