replaced all github flavored code blocks with fenced kramdown code blocks

security/AntiEvilMaid.md

@@ -18,9 +18,9 @@ Installing
 
 In Dom0 install anti-evil-maid:
 
-```
+~~~
 sudo qubes-dom0-update anti-evil-maid
-```
+~~~
 
 More information regarding configuration in the [README](https://github.com/QubesOS/qubes-antievilmaid/blob/master/README) file.
 

security/QubesFirewall.md

@@ -34,15 +34,15 @@ Reconnecting AppVMs after a NetVM reboot
 
 Normally Qubes doesn't let the user to stop a NetVM if there are other AppVMs running which use it as their own NetVM. But in case the NetVM stops for whatever reason (e.g. it crashes, or the user forces its shutdown via qvm-kill via terminal in the netvm), then there is an easy way to restore the connection to the netvm by issuing:
 
-```
+~~~
 qvm-prefs <appvm> -s netvm <netvm>
-```
+~~~
 
 Normally AppVMs do not connect directly to the actual NetVM which has networking devices, but rather to the default FirewallVM first, and in most cases it would be the NetVM that would crash, e.g. in response to S3 sleep/restore or other issues with WiFi drivers. In that case it is necessary to just issue the above command once, for the FirewallVM (this assumes default VM-nameing used by the default Qubes installation):
 
-```
+~~~
 qvm-prefs firewallvm -s netvm netvm
-```
+~~~
 
 Enabling networking between two AppVMs
 --------------------------------------
@@ -56,18 +56,18 @@ In order to allow networking between AppVM A and B follow those steps:
 -   Start both AppVMs, and also open a terminal in the firewall VM
 -   In the firewall VM's terminal enter the following iptables rule:
 
-    ```
+    ~~~
     sudo iptables -I FORWARD 2 -s <IP address of A> -d <IP address of B> -j ACCEPT
-    ```
+    ~~~
 
 -   Now you should be able to reach the AppVM B from A -- test it using e.g. ping issues from AppVM A. Note however, that this doesn't allow you to reach A from B -- for this you would need another rule, with A and B addresses swapped.
 -   If everything works as expected, then the above iptables rule(s) should be written into firewall VM's `qubes_firewall_user_script` script which is run on every firewall update. This is necessary, because Qubes orders every firewall VM to update all the rules whenever new VM is started in the system. If we didn't enter our rules into this "hook" script, then shortly our custom rules would disappear and inter-VM networking would stop working. Here's an example how to update the script (note that, by default, there is no script file present, so we likely will be creating it, unless we had some other custom rules defines earlier in this firewallvm):
 
-    ```
+    ~~~
     [user@firewallvm ~]$ sudo bash
     [root@firewallvm user]# echo "iptables -I FORWARD 2 -s 10.137.2.25 -d 10.137.2.6 -j ACCEPT" >> /rw/config/qubes_firewall_user_script
     [root@firewallvm user]# chmod +x /rw/config/qubes_firewall_user_script
-    ```
+    ~~~
 
 Port forwarding to an AppVM from the outside world
 --------------------------------------------------
@@ -90,15 +90,15 @@ In NetVM terminal, take note of the interface name and IPAddress on which you wa
 
 Still in NetVM terminal, code the appropriate natting firewall rule to intercept traffic on the inbound interface for the service and nat the destination IP address to the one of the firewallVM for the traffic to be routed there:
 
-```
+~~~
 iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 192.168.0.10 -j DNAT --to-destination 10.137.1.x
-```
+~~~
 
 Code the appropriate new filtering firewall rule to allow new connections for the service:
 
-```
+~~~
 iptables -I FORWARD 2 -i eth0 -d 10.137.1.x -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
-```
+~~~
 
 Note: If you want to expose the service on multiple interfaces, repeat the steps described in part 1 for each interface.
 
@@ -114,23 +114,23 @@ In order to ensure your set-up survive a reboot we need in the NetVM to:
 
 Store these commands in ` /rw/config/rc.local `:
 
-```
+~~~
 sudo nano /rw/config/rc.local
-```
+~~~
 
-```
+~~~
 #!/bin/sh
 
 /sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 192.168.0.10 -j DNAT --to-destination 10.137.1.x
 
 /sbin/iptables -I FORWARD 2 -s 192.168.0.0/24 -d 10.137.1.x -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
-```
+~~~
 
 Make this file executable:
 
-```
+~~~
 sudo chmod +x /rw/config/rc.local 
-```
+~~~
 
 **2. Allow packets to be routed from the firewallVM to the appVM**
 
@@ -140,15 +140,15 @@ In FirewallVM Terminal, take note of the IPAddress for interface eth0 using the
 
 Still in FirewallVM terminal, code the appropriate natting firewall rule to intercept traffic on the inbound interface for the service and nat the destination IP address to the one of the AppVM for the traffic to be routed there:
 
-```
+~~~
 iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 10.137.1.x -j DNAT --to-destination 10.137.2.y
-```
+~~~
 
 Code the appropriate new filtering firewall rule to allow new connections for the service:
 
-```
+~~~
 iptables -I FORWARD 2 -i eth0 -s 192.168.0.0/24 -d 10.137.2.y -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
-```
+~~~
 
 > Note: If you do not wish to limit the IP addresses connecting to the service, remove the ` -s 192.168.0.1/24 `
 
@@ -158,28 +158,28 @@ This time in order to ensure your set-up survive a reboot we need in the firewal
 
 Store these commands in ` /rw/config/qubes_firewall_user_script `:
 
-```
+~~~
 #!/bin/sh
 
 /sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 10.137.1.x -j DNAT --to-destination 10.137.2.y
 
 /sbin/iptables -I FORWARD 4 -i eth0 -s 192.168.0.0/24 -d 10.137.2.y -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
-```
+~~~
 
 And again make this file executable:
 
-```
+~~~
 sudo chmod +x /rw/config/qubes_firewall_user_script
-```
+~~~
 
 **3. Allow packets into the AppVM to reach the service**
 
 Here no routing is required, only filtering. Proceed in the same way as above but store the filtering rule in the `/rw/config/rc.local` script.
 
-```
+~~~
 #!/bin/sh
 
 /sbin/iptables -I INPUT 5 -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
-```
+~~~
 
 This time testing should allow connectivity to the service.

security/SecurityGuidelines.md

@@ -29,17 +29,17 @@ Download Verification
 
 Standard program installation
 
-```
+~~~
 sudo yum install <program>
-```
+~~~
 
 on template terminal already accomplishes verification, for fedora and qubes repositories.
 
 If you install new repositories, they might have gpgcheck disabled. [Check the config files](http://docs.fedoraproject.org/en-US/Fedora/12/html/Deployment_Guide/sec-Configuring_Yum_and_Yum_Repositories.html) and be sure to check that
 
-```
+~~~
 gpgcheck=1
-```
+~~~
 
 Plus, also make sure you **safely import their signing keys**. This may require you check from multiple sources that the signing key is always the same.
 
@@ -66,9 +66,9 @@ Enabling and Verifying VT-d/IOMMU
 
 In **Dom0** terminal, run:
 
-```
+~~~
 qubes-hcl-report <userVM>
-```
+~~~
 
 where \<userVM\> is the name of the VM within which the report will be written (but the report will also be displayed in the Dom0 terminal). If it displays that VT-d is active, you should be able to assign **PCIe devices to a HVM** and **enjoy DMA protection** for your driver domains, so you successfully passed this step.
 
@@ -79,15 +79,15 @@ Updating Software
 
 To keep your system regularly updated against security related bugs and get new features, run in Dom0:
 
-```
+~~~
 sudo qubes-dom0-update
-```
+~~~
 
 and run in templates and standalone VM
 
-```
+~~~
 sudo yum update
-```
+~~~
 
 or use the equivalent items in Qubes Manager, which displays an icon when an update is available.
 
@@ -145,9 +145,9 @@ An **USBVM** operates like a dedicated temporary parking area, used just to prev
 5.  Click OK. Restart the AppVM. (Restarting may not even be required.)
 6.  Set the VM to start automatically at Boot using the VM Manager, (under VM Settings), or **In dom0 terminal**, run
 
-    ```
+    ~~~
     qvm-prefs -s usbvm autostart true
-    ```
+    ~~~
 
 This will cause your new **USBVM** to automatically start when the system starts up. So that in case you forgot to start it and then accidentally plugged a USB stick (or your colleague at work did it while you were at lunch), **it won't compromise the Dom0**.
 

security/SecurityPage.md

@@ -21,9 +21,9 @@ Qubes Security Team
 
 The Qubes Security Team can be contacted via email using the following address:
 
-```
+~~~
 security at qubes-os dot org
-```
+~~~
 
 Qubes Security Team GPG Key
 ---------------------------