diff for duplicates of <1500204359.3583.126.camel@linux.vnet.ibm.com>

diff --git a/a/1.txt b/N1/1.txt
index 930a85c..ba69694 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -4,19 +4,19 @@ On Fri, 2017-07-14 at 19:02 -0500, Eric W. Biederman wrote:
 > > On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote:
 > >> "Serge E. Hallyn" <serge@hallyn.com> writes:
 > >> 
-> >> > Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
+> >> > Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):
 > >> >> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
-> >> >> >Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
+> >> >> >Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):
 > >> >> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
 > >> >> >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
 > >> >> >>>
 > >> >> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
 > >> >> >>>>
 > >> >> >>>>>My big question right now is can you implement Ted's suggested
-> >> >> >>>>>restriction.  Only one security.foo or secuirty.foo@... attribute ?
+> >> >> >>>>>restriction.  Only one security.foo or secuirty.foo at ... attribute ?
 > >> >> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
 > >> >> >>>>
-> >> >> >>>>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
+> >> >> >>>>So now you want to allow security.foo and one security.foo at uid=<> or just a single one security.foo(@[[:print:]]*)?
 > >> >> >>>>
 > >> >> >>>The latter.
 > >> >> >>That case would prevent a container user from overriding the xattr
@@ -33,7 +33,7 @@ On Fri, 2017-07-14 at 19:02 -0500, Eric W. Biederman wrote:
 > >> >> need to get rid of security.ima first, possibly by copying each
 > >> >> file, deleting the original file, and renaming the copied file to
 > >> >> the original name, or should I just be able to write out a new
-> >> >> signature, thus creating security.ima@uid=1000 besides the
+> >> >> signature, thus creating security.ima at uid=1000 besides the
 > >> >> security.ima ?
 > >> >> 
 > >> >>    Stefan
@@ -56,7 +56,7 @@ On Fri, 2017-07-14 at 19:02 -0500, Eric W. Biederman wrote:
 > > xattrs and other file metadata. (file meta-data)
 > >
 > > The same rules would apply to security.evm, as described in my
-> > response.  Based on it's view of the security xattrs, either the
+> > response. ?Based on it's view of the security xattrs, either the
 > > native or namespace security.evm would be updated.
 > >
 > >> If there is an attribute with a simple file hash I think it only make
@@ -64,8 +64,8 @@ On Fri, 2017-07-14 at 19:02 -0500, Eric W. Biederman wrote:
 > >> multiples.
 > >
 > > Only files that are in the IMA-appraisal policy is the file hash
-> > calculated and written out as security.ima.  Depending this policy,
-> > does the security.ima exist.  So if the file is in policy for both the
+> > calculated and written out as security.ima. ?Depending this policy,
+> > does the security.ima exist. ?So if the file is in policy for both the
 > > native and namespace policies, agreed the same hash doesn't need to be
 > > written as two different xattrs.
 > >
@@ -104,7 +104,7 @@ On Fri, 2017-07-14 at 19:02 -0500, Eric W. Biederman wrote:
 > >> evm content.
 > >
 > > We need to resolve the xattr issue in order to namespace IMA-
-> > appraisal. 
+> > appraisal.?
 > 
 > 
 > Mimi I have two questions:
@@ -127,13 +127,13 @@ determines whether the measurement exists in the native, the
 container, or both measurement lists.
 
 One of the main namespacing use cases for IMA-appraisal is the ability
-to limit running an executable to a particular container.  So unlike
+to limit running an executable to a particular container. ?So unlike
 IMA-measurement, which is hierarchical, the IMA-appraisal namespace
 policy takes precedence over the native policy.
 
 Mimi
 
-_______________________________________________
-Containers mailing list
-Containers@lists.linux-foundation.org
-https://lists.linuxfoundation.org/mailman/listinfo/containers
+--
+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 2fe7534..f28102f 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -12,19 +12,10 @@
  "ref\0xagsmtp2.20170714182525.6604@vmsdvm4.vnet.ibm.com\0"
  "ref\01500060374.3583.57.camel@linux.vnet.ibm.com\0"
  "ref\0xagsmtp3.20170715001054.9173@uk1vsc.vnet.ibm.com\0"
- "ref\0xagsmtp3.20170715001054.9173-17CmTKLGOXFpnrxNGchxj0EOCMrvLtNR@public.gmane.org\0"
- "From\0Mimi Zohar <zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>\0"
- "Subject\0Re: [PATCH v2] xattr: Enable security.capability in user namespaces\0"
+ "From\0zohar@linux.vnet.ibm.com (Mimi Zohar)\0"
+ "Subject\0[PATCH v2] xattr: Enable security.capability in user namespaces\0"
  "Date\0Sun, 16 Jul 2017 07:25:59 -0400\0"
- "To\0Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>\0"
- "Cc\0Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org>"
-  Mimi Zohar <zohar-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
-  containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
-  linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org
-  linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  casey-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org
- " lkp-JC7UmRfGjtg@public.gmane.org\0"
+ "To\0linux-security-module@vger.kernel.org\0"
  "\00:1\0"
  "b\0"
  "On Fri, 2017-07-14 at 19:02 -0500, Eric W. Biederman wrote:\n"
@@ -33,19 +24,19 @@
  "> > On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote:\n"
  "> >> \"Serge E. Hallyn\" <serge@hallyn.com> writes:\n"
  "> >> \n"
- "> >> > Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):\n"
+ "> >> > Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):\n"
  "> >> >> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:\n"
- "> >> >> >Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):\n"
+ "> >> >> >Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):\n"
  "> >> >> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:\n"
  "> >> >> >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:\n"
  "> >> >> >>>\n"
  "> >> >> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:\n"
  "> >> >> >>>>\n"
  "> >> >> >>>>>My big question right now is can you implement Ted's suggested\n"
- "> >> >> >>>>>restriction.  Only one security.foo or secuirty.foo@... attribute ?\n"
+ "> >> >> >>>>>restriction.  Only one security.foo or secuirty.foo at ... attribute ?\n"
  "> >> >> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.\n"
  "> >> >> >>>>\n"
- "> >> >> >>>>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?\n"
+ "> >> >> >>>>So now you want to allow security.foo and one security.foo at uid=<> or just a single one security.foo(@[[:print:]]*)?\n"
  "> >> >> >>>>\n"
  "> >> >> >>>The latter.\n"
  "> >> >> >>That case would prevent a container user from overriding the xattr\n"
@@ -62,7 +53,7 @@
  "> >> >> need to get rid of security.ima first, possibly by copying each\n"
  "> >> >> file, deleting the original file, and renaming the copied file to\n"
  "> >> >> the original name, or should I just be able to write out a new\n"
- "> >> >> signature, thus creating security.ima@uid=1000 besides the\n"
+ "> >> >> signature, thus creating security.ima at uid=1000 besides the\n"
  "> >> >> security.ima ?\n"
  "> >> >> \n"
  "> >> >>    Stefan\n"
@@ -85,7 +76,7 @@
  "> > xattrs and other file metadata. (file meta-data)\n"
  "> >\n"
  "> > The same rules would apply to security.evm, as described in my\n"
- "> > response. \302\240Based on it's view of the security xattrs, either the\n"
+ "> > response. ?Based on it's view of the security xattrs, either the\n"
  "> > native or namespace security.evm would be updated.\n"
  "> >\n"
  "> >> If there is an attribute with a simple file hash I think it only make\n"
@@ -93,8 +84,8 @@
  "> >> multiples.\n"
  "> >\n"
  "> > Only files that are in the IMA-appraisal policy is the file hash\n"
- "> > calculated and written out as security.ima. \302\240Depending this policy,\n"
- "> > does the security.ima exist. \302\240So if the file is in policy for both the\n"
+ "> > calculated and written out as security.ima. ?Depending this policy,\n"
+ "> > does the security.ima exist. ?So if the file is in policy for both the\n"
  "> > native and namespace policies, agreed the same hash doesn't need to be\n"
  "> > written as two different xattrs.\n"
  "> >\n"
@@ -133,7 +124,7 @@
  "> >> evm content.\n"
  "> >\n"
  "> > We need to resolve the xattr issue in order to namespace IMA-\n"
- "> > appraisal.\302\240\n"
+ "> > appraisal.?\n"
  "> \n"
  "> \n"
  "> Mimi I have two questions:\n"
@@ -156,15 +147,15 @@
  "container, or both measurement lists.\n"
  "\n"
  "One of the main namespacing use cases for IMA-appraisal is the ability\n"
- "to limit running an executable to a particular container. \302\240So unlike\n"
+ "to limit running an executable to a particular container. ?So unlike\n"
  "IMA-measurement, which is hierarchical, the IMA-appraisal namespace\n"
  "policy takes precedence over the native policy.\n"
  "\n"
  "Mimi\n"
  "\n"
- "_______________________________________________\n"
- "Containers mailing list\n"
- "Containers@lists.linux-foundation.org\n"
- https://lists.linuxfoundation.org/mailman/listinfo/containers
+ "--\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
 
-57f17ae6e77ac495e9eed4ad25eaad647a579f7a48ee1aad8e176a530856caa0
+306d583fe25f3ba136b77918d58c254030ec607d0edbaae499dfb022208c5c81
