Assign unsorted pages and delete deprecated/blank/test pages

developers/BugReportingGuide.md

@@ -0,0 +1,78 @@
+---
+layout: doc
+title: BugReportingGuide
+permalink: /doc/BugReportingGuide/
+redirect_from: /wiki/BugReportingGuide/
+---
+
+Bug Reporting Guide
+===================
+
+One of the most important contribution task is reporting the bugs you have found.
+
+Asking a Question
+-----------------
+
+Before you ask, do some searching and reading. Check [the
+docs](https://www.qubes-os.org/doc/), Google, GitHub, and StackOverflow. If
+your question is something that has been answered many times before, the
+project maintainers might be tired of repeating themselves.
+
+Whenever possible, ask your question on the Qubes mailing list which is
+located [here](https://groups.google.com/forum/#!forum/qubes-users). This
+allows anyone to answer and makes the answer available for the next person
+with the same question.
+
+Submitting a Bug Report (or "Issue")
+------------------------------------
+
+On GitHub, "Bug Reports" are called "Issues."
+
+Issues can be submitted to the Qubes project located at
+[https://github.com/QubesOS/qubes-issues](https://github.com/QubesOS/qubes-issues).
+
+### Has This Been Asked Before?
+
+Before you submit a bug report, you should search existing issues. Be sure
+to check both currently open issues, as well as issues that are already
+closed. If you find an issue that seems to be similar to yours, read
+through it.
+
+If this issue is the same as yours, you can comment with additional
+information to help the maintainer debug it. Adding a comment will
+subscribe you to email notifications, which can be helpful in getting
+important updates regarding the issue. If you don't have anything to add
+but still want to receive email updates, you can click the "watch" button
+at the bottom of the comments.
+
+### Nope, Hasn't Been Asked Before
+
+If you can't find anything in the existing issues, don't be shy about
+filing a new one.
+
+You should be sure to include the version the project, as well as versions
+of related software. For example, be sure to include the Qubes release
+version (R2, R3) and specific version numbers of package causing problems
+(if known).
+If your issue is related to hardware, provide as many details as possible
+about the hardware, which could include using commandline tools such as
+`lspci`.
+
+Project maintainers really appreciate thorough explanations. It usually
+helps them address the problem more quickly, so everyone wins!
+
+Improving the Code
+------------------
+
+The best way is to "Fork" the repo on GitHub. This will create a copy of
+the repo on your GitHub account.
+
+Before you set out to improve the code, you should have a focused idea in
+mind of what you want to do.
+
+Each commit should do one thing, and each PR should be one specific
+improvement. Each PR needs to be signed.
+
+* [How can I contribute to the Qubes Project?](https://www.qubes-os.org/doc/ContributingHowto/)
+* [Developer Documentation](https://www.qubes-os.org/doc/)
+* [Package Release Workflow](https://github.com/QubesOS/qubes-builder/blob/master/doc/ReleaseManagerWorkflow.md)

developers/QubesArchitecture.md

@@ -0,0 +1,31 @@
+---
+layout: doc
+title: QubesArchitecture
+permalink: /doc/QubesArchitecture/
+redirect_from: /wiki/QubesArchitecture/
+---
+
+Qubes Architecture Overview
+===========================
+
+Qubes implements a Security by Isolation approach. To do this, Qubes utilizes virtualization technology in order to isolate various programs from each other and even to sandbox many system-level components, such as networking and storage subsystems, so that the compromise of any of these programs or components does not affect the integrity of the rest of the system.
+
+Qubes lets the user define many security domains, which are implemented as lightweight Virtual Machines (VMs), or “AppVMs.” For example, the user can have “personal,” “work,” “shopping,” “bank,” and “random” AppVMs and can use the applications within those VMs just as if they were executing on the local machine. At the same time, however, these applications are well isolated from each other. Qubes also supports secure copy-and-paste and file sharing between the AppVMs, of course.
+
+[![qubes-arch-diagram-1.png](/attachment/wiki/QubesArchitecture/qubes-arch-diagram-1.png)](/attachment/wiki/QubesArchitecture/qubes-arch-diagram-1.png)
+
+(Note: In the diagram above, "Storage domain" is actually a USB domain.)
+
+Key Architecture features
+-------------------------
+
+-   Based on a secure bare-metal hypervisor (Xen)
+-   Networking code sand-boxed in an unprivileged VM (using IOMMU/VT-d)
+-   USB stacks and drivers sand-boxed in an unprivileged VM (currently experimental feature)
+-   No networking code in the privileged domain (dom0)
+-   All user applications run in “AppVMs,” lightweight VMs based on Linux
+-   Centralized updates of all AppVMs based on the same template
+-   Qubes GUI virtualization presents applications as if they were running locally
+-   Qubes GUI provides isolation between apps sharing the same desktop
+-   Secure system boot based (optional)
+

developers/QubesLicensing.md

@@ -0,0 +1,27 @@
+---
+layout: doc
+title: QubesLicensing
+permalink: /doc/QubesLicensing/
+redirect_from: /wiki/QubesLicensing/
+---
+
+Qubes OS License
+================
+
+Qubes is a compilation of software packages, each under its own license. The compilation is made available under the GNU General Public License version 2.
+
+The full text of the GPL v2 license can be found [here](http://www.gnu.org/licenses/gpl-2.0.html).
+
+Parts of the Qubes OS under proprietary license
+-----------------------------------------------
+
+Some software produced by the Qubes Project is proprietary software of Invisible Things Lab. Those parts are not distributed as part of the Qubes OS installation ISOs, but can be downloaded separately.
+
+The following software is licensed under a proprietary license:
+
+-   Qubes Windows Support Tools
+
+Note on rights to double-licensing of the Qubes code
+----------------------------------------------------
+
+Invisible Things Lab (ITL), who has funded and run the Qubes project since the beginning, and who has contributed majority of Qubes-specific code (specifically: `core-*`, `gui-*`, and `qubes-*` repositories) would like to have a right to redistribute parts of this code under proprietary licenses. This is especially important for Qubes R3 and later, where the new architecture allows the creation of many editions of Qubes, using different hypervisors, some of which might not be open source. That's why we ask every developer who contributes code to Qubes project to grant ITL permission to reuse the code under a different license, and to express this consent by including the [standard signed-off line](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=HEAD#n358) in the commit.

developers/QubesResearch.md

@@ -0,0 +1,32 @@
+---
+layout: doc
+title: QubesResearch
+permalink: /doc/QubesResearch/
+redirect_from: /wiki/QubesResearch/
+---
+
+Here are some links to various papers/research projects that somehow relate to Qubes.
+
+### Attacks on Intel TXT
+
+-   [Attacking Intel® Trusted Execution Technology](http://invisiblethingslab.com/resources/bh09dc/Attacking%20Intel%20TXT%20-%20paper.pdf) by Rafal Wojtczuk, Joanna Rutkowska
+-   [ACPI: Design Principles and Concerns](http://www.ssi.gouv.fr/IMG/pdf/article_acpi.pdf) by Loic Duflot, Olivier Levillain, and Benjamin Morin
+-   [Another Way to Circumvent Intel® Trusted Execution Technology](http://invisiblethingslab.com/resources/misc09/Another%20TXT%20Attack.pdf) by Rafal Wojtczuk, Joanna Rutkowska, Alex Tereshkin
+-   [Attacking Intel TXT® via SINIT code execution hijacking](http://www.invisiblethingslab.com/resources/2011/Attacking_Intel_TXT_via_SINIT_hijacking.pdf) by Rafal Wojtczuk and Joanna Rutkowska
+
+### Software attacks coming through devices
+
+-   [Can you still trust your network card?](http://www.ssi.gouv.fr/IMG/pdf/csw-trustnetworkcard.pdf) by Loïc Duflot, Yves-Alexis Perez and others
+-   [Remotely Attacking Network Cards (or why we do need VT-d and TXT)](http://theinvisiblethings.blogspot.com/2010/04/remotely-attacking-network-cards-or-why.html) by Joanna Rutkowska
+-   [On Formally Verified Microkernels (and on attacking them)](http://theinvisiblethings.blogspot.com/2010/05/on-formally-verified-microkernels-and.html) by Joanna Rutkowska
+-   [Following the White Rabbit: Software Attacks against Intel® VT-d](http://www.invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf) by Rafal Wojtczuk and Joanna Rutkowska
+
+### Application-level security
+
+-   [Virtics: A System for Privilege Separation of Legacy Desktop Applications](http://www.eecs.berkeley.edu/Pubs/TechRpts/2010/EECS-2010-70.pdf) by Matt Piotrowski
+
+### VMM/Xen disagregation
+
+-   [[http://tjd.phlegethon.org/words/sosp11-xoar.pdf](http://tjd.phlegethon.org/words/sosp11-xoar.pdf) "Breaking Up is Hard to Do: Security and Functionality in a Commodity Hypervisor] by Patrick Colp at el.
+     (Also see [this thread on xen-devel](http://www.gossamer-threads.com/lists/xen/devel/230011))
+

developers/SystemDoc.md

@@ -9,7 +9,9 @@ System Documentation for Developers
 ===================================
 
 1.  Fundamentals:
-    1.  Qubes OS Architecture v0.3 [(pdf)](http://files.qubes-os.org/files/doc/arch-spec-0.3.pdf) (The original 2009 document that started this all...)
+    1.  Qubes OS Architecture
+        1. [Overview](/doc/QubesArchitecture/)
+        2. [Architecture Spec v0.3 [PDF]](http://files.qubes-os.org/files/doc/arch-spec-0.3.pdf) (The original 2009 document that started this all...)
     2.  [Security-critical elements of Qubes OS](/doc/SecurityCriticalCode/)
     3.  Qubes RPC framework (qrexec):
         1.  [The Qubes RPC/Service API](/doc/Qrexec/)

developers/VersionScheme.md

@@ -0,0 +1,146 @@
+---
+layout: doc
+title: VersionScheme
+permalink: /doc/VersionScheme/
+redirect_from: /wiki/VersionScheme/
+---
+
+Version Scheme
+==============
+
+Beginning with R3 release, we change (and formalise) the versioning scheme.
+From now on, it will be as follows.
+
+Qubes distributions and products
+--------------------------------
+
+We intend to make it easy to make a remix of qubes, targetting another
+hypervisor or isolation provider. We may also create commercial products
+intended for specific circumstances. There is one distinguished distribution
+called **Qubes OS**. All source code for it is available for download under GPL
+licence and is openly developed on the mailing lists. The rest of this document
+discusses Qubes OS. Another remix may have its own version series.
+
+Release version
+---------------
+
+Qubes OS as a whole is released from time to time. Version scheme for all
+releases is modelled after Linux kernel version numbers. When announcing new
+release, we decide on the major.minor version (like `3.0`) and release
+`3.0-rc1`. When we feel that enough progress has been made, we put `3.0-rc2`
+and so on. All these versions are considered unstable and not ready for
+production. You may ask for support on mailing lists (specifically
+**qubes-devel**), but it is not guaranteed (you may for example get answer
+„update to newer `-rc`”). Public ISO image may or may not be available.
+
+When enough development has been made, we announce the first stable version,
+like e.g. `3.0.0` (i.e. without `-rc`). This version is considered stable and
+we support it for some period. Core components are branched at this moment and
+bugfixes are backported from master branch. Questions about stable release
+should be directed to the **qubes-users** mailing list. No major features and
+interface incompatibilities are to be included in this release. We release
+bugfixes as `3.0.1`, `3.0.2` and so on, while new features come into the next
+release e.g. `3.1-rcX`.
+
+Tickets in the tracker are sorted out by release major.minor, such as `3.0`,
+`3.1` (trac calls this „milestone”).
+
+Release schedule
+----------------
+
+There is no specific schedule for major and minor other that more general
+roadmap. When time comes, Supreme Committee declares feature freeze and tags
+`-rc1` and releases ISO image. From this time on, no new features are accepted.
+Also a strict time schedule kicks in.
+
+Each release candidate period is as follows. For the first two weeks we accept
+and assign bugreports to be fixed before next release candidate. For the next
+two weeks we generally focus on fixing assigned bugreports, so issues discovered
+during this time may be postponed until later RC. Finally after that there is
+one week of current-testing freeze, during which time no new packages are
+released, in hope that they will be installed by wider user base and tested.
+
+The next RC is released five weeks after the former. All packets are published
+in `current` repository and the cycle starts over. There should be no less than
+1 and no more than 3 release candidates before final release.
+
+<table>
+    <thead>
+        <tr><th>stage</th><th>time</th></tr>
+    </thead>
+    <tbody>
+        <tr><td>initial testing</td><td>2 weeks</td></tr>
+        <tr><td>bug fixing</td><td>2 weeks</td></tr>
+        <tr><td>`current-testing` freeze</td><td>1 week</td></tr>
+    </tbody>
+</table>
+
+Starting with second cycle (that is, after `-rc1`) two weeks into the cycle
+(after primary bug-reporting period) the Supreme Committee decides wether there
+should be another RC. If, based on remaining issues, the Committee decides to
+release final, then the Committee agrees upon the release date, which should be
+no later than a week after.
+
+Bug priorities
+--------------
+
+When deciding whether the current release candidate is the final one, the Committee
+takes bugs priorities into consideration. The meaning of them is as follows:
+
+* `blocker` - when any such bug is present in the current release candidate, it
+can't be considered final release. Bugs with this priority must be fixed before
+the next release candidate, even if that means delaying its release (which
+should be considered only last resort option).
+
+* `critical` - when any such bug is present in the current release candidate, it
+can't be considered final release. But such bugs are not qualified to delay
+next release candidate release.
+
+* `major` - existence of such bugs do not strictly prevent the current release
+candidate be considered final (but of course we should try hard to not have
+them there). Fixing bugs of this priority can be delayed and qualified as
+updates to the final stable release.
+
+* `minor` - existence of such bugs do not prevent the current release candidate
+be considered final. Fixing such bugs can be delayed to the next Qubes OS
+release. Eventually such fixes might be backported as an update to the stable
+release(s).
+
+All above is about bugs, no features should be assigned to the current release
+after first `-rc`. Supreme Committee is free to adjust priorities appropriately.
+
+Component version
+-----------------
+
+Qubes release is defined as specific versions of components, which are
+developed more or less separately. Their versions are composed of major and
+minor version of target Qubes OS release followed by third component which is
+just incremented. There is no apparent indication that given version is stable
+or not.
+
+There are some non-essential components like `qubes-apps-*` that are shared
+between releases. Their versions indicate oldest qubes-release that is
+supported. We try hard to support multiple releases by one branch to ease code
+maintenance.
+
+Different Qubes releases remixes may comprise of different components and
+version are not guaranteed to be monotonic between releases. We may decide that
+for newer release some component should be downgraded. There is no guarantee
+that arbitrary combination of different versions of random components will
+yield usable (or even install-able) compilation.
+
+Git tags and branches
+---------------------
+
+We mark each component version in the repository by tag containing
+`v<version>`. Likewise, each Qubes OS release is marked by `R<release>` tag.
+
+At the release of some release we create branches named like `release2`. Only
+bugfixes and compatible improvements are backported to these branches. These
+branches should compile. All new development is done in `master` branch. This
+branch is totally unsupported and may not even compile depending on maintainer
+of repository.
+
+All version and release tags should be made and signed by someone from ITL
+staff. Public keys are included in `qubes-builder` and available at
+[https://keys.qubes-os.org/keys/](https://keys.qubes-os.org/keys/).