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

diff --git a/a/1.txt b/N1/1.txt
index a73f8ab..cee9333 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -3,8 +3,8 @@ On Fri, 2017-07-14 at 15:29 -0400, Theodore Ts'o wrote:
 > > 
 > > If I'm understanding the discussion correctly, this isn't an issue for
 > > layered copy on write filesystems, as each fs layer could have it's
-> > own set of xattrs.  The underlying and layered xattrs should be able
-> > to co-exist.  Use the layered xattr if it exists, but fall back to
+> > own set of xattrs. ?The underlying and layered xattrs should be able
+> > to co-exist. ?Use the layered xattr if it exists, but fall back to
 > > using the underlying xattr if it doesn't.
 > 
 > Note that this assumes that it is possible to "copy up" the xattrs
@@ -15,13 +15,13 @@ On Fri, 2017-07-14 at 15:29 -0400, Theodore Ts'o wrote:
 Ok, so for the use case scneario where the container owner is willing
 to use the public key distributed with the files, then only those
 files that are new or modified in the overlay would need to be signed
-with a key local to the overlay.  In the worst case scenario, where
+with a key local to the overlay. ?In the worst case scenario, where
 the container owner is only willing to trust their own public key, I
 guess we can live with having to copy up the files.
 
 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 b5640a9..a2d2fb2 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -9,19 +9,10 @@
  "ref\020170714173556.GA19669@mail.hallyn.com\0"
  "ref\01500058090.3583.28.camel@linux.vnet.ibm.com\0"
  "ref\020170714192909.zoxnlm32nrxguqao@thunk.org\0"
- "ref\020170714192909.zoxnlm32nrxguqao-AKGzg7BKzIDYtjvyW6yDsg@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\0Fri, 14 Jul 2017 15:43:46 -0400\0"
- "To\0Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org>\0"
- "Cc\0Mimi 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
-  Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@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 15:29 -0400, Theodore Ts'o wrote:\n"
@@ -29,8 +20,8 @@
  "> > \n"
  "> > If I'm understanding the discussion correctly, this isn't an issue for\n"
  "> > layered copy on write filesystems, as each fs layer could have it's\n"
- "> > own set of xattrs. \302\240The underlying and layered xattrs should be able\n"
- "> > to co-exist. \302\240Use the layered xattr if it exists, but fall back to\n"
+ "> > own set of xattrs. ?The underlying and layered xattrs should be able\n"
+ "> > to co-exist. ?Use the layered xattr if it exists, but fall back to\n"
  "> > using the underlying xattr if it doesn't.\n"
  "> \n"
  "> Note that this assumes that it is possible to \"copy up\" the xattrs\n"
@@ -41,15 +32,15 @@
  "Ok, so for the use case scneario where the container owner is willing\n"
  "to use the public key distributed with the files, then only those\n"
  "files that are new or modified in the overlay would need to be signed\n"
- "with a key local to the overlay. \302\240In the worst case scenario, where\n"
+ "with a key local to the overlay. ?In the worst case scenario, where\n"
  "the container owner is only willing to trust their own public key, I\n"
  "guess we can live with having to copy up the files.\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
 
-85f78ded60062db6f1345b75911f1d7e4217818f21134d2d8391b4db68200a1d
+b3b331ad45485291c04c06005c8363905a0e861d2893764447e9d70f391a3108
