mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2025-05-02 23:05:19 -04:00
Merge branch 'md-refactoring-links' of https://github.com/tokideveloper/qubes-doc into tokideveloper-md-refactoring-links
This commit is contained in:
Andrew David Wong
commit
d2fa42c1e9
72 changed files with 733 additions and 1481 deletions
|
|
@ -323,7 +323,7 @@ current and current-testing).
|
|||
|
||||
### RPM packages - yum repo
|
||||
|
||||
In source VM, grab [linux-yum] repository (below is assumed you've made it in
|
||||
In source VM, grab [linux-yum](https://github.com/QubesOS/qubes-linux-yum) repository (below is assumed you've made it in
|
||||
`~/repo-yum-upload` directory) and replace `update_repo.sh` script with:
|
||||
|
||||
~~~
|
||||
|
|
@ -339,7 +339,7 @@ find -type f -name '*.rpm' -delete
|
|||
qrexec-client-vm $VMNAME local.UpdateYum
|
||||
~~~
|
||||
|
||||
In target VM, setup actual yum repository (also based on [linux-yum], this time
|
||||
In target VM, setup actual yum repository (also based on [linux-yum](https://github.com/QubesOS/qubes-linux-yum), this time
|
||||
without modifications). You will also need to setup some gpg key for signing
|
||||
packages (it is possible to force yum to install unsigned packages, but it
|
||||
isn't possible for `qubes-dom0-update` tool). Fill `~/.rpmmacros` with
|
||||
|
|
@ -387,7 +387,7 @@ Of course you will also need to setup qrexec policy in dom0
|
|||
If you want to access the repository from network, you need to setup HTTP
|
||||
server serving it, and configure the system to let other machines actually
|
||||
reach this HTTP server. You can use for example using [port
|
||||
forwarding][port-forwarding] or setting up Tor hidden service. Configuration
|
||||
forwarding](/doc/firewall/#port-forwarding-to-a-qube-from-the-outside-world) or setting up Tor hidden service. Configuration
|
||||
details of those services are outside of the scope of this page.
|
||||
|
||||
Usage: setup `builder.conf` in source VM to use your dummy-uploader repository:
|
||||
|
|
@ -419,7 +419,7 @@ Remember to also import gpg public key using `rpm --import`.
|
|||
|
||||
Steps are mostly the same as in the case of yum repo. The only details that differ:
|
||||
|
||||
- use [linux-deb] instead of [linux-yum] as a base - both in source and target VM
|
||||
- use [linux-deb](https://github.com/QubesOS/qubes-linux-deb) instead of [linux-yum](https://github.com/QubesOS/qubes-linux-yum) as a base - both in source and target VM
|
||||
- use different `update_repo.sh` script in source VM (below)
|
||||
- use `local.UpdateApt` qrexec service in target VM (code below)
|
||||
- in target VM additionally place `update-local-repo.sh` script in repository dir (code below)
|
||||
|
|
@ -539,6 +539,3 @@ 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/firewall/#port-forwarding-to-a-qube-from-the-outside-world
|
||||
[linux-yum]: https://github.com/QubesOS/qubes-linux-yum
|
||||
[linux-deb]: https://github.com/QubesOS/qubes-linux-deb
|
||||
|
|
|
|||
|
|
@ -8,13 +8,13 @@ title: Code Signing
|
|||
|
||||
# Code Signing
|
||||
|
||||
All contributions to the Qubes OS [source code] must be cryptographically signed by the author's PGP key.
|
||||
All contributions to the Qubes OS [source code](/doc/source-code/) must be cryptographically signed by the author's PGP key.
|
||||
|
||||
## Generating a Key
|
||||
|
||||
(Note: If you already have a PGP key, you may skip this step.)
|
||||
|
||||
Alex Cabal has written an excellent [guide] on creating a PGP keypair.
|
||||
Alex Cabal has written an excellent [guide](https://alexcabal.com/creating-the-perfect-gpg-keypair/) on creating a PGP keypair.
|
||||
Below, we reproduce just the minimum steps in generating a keypair using GnuPG.
|
||||
Please read Cabal's full guide for further important details.
|
||||
|
||||
|
|
@ -143,13 +143,12 @@ your Git commits.
|
|||
GitHub shows a green `Verified` label indicating that the GPG signature could be
|
||||
verified using any of the contributor’s GPG keys uploaded to GitHub. You can
|
||||
upload your public key on GitHub by adding your public GPG key on the [New GPG
|
||||
key][GitHub New GPG key] under the [SSH GPG keys page][GitHub SSH GPG keys
|
||||
page].
|
||||
key](https://github.com/settings/gpg/new) under the [SSH GPG keys page](https://github.com/settings/keys).
|
||||
|
||||
## Code Signature Checks
|
||||
|
||||
The [signature-checker] checks if code contributions are signed.
|
||||
Although GitHub adds a little green `Verified` button next to the commit, the [signature-checker] uses this algorithm to check if a commit is correctly signed:
|
||||
The [signature-checker](https://github.com/marmarek/signature-checker) checks if code contributions are signed.
|
||||
Although GitHub adds a little green `Verified` button next to the commit, the [signature-checker](https://github.com/marmarek/signature-checker) uses this algorithm to check if a commit is correctly signed:
|
||||
|
||||
1. Is the commit signed?
|
||||
If the commit is not signed, you can see the message
|
||||
|
|
@ -194,21 +193,14 @@ In this case, you have several options to sign the commit:
|
|||
|
||||
> policy/qubesos/code-signing — Unable to verify (no valid key found)
|
||||
|
||||
This means that the [signature-checker] has found a signature for the commit
|
||||
This means that the [signature-checker](https://github.com/marmarek/signature-checker) has found a signature for the commit
|
||||
but is not able to verify it using the any key available.
|
||||
This might be that you forgot to upload the key to a key server.
|
||||
Please upload it.
|
||||
|
||||
## Using PGP with Email
|
||||
|
||||
If you're submitting a patch by emailing the [developer mailing list], simply sign your email with your PGP key.
|
||||
One good way to do this is with a program like [Enigmail].
|
||||
If you're submitting a patch by emailing the [developer mailing list](/support/#qubes-devel), simply sign your email with your PGP key.
|
||||
One good way to do this is with a program like [Enigmail](https://www.enigmail.net/).
|
||||
Enigmail is a security addon for the Mozilla Thunderbird email client that allows you to easily digitally encrypt and sign your emails.
|
||||
|
||||
[guide]: https://alexcabal.com/creating-the-perfect-gpg-keypair/
|
||||
[source code]: /doc/source-code/
|
||||
[developer mailing list]: /support/#qubes-devel
|
||||
[Enigmail]: https://www.enigmail.net/
|
||||
[signature-checker]: https://github.com/marmarek/signature-checker
|
||||
[GitHub New GPG key]: https://github.com/settings/gpg/new
|
||||
[GitHub SSH GPG keys page]: https://github.com/settings/keys
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ several components, each of which has its own separate repository, for example:
|
|||
* `linux-template-builder.git` -- Scripts and other files used to create Qubes
|
||||
template images.
|
||||
|
||||
All of our repositories are available under the [QubesOS GitHub account].
|
||||
All of our repositories are available under the [QubesOS GitHub account](https://github.com/QubesOS/).
|
||||
|
||||
To clone a repository:
|
||||
|
||||
|
|
@ -38,7 +38,7 @@ git clone https://github.com/QubesOS/qubes-core-admin.git core-admin
|
|||
~~~
|
||||
|
||||
To build Qubes you do not need to download all these repositories.
|
||||
If you use [qubes builder] you can specify *what* you want to build, and download only the repositories needed to build that target.
|
||||
If you use [qubes builder](/doc/QubesBuilder/) you can specify *what* you want to build, and download only the repositories needed to build that target.
|
||||
|
||||
If you really do want to clone **all** of the repositories, you can use these commands:
|
||||
|
||||
|
|
@ -58,17 +58,17 @@ find . -mindepth 1 -maxdepth 1 -type d -exec git -C {} fetch --tags --recurse-su
|
|||
How to Send Patches
|
||||
-------------------
|
||||
|
||||
If you want to [contribute code] to the project, there are two ways. Whichever
|
||||
method you choose, you must [sign your code] before it can be accepted.
|
||||
If you want to [contribute code](/doc/contributing/#contributing-code) to the project, there are two ways. Whichever
|
||||
method you choose, you must [sign your code](/doc/code-signing/) before it can be accepted.
|
||||
|
||||
* **Preferred**: Use GitHub's [fork & pull requests].
|
||||
* **Preferred**: Use GitHub's [fork & pull requests](https://guides.github.com/activities/forking/).
|
||||
|
||||
Opening a pull request on GitHub greatly eases the code review and tracking
|
||||
process. In addition, especially for bigger changes, it's a good idea to send
|
||||
a message to the [qubes-devel mailing list] in order to notify people who
|
||||
a message to the [qubes-devel mailing list](/support/#qubes-devel) in order to notify people who
|
||||
do not receive GitHub notifications.
|
||||
|
||||
* Send a patch to the [qubes-devel mailing list] (`git format-patch`).
|
||||
* Send a patch to the [qubes-devel mailing list](/support/#qubes-devel) (`git format-patch`).
|
||||
|
||||
1. Make all the changes in your working directory, i.e. edit files, move them
|
||||
around (you can use 'git mv' for this), etc.
|
||||
|
|
@ -84,10 +84,3 @@ method you choose, you must [sign your code] before it can be accepted.
|
|||
5. Send your patch to `qubes-devel`. Start the message subject with
|
||||
`[PATCH]`.
|
||||
|
||||
|
||||
[QubesOS GitHub account]: https://github.com/QubesOS/
|
||||
[contribute code]: /doc/contributing/#contributing-code
|
||||
[sign your code]: /doc/code-signing/
|
||||
[fork & pull requests]: https://guides.github.com/activities/forking/
|
||||
[qubes-devel mailing list]: /support/#qubes-devel
|
||||
[qubes builder]: /doc/QubesBuilder/
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ title: Automated Tests
|
|||
|
||||
## Unit and Integration Tests
|
||||
|
||||
Starting with Qubes R3 we use [python unittest][unittest] to perform automatic tests of Qubes OS.
|
||||
Starting with Qubes R3 we use [python unittest](https://docs.python.org/3/library/unittest.html) to perform automatic tests of Qubes OS.
|
||||
Despite the name, we use it for both [unit tests](https://en.wikipedia.org/wiki/Unit_tests) and [integration tests](https://en.wikipedia.org/wiki/Integration_tests).
|
||||
The main purpose is, of course, to deliver much more stable releases.
|
||||
|
||||
|
|
@ -123,7 +123,7 @@ Tests are also compatible with nose2 test runner, so you can use this instead:
|
|||
sudo systemctl stop qubesd; sudo -E nose2 -v --plugin nose2.plugins.loader.loadtests qubes.tests; sudo systemctl start qubesd
|
||||
```
|
||||
|
||||
This may be especially useful together with various nose2 plugins to store tests results (for example `nose2.plugins.junitxml`), to ease presenting results. This is what we use on [OpenQA].
|
||||
This may be especially useful together with various nose2 plugins to store tests results (for example `nose2.plugins.junitxml`), to ease presenting results. This is what we use on [OpenQA](http://open.qa/).
|
||||
|
||||
### Unit testing inside a VM
|
||||
|
||||
|
|
@ -251,7 +251,7 @@ class SomeTestCase(unittest.TestCase):
|
|||
**Tests:** <https://github.com/marmarek/openqa-tests-qubesos>
|
||||
|
||||
Manually testing the installation of Qubes OS is a time-consuming process.
|
||||
We use [openQA] to automate this process.
|
||||
We use [OpenQA](http://open.qa/) to automate this process.
|
||||
It works by installing Qubes in KVM and interacting with it as a user would, including simulating mouse clicks and keyboard presses.
|
||||
Then, it checks the output to see whether various tests were passed, e.g. by comparing the virtual screen output to screenshots of a successful installation.
|
||||
|
||||
|
|
@ -262,5 +262,3 @@ Nonetheless, PV works well, which is sufficient for automated installation testi
|
|||
|
||||
Thanks to an anonymous donor, our openQA system is hosted in a datacenter on hardware that meets these requirements.
|
||||
|
||||
[unittest]: https://docs.python.org/3/library/unittest.html
|
||||
[OpenQA]: http://open.qa/
|
||||
|
|
|
|||
|
|
@ -53,6 +53,5 @@ From the GUI, or from the command line:
|
|||
|
||||
# References
|
||||
|
||||
Please consult this issue's [comment].
|
||||
Please consult this issue's [comment](https://github.com/QubesOS/qubes-issues/issues/4687#issuecomment-451626625).
|
||||
|
||||
[comment]: https://github.com/QubesOS/qubes-issues/issues/4687#issuecomment-451626625
|
||||
|
|
|
|||
|
|
@ -12,17 +12,17 @@ title: Documentation Guidelines
|
|||
|
||||
# Documentation guidelines
|
||||
|
||||
All Qubes OS documentation pages are stored as plain text files in the dedicated [qubes-doc] repository.
|
||||
All Qubes OS documentation pages are stored as plain text files in the dedicated [qubes-doc](https://github.com/QubesOS/qubes-doc) repository.
|
||||
By cloning and regularly pulling from this repo, users can maintain their own up-to-date offline copy of all Qubes documentation rather than relying solely on the web.
|
||||
|
||||
The documentation is a community effort. Volunteers work hard trying to keep everything accurate and comprehensive.
|
||||
If you notice a problem or some way it can be improved, please [edit the documentation][contribute]!
|
||||
If you notice a problem or some way it can be improved, please [edit the documentation](#how-to-contribute)!
|
||||
|
||||
## Security
|
||||
|
||||
*Also see: [Should I trust this website?](/faq/#should-i-trust-this-website)*
|
||||
|
||||
All pull requests against [qubes-doc] must pass review prior to be merged, except in the case of [external documentation] (see [#4693]).
|
||||
All pull requests against [qubes-doc](https://github.com/QubesOS/qubes-doc) must pass review prior to be merged, except in the case of [external documentation](/doc/#external-documentation) (see [#4693](https://github.com/QubesOS/qubes-issues/issues/4693)).
|
||||
This process is designed to ensure that contributed text is accurate and non-malicious.
|
||||
This process is a best effort that should provide a reasonable degree of assurance, but it is not foolproof.
|
||||
For example, all text characters are checked for ANSI escape sequences.
|
||||
|
|
@ -36,9 +36,9 @@ In cases in which another reviewer is not required, the documentation maintainer
|
|||
|
||||
## Questions, problems, and improvements
|
||||
|
||||
If you have a question about something you read in the documentation, please send it to the appropriate [mailing list][support].
|
||||
If you see that something in the documentation should be fixed or improved, please [contribute] the change yourself.
|
||||
To report an issue with the documentation, please follow our standard [issue reporting guidelines][issue].
|
||||
If you have a question about something you read in the documentation, please send it to the appropriate [mailing list](/support/).
|
||||
If you see that something in the documentation should be fixed or improved, please [contribute](#how-to-contribute) the change yourself.
|
||||
To report an issue with the documentation, please follow our standard [issue reporting guidelines](/doc/reporting-bugs/).
|
||||
(If you report an issue with the documentation, you will likely be asked to address it, unless there is a clear indication in your report that you are not willing or able to do so.)
|
||||
|
||||
## How to contribute
|
||||
|
|
@ -50,17 +50,17 @@ A few notes before we get started:
|
|||
* Since Qubes is a security-oriented project, every documentation change will be reviewed before it's accepted.
|
||||
This allows us to maintain quality control and protect our users.
|
||||
* We don't want you to spend time and effort on a contribution that we can't accept.
|
||||
If your contribution would take a lot of time, please [file an issue][issue] for it first so that we can make sure we're on the same page before significant works begins.
|
||||
If your contribution would take a lot of time, please [file an issue](/doc/reporting-bugs/) for it first so that we can make sure we're on the same page before significant works begins.
|
||||
* Alternatively, you may already have written content that doesn't conform to these guidelines, but you'd be willing to modify it so that it does.
|
||||
In this case, you can still submit it by following the instructions below.
|
||||
Just make a note in your pull request that you're aware of the changes that need to be made and that you're just asking for the content to be reviewed before you spend time making those changes.
|
||||
|
||||
As mentioned above, we keep all the documentation in a dedicated [Git repository][qubes-doc] hosted on [GitHub].
|
||||
As mentioned above, we keep all the documentation in a dedicated [Git repository](https://github.com/QubesOS/qubes-doc) hosted on [GitHub](https://github.com/).
|
||||
Thanks to GitHub's interface, you can edit the documentation even if you don't know Git at all!
|
||||
The only thing you need is a GitHub account, which is free.
|
||||
|
||||
(**Note:** If you're already familiar with GitHub or wish to work from the command line, you can skip the rest of this section.
|
||||
All you need to do to contribute is to [fork and clone][gh-fork] the [qubes-doc] repo, make your changes, then [submit a pull request][gh-pull].)
|
||||
All you need to do to contribute is to [fork and clone](https://guides.github.com/activities/forking/) the [qubes-doc](https://github.com/QubesOS/qubes-doc) repo, make your changes, then [submit a pull request](https://help.github.com/articles/using-pull-requests/).)
|
||||
|
||||
Ok, let's start.
|
||||
Every documentation page has an "Edit this page" button.
|
||||
|
|
@ -84,7 +84,7 @@ This step is only needed the first time you make a contribution.
|
|||
|
||||
Now you can make your modifications.
|
||||
You can also preview the changes to see how they'll be formatted by clicking the "Preview changes" tab.
|
||||
If you're making formatting changes, please [render the site locally] to verify that everything looks correct before submitting any changes.
|
||||
If you're making formatting changes, please [render the site locally](https://github.com/QubesOS/qubesos.github.io#instructions) to verify that everything looks correct before submitting any changes.
|
||||
|
||||
[](/attachment/wiki/doc-edit/06-edit.png)
|
||||
|
||||
|
|
@ -121,7 +121,7 @@ This will make the image a hyperlink to the image file, allowing the reader to c
|
|||
[](/attachment/wiki/page-title/image-filename.png)
|
||||
```
|
||||
|
||||
Then, submit your image(s) in a separate pull request to the [qubes-attachment] repository using the same path and filename.
|
||||
Then, submit your image(s) in a separate pull request to the [qubes-attachment](https://github.com/QubesOS/qubes-attachment) repository using the same path and filename.
|
||||
This is the only permitted way to include images.
|
||||
Do not link to images on other websites.
|
||||
|
||||
|
|
@ -140,11 +140,11 @@ There are some exceptions to this policy (e.g., information that is certain not
|
|||
|
||||
### Core vs. external documentation
|
||||
|
||||
Core documentation resides in the [Qubes OS Project's official repositories](https://github.com/QubesOS/), mainly in [qubes-doc].
|
||||
Core documentation resides in the [Qubes OS Project's official repositories](https://github.com/QubesOS/), mainly in [qubes-doc](https://github.com/QubesOS/qubes-doc).
|
||||
External documentation can be anywhere else (such as forums, community websites, and blogs), but there is an especially large collection in the [Qubes Community](https://github.com/Qubes-Community) project.
|
||||
External documentation should not be submitted to [qubes-doc].
|
||||
If you've written a piece of documentation that is not appropriate for [qubes-doc], we encourage you to submit it to the [Qubes Community](https://github.com/Qubes-Community) project instead.
|
||||
However, *linking* to external documentation from [qubes-doc] is perfectly fine.
|
||||
External documentation should not be submitted to [qubes-doc](https://github.com/QubesOS/qubes-doc).
|
||||
If you've written a piece of documentation that is not appropriate for [qubes-doc](https://github.com/QubesOS/qubes-doc), we encourage you to submit it to the [Qubes Community](https://github.com/Qubes-Community) project instead.
|
||||
However, *linking* to external documentation from [qubes-doc](https://github.com/QubesOS/qubes-doc) is perfectly fine.
|
||||
Indeed, the maintainers of the [Qubes Community](https://github.com/Qubes-Community) project should regularly submit PRs against [this file](https://github.com/QubesOS/qubesos.github.io/blob/master/_data/index.yml) to add and update Qubes Community links in the "External Documentation" section of the documentation table of contents.
|
||||
|
||||
The main difference between **core** (or **official**) and **external** (or **community** or **unofficial**) documentation is whether it documents software that is officially written and maintained by the Qubes OS Project.
|
||||
|
|
@ -275,11 +275,11 @@ Over time, the different branches would diverge in non-version-specific content.
|
|||
Good general content that was submitted only to one branch would effectively disappear once that version was deprecated.
|
||||
(Even if it were still on the website, no one would look at it, since it would explicitly be in the subdirectory of a deprecated version, and there would be a motivation to remove it from the website so that search results wouldn't be populated with out-of-date information.)
|
||||
|
||||
For further discussion about version-specific documentation in Qubes, see [here][version-thread].
|
||||
For further discussion about version-specific documentation in Qubes, see [here](https://groups.google.com/d/topic/qubes-users/H9BZX4K9Ptk/discussion).
|
||||
|
||||
## Style guidelines
|
||||
|
||||
* Familiarize yourself with the terms defined in the [glossary]. Use these
|
||||
* Familiarize yourself with the terms defined in the [glossary](/doc/glossary/). Use these
|
||||
terms consistently and accurately throughout your writing.
|
||||
* Syntactically distinguish variables in commands.
|
||||
For example, this is ambiguous:
|
||||
|
|
@ -304,11 +304,11 @@ When making contributions, please try to observe the following style conventions
|
|||
* Do not write HTML inside Markdown documents (except in rare, unavoidable cases, such as alerts).
|
||||
In particular, never include HTML or CSS for styling, formatting, or white space control.
|
||||
That belongs in the (S)CSS files instead.
|
||||
* Link only to images in [qubes-attachment] (see [instructions above](#how-to-add-images)).
|
||||
* Link only to images in [qubes-attachment](https://github.com/QubesOS/qubes-attachment) (see [instructions above](#how-to-add-images)).
|
||||
Do not link to images on other websites.
|
||||
* In order to enable offline browsing and automatic onion redirection, always use relative (rather than absolute) links, e.g., `/doc/doc-guidelines/` instead of `https://www.qubes-os.org/doc/doc-guidelines/`.
|
||||
Examples of exceptions:
|
||||
* The signed plain text portions of [QSBs] and [Canaries]
|
||||
* The signed plain text portions of [QSBs](/security/bulletins/) and [Canaries](/security/canaries/)
|
||||
* URLs that appear inside code blocks (e.g., in comments and document templates)
|
||||
* Files like `README.md` and `CONTRIBUTING.md`
|
||||
* Insert a newline at, and only at, the end of each sentence, except when the text will be reproduced outside of the Qubes website repo (see previous item for examples).
|
||||
|
|
@ -353,30 +353,10 @@ When making contributions, please try to observe the following style conventions
|
|||
* Use non-reference-style links like `[website](https://example.com/)`.
|
||||
Do *not* use reference links like `[website][example]`, `[website][]` or `[website]`.
|
||||
|
||||
([This][md] is a great source for learning about Markdown.)
|
||||
([This](https://daringfireball.net/projects/markdown/) is a great source for learning about Markdown.)
|
||||
|
||||
## Git conventions
|
||||
|
||||
Please try to write good commit messages, according to the
|
||||
[instructions in our coding style guidelines][git-commit].
|
||||
[instructions in our coding style guidelines](/doc/coding-style/#commit-message-guidelines).
|
||||
|
||||
[qubes-doc]: https://github.com/QubesOS/qubes-doc
|
||||
[glossary]: /doc/glossary/
|
||||
[issue]: /doc/reporting-bugs/
|
||||
[contribute]: #how-to-contribute
|
||||
[qubes-issues]: https://github.com/QubesOS/qubes-issues/issues
|
||||
[gh-fork]: https://guides.github.com/activities/forking/
|
||||
[gh-pull]: https://help.github.com/articles/using-pull-requests/
|
||||
[GitHub]: https://github.com/
|
||||
[support]: /support/
|
||||
[version-example]: /doc/template/fedora/upgrade-25-to-26/
|
||||
[version-thread]: https://groups.google.com/d/topic/qubes-users/H9BZX4K9Ptk/discussion
|
||||
[QSBs]: /security/bulletins/
|
||||
[Canaries]: /security/canaries/
|
||||
[News]: /news/
|
||||
[md]: https://daringfireball.net/projects/markdown/
|
||||
[git-commit]: /doc/coding-style/#commit-message-guidelines
|
||||
[render the site locally]: https://github.com/QubesOS/qubesos.github.io#instructions
|
||||
[qubes-attachment]: https://github.com/QubesOS/qubes-attachment
|
||||
[external documentation]: /doc/#external-documentation
|
||||
[#4693]: https://github.com/QubesOS/qubes-issues/issues/4693
|
||||
|
|
|
|||
|
|
@ -11,28 +11,28 @@ title: Google Summer of Code
|
|||
================
|
||||
## Information for Students
|
||||
|
||||
Thank you for your interest in participating in the [Google Summer of Code program][gsoc-qubes] with the [Qubes OS team][team]. You can read more about the Google Summer of Code program at the [official website][gsoc] and the [official FAQ][gsoc-faq].
|
||||
Thank you for your interest in participating in the [Google Summer of Code program](https://summerofcode.withgoogle.com/organizations/4675790572093440/) with the [Qubes OS team](/team/). You can read more about the Google Summer of Code program at the [official website](https://summerofcode.withgoogle.com/) and the [official FAQ](https://developers.google.com/open-source/gsoc/faq).
|
||||
|
||||
Being accepted as a Google Summer of Code student is quite competitive. Students wishing to participate in the Summer of Code must be aware that you will be required to produce code for Qubes OS for 3 months. Your mentors, Qubes developers, will dedicate a portion of their time towards mentoring you. Therefore, we seek candidates who are committed to helping Qubes long-term and are willing to do quality work and be proactive in communicating with your mentor.
|
||||
|
||||
You don't have to be a proven developer -- in fact, this whole program is meant to facilitate joining Qubes and other free and open source communities. The Qubes community maintains information about [contributing to Qubes development][contributing] and [how to send patches][patches]. In order to contribute code to the Qubes project, you must be able to [sign your code][code-signing].
|
||||
You don't have to be a proven developer -- in fact, this whole program is meant to facilitate joining Qubes and other free and open source communities. The Qubes community maintains information about [contributing to Qubes development](/doc/contributing/#contributing-code) and [how to send patches](/doc/source-code/#how-to-send-patches). In order to contribute code to the Qubes project, you must be able to [sign your code](/doc/code-signing/).
|
||||
|
||||
You should start learning the components that you plan on working on before the start date. Qubes developers are available on the [mailing lists][ml-devel] for help. The GSoC timeline reserves a lot of time for bonding with the project -- use that time wisely. Good communication is key, you should plan to communicate with your team daily and formally report progress and plans weekly. Students who neglect active communication will be failed.
|
||||
You should start learning the components that you plan on working on before the start date. Qubes developers are available on the [mailing lists](/support/#qubes-devel) for help. The GSoC timeline reserves a lot of time for bonding with the project -- use that time wisely. Good communication is key, you should plan to communicate with your team daily and formally report progress and plans weekly. Students who neglect active communication will be failed.
|
||||
|
||||
### Overview of Steps
|
||||
|
||||
- Join the [qubes-devel list][ml-devel] and introduce yourself, and meet your fellow developers
|
||||
- Read [Google's instructions for participating][gsoc-participate] and the [GSoC Student Manual][gsoc-student]
|
||||
- Join the [qubes-devel list](/support/#qubes-devel) and introduce yourself, and meet your fellow developers
|
||||
- Read [Google's instructions for participating](https://developers.google.com/open-source/gsoc/) and the [GSoC Student Manual](https://developers.google.com/open-source/gsoc/resources/manual#student_manual)
|
||||
- Take a look at the list of ideas below
|
||||
- Come up with a project that you are interested in (and feel free to propose your own! Don't feel limited by the list below.)
|
||||
- Read the Student Proposal guidelines below
|
||||
- Write a first draft proposal and send it to the qubes-devel mailing list for review
|
||||
- Submit proposal using [Google's web interface][gsoc-submit] ahead of the deadline (this requires a Google Account!)
|
||||
- Submit proposal using [Google's web interface](https://summerofcode.withgoogle.com/) ahead of the deadline (this requires a Google Account!)
|
||||
- Submit proof of enrollment well ahead of the deadline
|
||||
|
||||
Coming up with an interesting idea that you can realistically achieve in the time available to you (one summer) is probably the most difficult part. We strongly recommend getting involved in advance of the beginning of GSoC, and we will look favorably on applications from students who have already started to act like free and open source developers.
|
||||
|
||||
Before the summer starts, there are some preparatory tasks which are highly encouraged. First, if you aren't already, definitely start using Qubes as your primary OS as soon as possible! Also, it is encouraged that you become familiar and comfortable with the Qubes development workflow sooner than later. A good way to do this (and also a great way to stand out as an awesome applicant and make us want to accept you!) might be to pick up some issues from [qubes-issues][qubes-issues] (our issue-tracking repo) and submit some patches addressing them. Some suitable issues might be those with tags ["help wanted" and "P: minor"][qubes-issues-suggested] (although more significant things are also welcome, of course). Doing this will get you some practice with [qubes-builder][qubes-builder], our code-signing policies, and some familiarity with our code base in general so you are ready to hit the ground running come summer.
|
||||
Before the summer starts, there are some preparatory tasks which are highly encouraged. First, if you aren't already, definitely start using Qubes as your primary OS as soon as possible! Also, it is encouraged that you become familiar and comfortable with the Qubes development workflow sooner than later. A good way to do this (and also a great way to stand out as an awesome applicant and make us want to accept you!) might be to pick up some issues from [qubes-issues](https://github.com/QubesOS/qubes-issues/issues) (our issue-tracking repo) and submit some patches addressing them. Some suitable issues might be those with tags ["help wanted" and "P: minor"](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue%20is%3Aopen%20label%3A%22P%3A%20minor%22%20label%3A%22help%20wanted%22) (although more significant things are also welcome, of course). Doing this will get you some practice with [qubes-builder](/doc/qubes-builder/), our code-signing policies, and some familiarity with our code base in general so you are ready to hit the ground running come summer.
|
||||
|
||||
### Student proposal guidelines
|
||||
|
||||
|
|
@ -75,7 +75,7 @@ Other things to think about:
|
|||
|
||||
## Project Ideas
|
||||
|
||||
These project ideas were contributed by our developers and may be incomplete. If you are interested in submitting a proposal based on these ideas, you should contact the [qubes-devel mailing list][ml-devel] and associated GitHub issue to learn more about the idea.
|
||||
These project ideas were contributed by our developers and may be incomplete. If you are interested in submitting a proposal based on these ideas, you should contact the [qubes-devel mailing list](/support/#qubes-devel) and associated GitHub issue to learn more about the idea.
|
||||
|
||||
```
|
||||
### Adding a Proposal
|
||||
|
|
@ -463,7 +463,7 @@ Details, reference: [#2233](https://github.com/QubesOS/qubes-issues/issues/2233)
|
|||
|
||||
**Knowledge prerequisite**:
|
||||
|
||||
**Mentor**: Inquire on [qubes-devel][ml-devel].
|
||||
**Mentor**: Inquire on [qubes-devel](/support/#qubes-devel).
|
||||
|
||||
### Admin API Fuzzer
|
||||
|
||||
|
|
@ -487,7 +487,7 @@ A [Fuzzer](https://en.wikipedia.org/wiki/Fuzzing) would help to automate part of
|
|||
- some knowledge about fuzzing & existing fuzzing frameworks (e.g. [oss-fuzz](https://github.com/google/oss-fuzz/tree/master/projects/qubes-os))
|
||||
- a hacker's curiosity
|
||||
|
||||
**Mentor**: Inquire on [qubes-devel][ml-devel].
|
||||
**Mentor**: Inquire on [qubes-devel](/support/#qubes-devel).
|
||||
|
||||
|
||||
### Secure Boot support
|
||||
|
|
@ -525,7 +525,7 @@ A [Fuzzer](https://en.wikipedia.org/wiki/Fuzzing) would help to automate part of
|
|||
|
||||
## Past Projects
|
||||
|
||||
You can view the projects we had in 2017 in the [GSoC 2017 archive][2017-archive]. We also participated in GSoC 2020, and you can see the project in the [GSoC 2020 archive][2020-archive].
|
||||
You can view the projects we had in 2017 in the [GSoC 2017 archive](https://summerofcode.withgoogle.com/archive/2017/organizations/5074771758809088/). We also participated in GSoC 2020, and you can see the project in the [GSoC 2020 archive](https://summerofcode.withgoogle.com/archive/2020/organizations/4924517870206976/).
|
||||
|
||||
Here are some successful projects which have been implemented in the past by Google Summer of Code participants.
|
||||
|
||||
|
|
@ -588,21 +588,3 @@ would override all the user changes there). More details:
|
|||
|
||||
We adapted some of the language here about GSoC from the [KDE GSoC page](https://community.kde.org/GSoC).
|
||||
|
||||
[2017-archive]: https://summerofcode.withgoogle.com/archive/2017/organizations/5074771758809088/
|
||||
[2020-archive]: https://summerofcode.withgoogle.com/archive/2020/organizations/4924517870206976/
|
||||
[gsoc-qubes]: https://summerofcode.withgoogle.com/organizations/4675790572093440/
|
||||
[gsoc]: https://summerofcode.withgoogle.com/
|
||||
[team]: /team/
|
||||
[gsoc-faq]: https://developers.google.com/open-source/gsoc/faq
|
||||
[contributing]: /doc/contributing/#contributing-code
|
||||
[patches]: /doc/source-code/#how-to-send-patches
|
||||
[code-signing]: /doc/code-signing/
|
||||
[ml-devel]: /support/#qubes-devel
|
||||
[gsoc-participate]: https://developers.google.com/open-source/gsoc/
|
||||
[gsoc-student]: https://developers.google.com/open-source/gsoc/resources/manual#student_manual
|
||||
[how-to-gsoc]: http://teom.org/blog/kde/how-to-write-a-kick-ass-proposal-for-google-summer-of-code/
|
||||
[gsoc-submit]: https://summerofcode.withgoogle.com/
|
||||
[mailing-lists]: /support/
|
||||
[qubes-issues]: https://github.com/QubesOS/qubes-issues/issues
|
||||
[qubes-issues-suggested]: https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue%20is%3Aopen%20label%3A%22P%3A%20minor%22%20label%3A%22help%20wanted%22
|
||||
[qubes-builder]: /doc/qubes-builder/
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ title: Google Season of Docs
|
|||
|
||||
# 2021 Google Season of Docs
|
||||
|
||||
Thank you for your interest in participating in the [2021 Google Season of Docs][gsod] program with the [Qubes OS team][team]. You can read more about the Google Season of Docs in the official [guides][gsod-doc] and [FAQ][gsod-faq].
|
||||
Thank you for your interest in participating in the [2021 Google Season of Docs](https://developers.google.com/season-of-docs/) program with the [Qubes OS team](/team/). You can read more about the Google Season of Docs in the official [guides](https://developers.google.com/season-of-docs/docs/) and [FAQ](https://developers.google.com/season-of-docs/docs/faq).
|
||||
|
||||
## 2021 Project Idea
|
||||
|
||||
|
|
@ -83,9 +83,9 @@ within the times allotted. The past Google Season of Docs projects have given us
|
|||
|
||||
## Past Projects
|
||||
|
||||
You can view the project we had in 2019 in the [2019 GSoD archive][2019-qubes-gsod] and the [2019 writer's report][2019-qubes-report].
|
||||
You can view the project we had in 2019 in the [2019 GSoD archive](https://developers.google.com/season-of-docs/docs/2019/participants/project-qubes) and the [2019 writer's report](https://refre.ch/report-qubesos/).
|
||||
|
||||
You can also view the project we had in 2020 in the [2020 GSoD archive][2020-qubes-gsod] and the [2020 writer's report][2020-qubes-report].
|
||||
You can also view the project we had in 2020 in the [2020 GSoD archive](https://developers.google.com/season-of-docs/docs/2020/participants/project-qubesos-c1e0) and the [2020 writer's report](https://gist.github.com/PROTechThor/bfe9b8b28295d88c438b6f6c754ae733).
|
||||
|
||||
Here are some successful projects which have been implemented in the past by Google Season of Docs participants.
|
||||
|
||||
|
|
@ -99,14 +99,14 @@ This could be helped by writing consolidated guide with with a clear list of sym
|
|||
**Expected results**:
|
||||
|
||||
- Review existing [troubleshooting guides](/doc/#troubleshooting)
|
||||
- Review [issues][doc-issues] containing common troubleshooting steps (checking specific logs etc)
|
||||
- Review [issues](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+label%3A%22C%3A+doc%22) containing common troubleshooting steps (checking specific logs etc)
|
||||
- Propose updated, consolidated troubleshooting documentation, including its layout
|
||||
|
||||
**Knowledge prerequisite**:
|
||||
|
||||
- [Markdown][markdown]
|
||||
- [Markdown](https://daringfireball.net/projects/markdown/)
|
||||
|
||||
**Mentor**: [Marek Marczykowski-Górecki][team]
|
||||
**Mentor**: [Marek Marczykowski-Górecki](/team/)
|
||||
|
||||
### Improve Getting Started page
|
||||
|
||||
|
|
@ -122,9 +122,9 @@ This could be helped by writing consolidated guide with with a clear list of sym
|
|||
**Knowledge prerequisite**:
|
||||
|
||||
- basic Qubes OS knowledge
|
||||
- [Markdown][markdown]
|
||||
- [Markdown](https://daringfireball.net/projects/markdown/)
|
||||
|
||||
**Mentor**: [Michael Carbone][team]
|
||||
**Mentor**: [Michael Carbone](/team/)
|
||||
|
||||
### Rewrite qrexec documentation
|
||||
|
||||
|
|
@ -143,26 +143,7 @@ Fixing this last point may require very close cooperation with developers, as th
|
|||
|
||||
**Knowledge prerequisite**:
|
||||
|
||||
- [Markdown][markdown]
|
||||
- [Markdown](https://daringfireball.net/projects/markdown/)
|
||||
|
||||
**Mentor**: [Marek Marczykowski-Górecki][team]
|
||||
**Mentor**: [Marek Marczykowski-Górecki](/team/)
|
||||
|
||||
|
||||
[gsod]: https://developers.google.com/season-of-docs/
|
||||
[team]: /team/
|
||||
[gsod-doc]: https://developers.google.com/season-of-docs/docs/
|
||||
[gsod-faq]: https://developers.google.com/season-of-docs/docs/faq
|
||||
[gsod.md]: https://github.com/QubesOS/qubes-doc/blob/master/developer/general/gsod.md
|
||||
[gsod-2020-thread]: https://groups.google.com/d/msgid/qubes-project/aac9b148-4081-ebd8-cb9d-9a9191033484%40qubes-os.org
|
||||
[Documentation Guidelines]: /doc/doc-guidelines/
|
||||
[Help, Support, and Mailing Lists]: /support/
|
||||
[intro]: /intro/
|
||||
[getting started]: /getting-started/
|
||||
[markdown]: https://daringfireball.net/projects/markdown/
|
||||
[doc-issues]: https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+label%3A%22C%3A+doc%22
|
||||
[2019-qubes-gsod]: https://developers.google.com/season-of-docs/docs/2019/participants/project-qubes
|
||||
[2019-qubes-report]: https://refre.ch/report-qubesos/
|
||||
[2020-qubes-gsod]: https://developers.google.com/season-of-docs/docs/2020/participants/project-qubesos-c1e0
|
||||
[2020-qubes-report]: https://gist.github.com/PROTechThor/bfe9b8b28295d88c438b6f6c754ae733
|
||||
[existing installation guide]: https://www.youtube.com/watch?v=mATI8Lht0Js
|
||||
[virtual box issue]: https://www.virtualbox.org/ticket/16771
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Package Contributions
|
|||
=====================
|
||||
|
||||
_This page is for developers who wish to contribute packages.
|
||||
If you want to install contributed packages, please see [installing contributed packages]._
|
||||
If you want to install contributed packages, please see [installing contributed packages](/doc/installing-contributed-packages/)._
|
||||
|
||||
We're very grateful to the talented and hard-working community members who contribute software packages to Qubes OS.
|
||||
This page explains the inclusion criteria and procedures for such packages, as well as the roles and responsibilities of those involved.
|
||||
|
|
@ -21,8 +21,8 @@ Inclusion Criteria
|
|||
In order to be accepted, packages must:
|
||||
|
||||
* In no way weaken the security of Qubes OS.
|
||||
* Be published under an open-source license (read about the [Qubes OS License]).
|
||||
* Follow our [coding guidelines].
|
||||
* Be published under an open-source license (read about the [Qubes OS License](/doc/license/)).
|
||||
* Follow our [coding guidelines](/doc/coding-style/).
|
||||
* Be thoroughly tested.
|
||||
* Have a clearly-defined use case for Qubes users.
|
||||
* Not be unduly burdensome to review.
|
||||
|
|
@ -32,13 +32,13 @@ In order to be accepted, packages must:
|
|||
Contribution Procedure
|
||||
----------------------
|
||||
|
||||
Before you start putting serious work into a package, we recommend that you discuss your idea with the Qubes developers and the broader community on the [qubes-devel mailing list].
|
||||
Before you start putting serious work into a package, we recommend that you discuss your idea with the Qubes developers and the broader community on the [qubes-devel mailing list](/support/#qubes-devel).
|
||||
Once you have a package that's ready to become part of Qubes OS, please follow this procedure:
|
||||
|
||||
1. Ensure that your package satisfies the [Inclusion Criteria].
|
||||
2. If your code isn't already on GitHub, create a GitHub repo that contains your code. You can have a look to an example package called [qubes-skeleton].
|
||||
3. If you haven't already, [sign your code][sig].
|
||||
4. Create an issue in [qubes-issues] with the title `[Contribution] your-package-name`.
|
||||
1. Ensure that your package satisfies the [Inclusion Criteria](#inclusion-criteria).
|
||||
2. If your code isn't already on GitHub, create a GitHub repo that contains your code. You can have a look to an example package called [qubes-skeleton](https://github.com/QubesOS-contrib/qubes-skeleton).
|
||||
3. If you haven't already, [sign your code](/doc/code-signing/).
|
||||
4. Create an issue in [qubes-issues](https://github.com/QubesOS/qubes-issues/issues/) with the title `[Contribution] your-package-name`.
|
||||
Include a link to your repo, a brief description of your package, and a brief explanation of why you think it should be included in Qubes.
|
||||
Please note that the Qubes core developers are very busy.
|
||||
If they are under heavy load when you submit your contribution, it may be a very long time before they have time to review your package.
|
||||
|
|
@ -46,7 +46,7 @@ Once you have a package that's ready to become part of Qubes OS, please follow t
|
|||
If you think they may have forgotten about your pending contribution, you may "bump" your request by commenting on your issue, but please do this *very* sparingly (i.e., no more than once a month).
|
||||
We appreciate your understanding!
|
||||
5. You may be asked followup questions.
|
||||
If we decide to accept your contribution, you will be invited to join the [QubesOS-contrib] organization on GitHub as public recognition of your contribution (but without push access; see [Review Procedure]), and [QubesOS-contrib] will fork your repo.
|
||||
If we decide to accept your contribution, you will be invited to join the [QubesOS-contrib](https://github.com/QubesOS-contrib) organization on GitHub as public recognition of your contribution (but without push access; see [Review Procedure](#review-procedure)), and [QubesOS-contrib](https://github.com/QubesOS-contrib) will fork your repo.
|
||||
If we decide not to accept your contribution, we will state the reason and close the issue.
|
||||
|
||||
Update Procedure
|
||||
|
|
@ -55,16 +55,16 @@ Update Procedure
|
|||
*Anyone* can provide an update (patch) to a contributed package, not just the person who contributed that package!
|
||||
The update procedure is the same for everyone, including the original package contributor.
|
||||
|
||||
If you would like to update an already-contributed package (specifically, a fork owned by [QubesOS-contrib]), please submit a [signed][sig], fast-forwardable pull request to that repo with your changes.
|
||||
Please note that your pull request **must** be both [signed][sig] and fast-forwardable, or else it will be closed without further review.
|
||||
If you would like to update an already-contributed package (specifically, a fork owned by [QubesOS-contrib](https://github.com/QubesOS-contrib)), please submit a [signed](/doc/code-signing/), fast-forwardable pull request to that repo with your changes.
|
||||
Please note that your pull request **must** be both [signed](/doc/code-signing/) and fast-forwardable, or else it will be closed without further review.
|
||||
One or more reviewers may post comments on your pull request.
|
||||
Please be prepared to read and respond to these comments.
|
||||
|
||||
Review Procedure
|
||||
----------------
|
||||
|
||||
This review procedure covers both original package contributions (see [Contribution Procedure]) and all subsequent updates to those packages, including updates from the original package contributor (see [Update Procedure]).
|
||||
All changes will be reviewed by a Qubes Core Reviewer (QCR) and the [Package Maintainer] (PM).
|
||||
This review procedure covers both original package contributions (see [Contribution Procedure](#contribution-procedure)) and all subsequent updates to those packages, including updates from the original package contributor (see [Update Procedure](#update-procedure)).
|
||||
All changes will be reviewed by a Qubes Core Reviewer (QCR) and the [Package Maintainer](#package-maintainers) (PM).
|
||||
In all cases, the QCR will be a core Qubes developer.
|
||||
In some cases, the QCR and the PM will be the same person.
|
||||
For example, if someone contributes a package, then disappears, and no suitable replacement has been found, then it is likely that a core Qubes developer will play both the QCR and PM roles for that package, at least until another suitable candidate volunteers to become the PM for that package.
|
||||
|
|
@ -72,25 +72,25 @@ For example, if someone contributes a package, then disappears, and no suitable
|
|||
The review procedure is as follows:
|
||||
|
||||
1. Someone, S, wishes to make a change to a package, P.
|
||||
2. S submits a fast-forwardable pull request against the fork of P's repo owned by [QubesOS-contrib].
|
||||
2. S submits a fast-forwardable pull request against the fork of P's repo owned by [QubesOS-contrib](https://github.com/QubesOS-contrib).
|
||||
3. The PM reviews the pull request.
|
||||
If the the pull request passes the PM's review, the PM adds a [signed][sig] *comment* on the pull request stating that it has passed review.
|
||||
(In cases in which S = PM, the PM can simply add a [signed][sig] *tag* to the HEAD commit prior to submitting the pull request.)
|
||||
If the the pull request passes the PM's review, the PM adds a [signed](/doc/code-signing/) *comment* on the pull request stating that it has passed review.
|
||||
(In cases in which S = PM, the PM can simply add a [signed](/doc/code-signing/) *tag* to the HEAD commit prior to submitting the pull request.)
|
||||
If the pull request does not pass the PM's review, the PM leaves a comment on the pull request explaining why not.
|
||||
4. The QCR reviews the pull request.
|
||||
If the pull request passes the QCR's review, the QCR pushes a [signed][sig] tag to the HEAD commit stating that it has passed review and fast-forward merges the pull request.
|
||||
If the pull request passes the QCR's review, the QCR pushes a [signed](/doc/code-signing/) tag to the HEAD commit stating that it has passed review and fast-forward merges the pull request.
|
||||
If the pull request does not pass the QCR's review, the QCR leaves a comment on the pull request explaining why not, and the QCR may decide to close the pull request.
|
||||
|
||||
In all the cases, the first condition to be validated by the QCR's review is to ensure that the contribution **will not** hijack any core packages of [QubesOS] and of course, none of the [QubesOS-contrib] packages too. More precisely, particular attention to the whole build pipeline will be made with a specific review of:
|
||||
In all the cases, the first condition to be validated by the QCR's review is to ensure that the contribution **will not** hijack any core packages of [QubesOS](https://github.com/QubesOS) and of course, none of the [QubesOS-contrib](https://github.com/QubesOS-contrib) packages too. More precisely, particular attention to the whole build pipeline will be made with a specific review of:
|
||||
|
||||
* Package dependencies,
|
||||
* Build scripts (including downloaded ones),
|
||||
* All downloaded components should be verified against static hash,
|
||||
* RPM/DEB installation scripts (e.g. looking at constraints who would hijack other packages),
|
||||
* Makefiles,
|
||||
* Package build [reproducible]
|
||||
* Package build [reproducible](https://reproducible-builds.org/)
|
||||
|
||||
and any steps which would result in partial/total compromise of legitimate components. For this part, you can have a look to an example package called [qubes-skeleton].
|
||||
and any steps which would result in partial/total compromise of legitimate components. For this part, you can have a look to an example package called [qubes-skeleton](https://github.com/QubesOS-contrib/qubes-skeleton).
|
||||
|
||||
Package Maintainers
|
||||
-------------------
|
||||
|
|
@ -98,24 +98,9 @@ Package Maintainers
|
|||
If you contribute a package, we assume that you will be the maintainer of that package, unless you tell us otherwise.
|
||||
As the maintainer of the package, it is your privilege and responsibility to:
|
||||
|
||||
* [Review][Review Procedure] each pull request made against the package.
|
||||
* [Review](#review-procedure) each pull request made against the package.
|
||||
* Decide when the package has reached a new version, and notify the Qubes core developers when this occurs.
|
||||
|
||||
If you do not wish to be the maintainer of your package, please let us know.
|
||||
If you do not act on your maintainer duties for a given package for an extended period of time and after at least one reminder, we will assume that you no longer wish to be the maintainer for that package.
|
||||
|
||||
[installing contributed packages]: /doc/installing-contributed-packages/
|
||||
[Inclusion Criteria]: #inclusion-criteria
|
||||
[Contribution Procedure]: #contribution-procedure
|
||||
[Update Procedure]: #update-procedure
|
||||
[Review Procedure]: #review-procedure
|
||||
[Package Maintainer]: #package-maintainers
|
||||
[Qubes OS License]: /doc/license/
|
||||
[sig]: /doc/code-signing/
|
||||
[coding guidelines]: /doc/coding-style/
|
||||
[qubes-devel mailing list]: /support/#qubes-devel
|
||||
[QubesOS]: https://github.com/QubesOS
|
||||
[QubesOS-contrib]: https://github.com/QubesOS-contrib
|
||||
[qubes-issues]: https://github.com/QubesOS/qubes-issues/issues/
|
||||
[reproducible]: https://reproducible-builds.org/
|
||||
[qubes-skeleton]: https://github.com/QubesOS-contrib/qubes-skeleton
|
||||
|
|
|
|||
|
|
@ -10,18 +10,18 @@ title: Qubes R3.1 release notes
|
|||
|
||||
## New features since 3.0
|
||||
|
||||
* Management Stack based of Salt Stack in dom0 - [documentation][salt-doc]
|
||||
* Management Stack based of Salt Stack in dom0 - [documentation](/doc/salt/)
|
||||
* Out of the box Whonix setup
|
||||
* UEFI support
|
||||
* LIVE edition (still alpha, not part of R3.1-rc1)
|
||||
* Updated GPU drivers in dom0
|
||||
* Colorful window application icons (instead of just colorful lock icon)
|
||||
* PV Grub support ([documentation][pvgrub-doc])
|
||||
* Out of the box USB VM setup, including [handling USB mouse][input-proxy]
|
||||
* PV Grub support ([documentation](/doc/managing-vm-kernel/))
|
||||
* Out of the box USB VM setup, including [handling USB mouse](https://github.com/QubesOS/qubes-app-linux-input-proxy/blob/master/README.md)
|
||||
* Xen upgraded to 4.6, for better hardware support (especially Skylake platform)
|
||||
* Improve updates proxy flexibility - especially repositories served over HTTPS
|
||||
|
||||
You can get detailed description in [completed github issues][github-release-notes]
|
||||
You can get detailed description in [completed github issues](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+sort%3Aupdated-desc+milestone%3A%22Release+3.1%22+label%3Arelease-notes+is%3Aclosed)
|
||||
|
||||
## Known issues
|
||||
|
||||
|
|
@ -66,7 +66,3 @@ Alternatively you can [upgrade to R3.0
|
|||
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/
|
||||
[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
|
||||
|
|
|
|||
|
|
@ -10,16 +10,16 @@ title: Qubes R3.2 release notes
|
|||
|
||||
## New features since 3.1
|
||||
|
||||
* Management Stack extended to support in-VM configuration - [documentation][salt-doc]
|
||||
* PV USB - [documentation][usb]
|
||||
* Management Stack extended to support in-VM configuration - [documentation](/doc/salt/)
|
||||
* PV USB - [documentation](/doc/usb/)
|
||||
* Dom0 update to Fedora 23 for better hardware support
|
||||
* Kernel 4.4.x
|
||||
* Default desktop environment switched to Xfce4
|
||||
* KDE 5 support (but it is no longer the default one)
|
||||
* Tiling window managers support: awesome, [i3][i3]
|
||||
* More flexible Qubes RPC services - [related ticket][qrexec-argument], [documentation][qrexec-doc]
|
||||
* Tiling window managers support: awesome, [i3](/doc/i3/)
|
||||
* More flexible Qubes RPC services - [related ticket](https://github.com/QubesOS/qubes-issues/issues/1876), [documentation](/doc/qrexec/#service-policies-with-arguments)
|
||||
|
||||
You can get detailed description in [completed github issues][github-release-notes]
|
||||
You can get detailed description in [completed github issues](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+sort%3Aupdated-desc+milestone%3A%22Release+3.2%22+label%3Arelease-notes+is%3Aclosed)
|
||||
|
||||
## Known issues
|
||||
|
||||
|
|
@ -47,27 +47,18 @@ After installation, [manually upgrade to Fedora 26](/news/2018/01/06/fedora-26-u
|
|||
### From R3.1
|
||||
|
||||
The easiest and safest way to upgrade to Qubes R3.2 is to install it from
|
||||
scratch and use [qubes backup and restore tools][backup] for
|
||||
scratch and use [qubes backup and restore tools](/doc/backup-restore/) for
|
||||
migrating of all of the user VMs.
|
||||
|
||||
Users of Qubes R3.1 can also upgrade using [this
|
||||
procedure][upgrade].
|
||||
procedure](/doc/upgrade-to-r3.2/).
|
||||
|
||||
### From R3.0 or earlier
|
||||
|
||||
When upgrading from earlier versions the easiest and safest way is to install
|
||||
it from scratch and use [qubes backup and restore tools][backup]
|
||||
it from scratch and use [qubes backup and restore tools](/doc/backup-restore/)
|
||||
for migrating of all of the user VMs.
|
||||
|
||||
Alternatively you can [upgrade to R3.1 using][upgrade-r3.1] first, then follow
|
||||
Alternatively you can [upgrade to R3.1 using](/doc/releases/3.1/release-notes/#upgrading) first, then follow
|
||||
the instructions above. This will be time consuming process.
|
||||
|
||||
[salt-doc]: /doc/salt/
|
||||
[usb]: /doc/usb/
|
||||
[i3]: /doc/i3/
|
||||
[upgrade]: /doc/upgrade-to-r3.2/
|
||||
[upgrade-r3.1]: /doc/releases/3.1/release-notes/#upgrading
|
||||
[backup]: /doc/backup-restore/
|
||||
[qrexec-argument]: https://github.com/QubesOS/qubes-issues/issues/1876
|
||||
[qrexec-doc]: /doc/qrexec/#service-policies-with-arguments
|
||||
[github-release-notes]: https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+sort%3Aupdated-desc+milestone%3A%22Release+3.2%22+label%3Arelease-notes+is%3Aclosed
|
||||
|
|
|
|||
|
|
@ -12,36 +12,36 @@ Qubes R4.0 release notes
|
|||
New features since 3.2
|
||||
----------------------
|
||||
|
||||
* Core management scripts rewrite with better structure and extensibility, [API documentation][api-doc]
|
||||
* [Admin API][admin-api] allowing strictly controlled managing from non-dom0
|
||||
* Core management scripts rewrite with better structure and extensibility, [API documentation](https://dev.qubes-os.org/projects/qubes-core-admin/en/latest/)
|
||||
* [Admin API](/news/2017/06/27/qubes-admin-api/) allowing strictly controlled managing from non-dom0
|
||||
* All `qvm-*` command-line tools rewritten, some options have changed
|
||||
* Renaming VM directly is prohibited, there is GUI to clone under new name and remove old VM
|
||||
* Use [PVH][qsb-37] and [HVM][hvm-switch] by default to [mitigate Meltdown & Spectre][qsb-37] and lower the [attack surface on Xen][qsb-24]
|
||||
* Use [PVH](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-2018.txt) and [HVM](https://github.com/QubesOS/qubes-issues/issues/2185) by default to [mitigate Meltdown & Spectre](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-2018.txt) and lower the [attack surface on Xen](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-024-2016.txt)
|
||||
* Create USB VM by default
|
||||
* [Multiple DisposableVMs templates support][dispvm-ticket]
|
||||
* New [backup format][backup-format] using scrypt key-derivation function
|
||||
* [Multiple DisposableVMs templates support](https://github.com/QubesOS/qubes-issues/issues/2253)
|
||||
* New [backup format](/doc/backup-emergency-restore-v4/) using scrypt key-derivation function
|
||||
* Non-encrypted backups no longer supported
|
||||
* [split VM packages][packages-split], for better support minimal, specialized templates
|
||||
* [Qubes Manager decomposition][manager-ticket] - domains and devices widgets instead of full Qubes Manager; devices widget support also USB
|
||||
* [More flexible firewall interface][vm-interface] for ease unikernel integration
|
||||
* Template VMs do not have network interface by default, [qrexec-based updates proxy][qrexec-proxy] is used instead
|
||||
* More flexible IP addressing for VMs - [custom IP][custom-ip], [hidden from the IP][hide-ip]
|
||||
* More flexible Qubes RPC policy - [related ticket][qrexec-policy-keywords], [documentation][qrexec-doc]
|
||||
* [New Qubes RPC confirmation window][qrexec-confirm], including option to specify destination VM
|
||||
* [New storage subsystem design][storage]
|
||||
* [split VM packages](https://github.com/QubesOS/qubes-issues/issues/2771), for better support minimal, specialized templates
|
||||
* [Qubes Manager decomposition](https://github.com/QubesOS/qubes-issues/issues/2132) - domains and devices widgets instead of full Qubes Manager; devices widget support also USB
|
||||
* [More flexible firewall interface](/doc/vm-interface/) for ease unikernel integration
|
||||
* Template VMs do not have network interface by default, [qrexec-based updates proxy](https://github.com/QubesOS/qubes-issues/issues/1854) is used instead
|
||||
* More flexible IP addressing for VMs - [custom IP](https://github.com/QubesOS/qubes-issues/issues/1477), [hidden from the IP](https://github.com/QubesOS/qubes-issues/issues/1143)
|
||||
* More flexible Qubes RPC policy - [related ticket](https://github.com/QubesOS/qubes-issues/issues/865), [documentation](/doc/qrexec/#specifying-vms-tags-types-targets-etc)
|
||||
* [New Qubes RPC confirmation window](https://github.com/QubesOS/qubes-issues/issues/910), including option to specify destination VM
|
||||
* [New storage subsystem design](https://github.com/QubesOS/qubes-issues/issues/1842)
|
||||
* Dom0 update to Fedora 25 for better hardware support
|
||||
* Kernel 4.9.x
|
||||
|
||||
You can get detailed description in [completed github issues][github-release-notes]
|
||||
You can get detailed description in [completed github issues](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+sort%3Aupdated-desc+milestone%3A%22Release+4.0%22+label%3Arelease-notes+is%3Aclosed)
|
||||
|
||||
Security Notes
|
||||
--------------
|
||||
|
||||
* PV VMs migrated from 3.2 to 4.0-rc4 or later are automatically set to PVH mode in order to protect against Meltdown (see [QSB #37][qsb-37]).
|
||||
* PV VMs migrated from 3.2 to 4.0-rc4 or later are automatically set to PVH mode in order to protect against Meltdown (see [QSB #37](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-2018.txt)).
|
||||
However, PV VMs migrated from any earlier 4.0 release candidate (RC1, RC2, or RC3) are not automatically set to PVH mode.
|
||||
These must be set manually.
|
||||
|
||||
* The following steps may need to be applied in dom0 and Fedora 26 TemplateVMs in order to receive updates (see [#3737]).
|
||||
* The following steps may need to be applied in dom0 and Fedora 26 TemplateVMs in order to receive updates (see [#3737](https://github.com/QubesOS/qubes-issues/issues/3737)).
|
||||
|
||||
Steps for dom0 updates:
|
||||
|
||||
|
|
@ -77,9 +77,9 @@ Security Notes
|
|||
Known issues
|
||||
------------
|
||||
|
||||
* Locale using coma as decimal separator [crashes qubesd][locale-bug]. Either install with different locale (English (United States) for example), or manually apply fix explained in that issue.
|
||||
* Locale using coma as decimal separator [crashes qubesd](https://github.com/QubesOS/qubes-issues/issues/3753). Either install with different locale (English (United States) for example), or manually apply fix explained in that issue.
|
||||
|
||||
* In the middle of installation, [keyboard layout reset to US][keyboard-layout-bug]. Be careful what is the current layout while setting default user password (see upper right screen corner).
|
||||
* In the middle of installation, [keyboard layout reset to US](https://github.com/QubesOS/qubes-issues/issues/3352). Be careful what is the current layout while setting default user password (see upper right screen corner).
|
||||
|
||||
* On some laptops (for example Librem 15v2), touchpad do not work directly after installation. Reboot the system to fix the issue.
|
||||
|
||||
|
|
@ -106,29 +106,6 @@ Upgrading
|
|||
|
||||
There is no in-place upgrade path from earlier Qubes versions. The only
|
||||
supported option to upgrade to Qubes R4.0 is to install it from scratch and use
|
||||
[qubes backup and restore tools][backup] for migrating of all of the user VMs.
|
||||
We also provide [detailed instruction][upgrade-to-r4.0] for this procedure.
|
||||
[qubes backup and restore tools](/doc/backup-restore/) for migrating of all of the user VMs.
|
||||
We also provide [detailed instruction](/doc/upgrade-to-r4.0/) for this procedure.
|
||||
|
||||
[backup]: /doc/backup-restore/
|
||||
[github-release-notes]: https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+sort%3Aupdated-desc+milestone%3A%22Release+4.0%22+label%3Arelease-notes+is%3Aclosed
|
||||
[custom-ip]: https://github.com/QubesOS/qubes-issues/issues/1477
|
||||
[hide-ip]: https://github.com/QubesOS/qubes-issues/issues/1143
|
||||
[packages-split]: https://github.com/QubesOS/qubes-issues/issues/2771
|
||||
[hvm-switch]: https://github.com/QubesOS/qubes-issues/issues/2185
|
||||
[manager-ticket]: https://github.com/QubesOS/qubes-issues/issues/2132
|
||||
[dispvm-ticket]: https://github.com/QubesOS/qubes-issues/issues/2253
|
||||
[qrexec-proxy]: https://github.com/QubesOS/qubes-issues/issues/1854
|
||||
[qrexec-policy-keywords]: https://github.com/QubesOS/qubes-issues/issues/865
|
||||
[qrexec-confirm]: https://github.com/QubesOS/qubes-issues/issues/910
|
||||
[qrexec-doc]: /doc/qrexec/#specifying-vms-tags-types-targets-etc
|
||||
[storage]: https://github.com/QubesOS/qubes-issues/issues/1842
|
||||
[vm-interface]: /doc/vm-interface/
|
||||
[admin-api]: /news/2017/06/27/qubes-admin-api/
|
||||
[qsb-24]: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-024-2016.txt
|
||||
[qsb-37]: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-2018.txt
|
||||
[backup-format]: /doc/backup-emergency-restore-v4/
|
||||
[api-doc]: https://dev.qubes-os.org/projects/qubes-core-admin/en/latest/
|
||||
[upgrade-to-r4.0]: /doc/upgrade-to-r4.0/
|
||||
[locale-bug]: https://github.com/QubesOS/qubes-issues/issues/3753
|
||||
[keyboard-layout-bug]: https://github.com/QubesOS/qubes-issues/issues/3352
|
||||
[#3737]: https://github.com/QubesOS/qubes-issues/issues/3737
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ TBD
|
|||
|
||||
## Components
|
||||
|
||||
![Admin API Architecture][admin-api-architecture]
|
||||
|
||||
|
||||
A central entity in the Qubes Admin API system is a `qubesd` daemon, which
|
||||
holds information about all domains in the system and mediates all actions (like
|
||||
|
|
@ -355,4 +355,3 @@ In addition, there is a mechanism to prevent concurrent modifications of the pol
|
|||
|
||||
<!-- vim: set ts=4 sts=4 sw=4 et : -->
|
||||
|
||||
[admin-api-architecture]: /attachment/wiki/AdminAPI/admin-api-architecture.svg
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ One of the main goals of the project is to keep the TCB to an absolute minimum.
|
|||
The size of the current TCB is on the order order of hundreds of thousands of lines of C code, which is several orders of magnitude less than other OSes.
|
||||
(In Windows, Linux, and Mac OSes, the amount of trusted code is typically on the order of tens of *millions* of lines of C code.)
|
||||
|
||||
For more information, see [Qubes Security Goals].
|
||||
For more information, see [Qubes Security Goals](/security/goals/).
|
||||
|
||||
Security-critical Qubes-specific Components
|
||||
-------------------------------------------
|
||||
|
|
@ -69,9 +69,6 @@ In that case, only network-isolated domains would be somewhat trustworthy.
|
|||
|
||||
This means that we must trust at least some of the vendors that supply the code we run inside our domains.
|
||||
(We don't have to trust *all* of them, but we at least have to trust the few that provide the apps we use in the most critical domains.)
|
||||
In practice, we trust the software provided by the [Fedora Project].
|
||||
In practice, we trust the software provided by the [Fedora Project](https://getfedora.org/).
|
||||
This software is signed by Fedora distribution keys, so it is also critical that the tools used in domains for software updates (`dnf` and `rpm`) are trustworthy.
|
||||
|
||||
[Qubes Security Goals]: /security/goals/
|
||||
[Fedora Project]: https://getfedora.org/
|
||||
[Understanding and Preventing Data Leaks]: /doc/data-leaks/
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue