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

diff --git a/a/1.txt b/N1/1.txt
index f12bbb7..1ae85f3 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -19,11 +19,11 @@ On Thu, 2018-01-25 at 14:11 -0500, Theodore Ts'o wrote:
 > the file is first opened or referenced.
 
 Secure and trusted boot standards require files to be measured and
-appraised before usage.  Perhaps verifying the merkle tree satifies
+appraised before usage.  Perhaps verifying the merkle tree satifies
 these requirements.
 
 IMA-appraisal is being extended to support appended signatures, as
-generated by scripts/sign-file.  This proposed method of calculating
+generated by scripts/sign-file.  This proposed method of calculating
 the file hash could be another signature method.
 
 > *) The design and code are done by file system developers, so it
@@ -31,11 +31,11 @@ the file hash could be another signature method.
 
 True, the locking problem is a direct result of using xattrs for
 storing file metadata, which requires taking the i_rwsem exclusively
-for writing.  This solution circumvents the locking issues because it
+for writing.  This solution circumvents the locking issues because it
 appends the file metadata to the file data instead of using xattrs.
 
 By using atomic flags, as suggested by Linus, Dmitry Kasatkin has
-resolved the xattr locking issue.  The patch is currently staged to
+resolved the xattr locking issue.  The patch is currently staged to
 be upstreamed in the next open window.
 
 > 
@@ -54,7 +54,7 @@ be upstreamed in the next open window.
 > for files being stored for backup purposes, it should work quite well.
 
 Signing and verifying local file signatures, is a lot simpler than
-supporting a full software package life cycle.  Can the file metadata
+supporting a full software package life cycle.  Can the file metadata
 - signatures and trees - be calculated and included in software
 packages, with the file data, for distribution?
 
diff --git a/a/content_digest b/N1/content_digest
index 7847980..8a5cdbe 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -29,11 +29,11 @@
  "> the file is first opened or referenced.\n"
  "\n"
  "Secure and trusted boot standards require files to be measured and\n"
- "appraised before usage.  Perhaps verifying the merkle tree satifies\n"
+ "appraised before usage.\302\240\302\240Perhaps verifying the merkle tree satifies\n"
  "these requirements.\n"
  "\n"
  "IMA-appraisal is being extended to support appended signatures, as\n"
- "generated by scripts/sign-file.  This proposed method of calculating\n"
+ "generated by scripts/sign-file.\302\240\302\240This proposed method of calculating\n"
  "the file hash could be another signature method.\n"
  "\n"
  "> *) The design and code are done by file system developers, so it\n"
@@ -41,11 +41,11 @@
  "\n"
  "True, the locking problem is a direct result of using xattrs for\n"
  "storing file metadata, which requires taking the i_rwsem exclusively\n"
- "for writing.  This solution circumvents the locking issues because it\n"
+ "for writing.\302\240\302\240This solution circumvents the locking issues because it\n"
  "appends the file metadata to the file data instead of using xattrs.\n"
  "\n"
  "By using atomic flags, as suggested by Linus, Dmitry Kasatkin has\n"
- "resolved the xattr locking issue.  The patch is currently staged to\n"
+ "resolved the xattr locking issue.\302\240\302\240The patch is currently staged to\n"
  "be upstreamed in the next open window.\n"
  "\n"
  "> \n"
@@ -64,7 +64,7 @@
  "> for files being stored for backup purposes, it should work quite well.\n"
  "\n"
  "Signing and verifying local file signatures, is a lot simpler than\n"
- "supporting a full software package life cycle.  Can the file metadata\n"
+ "supporting a full software package life cycle.\302\240\302\240Can the file metadata\n"
  "- signatures and trees - be calculated and included in software\n"
  "packages, with the file data, for distribution?\n"
  "\n"
@@ -73,4 +73,4 @@
  "\n"
  Mimi
 
-0697868dc377bf99d10b622a7250b2df02e362806f221a6683059ea106a64c19
+bf4cac819de48e782667656ff8ad8e0a1c5c17d088825f4f7e5ec6f64cdb57c5

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.