diff for duplicates of <20180327110814.GC5669@linux-l9pv.suse> diff --git a/a/1.txt b/N1/1.txt index 9c72e91..1d2fc9b 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -22,7 +22,7 @@ On Mon, Mar 19, 2018 at 10:12:03AM -0400, Mimi Zohar 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 c8fc262..5ef5ddb 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -6,7 +6,7 @@ "ref\01521468723.3503.171.camel@linux.vnet.ibm.com\0" "From\0joeyli <jlee@suse.com>\0" "Subject\0Re: [PATCH 0/9] KEYS: Blacklisting & UEFI database load\0" - "Date\0Tue, 27 Mar 2018 11:08:14 +0000\0" + "Date\0Tue, 27 Mar 2018 19:08:14 +0800\0" "To\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0" "Cc\0James Bottomley <James.Bottomley@hansenpartnership.com>" Jiri Slaby <jslaby@suse.cz> @@ -42,7 +42,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" @@ -113,4 +113,4 @@ "Thanks a lot!\n" Joey Lee -2f013ef150fdffc668714c1bbb9668fe42acde52cce941e35629dcc52a60933d +5aba381d4467ab01e514bd6863fd2a2e896ebf2e790c9238a2d0dbc271313d09
diff --git a/a/1.txt b/N2/1.txt index 9c72e91..7de1ed3 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -11,7 +11,7 @@ On Mon, Mar 19, 2018 at 10:12:03AM -0400, Mimi Zohar 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). > > > @@ -22,13 +22,13 @@ On Mon, Mar 19, 2018 at 10:12:03AM -0400, Mimi Zohar 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. > @@ -43,9 +43,9 @@ enabled without physical accessing. > > > > 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? > > > > > @@ -60,8 +60,8 @@ enabled without physical accessing. > > 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.) > @@ -82,7 +82,7 @@ Could you please provide more detail for those methods? Thanks! > > 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? > @@ -91,4 +91,8 @@ currently the only solution for general EFI firmware. Or you have other solution can be used for all architectures? Thanks a lot! -Joey Lee +Joey Lee +-- +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 c8fc262..3b50736 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -4,18 +4,10 @@ "ref\01520436517.5558.2.camel@HansenPartnership.com\0" "ref\020180311032022.GA31059@linux-l9pv.suse\0" "ref\01521468723.3503.171.camel@linux.vnet.ibm.com\0" - "From\0joeyli <jlee@suse.com>\0" - "Subject\0Re: [PATCH 0/9] KEYS: Blacklisting & UEFI database load\0" - "Date\0Tue, 27 Mar 2018 11:08:14 +0000\0" - "To\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0" - "Cc\0James Bottomley <James.Bottomley@hansenpartnership.com>" - Jiri 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\0jlee@suse.com (joeyli)\0" + "Subject\0[PATCH 0/9] KEYS: Blacklisting & UEFI database load\0" + "Date\0Tue, 27 Mar 2018 19:08:14 +0800\0" + "To\0linux-security-module@vger.kernel.org\0" "\00:1\0" "b\0" "Hi Mimi,\n" @@ -31,7 +23,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" @@ -42,13 +34,13 @@ "> > 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" "\n" @@ -63,9 +55,9 @@ "> > > > 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" @@ -80,8 +72,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" "\n" @@ -102,7 +94,7 @@ "> > 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" "\n" @@ -111,6 +103,10 @@ "solution can be used for all architectures?\n" "\n" "Thanks a lot!\n" - Joey Lee + "Joey Lee \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 -2f013ef150fdffc668714c1bbb9668fe42acde52cce941e35629dcc52a60933d +d2fdb62ba22e50b033cdaf318d6aa34bd1a40ec5d4dc132b65eff0d4fba99c2e
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.