diff for duplicates of <1521135192.5348.64.camel@HansenPartnership.com>

diff --git a/a/1.txt b/N1/1.txt
index dbfaa94..7ca279c 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -6,19 +6,19 @@ On Thu, 2018-03-15 at 11:26 -0400, Stefan Berger wrote:
 > > > 
 > > > From: Yuqiong Sun <suny@us.ibm.com>
 > > > 
-> > > Add new CONFIG_IMA_NS config option.  Let clone() create a new
+> > > Add new CONFIG_IMA_NS config option.  Let clone() create a new
 > > > IMA namespace upon CLONE_NEWNS flag. Add ima_ns data structure in
-> > > nsproxy.  ima_ns is allocated and freed upon IMA namespace
-> > > creation and exit.  Currently, the ima_ns contains no useful IMA
+> > > nsproxy.  ima_ns is allocated and freed upon IMA namespace
+> > > creation and exit.  Currently, the ima_ns contains no useful IMA
 > > > data but only a dummy interface. This patch creates the framework
 > > > for namespacing the different aspects of IMA (eg. IMA-audit, IMA-
 > > > measurement, IMA-appraisal).
-> > IMA is not path based.  The only thing that belongs to a mount
-> > namespace are paths.  Therefore IMA is completely inappropriate to
+> > IMA is not path based.  The only thing that belongs to a mount
+> > namespace are paths.  Therefore IMA is completely inappropriate to
 > > be joint with a mount namespace.
 
 Just to be clear: The mount namespace is not only about paths it's also
-about subtree properties.  However, the point still stands that IMA has
+about subtree properties.  However, the point still stands that IMA has
 a dependency on neither.
 
 > IMA measures the files described by these paths. The files also may
@@ -27,19 +27,19 @@ a dependency on neither.
 The xattr is an inode property, which isn't namespaced by the mount_ns.
 
 When we had this discussion last year, we talked about possibly using
-the user_ns instead.  It makes sense because for IMA signatures you're
+the user_ns instead.  It makes sense because for IMA signatures you're
 going to need some type of keyring namespace and there's already one
 hanging off the user_ns:
 
 commit f36f8c75ae2e7d4da34f4c908cebdb4aa42c977e
 Author: David Howells <dhowells@redhat.com>
-Date:   Tue Sep 24 10:35:19 2013 +0100
+Date:   Tue Sep 24 10:35:19 2013 +0100
 
-    KEYS: Add per-user_namespace registers for persistent per-UID
+    KEYS: Add per-user_namespace registers for persistent per-UID
 kerberos caches
 
 > > I saw that Serge even recently mentioned that you need to take
-> > this aspect of the changes back to the drawing board.  With my
+> > this aspect of the changes back to the drawing board.  With my
 > > namespace maintainer hat on I repeat that.
 > 
 > Drawing board is here now (tuning on the text...):
@@ -48,21 +48,21 @@ kerberos caches
 > ns
 
 You mention an abuse case here which is basically a way of relaxing
-security policy.  Cannot we fix that by making policy hierarchical, so
+security policy.  Cannot we fix that by making policy hierarchical, so
 a child namespace must have the same or a more strict policy than the
 parent?
 
-> >  From a 10,000 foot view I can already tell that this is hopeless.
+> >  From a 10,000 foot view I can already tell that this is hopeless.
 > > So for binding IMA namspaces and CLONE_NEWNS:
 > > 
 > > Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
 > > 
 > > I am not nacking IMA namespacing just inappropriately tying ima
-> > namespaces to mount namespaces.  These should be completely
+> > namespaces to mount namespaces.  These should be completely
 > > separate entities.
 > 
 > Let's say we go down the road of spawning it independently. Can we
-> use the unused clone flag 0x1000? Or should we come up with new 
+> use the unused clone flag 0x1000? Or should we come up with new 
 > unshare2()/clone2() syscalls to extend the clone bits to 64 bit? Or
 > use a sysfs/securityfs file to spawn a new IMA namespace? Make this a
 > generic file not an IMA specific one?
@@ -72,9 +72,3 @@ is the correct way to proceed, I'm sure we can sort out the details of
 how we cope with the flag paucity problem.
 
 James
-
-
-_______________________________________________
-Containers mailing list
-Containers@lists.linux-foundation.org
-https://lists.linuxfoundation.org/mailman/listinfo/containers
diff --git a/a/content_digest b/N1/content_digest
index 84e0008..63b81bf 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -2,23 +2,22 @@
  "ref\020180309201421.6150-2-stefanb@linux.vnet.ibm.com\0"
  "ref\087vadxfwqj.fsf@xmission.com\0"
  "ref\0c18b6e92-57f0-5994-eb60-5fadc6671832@linux.vnet.ibm.com\0"
- "ref\0c18b6e92-57f0-5994-eb60-5fadc6671832-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org\0"
- "From\0James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>\0"
+ "From\0James Bottomley <James.Bottomley@hansenpartnership.com>\0"
  "Subject\0Re: [RFC PATCH v2 1/3] ima: extend clone() with IMA namespace support\0"
  "Date\0Thu, 15 Mar 2018 10:33:12 -0700\0"
- "To\0Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>"
- " Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>\0"
- "Cc\0mkayaalp-4hyTIkVWTs8LubxHQvXPfYdd74u8MsAO@public.gmane.org"
-  Mehmet Kayaalp <mkayaalp-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
-  sunyuqiong1988-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
-  containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
-  linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  david.safford-JJi787mZWgc@public.gmane.org
-  linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  linux-ima-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
-  linux-integrity-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  Yuqiong Sun <suny-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
- " zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org\0"
+ "To\0Stefan Berger <stefanb@linux.vnet.ibm.com>"
+ " Eric W. Biederman <ebiederm@xmission.com>\0"
+ "Cc\0linux-ima-devel@lists.sourceforge.net"
+  mkayaalp@cs.binghamton.edu
+  Mehmet Kayaalp <mkayaalp@linux.vnet.ibm.com>
+  sunyuqiong1988@gmail.com
+  containers@lists.linux-foundation.org
+  linux-kernel@vger.kernel.org
+  david.safford@ge.com
+  linux-security-module@vger.kernel.org
+  linux-integrity@vger.kernel.org
+  Yuqiong Sun <suny@us.ibm.com>
+ " zohar@linux.vnet.ibm.com\0"
  "\00:1\0"
  "b\0"
  "On Thu, 2018-03-15 at 11:26 -0400, Stefan Berger wrote:\n"
@@ -29,19 +28,19 @@
  "> > > \n"
  "> > > From: Yuqiong Sun <suny@us.ibm.com>\n"
  "> > > \n"
- "> > > Add new CONFIG_IMA_NS config option.\302\240\302\240Let clone() create a new\n"
+ "> > > Add new CONFIG_IMA_NS config option.  Let clone() create a new\n"
  "> > > IMA namespace upon CLONE_NEWNS flag. Add ima_ns data structure in\n"
- "> > > nsproxy. \302\240ima_ns is allocated and freed upon IMA namespace\n"
- "> > > creation and exit. \302\240Currently, the ima_ns contains no useful IMA\n"
+ "> > > nsproxy.  ima_ns is allocated and freed upon IMA namespace\n"
+ "> > > creation and exit.  Currently, the ima_ns contains no useful IMA\n"
  "> > > data but only a dummy interface. This patch creates the framework\n"
  "> > > for namespacing the different aspects of IMA (eg. IMA-audit, IMA-\n"
  "> > > measurement, IMA-appraisal).\n"
- "> > IMA is not path based.\302\240\302\240The only thing that belongs to a mount\n"
- "> > namespace are paths.\302\240\302\240Therefore IMA is completely inappropriate to\n"
+ "> > IMA is not path based.  The only thing that belongs to a mount\n"
+ "> > namespace are paths.  Therefore IMA is completely inappropriate to\n"
  "> > be joint with a mount namespace.\n"
  "\n"
  "Just to be clear: The mount namespace is not only about paths it's also\n"
- "about subtree properties. \302\240However, the point still stands that IMA has\n"
+ "about subtree properties.  However, the point still stands that IMA has\n"
  "a dependency on neither.\n"
  "\n"
  "> IMA measures the files described by these paths. The files also may\n"
@@ -50,19 +49,19 @@
  "The xattr is an inode property, which isn't namespaced by the mount_ns.\n"
  "\n"
  "When we had this discussion last year, we talked about possibly using\n"
- "the user_ns instead. \302\240It makes sense because for IMA signatures you're\n"
+ "the user_ns instead.  It makes sense because for IMA signatures you're\n"
  "going to need some type of keyring namespace and there's already one\n"
  "hanging off the user_ns:\n"
  "\n"
  "commit f36f8c75ae2e7d4da34f4c908cebdb4aa42c977e\n"
  "Author: David Howells <dhowells@redhat.com>\n"
- "Date:\302\240\302\240\302\240Tue Sep 24 10:35:19 2013 +0100\n"
+ "Date:   Tue Sep 24 10:35:19 2013 +0100\n"
  "\n"
- "\302\240\302\240\302\240\302\240KEYS: Add per-user_namespace registers for persistent per-UID\n"
+ "    KEYS: Add per-user_namespace registers for persistent per-UID\n"
  "kerberos caches\n"
  "\n"
  "> > I saw that Serge even recently mentioned that you need to take\n"
- "> > this aspect of the changes back to the drawing board.\302\240\302\240With my\n"
+ "> > this aspect of the changes back to the drawing board.  With my\n"
  "> > namespace maintainer hat on I repeat that.\n"
  "> \n"
  "> Drawing board is here now (tuning on the text...):\n"
@@ -71,21 +70,21 @@
  "> ns\n"
  "\n"
  "You mention an abuse case here which is basically a way of relaxing\n"
- "security policy. \302\240Cannot we fix that by making policy hierarchical, so\n"
+ "security policy.  Cannot we fix that by making policy hierarchical, so\n"
  "a child namespace must have the same or a more strict policy than the\n"
  "parent?\n"
  "\n"
- "> > \302\240From a 10,000 foot view I can already tell that this is hopeless.\n"
+ "> >  From a 10,000 foot view I can already tell that this is hopeless.\n"
  "> > So for binding IMA namspaces and CLONE_NEWNS:\n"
  "> > \n"
  "> > Nacked-by: \"Eric W. Biederman\" <ebiederm@xmission.com>\n"
  "> > \n"
  "> > I am not nacking IMA namespacing just inappropriately tying ima\n"
- "> > namespaces to mount namespaces.\302\240\302\240These should be completely\n"
+ "> > namespaces to mount namespaces.  These should be completely\n"
  "> > separate entities.\n"
  "> \n"
  "> Let's say we go down the road of spawning it independently. Can we\n"
- "> use the unused clone flag 0x1000? Or should we come up with new\302\240\n"
+ "> use the unused clone flag 0x1000? Or should we come up with new \n"
  "> unshare2()/clone2() syscalls to extend the clone bits to 64 bit? Or\n"
  "> use a sysfs/securityfs file to spawn a new IMA namespace? Make this a\n"
  "> generic file not an IMA specific one?\n"
@@ -94,12 +93,6 @@
  "is the correct way to proceed, I'm sure we can sort out the details of\n"
  "how we cope with the flag paucity problem.\n"
  "\n"
- "James\n"
- "\n"
- "\n"
- "_______________________________________________\n"
- "Containers mailing list\n"
- "Containers@lists.linux-foundation.org\n"
- https://lists.linuxfoundation.org/mailman/listinfo/containers
+ James
 
-86836efdb222cfce618ae5784a0a3719e311449af760fe4faa1d23fd0b3b2675
+d40e7eed8115da492336657de28df2c3019d808d0a5d0cb625bc90e343ce94d8
