All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <1519135329.3736.88.camel@linux.vnet.ibm.com>

diff --git a/a/1.txt b/N1/1.txt
index 66ced7b..f4349ac 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -48,7 +48,7 @@ On Mon, 2018-02-19 at 20:02 -0600, Eric W. Biederman wrote:
 > Now that might be better called SB_I_IMA_UNVERIFIABLE_SIGNATURES.
 
 The file signatures are always unverifiable, whether it is mounted by
-root or an unprivileged user.  This flag would always be set.
+root or an unprivileged user. ?This flag would always be set.
 
 > We may want to complement that flag with SB_I_UNTRUSTED_MOUNTER.
 > For the times when it is not the global root user who mounts
@@ -66,12 +66,12 @@ Agreed
 > configuration that IMA has a reasonable expectation of seeing all of
 > the changes it would be nice if we can say please trust this mount.
 
-IMA has no way of detecting file change.  This was one of the reasons
+IMA has no way of detecting file change. ?This was one of the reasons
 for the original patch set's not using the cached IMA results.
 
 Even in the case of a trusted mounter and not using IMA cached
 results, there are no guarantees that the data read to calculate the
-file hash, will be the same as what is subsequently read.  In some
+file hash, will be the same as what is subsequently read. ?In some
 environments this might be an acceptable risk, while in others not.
 
 > It would also be nice if I could provide all of this information at
@@ -80,8 +80,13 @@ environments this might be an acceptable risk, while in others not.
 > am mounting a filesystem.
 
 The latest version of this patch relies on a builtin IMA policy to set
-a flag.  No other changes are required to the IMA policy.  This
+a flag. ?No other changes are required to the IMA policy. ?This
 builtin policy could be used for environments not willing to accept
 the default unverifiable signature risk.
 
 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/N1/content_digest
index cc3de0a..ef58517 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -3,19 +3,10 @@
  "ref\087zi44mz26.fsf@xmission.com\0"
  "ref\0alpine.LRH.2.21.1802201152240.883@namei.org\0"
  "ref\087tvucifji.fsf@xmission.com\0"
- "From\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0"
- "Subject\0Re: [PATCH v1 1/2] ima: fail signature verification on untrusted filesystems\0"
+ "From\0zohar@linux.vnet.ibm.com (Mimi Zohar)\0"
+ "Subject\0[PATCH v1 1/2] ima: fail signature verification on untrusted filesystems\0"
  "Date\0Tue, 20 Feb 2018 09:02:09 -0500\0"
- "To\0Eric W. Biederman <ebiederm@xmission.com>"
- " James Morris <jmorris@namei.org>\0"
- "Cc\0linux-integrity@vger.kernel.org"
-  linux-security-module@vger.kernel.org
-  linux-fsdevel@vger.kernel.org
-  Miklos Szeredi <miklos@szeredi.hu>
-  Seth Forshee <seth.forshee@canonical.com>
-  Dongsu Park <dongsu@kinvolk.io>
-  Alban Crequy <alban@kinvolk.io>
- " Serge E . Hallyn <serge@hallyn.com>\0"
+ "To\0linux-security-module@vger.kernel.org\0"
  "\00:1\0"
  "b\0"
  "On Mon, 2018-02-19 at 20:02 -0600, Eric W. Biederman wrote:\n"
@@ -68,7 +59,7 @@
  "> Now that might be better called SB_I_IMA_UNVERIFIABLE_SIGNATURES.\n"
  "\n"
  "The file signatures are always unverifiable, whether it is mounted by\n"
- "root or an unprivileged user.  This flag would always be set.\n"
+ "root or an unprivileged user. ?This flag would always be set.\n"
  "\n"
  "> We may want to complement that flag with SB_I_UNTRUSTED_MOUNTER.\n"
  "> For the times when it is not the global root user who mounts\n"
@@ -86,12 +77,12 @@
  "> configuration that IMA has a reasonable expectation of seeing all of\n"
  "> the changes it would be nice if we can say please trust this mount.\n"
  "\n"
- "IMA has no way of detecting file change.  This was one of the reasons\n"
+ "IMA has no way of detecting file change. ?This was one of the reasons\n"
  "for the original patch set's not using the cached IMA results.\n"
  "\n"
  "Even in the case of a trusted mounter and not using IMA cached\n"
  "results, there are no guarantees that the data read to calculate the\n"
- "file hash, will be the same as what is subsequently read.  In some\n"
+ "file hash, will be the same as what is subsequently read. ?In some\n"
  "environments this might be an acceptable risk, while in others not.\n"
  "\n"
  "> It would also be nice if I could provide all of this information at\n"
@@ -100,10 +91,15 @@
  "> am mounting a filesystem.\n"
  "\n"
  "The latest version of this patch relies on a builtin IMA policy to set\n"
- "a flag.  No other changes are required to the IMA policy.  This\n"
+ "a flag. ?No other changes are required to the IMA policy. ?This\n"
  "builtin policy could be used for environments not willing to accept\n"
  "the default unverifiable signature risk.\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
 
-fb984dfe042a252726c1a9b677a4942f93ab12501abf1b803483a8008a673934
+c519b44d6b8bfd50c8bf2a83d881b9544a24b6e1003d1f0ad8d15d806bad6e95

diff --git a/a/1.txt b/N2/1.txt
index 66ced7b..14b3262 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -48,7 +48,7 @@ On Mon, 2018-02-19 at 20:02 -0600, Eric W. Biederman wrote:
 > Now that might be better called SB_I_IMA_UNVERIFIABLE_SIGNATURES.
 
 The file signatures are always unverifiable, whether it is mounted by
-root or an unprivileged user.  This flag would always be set.
+root or an unprivileged user.  This flag would always be set.
 
 > We may want to complement that flag with SB_I_UNTRUSTED_MOUNTER.
 > For the times when it is not the global root user who mounts
@@ -66,12 +66,12 @@ Agreed
 > configuration that IMA has a reasonable expectation of seeing all of
 > the changes it would be nice if we can say please trust this mount.
 
-IMA has no way of detecting file change.  This was one of the reasons
+IMA has no way of detecting file change.  This was one of the reasons
 for the original patch set's not using the cached IMA results.
 
 Even in the case of a trusted mounter and not using IMA cached
 results, there are no guarantees that the data read to calculate the
-file hash, will be the same as what is subsequently read.  In some
+file hash, will be the same as what is subsequently read.  In some
 environments this might be an acceptable risk, while in others not.
 
 > It would also be nice if I could provide all of this information at
@@ -80,7 +80,7 @@ environments this might be an acceptable risk, while in others not.
 > am mounting a filesystem.
 
 The latest version of this patch relies on a builtin IMA policy to set
-a flag.  No other changes are required to the IMA policy.  This
+a flag.  No other changes are required to the IMA policy.  This
 builtin policy could be used for environments not willing to accept
 the default unverifiable signature risk.
 
diff --git a/a/content_digest b/N2/content_digest
index cc3de0a..a67d504 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -68,7 +68,7 @@
  "> Now that might be better called SB_I_IMA_UNVERIFIABLE_SIGNATURES.\n"
  "\n"
  "The file signatures are always unverifiable, whether it is mounted by\n"
- "root or an unprivileged user.  This flag would always be set.\n"
+ "root or an unprivileged user. \302\240This flag would always be set.\n"
  "\n"
  "> We may want to complement that flag with SB_I_UNTRUSTED_MOUNTER.\n"
  "> For the times when it is not the global root user who mounts\n"
@@ -86,12 +86,12 @@
  "> configuration that IMA has a reasonable expectation of seeing all of\n"
  "> the changes it would be nice if we can say please trust this mount.\n"
  "\n"
- "IMA has no way of detecting file change.  This was one of the reasons\n"
+ "IMA has no way of detecting file change. \302\240This was one of the reasons\n"
  "for the original patch set's not using the cached IMA results.\n"
  "\n"
  "Even in the case of a trusted mounter and not using IMA cached\n"
  "results, there are no guarantees that the data read to calculate the\n"
- "file hash, will be the same as what is subsequently read.  In some\n"
+ "file hash, will be the same as what is subsequently read. \302\240In some\n"
  "environments this might be an acceptable risk, while in others not.\n"
  "\n"
  "> It would also be nice if I could provide all of this information at\n"
@@ -100,10 +100,10 @@
  "> am mounting a filesystem.\n"
  "\n"
  "The latest version of this patch relies on a builtin IMA policy to set\n"
- "a flag.  No other changes are required to the IMA policy.  This\n"
+ "a flag. \302\240No other changes are required to the IMA policy. \302\240This\n"
  "builtin policy could be used for environments not willing to accept\n"
  "the default unverifiable signature risk.\n"
  "\n"
  Mimi
 
-fb984dfe042a252726c1a9b677a4942f93ab12501abf1b803483a8008a673934
+47f1eb07845318bcb1c3c732fb0a7235d0f37d5970671e5b00099acec9531d0b

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.