diff for duplicates of <1525917658.3551.322.camel@linux.vnet.ibm.com> diff --git a/a/1.txt b/N1/1.txt index ad952da..6604333 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -22,7 +22,7 @@ On Wed, 2018-05-09 at 23:48 +0000, Luis R. Rodriguez wrote: > > > the wireless-regdgb maintainer's key for this file, could IMA be configured to > > > do that? > > -> > IMA has its own trusted keyring. So either the maintainer's key would +> > IMA has its own trusted keyring. ?So either the maintainer's key would > > need to be added to the IMA keyring, > > I see so we'd need this documented somehow. @@ -38,12 +38,12 @@ builtin regulatory key to its keyring or use the regdb keyring, as IMA-appraisal doesn't (yet) support detached signatures. The other option would be to include the regulatory.db signature in -the package. For rpm, the file signature is included in the RPM -header. Multiple attempts have been made to have Debian packages -include file signatures. This is the most recent attempt - https://li +the package. ?For rpm, the file signature is included in the RPM +header. ?Multiple attempts have been made to have Debian packages +include file signatures. ?This is the most recent attempt -?https://li sts.debian.org/debian-dpkg/2018/05/msg00005.html -> > > > Yes, writing regdb as a micro/mini LSM sounds reasonable. The LSM +> > > > Yes, writing regdb as a micro/mini LSM sounds reasonable. ?The LSM > > > > would differentiate between other firmware and the regulatory.db based > > > > on the firmware's pathname. > > > @@ -52,7 +52,7 @@ sts.debian.org/debian-dpkg/2018/05/msg00005.html > > > regulatory db also doesn't make much sense. > > > > All calls to request_firmware() are already going through this LSM -> > hook. I should have said, it would be based on both READING_FIRMWARE +> > hook. ?I should have said, it would be based on both READING_FIRMWARE > > and the firmware's pathname. > > Yes, but it would still be a strcmp() computation added for all @@ -76,10 +76,15 @@ Mimi > > > Its unclear to me why they can't co-exist yet and not have to touch > > > the firmware_loader code at all. > > -> > With the changes discussed above, they will co-exist. Other than the +> > With the changes discussed above, they will co-exist. ?Other than the > > Kconfig changes, I don't think it will touch the firmware_loader code. > > Great. > > Luis -> +> + +-- +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/N1/content_digest index 2f477fa..4f38b39 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -9,30 +9,10 @@ "ref\020180509212212.GX27853@wotan.suse.de\0" "ref\01525903617.3551.281.camel@linux.vnet.ibm.com\0" "ref\020180509234814.GY27853@wotan.suse.de\0" - "From\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0" - "Subject\0Re: [PATCH 3/6] firmware: differentiate between signed regulatory.db and other firmware\0" + "From\0zohar@linux.vnet.ibm.com (Mimi Zohar)\0" + "Subject\0[PATCH 3/6] firmware: differentiate between signed regulatory.db and other firmware\0" "Date\0Wed, 09 May 2018 22:00:58 -0400\0" - "To\0Luis R. Rodriguez <mcgrof@kernel.org>" - Matthew Garrett <mjg59@srcf.ucam.org> - Peter Jones <pjones@redhat.com> - AKASHI - Takahiro <takahiro.akashi@linaro.org> - " David Howells <dhowells@redhat.com>\0" - "Cc\0linux-wireless <linux-wireless@vger.kernel.org>" - Kalle Valo <kvalo@codeaurora.org> - Seth Forshee <seth.forshee@canonical.com> - Johannes Berg <johannes.berg@intel.com> - linux-integrity@vger.kernel.org - Hans de Goede <hdegoede@redhat.com> - Ard Biesheuvel <ard.biesheuvel@linaro.org> - linux-security-module@vger.kernel.org - linux-kernel@vger.kernel.org - Kees Cook <keescook@chromium.org> - Greg Kroah-Hartman <gregkh@linuxfoundation.org> - Andres Rodriguez <andresx7@gmail.com> - Linus Torvalds <torvalds@linux-foundation.org> - Andy Lutomirski <luto@kernel.org> - " Casey Schaufler <casey@schaufler-ca.com>\0" + "To\0linux-security-module@vger.kernel.org\0" "\00:1\0" "b\0" "On Wed, 2018-05-09 at 23:48 +0000, Luis R. Rodriguez wrote:\n" @@ -59,7 +39,7 @@ "> > > the wireless-regdgb maintainer's key for this file, could IMA be configured to\n" "> > > do that?\n" "> > \n" - "> > IMA has its own trusted keyring. So either the maintainer's key would\n" + "> > IMA has its own trusted keyring. ?So either the maintainer's key would\n" "> > need to be added to the IMA keyring,\n" "> \n" "> I see so we'd need this documented somehow.\n" @@ -75,12 +55,12 @@ "IMA-appraisal doesn't (yet) support detached signatures.\n" "\n" "The other option would be to include the regulatory.db signature in\n" - "the package. For rpm, the file signature is included in the RPM\n" - "header. Multiple attempts have been made to have Debian packages\n" - "include file signatures. This is the most recent attempt - https://li\n" + "the package. ?For rpm, the file signature is included in the RPM\n" + "header. ?Multiple attempts have been made to have Debian packages\n" + "include file signatures. ?This is the most recent attempt -?https://li\n" "sts.debian.org/debian-dpkg/2018/05/msg00005.html\n" "\n" - "> > > > Yes, writing regdb as a micro/mini LSM sounds reasonable. The LSM\n" + "> > > > Yes, writing regdb as a micro/mini LSM sounds reasonable. ?The LSM\n" "> > > > would differentiate between other firmware and the regulatory.db based\n" "> > > > on the firmware's pathname.\n" "> > > \n" @@ -89,7 +69,7 @@ "> > > regulatory db also doesn't make much sense.\n" "> > \n" "> > All calls to request_firmware() are already going through this LSM\n" - "> > hook. I should have said, it would be based on both READING_FIRMWARE\n" + "> > hook. ?I should have said, it would be based on both READING_FIRMWARE\n" "> > and the firmware's pathname.\n" "> \n" "> Yes, but it would still be a strcmp() computation added for all\n" @@ -113,12 +93,17 @@ "> > > Its unclear to me why they can't co-exist yet and not have to touch\n" "> > > the firmware_loader code at all.\n" "> > \n" - "> > With the changes discussed above, they will co-exist. Other than the\n" + "> > With the changes discussed above, they will co-exist. ?Other than the\n" "> > Kconfig changes, I don't think it will touch the firmware_loader code.\n" "> \n" "> Great.\n" "> \n" "> Luis\n" - > + "> \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 -cc3499eec581d5b5fdb34ccf44b4e351dbaaf34c59878fbbfeec578fda572b12 +1952cfd984668a964aa8b3d0231664a1417421304083e4181cf5d9c44d69c863
diff --git a/a/1.txt b/N2/1.txt index ad952da..d5463d6 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -22,7 +22,7 @@ On Wed, 2018-05-09 at 23:48 +0000, Luis R. Rodriguez wrote: > > > the wireless-regdgb maintainer's key for this file, could IMA be configured to > > > do that? > > -> > IMA has its own trusted keyring. So either the maintainer's key would +> > IMA has its own trusted keyring. So either the maintainer's key would > > need to be added to the IMA keyring, > > I see so we'd need this documented somehow. @@ -38,12 +38,12 @@ builtin regulatory key to its keyring or use the regdb keyring, as IMA-appraisal doesn't (yet) support detached signatures. The other option would be to include the regulatory.db signature in -the package. For rpm, the file signature is included in the RPM -header. Multiple attempts have been made to have Debian packages -include file signatures. This is the most recent attempt - https://li +the package. For rpm, the file signature is included in the RPM +header. Multiple attempts have been made to have Debian packages +include file signatures. This is the most recent attempt - https://li sts.debian.org/debian-dpkg/2018/05/msg00005.html -> > > > Yes, writing regdb as a micro/mini LSM sounds reasonable. The LSM +> > > > Yes, writing regdb as a micro/mini LSM sounds reasonable. The LSM > > > > would differentiate between other firmware and the regulatory.db based > > > > on the firmware's pathname. > > > @@ -52,7 +52,7 @@ sts.debian.org/debian-dpkg/2018/05/msg00005.html > > > regulatory db also doesn't make much sense. > > > > All calls to request_firmware() are already going through this LSM -> > hook. I should have said, it would be based on both READING_FIRMWARE +> > hook. I should have said, it would be based on both READING_FIRMWARE > > and the firmware's pathname. > > Yes, but it would still be a strcmp() computation added for all @@ -76,7 +76,7 @@ Mimi > > > Its unclear to me why they can't co-exist yet and not have to touch > > > the firmware_loader code at all. > > -> > With the changes discussed above, they will co-exist. Other than the +> > With the changes discussed above, they will co-exist. Other than the > > Kconfig changes, I don't think it will touch the firmware_loader code. > > Great. diff --git a/a/content_digest b/N2/content_digest index 2f477fa..b128bcd 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -59,7 +59,7 @@ "> > > the wireless-regdgb maintainer's key for this file, could IMA be configured to\n" "> > > do that?\n" "> > \n" - "> > IMA has its own trusted keyring. So either the maintainer's key would\n" + "> > IMA has its own trusted keyring. \302\240So either the maintainer's key would\n" "> > need to be added to the IMA keyring,\n" "> \n" "> I see so we'd need this documented somehow.\n" @@ -75,12 +75,12 @@ "IMA-appraisal doesn't (yet) support detached signatures.\n" "\n" "The other option would be to include the regulatory.db signature in\n" - "the package. For rpm, the file signature is included in the RPM\n" - "header. Multiple attempts have been made to have Debian packages\n" - "include file signatures. This is the most recent attempt - https://li\n" + "the package. \302\240For rpm, the file signature is included in the RPM\n" + "header. \302\240Multiple attempts have been made to have Debian packages\n" + "include file signatures. \302\240This is the most recent attempt -\302\240https://li\n" "sts.debian.org/debian-dpkg/2018/05/msg00005.html\n" "\n" - "> > > > Yes, writing regdb as a micro/mini LSM sounds reasonable. The LSM\n" + "> > > > Yes, writing regdb as a micro/mini LSM sounds reasonable. \302\240The LSM\n" "> > > > would differentiate between other firmware and the regulatory.db based\n" "> > > > on the firmware's pathname.\n" "> > > \n" @@ -89,7 +89,7 @@ "> > > regulatory db also doesn't make much sense.\n" "> > \n" "> > All calls to request_firmware() are already going through this LSM\n" - "> > hook. I should have said, it would be based on both READING_FIRMWARE\n" + "> > hook. \302\240I should have said, it would be based on both READING_FIRMWARE\n" "> > and the firmware's pathname.\n" "> \n" "> Yes, but it would still be a strcmp() computation added for all\n" @@ -113,7 +113,7 @@ "> > > Its unclear to me why they can't co-exist yet and not have to touch\n" "> > > the firmware_loader code at all.\n" "> > \n" - "> > With the changes discussed above, they will co-exist. Other than the\n" + "> > With the changes discussed above, they will co-exist. \302\240Other than the\n" "> > Kconfig changes, I don't think it will touch the firmware_loader code.\n" "> \n" "> Great.\n" @@ -121,4 +121,4 @@ "> Luis\n" > -cc3499eec581d5b5fdb34ccf44b4e351dbaaf34c59878fbbfeec578fda572b12 +13f77c2842a0773b3bed82059ae87f9e5469fd9b2f33d9874f8e2f4637ae8ac7
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.