Fix internal links

This commit is contained in:
Marek Marczykowski-Górecki 2016-09-25 01:25:34 +02:00
parent f32bf85689
commit e02030119e
No known key found for this signature in database
GPG Key ID: F32894BE9684938A
16 changed files with 20 additions and 20 deletions

View File

@ -30,7 +30,7 @@ Qubes Users' FAQ
* [Is Qubes a multi-user system?](#is-qubes-a-multi-user-system)
* [Why passwordless sudo?](#why-passwordless-sudo)
* [How should I report documentation issues?](#how-should-i-report-documentation-issues)
* [Will Qubes seek to get certified on the GNU Free System Distribution Guidelines (GNU FSDG)?](#will-qubes-seek-gnu-fsdg)
* [Will Qubes seek to get certified on the GNU Free System Distribution Guidelines (GNU FSDG)?](#will-qubes-seek-to-get-certified-under-the-gnu-free-system-distribution-guidelines-gnu-fsdg)
[Installation & Hardware Compatibility](#installation--hardware-compatibility)
------------------------------------------------------------------------------
@ -51,8 +51,8 @@ Qubes Users' FAQ
* [My dom0 and/or TemplateVM update stalls when attempting to update via …](#my-dom0-andor-templatevm-update-stalls-when-attempting-to-update-via-the-gui-tool-what-should-i-do)
* [How do I run a Windows HVM in non-seamless mode (i.e., as a single window)?](#how-do-i-run-a-windows-hvm-in-non-seamless-mode-ie-as-a-single-window)
* [I created a usbVM and assigned usb controllers to it. Now the usbVM wont boot.](#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot)
* [I assigned a PCI device to a qube, then unassigned it/shut down the …](#i-assigned-a-pci-device-to-a-qube-then-unassigned-itshut-down-the-qube`-why-isnt-the-device-available-in-dom0)
* [How do I install Flash in a Debian qube?](#how-do-i-install-flash-in-a Debian-qube)
* [I assigned a PCI device to a qube, then unassigned it/shut down the …](#i-assigned-a-pci-device-to-a-qube-then-unassigned-itshut-down-the-qube-why-isnt-the-device-available-in-dom0)
* [How do I install Flash in a Debian qube?](#how-do-i-install-flash-in-a-debian-qube)
-----------------

View File

@ -541,6 +541,6 @@ Usage: add this line to `/etc/apt/sources.list` on test machine (adjust host and
deb http://local-test.lan/linux-deb/r3.1 jessie-unstable main
~~~
[port-forwarding]: /doc/qubes-firewall/#tocAnchor-1-1-5
[port-forwarding]: /doc/qubes-firewall/#port-forwarding-to-a-vm-from-the-outside-world
[linux-yum]: https://github.com/QubesOS/qubes-linux-yum
[linux-deb]: https://github.com/QubesOS/qubes-linux-deb

View File

@ -87,7 +87,7 @@ For emergency restore of backup created on Qubes R2 or newer take a look [here](
Migrating Between Two Physical Machines
---------------------------------------
In order to migrate your Qubes system from one physical machine to another, simply follow the backup procedure on the old machine, [install Qubes](/doc/downloads/) on the new machine, and follow the restoration procedure on the new machine. All of your settings and data will be preserved!
In order to migrate your Qubes system from one physical machine to another, simply follow the backup procedure on the old machine, [install Qubes](/downloads/) on the new machine, and follow the restoration procedure on the new machine. All of your settings and data will be preserved!
Notes

View File

@ -43,4 +43,4 @@ However, one should keep in mind that performing a data transfer from *less trus
See also [this article](http://theinvisiblethings.blogspot.com/2011/03/partitioning-my-digital-life-into.html) for more information on this topic, and some ideas of how we might solve this problem in some future version of Qubes.
You may also want to read how to [revoke "Yes to All" authorization](/doc/Qrexec/#revoking-yes-to-all-authorization)
You may also want to read how to [revoke "Yes to All" authorization](/doc/qrexec3/#revoking-yes-to-all-authorization)

View File

@ -97,7 +97,7 @@ redirect_from:
[Hardware Certification]: /hardware-certification/
[Hardware Compatibility List]: /hcl/
[hcl-doc]: /doc/hcl/
[hcl-report]: /doc/HCL/#generating-and-submitting-new-reports
[hcl-report]: /doc/hcl/#generating-and-submitting-new-reports
[Anti Evil Maid]: /doc/anti-evil-maid/
[Qubes-certified laptop]: /doc/certified-laptops/
[live USB]: /doc/live-usb/

View File

@ -100,7 +100,7 @@ Downloading and burning
-----------------------
1. Download the ISO (and its signature for verification) from the
[downloads page](/downloads/#qubes-live-usb-alpha/).
[downloads page](/downloads/#qubes-live-usb-alpha).
2. "Burn" (copy) the ISO onto a USB drive (replace `/dev/sdX` with your USB
drive device):

View File

@ -19,7 +19,7 @@ Current Qubes R2 Beta 3 (R2B3) systems can be upgraded in-place to the latest R2
Upgrade Template and Standalone VM(s)
-------------------------------------
- Qubes R2 comes with new template based on Fedora 20. You can upgrade existing template according to procedure described [here](/doc/FedoraTemplateUpgrade/).
- Qubes R2 comes with new template based on Fedora 20. You can upgrade existing template according to procedure described [here](/doc/fedora-template-upgrade-20/).
- **It also possible to download a new Fedora 20-based template from our repositories**. To do this please first upgrade the Dom0 distro as described in the section below.

View File

@ -17,7 +17,7 @@ TemplateBasedVMs is installed. The default template is based on Fedora,
but there are additional templates based on other Linux distributions. There
are also templates available with or without certain software preinstalled. The
concept of TemplateVMs is initially described
[here](/doc/getting-started/#appvms-domains-and-templatevms). The technical
[here](/getting-started/#appvms-qubes-and-templatevms). The technical
details of this implementation are described in the developer documentation
[here](/doc/template-implementation/).

View File

@ -694,6 +694,6 @@ Note: For info on Reflector and its configs: [Reflector](https://wiki.archlinux.
* [How can I contribute to the Qubes Project?](/doc/contributing/)
* [Guidelines for Documentation Contributors](doc/doc-guidelines/)
* [Guidelines for Documentation Contributors](/doc/doc-guidelines/)
<br>

View File

@ -75,7 +75,7 @@ This template is now ready to use for a standard firewall VM.
The needed packages depend on the VPN technology. The `dnf search "NetworkManager VPN plugin"` command may help you to choose the right one. You should also install the corresponding GNOME related packages as well.
[More details about setting up a VPN Gateway](/wiki/VPN#ProxyVM)
[More details about setting up a VPN Gateway](/doc/vpn/#proxyvm)
#### TOR

View File

@ -71,6 +71,6 @@ using](/doc/releases/3.0/release-notes/#upgrading) first, then follow the
instructions above. This will be time consuming process.
[salt-doc]: /doc/salt/
[pvgrub-doc]: /doc/managing-vm-kernel/#tocAnchor-1-3
[pvgrub-doc]: /doc/managing-vm-kernel/#using-kernel-installed-in-the-vm
[input-proxy]: https://github.com/QubesOS/qubes-app-linux-input-proxy/blob/master/README.md
[github-release-notes]: https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+sort%3Aupdated-desc+milestone%3A%22Release+3.1%22+label%3Arelease-notes+is%3Aclosed

View File

@ -9,7 +9,7 @@ redirect_from:
Qubes R3.1 Release Schedule
===========================
This schedule is based on [Version Scheme](/doc/version-scheme/#tocAnchor-1-1-3).
This schedule is based on [Version Scheme](/doc/version-scheme/#release-schedule).
<style>
article td, article th {

View File

@ -9,7 +9,7 @@ redirect_from:
Qubes R3.2 Release Schedule
===========================
This schedule is based on [Version Scheme](/doc/version-scheme/#tocAnchor-1-1-3).
This schedule is based on [Version Scheme](/doc/version-scheme/#release-schedule).
<style>
article td, article th {

View File

@ -32,7 +32,7 @@ Security Considerations
[Qubes security guidelines](/doc/security-guidelines/) dictate that USB devices should never be attached directly to dom0, since this can result in the entire system being compromised. However, in its default configuration, installing and using AEM requires attaching a USB drive (i.e., [mass storage device](https://en.wikipedia.org/wiki/USB_mass_storage_device_class)) directly to dom0. (The other option is to install AEM to an internal disk. However, this carries significant security implications, as explained [here](http://theinvisiblethings.blogspot.com/2011/09/anti-evil-maid.html).) This presents us with a classic security trade-off: each Qubes user must make a choice between protecting dom0 from a potentially malicious USB drive, on the one hand, and protecting the system from Evil Maid attacks, on the other hand. Given the practical feasibility of attacks like [BadUSB](https://srlabs.de/badusb/) and revelations regarding pervasive government hardware backdoors, this is no longer a straightforward decision. New, factory-sealed USB drives cannot simply be assumed to be "clean" (e.g., to have non-malicious microcontroller firmware). Therefore, it is up to each individual Qubes user to evaluate the relative risk of each attack vector against his or her security model.
For example, a user who frequently travels with a Qubes laptop holding sensitive data may be at a much higher risk of Evil Maid attacks than a home user with a stationary Qubes desktop. If the frequent traveler judges her risk of an Evil Maid attack to be higher than the risk of a malicious USB device, she might reasonably opt to install and use AEM. On the other hand, the home user might deem the probability of an Evil Maid attack occurring in her own home to be so low that there is a higher probability that any USB drive she purchases is already compromised, in which case she might reasonably opt never to attach any USB devices directly to dom0. (In either case, users can--and should--secure dom0 against further USB-related attacks through the use of a [USBVM](/doc/SecurityGuidelines/#creating-and-using-a-usbvm).)
For example, a user who frequently travels with a Qubes laptop holding sensitive data may be at a much higher risk of Evil Maid attacks than a home user with a stationary Qubes desktop. If the frequent traveler judges her risk of an Evil Maid attack to be higher than the risk of a malicious USB device, she might reasonably opt to install and use AEM. On the other hand, the home user might deem the probability of an Evil Maid attack occurring in her own home to be so low that there is a higher probability that any USB drive she purchases is already compromised, in which case she might reasonably opt never to attach any USB devices directly to dom0. (In either case, users can--and should--secure dom0 against further USB-related attacks through the use of a [USBVM](/doc/security-guidelines/#creating-and-using-a-usbvm).)
For more information, please see [this discussion thread](https://groups.google.com/d/msg/qubes-devel/EBc4to5IBdg/n1hfsHSfbqsJ).

View File

@ -113,7 +113,7 @@ It is preferably to avoid using **Bluetooth** if you travel and if you do not tr
Many laptops will also allow one to disable various hardware (Camera, BT, Mic, etc) **in BIOS**. This might or might not be safe, depending on how much you trust your BIOS vendor.
If the VM will not start after you have assigned a USB controller, look at [this faq](../UserFaq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot)
If the VM will not start after you have assigned a USB controller, look at [this faq](../user-faq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot)
Creating and Using a USBVM
@ -125,7 +125,7 @@ See [here](/doc/usb/).
Dom0 Precautions
----------------
As explained [here](/doc/GettingStarted/#appvms-domains-and-templatevms), dom0 should not be used for any user operations. There are several reasons for this:
As explained [here](/getting-started/#appvms-qubes-and-templatevms), dom0 should not be used for any user operations. There are several reasons for this:
1. Secure isolation among domUs (i.e., AppVMs, StandaloneVMs, HVMs, etc.) is the *raison d'être* of Qubes. This is the primary reason that we recommend the delegation of all user activities to some number of AppVMs. In the event that any given VM is compromised, only that particular VM is compromised. (TemplateVMs are the exception to this. If a TemplateVM were compromised, then every AppVM based on it might also be compromised. Even in this case, however, the entire system would not necessarily have been compromised, since StandaloneVM(s), HVM(s), and/or multiple TemplateVMs might be in use.) By contrast, if dom0 were ever compromised, the entire system would thereby be compromised.
2. Due to the absence of convenience mechanisms in dom0 such as the inter-VM clipboard and inter-VM file copying, it is significantly less convenient to attempt to use dom0 for user operations (e.g., password management) in conjunction with AppVMs than it is to use another dedicated AppVM (e.g., a "vault" VM).

View File

@ -377,11 +377,11 @@ exercise caution and use your good judgment.)
[#474]: https://github.com/QubesOS/qubes-issues/issues/474
[using split GPG with subkeys]: #advanced-using-split-gpg-with-subkeys
[subkeys]: https://wiki.debian.org/Subkeys
[copied]: /doc/copying-files#on-inter-domain-file-copy-security
[copied]: /doc/copying-files#on-inter-qube-file-copy-security
[pasted]: /doc/copy-paste#on-copypaste-security
[MUA]: https://en.wikipedia.org/wiki/Mail_user_agent
[covert channels]: /doc/data-leaks
[trusting-templates]: /doc/SoftwareUpdateVM#notes-on-trusting-your-template-vms
[trusting-templates]: /doc/software-update-vm/#notes-on-trusting-your-template-vms
[openpgp-in-qubes-os]: https://groups.google.com/d/topic/qubes-users/Kwfuern-R2U/discussion
[cabal]: https://alexcabal.com/creating-the-perfect-gpg-keypair/
[luck]: https://gist.github.com/abeluck/3383449