replaced all github flavored code blocks with fenced kramdown code blocks

developers/services/Dom0SecureUpdates.md

@@ -31,7 +31,7 @@ Keeping Dom0 not connected to any network makes it hard, however, to provide upd
 
 The update process is initiated by [qvm-dom0-update script](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes-dom0-update), running in Dom0.
 
-Updates (\*.rpm files) are checked and downloaded by UpdateVM, which by default is the same as the firewall VM, but can be configured to be any other, network-connected VM. This is done by [qubes-download-dom0-updates.sh script](https://github.com/QubesOS/qubes-core-agent-linux/blob/release2/misc/qubes-download-dom0-updates.sh) (this script is executed using qrexec by the previously mentioned qvm-dom0-update). Note that we assume that this script might get compromised and might download a maliciously compromised downloads -- this is not a problem as Dom0 verifies digital signatures on updates later. The downloaded rpm files are placed in a ```/var/lib/qubes/dom0-updates``` directory on UpdateVM filesystem (again, they might get compromised while being kept there, still this isn't a problem). This directory is passed to yum using the ```--installroot=``` option.
+Updates (\*.rpm files) are checked and downloaded by UpdateVM, which by default is the same as the firewall VM, but can be configured to be any other, network-connected VM. This is done by [qubes-download-dom0-updates.sh script](https://github.com/QubesOS/qubes-core-agent-linux/blob/release2/misc/qubes-download-dom0-updates.sh) (this script is executed using qrexec by the previously mentioned qvm-dom0-update). Note that we assume that this script might get compromised and might download a maliciously compromised downloads -- this is not a problem as Dom0 verifies digital signatures on updates later. The downloaded rpm files are placed in a ~~~/var/lib/qubes/dom0-updates~~~ directory on UpdateVM filesystem (again, they might get compromised while being kept there, still this isn't a problem). This directory is passed to yum using the ~~~--installroot=~~~ option.
 
 Once updates are downloaded, the update script that runs in UpdateVM requests an RPM service [qubes.ReceiveUpdates](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes.ReceiveUpdates) to be executed in Dom0. This service is implemented by [qubes-receive-updates script](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes-receive-updates) running in Dom0. The Dom0's qvm-dom0-update script (which originally initiated the whole update process) waits until qubes-receive-updates finished.
 

developers/services/Qrexec.md

@@ -19,9 +19,9 @@ Typically, the first thing that a `qrexec-client` instance does is to send a req
 
 E.g., to start a primitive shell in a VM type the following in Dom0 console:
 
-```
+~~~
 [user@dom0 ~]$ /usr/lib/qubes/qrexec-client -d <vm name> user:bash
-```
+~~~
 
 The string before first semicolon specifies what user to run the command as.
 
@@ -65,9 +65,9 @@ In dom0, there is a bunch of files in `/etc/qubes-rpc/policy/` directory, whose
 
 These files contain lines with the following format:
 
-```
+~~~
 srcvm destvm (allow|deny|ask)[,user=user_to_run_as][,target=VM_to_redirect_to]
-```
+~~~
 
 You can specify `srcvm` and `destvm` by name, or by one of `$anyvm`, `$dispvm`, `dom0` reserved keywords (note string `dom0` does not match the `$anyvm` pattern; all other names do). Only `$anyvm` keyword makes sense in the `srcvm` field (service calls from dom0 are currently always allowed, `$dispvm` means "new VM created for this particular request" - so it is never a source of request). Currently, there is no way to specify source VM by type, but this is planned for Qubes R3.
 
@@ -80,9 +80,9 @@ Requesting VM-VM (and VM-Dom0) services execution
 
 In a src VM, one should invoke the qrexec client via the following command:
 
-```
+~~~
 /usr/lib/qubes/qrexec-client-vm <target vm name> <service name> <local program path> [local program arguments]`
-```
+~~~
 
 Note that only stdin/stdout is passed between RPC server and client - notably, no cmdline argument are passed.
 
@@ -103,9 +103,9 @@ Qubes RPC policy supports an "ask" action, that will prompt the user whether a g
 
 In order to remove such authorization, issue this command from a Dom0 terminal (example below for qubes.Filecopy service):
 
-```
+~~~
 sudo nano /etc/qubes-rpc/policy/qubes.Filecopy
-```
+~~~
 
 and then remove any line(s) ending in "allow" (before the first \#\# comment) which are the "Yes to All" results.
 
@@ -117,37 +117,37 @@ We will show the necessary files to create a simple RPC call that adds two integ
 
 -   Client code on source VM (`/usr/bin/our_test_add_client`)
 
-```
+~~~
 #!/bin/sh
 echo $1 $2    # pass data to rpc server
 exec cat >&$SAVED_FD_1 # print result to the original stdout, not to the other rpc endpoint
-```
+~~~
 
 -   Server code on target VM (`/usr/bin/our_test_add_server`)
 
-```
+~~~
 #!/bin/sh
 read arg1 arg2 # read from stdin, which is received from the rpc client
 echo $(($arg1+$arg2)) # print to stdout - so, pass to the rpc client
-```
+~~~
 
 -   Policy file in dom0 (`/etc/qubes-rpc/policy/test.Add`)
 
-```
+~~~
 $anyvm $anyvm ask
-```
+~~~
 
 -   Server path definition on target VM (`/etc/qubes-rpc/test.Add`)
 
-```
+~~~
 /usr/bin/our_test_add_server
-```
+~~~
 
 -   To test this service, run the following in the source VM:
 
-```
+~~~
 /usr/lib/qubes/qrexec-client-vm <target VM> test.Add /usr/bin/our_test_add_client 1 2
-```
+~~~
 
 and we should get "3" as answer, provided dom0 policy allows the call to pass through, which would happen after we click "Yes" in the popup that should appear after the invocation of this command. If we changed the policy from "ask" to "allow", then no popup should be presented, and the call will always be allowed.
 

developers/services/Qrexec3.md

@@ -87,37 +87,37 @@ We will show the necessary files to create rpc call that adds two integers on th
 
 -   rpc client code (*/usr/bin/our\_test\_add\_client*)
 
-    ```
+    ~~~
     #!/bin/sh
     echo $1 $2    # pass data to rpc server
     exec cat >&$SAVED_FD_1 # print result to the original stdout, not to the other rpc endpoint
-    ```
+    ~~~
 
 -   rpc server code (*/usr/bin/our\_test\_add\_server*)
 
-    ```
+    ~~~
     #!/bin/sh
     read arg1 arg2 # read from stdin, which is received from the rpc client
     echo $(($arg1+$arg2)) # print to stdout - so, pass to the rpc client
-    ```
+    ~~~
 
 -   policy file in dom0 (*/etc/qubes-rpc/policy/test.Add* )
 
-    ```
+    ~~~
     $anyvm $anyvm ask
-    ```
+    ~~~
 
 -   server path definition ( */etc/qubes-rpc/test.Add*)
 
-    ```
+    ~~~
     /usr/bin/our_test_add_server
-    ```
+    ~~~
 
 -   invoke rpc via
 
-    ```
+    ~~~
     /usr/lib/qubes/qrexec-client-vm target_vm test.Add /usr/bin/our_test_add_client 1 2
-    ```
+    ~~~
 
 and we should get "3" as answer, after dom0 allows it.
 

developers/services/Qrexec3Implementation.md

@@ -66,21 +66,21 @@ Qrexec protocol details
 
 Qrexec protocol is message-based. All messages share a common header followed by an optional data packet.
 
-```
+~~~
 /* uniform for all peers, data type depends on message type */
 struct msg_header {
    uint32_t type;           /* message type */
    uint32_t len;            /* data length */
 };
-```
+~~~
 
 When two peers establish connection, the server sends `MSG_HELLO` followed by `peer_info` struct:
 
-```
+~~~
 struct peer_info {
    uint32_t version; /* qrexec protocol version */
 };
-```
+~~~
 
 The client then should reply with its own `MSG_HELLO` and `peer_info`. If protocol versions don't match, the connection is closed. TODO: fallback for backwards compatibility, don't do handshake in the same domain?.
 
@@ -101,14 +101,14 @@ Details of all possible use cases and the messages involved are described below.
 -   **dom0**: `qrexec-client` replies with `MSG_HELLO` header followed by `peer_info` to `qrexec-daemon`.
 -   **dom0**: `qrexec-client` sends `MSG_EXEC_CMDLINE` header followed by `exec_params` to `qrexec-daemon`
 
-    ```
+    ~~~
      /* variable size */
      struct exec_params {
         uint32_t connect_domain; /* target domain id */
         uint32_t connect_port;   /* target vchan port for i/o exchange */
         char cmdline[0];         /* command line to execute, size = msg_header.len - sizeof(struct exec_params) */
      };
-    ```
+    ~~~
 
     In this case, `connect_domain` and `connect_port` are set to 0.
 
@@ -133,7 +133,7 @@ Details of all possible use cases and the messages involved are described below.
 -   **domY**: `qrexec-client-vm` connects to `qrexec-agent` (via local socket/named pipe).
 -   **domY**: `qrexec-client-vm` sends `trigger_service_params` data to `qrexec-agent` (without filling the `request_id` field):
 
-    ```
+    ~~~
      struct trigger_service_params {
         char service_name[64];
         char target_domain[32];
@@ -143,7 +143,7 @@ Details of all possible use cases and the messages involved are described below.
      struct service_params {
         char ident[32];
     };
-    ```
+    ~~~
 
 -   **domY**: `qrexec-agent` allocates a locally-unique (for this domain) `request_id` (let's say `13`) and fills it in the `trigger_service_params` struct received from `qrexec-client-vm`.
 -   **domY**: `qrexec-agent` sends `MSG_TRIGGER_SERVICE` header followed by `trigger_service_params` to `qrexec-daemon` in **dom0** via vchan.
@@ -159,14 +159,14 @@ Details of all possible use cases and the messages involved are described below.
 -   **dom0**: `qrexec-client` replies with `MSG_HELLO` header followed by `peer_info` to **domX**'s`qrexec-daemon`.
 -   **dom0**: `qrexec-client` sends `MSG_EXEC_CMDLINE` header followed by `exec_params` to **domX**'s`qrexec-daemon`
 
-    ```
+    ~~~
      /* variable size */
      struct exec_params {
         uint32_t connect_domain; /* target domain id */
         uint32_t connect_port;   /* target vchan port for i/o exchange */
         char cmdline[0];         /* command line to execute, size = msg_header.len - sizeof(struct exec_params) */
      };
-    ```
+    ~~~
 
     In this case, `connect_domain` is set to id of **domY** (from the `-c` parameter) and `connect_port` is set to 0. `cmdline` field contains the RPC to execute, in this case `user:QUBESRPC qubes.SomeRpc domY`.