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

diff --git a/a/1.txt b/N1/1.txt
index 05df91b..89ec268 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -32,7 +32,7 @@ On Thu, 2018-03-08 at 12:47 -0700, Tycho Andersen wrote:
 > > > > > works and then re-send.
 > > > > 
 > > > > The hash algorithm name is an enumeration that comes from the kernel.
-> > > >  It's defined in crypto/hash_info.c: hash_algo_name.  Why do we need
+> > > >  It's defined in crypto/hash_info.c: hash_algo_name.  Why do we need
 > > > > to use audit_log_untrustedstring()?
 > > > 
 > > > Yes, I suppose we don't need it for the hash either, since we're
@@ -46,9 +46,9 @@ On Thu, 2018-03-08 at 12:47 -0700, Tycho Andersen wrote:
 > > 
 > > Based on the discussion with Richard Briggs, we need to differentiate
 > > between the ima_audit_measurement() and the ima_parse_rule() usage of
-> > AUDIT_INTEGRITY_RULE.  The ima_parse_rule() will continue to use
-> > AUDIT_INTEGRITY_RULE.  ima_audit_measurement() will need to define and
-> > use a new number.  Auidt name suggestions would be appreciated.
+> > AUDIT_INTEGRITY_RULE.  The ima_parse_rule() will continue to use
+> > AUDIT_INTEGRITY_RULE.  ima_audit_measurement() will need to define and
+> > use a new number.  Auidt name suggestions would be appreciated.
 > > 
 > > When we make that sort of change, any other changes are insignificant.
 > > How different are the two formats?
@@ -64,7 +64,7 @@ On Thu, 2018-03-08 at 12:47 -0700, Tycho Andersen wrote:
 > I'm happy to do either way.
 
 If you're willing to wait until the container-id issue is
-resolved/upstreamed, then either way is fine.  If you want the change
+resolved/upstreamed, then either way is fine.  If you want the change
 to go in sooner, then keep it as it currently is.
 
 Mimi
diff --git a/a/content_digest b/N1/content_digest
index 6c6a803..e33e9b9 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -51,7 +51,7 @@
  "> > > > > works and then re-send.\n"
  "> > > > \n"
  "> > > > The hash algorithm name is an enumeration that comes from the kernel.\n"
- "> > > > \302\240It's defined in crypto/hash_info.c: hash_algo_name. \302\240Why do we need\n"
+ "> > > >  It's defined in crypto/hash_info.c: hash_algo_name.  Why do we need\n"
  "> > > > to use audit_log_untrustedstring()?\n"
  "> > > \n"
  "> > > Yes, I suppose we don't need it for the hash either, since we're\n"
@@ -65,9 +65,9 @@
  "> > \n"
  "> > Based on the discussion with Richard Briggs, we need to differentiate\n"
  "> > between the ima_audit_measurement() and the ima_parse_rule() usage of\n"
- "> > AUDIT_INTEGRITY_RULE. \302\240The ima_parse_rule() will continue to use\n"
- "> > AUDIT_INTEGRITY_RULE. \302\240ima_audit_measurement() will need to define and\n"
- "> > use a new number. \302\240Auidt name suggestions would be appreciated.\n"
+ "> > AUDIT_INTEGRITY_RULE.  The ima_parse_rule() will continue to use\n"
+ "> > AUDIT_INTEGRITY_RULE.  ima_audit_measurement() will need to define and\n"
+ "> > use a new number.  Auidt name suggestions would be appreciated.\n"
  "> > \n"
  "> > When we make that sort of change, any other changes are insignificant.\n"
  "> > How different are the two formats?\n"
@@ -83,9 +83,9 @@
  "> I'm happy to do either way.\n"
  "\n"
  "If you're willing to wait until the container-id issue is\n"
- "resolved/upstreamed, then either way is fine. \302\240If you want the change\n"
+ "resolved/upstreamed, then either way is fine.  If you want the change\n"
  "to go in sooner, then keep it as it currently is.\n"
  "\n"
  Mimi
 
-2836ba28aea9ac1c3254c8b94d1f02936384b81d1218ca6e629ad47b10b0691b
+729aa599b139f588a47a9977e2ad50dea9a905b1baf5d8501ae1fd6fc16732a1

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.