diff for duplicates of <1521468723.3503.171.camel@linux.vnet.ibm.com> diff --git a/a/1.txt b/N1/1.txt index 44abdd0..7dfe581 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -19,7 +19,7 @@ On Sun, 2018-03-11 at 11:20 +0800, joeyli wrote: > Josh Boyer's "MODSIGN: Allow the "db" UEFI variable to be suppressed" > patch checks MokIgnoreDB variable to ignore db: > -> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=keys-uefi&id|395b30a33a617c5cc2cdd419300af71277b79a +> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=keys-uefi&id=7c395b30a33a617c5cc2cdd419300af71277b79a > > I think that we can consider to use MokAllowDB. Which means that kernel > ignores DB by default. diff --git a/a/content_digest b/N1/content_digest index f869e6b..ad9312f 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -5,7 +5,7 @@ "ref\020180311032022.GA31059@linux-l9pv.suse\0" "From\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0" "Subject\0Re: [PATCH 0/9] KEYS: Blacklisting & UEFI database load\0" - "Date\0Mon, 19 Mar 2018 14:12:03 +0000\0" + "Date\0Mon, 19 Mar 2018 10:12:03 -0400\0" "To\0joeyli <jlee@suse.com>" " James Bottomley <James.Bottomley@hansenpartnership.com>\0" "Cc\0Jiri Slaby <jslaby@suse.cz>" @@ -38,7 +38,7 @@ "> Josh Boyer's \"MODSIGN: Allow the \"db\" UEFI variable to be suppressed\"\n" "> patch checks MokIgnoreDB variable to ignore db:\n" "> \n" - "> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=keys-uefi&id|395b30a33a617c5cc2cdd419300af71277b79a\n" + "> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=keys-uefi&id=7c395b30a33a617c5cc2cdd419300af71277b79a\n" "> \n" "> I think that we can consider to use MokAllowDB. Which means that kernel\n" "> ignores DB by default.\n" @@ -91,4 +91,4 @@ "\n" Mimi -8bbe7aaaea3c535e0a7ce14b7862f57a2726763a2e01eb6c01c836becb5d0dfc +3577c7730c948a3ef05aadbf5fd28f9ea529e683ade5ed1a86e7df19a91b93aa
diff --git a/a/1.txt b/N2/1.txt index 44abdd0..8a6e9f3 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -8,7 +8,7 @@ On Sun, 2018-03-11 at 11:20 +0800, joeyli wrote: > > > > to resend the PR to have this merged? > > [...] > > > Just because I trust the platform keys prior to booting the kernel, -> > > doesn't mean that I *want* to trust those keys once booted. There +> > > doesn't mean that I *want* to trust those keys once booted. ?There > > > are, however, places where we need access to those keys to verify a > > > signature (eg. kexec kernel image). > > @@ -19,21 +19,21 @@ On Sun, 2018-03-11 at 11:20 +0800, joeyli wrote: > Josh Boyer's "MODSIGN: Allow the "db" UEFI variable to be suppressed" > patch checks MokIgnoreDB variable to ignore db: > -> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=keys-uefi&id|395b30a33a617c5cc2cdd419300af71277b79a +> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=keys-uefi&id=7c395b30a33a617c5cc2cdd419300af71277b79a > > I think that we can consider to use MokAllowDB. Which means that kernel > ignores DB by default. -Not all systems have a shim layer. This design is really x86 -specific. Allowing shim keys, but ignoring DB, does not address those +Not all systems have a shim layer.??This design is really x86 +specific.??Allowing shim keys, but ignoring DB, does not address those systems. > > > Nayna Jain's "certs: define a trusted platform keyring" patch set > > > introduces a new, separate keyring for these platform keys. > > -> > Perhaps, to break the deadlock, we should ask Jiří what the reason is -> > the distros want these keys to be trusted. Apart from the Microsoft -> > key, it will also give you an OEM key in your trusted keyring. Is it +> > Perhaps, to break the deadlock, we should ask Ji?? what the reason is +> > the distros want these keys to be trusted. ?Apart from the Microsoft +> > key, it will also give you an OEM key in your trusted keyring. ?Is it > > something to do with OEM supplied modules? > > > @@ -48,8 +48,8 @@ systems. > face to mokmanager UI. The reason for trusting enrolled shim keys is because it requires -physical presence. (I kind of remember hearing that this changed. - There is some method of accepting enrolled keys that does not require +physical presence. ?(I kind of remember hearing that this changed. +?There is some method of accepting enrolled keys that does not require physical presence.) > - The db is a authenticated variable, it's still secure when secure @@ -67,7 +67,12 @@ physical presence.) > in db by default. Between requiring a shim layer and relying on physical presence, I'm -not convinced this is the best solution. Do we really want to support +not convinced this is the best solution. ?Do we really want to support different methods for different architectures? Mimi + +-- +To unsubscribe from this list: send the line "unsubscribe linux-security-module" in +the body of a message to majordomo at vger.kernel.org +More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N2/content_digest index f869e6b..dbef17c 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -3,18 +3,10 @@ "ref\01520428682.10396.445.camel@linux.vnet.ibm.com\0" "ref\01520436517.5558.2.camel@HansenPartnership.com\0" "ref\020180311032022.GA31059@linux-l9pv.suse\0" - "From\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0" - "Subject\0Re: [PATCH 0/9] KEYS: Blacklisting & UEFI database load\0" - "Date\0Mon, 19 Mar 2018 14:12:03 +0000\0" - "To\0joeyli <jlee@suse.com>" - " James Bottomley <James.Bottomley@hansenpartnership.com>\0" - "Cc\0Jiri Slaby <jslaby@suse.cz>" - David Howells <dhowells@redhat.com> - keyrings@vger.kernel.org - matthew.garrett@nebula.com - linux-security-module@vger.kernel.org - linux-efi@vger.kernel.org - " linux-kernel@vger.kernel.org\0" + "From\0zohar@linux.vnet.ibm.com (Mimi Zohar)\0" + "Subject\0[PATCH 0/9] KEYS: Blacklisting & UEFI database load\0" + "Date\0Mon, 19 Mar 2018 10:12:03 -0400\0" + "To\0linux-security-module@vger.kernel.org\0" "\00:1\0" "b\0" "On Sun, 2018-03-11 at 11:20 +0800, joeyli wrote:\n" @@ -27,7 +19,7 @@ "> > > > to resend the PR to have this merged?\n" "> > [...]\n" "> > > Just because I trust the platform keys prior to booting the kernel,\n" - "> > > doesn't mean that I *want* to trust those keys once booted. \302\240There\n" + "> > > doesn't mean that I *want* to trust those keys once booted. ?There\n" "> > > are, however, places where we need access to those keys to verify a\n" "> > > signature (eg. kexec kernel image).\n" "> > \n" @@ -38,21 +30,21 @@ "> Josh Boyer's \"MODSIGN: Allow the \"db\" UEFI variable to be suppressed\"\n" "> patch checks MokIgnoreDB variable to ignore db:\n" "> \n" - "> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=keys-uefi&id|395b30a33a617c5cc2cdd419300af71277b79a\n" + "> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=keys-uefi&id=7c395b30a33a617c5cc2cdd419300af71277b79a\n" "> \n" "> I think that we can consider to use MokAllowDB. Which means that kernel\n" "> ignores DB by default.\n" "\n" - "Not all systems have a shim layer.\302\240\302\240This design is really x86\n" - "specific.\302\240\302\240Allowing shim keys, but ignoring DB, does not address those\n" + "Not all systems have a shim layer.??This design is really x86\n" + "specific.??Allowing shim keys, but ignoring DB, does not address those\n" "systems.\n" "\n" "> > > Nayna Jain's \"certs: define a trusted platform keyring\" patch set\n" "> > > introduces a new, separate keyring for these platform keys.\n" "> > \n" - "> > Perhaps, to break the deadlock, we should ask Ji\305\231\303\255 what the reason is\n" - "> > the distros want these keys to be trusted. \302\240Apart from the Microsoft\n" - "> > key, it will also give you an OEM key in your trusted keyring. \302\240Is it\n" + "> > Perhaps, to break the deadlock, we should ask Ji?? what the reason is\n" + "> > the distros want these keys to be trusted. ?Apart from the Microsoft\n" + "> > key, it will also give you an OEM key in your trusted keyring. ?Is it\n" "> > something to do with OEM supplied modules?\n" "> >\n" "> \n" @@ -67,8 +59,8 @@ "> face to mokmanager UI. \n" "\n" "The reason for trusting enrolled shim keys is because it requires\n" - "physical presence. \302\240(I kind of remember hearing that this changed.\n" - "\302\240There is some method of accepting enrolled keys that does not require\n" + "physical presence. ?(I kind of remember hearing that this changed.\n" + "?There is some method of accepting enrolled keys that does not require\n" "physical presence.)\n" "\n" "> - The db is a authenticated variable, it's still secure when secure\n" @@ -86,9 +78,14 @@ "> in db by default.\n" "\n" "Between requiring a shim layer and relying on physical presence, I'm\n" - "not convinced this is the best solution. \302\240Do we really want to support\n" + "not convinced this is the best solution. ?Do we really want to support\n" "different methods for different architectures?\n" "\n" - Mimi + "Mimi\n" + "\n" + "--\n" + "To unsubscribe from this list: send the line \"unsubscribe linux-security-module\" in\n" + "the body of a message to majordomo at vger.kernel.org\n" + More majordomo info at http://vger.kernel.org/majordomo-info.html -8bbe7aaaea3c535e0a7ce14b7862f57a2726763a2e01eb6c01c836becb5d0dfc +d8f595bf0682bd7db05d9629b47d365e276f1bd8bbaadaa69f84d9a2210b017c
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.