From 671f22be3888aa9d056e0798508c42420638cb1f Mon Sep 17 00:00:00 2001
From: rene <41963722+renaynay@users.noreply.github.com>
Date: Tue, 7 Apr 2020 14:37:24 +0200
Subject: [PATCH] couple of fixes to docs in clef (#20900)

---
 cmd/clef/docs/setup.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/cmd/clef/docs/setup.md b/cmd/clef/docs/setup.md
index 33d2b0381f..a25f87ce64 100644
--- a/cmd/clef/docs/setup.md
+++ b/cmd/clef/docs/setup.md
@@ -34,7 +34,7 @@ There are two ways that this can be achieved: integrated via Qubes or integrated
 
 #### 1. Qubes Integrated
 
-Qubes provdes a facility for inter-qubes communication via `qrexec`. A qube can request to make a cross-qube RPC request 
+Qubes provides a facility for inter-qubes communication via `qrexec`. A qube can request to make a cross-qube RPC request 
 to another qube. The OS then asks the user if the call is permitted. 
 
 ![Example](qubes/qrexec-example.png)
@@ -48,7 +48,7 @@ This is how [Split GPG](https://www.qubes-os.org/doc/split-gpg/) is implemented.
 
 ![Clef via qrexec](qubes/clef_qubes_qrexec.png)
 
-On the `target` qubes, we need to define the rpc service.
+On the `target` qubes, we need to define the RPC service.
 
 [qubes.Clefsign](qubes/qubes.Clefsign):
 
@@ -135,11 +135,11 @@ $ cat newaccnt.json
 $ cat newaccnt.json| qrexec-client-vm debian-work qubes.Clefsign
 ```
 
-This should pop up first a dialog to allow the IPC call:
+A dialog should pop up first to allow the IPC call:
 
 ![one](qubes/qubes_newaccount-1.png)
 
-Followed by a GTK-dialog to approve the operation
+Followed by a GTK-dialog to approve the operation:
 
 ![two](qubes/qubes_newaccount-2.png)
 
@@ -169,7 +169,7 @@ However, it comes with a couple of drawbacks:
   - The `Origin` header must be forwarded
   - Information about the remote ip must be added as a `X-Forwarded-For`. However, Clef cannot always trust an `XFF` header, 
   since malicious clients may lie about `XFF` in order to fool the http server into believing it comes from another address.
-- Even with a policy in place to allow rpc-calls between `caller` and `target`, there will be several popups:
+- Even with a policy in place to allow RPC calls between `caller` and `target`, there will be several popups:
   - One qubes-specific where the user specifies the `target` vm
   - One clef-specific to approve the transaction
   
@@ -177,7 +177,7 @@ However, it comes with a couple of drawbacks:
 #### 2. Network integrated
 
 The second way to set up Clef on a qubes system is to allow networking, and have Clef listen to a port which is accessible
-form other qubes. 
+from other qubes. 
 
 ![Clef via http](qubes/clef_qubes_http.png)
 
@@ -193,6 +193,6 @@ to your computer. Over this new network interface, you can SSH into the device.
 Running Clef off a USB armory means that you can use the armory as a very versatile offline computer, which only
 ever connects to a local network between your computer and the device itself.
 
-Needless to say, the while this model should be fairly secure against remote attacks, an attacker with physical access
+Needless to say, while this model should be fairly secure against remote attacks, an attacker with physical access
 to the USB Armory would trivially be able to extract the contents of the device filesystem.