mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2025-09-26 03:21:03 -04:00
Assign unsorted pages and delete deprecated/blank/test pages
This commit is contained in:
Axon
parent
c53dbe5c2e
commit
bd877ddc54
17 changed files with 10 additions and 64 deletions
|
|
@ -1,78 +0,0 @@
|
|||
---
|
||||
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)
|
||||
|
|
@ -1,76 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: Fetchmail
|
||||
permalink: /doc/Fetchmail/
|
||||
redirect_from: /wiki/Fetchmail/
|
||||
---
|
||||
|
||||
Fetchmail
|
||||
=========
|
||||
|
||||
Fetchmail is standalone MRA (Mail Retrieval Agent) aka "IMAP/POP3 client". Its sole purpose is to fetch your messages and store it locally or feed to local MTA (Message Transfer Agent). It cannot "read" messages — for that, use a MUA like Thunderbird or [Mutt](/doc/Mutt/).
|
||||
|
||||
Installation
|
||||
------------
|
||||
|
||||
`yum install fetchmail`
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
Assuming you have more than one account (safe assumption these days), you need to spawn multiple fetchmail instances, one for each IMAP/POP3 server (though one instance can watch over several accounts on one server). The easiest way is to create template systemd unit and start it several times. Fedora does not supply any, so we have to write one anyway.
|
||||
|
||||
**NOTE:** this assumes you use [Postfix](/doc/Postfix/) as your local MTA.
|
||||
|
||||
In TemplateVM create `/etc/systemd/system/fetchmail@.service`:
|
||||
|
||||
```
|
||||
[Unit]
|
||||
Description=Mail Retrieval Agent
|
||||
After=network.target
|
||||
Requires=postfix.service
|
||||
|
||||
[Service]
|
||||
User=user
|
||||
ExecStart=/bin/fetchmail -f /usr/local/etc/fetchmail/%I.rc -d 60 -i /usr/local/etc/fetchmail/.%I.fetchids --pidfile /usr/local/etc/fetchmail/.%I.pid
|
||||
RestartSec=1
|
||||
```
|
||||
|
||||
Then shutdown TemplateVM, start AppVM and create directory `/usr/local/etc/fetchmail`. In it, create one `.rc` file for each instance of fetchmail, ie. `personal1.rc` and `personal2.rc`. Sample configuration file:
|
||||
|
||||
```
|
||||
set syslog
|
||||
set no bouncemail
|
||||
#set daemon 600
|
||||
|
||||
poll mailserver1.com proto imap
|
||||
no dns
|
||||
uidl
|
||||
tracepolls
|
||||
user woju pass supersecret
|
||||
ssl
|
||||
sslproto "TLS1"
|
||||
sslcertfile "/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt"
|
||||
sslcertck
|
||||
mda "/usr/sbin/sendmail -i -f %F -- user"
|
||||
fetchall
|
||||
idle
|
||||
|
||||
# vim: ft=fetchmail
|
||||
```
|
||||
|
||||
Then `chown -R user:user /usr/local/etc/fetchmail` and `chmod 600 /usr/local/etc/fetchmail/*.rc`. **This is important**, fetchmail will refuse to run with wrong permissions on its rc-file.
|
||||
|
||||
Next, add this to `/rw/config/rc.local`:
|
||||
|
||||
```
|
||||
#!/bin/sh
|
||||
|
||||
for rc in /usr/local/etc/fetchmail/*.rc; do
|
||||
instance=${rc%.*}
|
||||
instance=${instance##*/}
|
||||
echo systemctl --no-block start fetchmail@${instance}
|
||||
done
|
||||
```
|
||||
|
||||
Now reboot your AppVM and you are done.
|
||||
217
unsorted/Mutt.md
217
unsorted/Mutt.md
|
|
@ -1,217 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: Mutt
|
||||
permalink: /doc/Mutt/
|
||||
redirect_from: /wiki/Mutt/
|
||||
---
|
||||
|
||||
Mutt
|
||||
====
|
||||
|
||||
Mutt is a fast, standards-compliant, efficient MUA (Mail User Agent). In some areas it works better than Thunderbird+Enigmail, and is certainly faster and more responsive.
|
||||
|
||||
Mutt lacks true MTA (Message Transfer Agent aka "SMTP client") and MRA (Mail
|
||||
Retrieval Agent aka "IMAP/POP3 client"), thus there are some provisions
|
||||
built-in. In principle it is only mail reader and composer. You may install
|
||||
true MTA such as [Postfix](/doc/Postfix/) or Exim and MRA such as
|
||||
[Fetchmail](/doc/Fetchmail/). Alternatively you can synchronize your mailbox
|
||||
using [OfflineIMAP](https://github.com/OfflineIMAP/offlineimap) and just stick
|
||||
to integrated SMTP support. You can even use integrated IMAP client, but it is
|
||||
not very convenient.
|
||||
|
||||
Installation
|
||||
------------
|
||||
|
||||
`yum install mutt`
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
Mutt generally works out of the box. This configuration guide discusses only Qubes-specific setup. In this example we will have one TemplateVM and several AppVMs. It also takes advantage of [SplitGPG](/doc/UserDoc/SplitGpg/), which is assumed to be already working.
|
||||
|
||||
**NOTE:** this requires `qubes-gpg-split >= 2.0.9`. 2.0.8 and earlier contains bug which causes this setup to hang in specific situations and does not allow to list keys.
|
||||
|
||||
First, paste this to `/etc/Muttrc.local` in TemplateVM:
|
||||
|
||||
```
|
||||
# specify your key or override in ~/.mutt/muttrc in AppVM
|
||||
set pgp_sign_as="0xDEADBEEF"
|
||||
|
||||
set pgp_use_gpg_agent = no
|
||||
|
||||
# this needs qubes-gpg-split >= 2.0.8; 2.0.7 end earlier has had a deadlock on this
|
||||
set pgp_decode_command="qubes-gpg-client-wrapper --status-fd=2 --batch %f"
|
||||
#set pgp_decode_command="gpg --status-fd=2 %?p?--passphrase-fd=0? --no-verbose --quiet --batch --output - %f"
|
||||
|
||||
set pgp_decrypt_command="$pgp_decode_command"
|
||||
|
||||
set pgp_verify_command="qubes-gpg-client-wrapper --status-fd=2 --no-verbose --quiet --batch --output - --verify %s %f"
|
||||
|
||||
set pgp_sign_command="qubes-gpg-client-wrapper --batch --armor --detach-sign --textmode %?a?-u %a? %f"
|
||||
set pgp_clearsign_command="qubes-gpg-client-wrapper --batch --armor --textmode --clearsign %?a?-u %a? %f"
|
||||
|
||||
# I found no option to add Charset armor header when it is UTF-8, since this is
|
||||
# default (as specified in RFC4880). This is needed to workaround bug in
|
||||
# Enigmail, which ignores RFC and without this header Thunderbird interprets
|
||||
# plaintext as us-ascii. See http://sourceforge.net/p/enigmail/bugs/38/.
|
||||
|
||||
### also note you must specify absolute path of pgpewrap when using debian
|
||||
### e.g. /usr/lib/mutt/pgpewrap
|
||||
|
||||
set pgp_encrypt_only_command="pgpewrap qubes-gpg-client-wrapper --batch --textmode --armor --always-trust %?a?--encrypt-to %a? --encrypt -- -r %r -- %f | sed -e '2iCharset: UTF-8'"
|
||||
set pgp_encrypt_sign_command="pgpewrap qubes-gpg-client-wrapper --batch --textmode --armor --always-trust %?a?--encrypt-to %a? --encrypt --sign %?a?-u %a? -- -r %r -- %f | sed -e '2iCharset: UTF-8'"
|
||||
|
||||
# we need to import both into vault and locally wrt $pgp_verify_command
|
||||
set pgp_import_command="qubes-gpg-import-key %f; gpg --no-verbose --import %f"
|
||||
|
||||
# those are unsupported by split-gpg
|
||||
set pgp_export_command="gpg --no-verbose --export --armor %r"
|
||||
set pgp_verify_key_command="gpg --no-verbose --batch --fingerprint --check-sigs %r"
|
||||
|
||||
# read in the public key ring
|
||||
set pgp_list_pubring_command="qubes-gpg-client-wrapper --no-verbose --batch --quiet --with-colons --list-keys %r"
|
||||
|
||||
# read in the secret key ring
|
||||
set pgp_list_secring_command="qubes-gpg-client-wrapper --no-verbose --batch --quiet --with-colons --list-secret-keys %r"
|
||||
|
||||
# this set the number of seconds to keep in memory the passpharse used to encrypt/sign
|
||||
# the more the less secure it will be
|
||||
set pgp_timeout=600
|
||||
|
||||
# it's a regexp used against the GPG output: if it matches some line of the output
|
||||
# then mutt considers the message a good signed one (ignoring the GPG exit code)
|
||||
#set pgp_good_sign="^gpg: Good signature from"
|
||||
set pgp_good_sign="^\\[GNUPG:\\] GOODSIG"
|
||||
|
||||
# mutt uses by default PGP/GPG to sign/encrypt messages
|
||||
# if you want to use S-mime instead set the smime_is_default variable to yes
|
||||
|
||||
# automatically sign all outcoming messages
|
||||
set crypt_autosign=yes
|
||||
# sign only replies to signed messages
|
||||
#set crypt_replysign
|
||||
|
||||
# automatically encrypt outcoming messages
|
||||
#set crypt_autoencrypt=yes
|
||||
# encrypt only replies to signed messages
|
||||
set crypt_replyencrypt=yes
|
||||
# encrypt and sign replies to encrypted messages
|
||||
set crypt_replysignencrypted=yes
|
||||
|
||||
# automatically verify the sign of a message when opened
|
||||
set crypt_verify_sig=yes
|
||||
|
||||
send-hook "~A" set pgp_autoinline=no crypt_autoencrypt=no
|
||||
send-hook "~t @invisiblethingslab\.com" set crypt_autoencrypt=yes
|
||||
|
||||
# vim:ft=muttrc
|
||||
```
|
||||
|
||||
Then shutdown your TemplateVM. Next open your AppVM, create file `/home/user/.mutt/muttrc` and adjust for your needs:
|
||||
|
||||
```
|
||||
#
|
||||
# accounts
|
||||
#
|
||||
set from = "Wojciech Zygmunt Porczyk <woju@invisiblethingslab.com>"
|
||||
alternates '^woju@invisiblethingslab\.com$'
|
||||
alternates '^wojciech@porczyk\.eu$'
|
||||
|
||||
#
|
||||
# crypto
|
||||
#
|
||||
set pgp_sign_as = "0xDEADBEEF"
|
||||
send-hook "~t @my\.family\.com" set crypt_autoencrypt=no
|
||||
|
||||
#
|
||||
# lists
|
||||
#
|
||||
|
||||
# google groups
|
||||
lists .*@googlegroups\.com
|
||||
|
||||
subscribe (qubes-(users|devel)|othergroup)@googlegroups\.com
|
||||
fcc-save-hook qubes-users@googlegroups\.com =list/qubes-users/
|
||||
fcc-save-hook qubes-devel@googlegroups\.com =list/qubes-devel/
|
||||
fcc-save-hook othergroup@googlegroups\.com =list/othergroup/
|
||||
```
|
||||
|
||||
You may also create `/home/user/.signature`:
|
||||
|
||||
```
|
||||
regards,
|
||||
Wojciech Porczyk
|
||||
```
|
||||
|
||||
Some additional useful settings
|
||||
-------------------------------
|
||||
|
||||
In `muttrc`:
|
||||
|
||||
###qubes integration stuff
|
||||
|
||||
#open links in a dispvm using urlview
|
||||
#see below for sample .urlview
|
||||
macro pager \cb <pipe-entry>'urlview'<enter> 'Follow links with urlview'
|
||||
|
||||
#override default mailcap MIME settings with qvm-open-in-dvm calls
|
||||
#see sample .mailcap below
|
||||
set mailcap_path=~/.mailcap
|
||||
|
||||
bind attach <return> view-mailcap
|
||||
|
||||
Debian-specific options:
|
||||
|
||||
#use debian mutt-patched package for mailbox sidebar hack
|
||||
set sidebar_width = 30
|
||||
set sidebar_visible = no
|
||||
set sidebar_delim='|'
|
||||
|
||||
#show/hide sidebar
|
||||
macro index S '<enter-command>toggle sidebar_visible<enter>'
|
||||
macro pager S '<enter-command>toggle sidebar_visible<enter>'
|
||||
|
||||
#navigate the sidebar folders
|
||||
bind index CP sidebar-prev
|
||||
bind index CN sidebar-next
|
||||
bind index CO sidebar-open
|
||||
bind pager CP sidebar-prev
|
||||
bind pager CN sidebar-next
|
||||
|
||||
|
||||
In `.urlview`:
|
||||
|
||||
### TODO: this doesn't work with encrypted emails --
|
||||
### urlview can't find the links
|
||||
###
|
||||
COMMAND qvm-open-in-dvm %s
|
||||
|
||||
|
||||
In `.mailcap`:
|
||||
|
||||
### TODO: override most/all default mailcap settings to prevent
|
||||
### opening in muttvm
|
||||
### is there a way to do this polymorphically? i.e. not
|
||||
### listing every damn mimetype by hand
|
||||
###
|
||||
### also would be convenient to use mailcap's TEST feature to
|
||||
### show some html in mutt pager (e.g. with w3m, links or html2text),
|
||||
### else open others in dispvm
|
||||
|
||||
# MS Word documents
|
||||
application/msword; qvm-open-in-dvm %s
|
||||
|
||||
application/vnd.oasis.opendocument.spreadsheet; qvm-open-in-dvm %s
|
||||
application/vnd.oasis.opendocument.text; qvm-open-in-dvm %s
|
||||
|
||||
# Images
|
||||
image/jpg; qvm-open-in-dvm %s
|
||||
image/jpeg; qvm-open-in-dvm %s
|
||||
image/png; qvm-open-in-dvm %s
|
||||
image/gif; qvm-open-in-dvm %s
|
||||
|
||||
# PDFs
|
||||
application/pdf; qvm-open-in-dvm %s
|
||||
|
||||
# HTML
|
||||
text/html; qvm-open-in-dvm %s
|
||||
|
|
@ -1,150 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: Postfix
|
||||
permalink: /doc/Postfix/
|
||||
redirect_from: /wiki/Postfix/
|
||||
---
|
||||
|
||||
Postfix
|
||||
=======
|
||||
|
||||
Postfix is full featured MTA (Message Transfer Agent). Here we will configure it in smarthost mode as part of common [Mutt](/doc/Mutt/)+Postfix+[Fetchmail](/doc/Fetchmail/) stack.
|
||||
|
||||
Installation
|
||||
------------
|
||||
|
||||
`yum install postfix procmail make`
|
||||
|
||||
Procmail is not strictly neccessary, but is useful to sort your incoming mail, for example to put each mailing list in its own directory. Make is also not neccessary, but is used to keep Postfix lookup tables. You should also check `alternatives` command, to see if it is the default `mta`. It probably is not. You may need to `yum remove ssmtp` or something.
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
In TemplateVM open `/etc/aliases` and add line:
|
||||
|
||||
```
|
||||
root: user
|
||||
```
|
||||
|
||||
and run `newaliases`.
|
||||
|
||||
This is the only thing to do in TemplateVM, as MTA configuration is AppVM specific, so we will keep it in `/usr/local` (ie. `/rw/usrlocal`) in each AppVM.
|
||||
|
||||
Now shutdown TemplateVM, start AppVM. Create directory `/usr/local/etc/postfix` and copy `/etc/postfix/master.cf` there.
|
||||
|
||||
### Makefile
|
||||
|
||||
Postfix keeps its lookup tables in bdb hash databases. They need to be compiled from source files. Postfix admins like to keep track of them by means of `/usr/local/etc/postfix/Makefile`:
|
||||
|
||||
```
|
||||
all: $(addsuffix .db,$(shell sed -n -e '/^[^#].*hash:\/etc\/postfix/s:.*/::p' main.cf))
|
||||
newaliases
|
||||
clean:
|
||||
$(RM) *.db
|
||||
.PHONY: all clean
|
||||
|
||||
%.db: %
|
||||
/usr/sbin/postmap hash:$<
|
||||
```
|
||||
|
||||
### Postfix main configuration
|
||||
|
||||
`/usr/local/etc/postfix/main.cf` (`/etc/postfix` is intentional, don't correct it):
|
||||
|
||||
```
|
||||
mydestination = $myhostname, $myhostname.$mydomain, $myhostname.localdomain, localhost, localhost.$mydomain, localhost.localdomain, $mydomain, localdomain
|
||||
mynetworks_style = host
|
||||
|
||||
inet_protocols = ipv4
|
||||
|
||||
smtp_generic_maps = hash:/etc/postfix/generic
|
||||
local_header_rewrite_clients =
|
||||
|
||||
smtp_sender_dependent_authentication = yes
|
||||
sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
|
||||
smtp_sasl_auth_enable = yes
|
||||
smtp_sasl_password_maps = hash:/etc/postfix/saslpass
|
||||
smtp_sasl_security_options =
|
||||
smtp_tls_security_level = encrypt
|
||||
smtp_sasl_mechanism_filter = plain, login
|
||||
smtpd_relay_restrictions = permit_mynetworks,permit_sasl_authenticated,defer_unauth_destination
|
||||
smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/sender_access
|
||||
|
||||
home_mailbox = .maildir/
|
||||
setgid_group = postdrop
|
||||
mail_owner = postfix
|
||||
|
||||
html_directory = no
|
||||
manpage_directory = /usr/share/man
|
||||
queue_directory = /var/spool/postfix
|
||||
readme_directory = no
|
||||
|
||||
mailbox_command = /usr/bin/procmail
|
||||
sendmail_path = /usr/sbin/sendmail
|
||||
newaliases_path = /usr/bin/newaliases
|
||||
mailq_path = /usr/bin/mailq
|
||||
alias_maps = hash:/etc/aliases
|
||||
```
|
||||
|
||||
### Lookup tables
|
||||
|
||||
`/usr/local/etc/postfix/generic` (put there your primary address):
|
||||
|
||||
```
|
||||
@localhost your.mail@example.com
|
||||
```
|
||||
|
||||
`/usr/local/etc/postfix/sender_relay`. This is important file. Put there all your SMTP servers. Pay attention to port (smtp/submission). Square brackets have their special meaning, they are almost certainly needed. For more info consult Postfix manual.
|
||||
|
||||
```
|
||||
your.mail@exmaple.com [mail.example.com]:submission
|
||||
your.other@mail.com [smtp.mail.com]:smtp
|
||||
```
|
||||
|
||||
`/usr/local/etc/postfix/saslpass`. Here you put passwords to abovementioned servers. It depends on provider if you need to put whole email as username or just the part before `@`.
|
||||
|
||||
```
|
||||
[mail.example.com]:submission your.mail:y0urP4ssw0rd
|
||||
[smtp.mail.com]:smtp your.other@mail.com:supers3cret
|
||||
```
|
||||
|
||||
`/usr/local/etc/postfix/sender_access`. I use it to nullroute known spam domains. If you do not need it, comment respective line in `main.cf`.
|
||||
|
||||
```
|
||||
spamdomain1.com DISCARD
|
||||
spamdomain2.com DISCARD
|
||||
```
|
||||
|
||||
Now run `make` in `/usr/local/etc/postfix`. It will hopefully compile four abovementioned lookup tables (`generic.db`, `sender_relay.db`, `saslpass.db` and `sender_access`).
|
||||
|
||||
### procmail
|
||||
|
||||
Don't start postfix or fetchmail yet, first create `/home/user/.procmailrc`:
|
||||
|
||||
```
|
||||
MAILDIR = "${HOME}/.maildir"
|
||||
ORGMAIL = "${MAILDIR}/"
|
||||
DEFAULT = "${MAILDIR}/"
|
||||
|
||||
:0
|
||||
* ^List-Id:.*qubes-users\.googlegroups\.com
|
||||
list/qubes-users/
|
||||
|
||||
:0
|
||||
* ^List-Id:.*qubes-devel\.googlegroups\.com
|
||||
list/qubes-devel/
|
||||
```
|
||||
|
||||
Run
|
||||
---
|
||||
|
||||
Open `/rw/config/rc.local` and add those two lines (before fetchmail lines, if you have them):
|
||||
|
||||
```
|
||||
#!/bin/sh
|
||||
|
||||
mount --bind /usr/local/etc/postfix /etc/postfix
|
||||
systemctl --no-block start postfix
|
||||
```
|
||||
|
||||
Reboot your AppVM and you are done.
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
---
|
||||
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.
|
||||
|
||||
[](/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)
|
||||
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: QubesContacts
|
||||
permalink: /doc/QubesContacts/
|
||||
redirect_from: /wiki/QubesContacts/
|
||||
---
|
||||
|
||||
Contacting the Qubes OS Team
|
||||
============================
|
||||
|
||||
**Note:** Please send all the questions regarding Qubes to the [mailing list](/doc/QubesLists/). This way, your questions, as well as answers to those questions, could be also shared with other users.
|
||||
|
||||
Press & business contact
|
||||
------------------------
|
||||
|
||||
- Joanna Rutkowska `joanna at invisiblethingslab dot com`
|
||||
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
---
|
||||
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.
|
||||
|
|
@ -1,83 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: QubesLists
|
||||
permalink: /doc/QubesLists/
|
||||
redirect_from: /wiki/QubesLists/
|
||||
---
|
||||
|
||||
Qubes Mailing Lists
|
||||
===================
|
||||
|
||||
Please send all the questions regarding Qubes to one of the following mailing lists. **Please do not send questions to individual Qubes developers.** By sending a message to the appropriate mailing list, you are not only giving others a chance to help you, but you may also be helping others by starting a public discussion about a shared problem or interest.
|
||||
|
||||
Mailing List Rules
|
||||
------------------
|
||||
|
||||
- Send your message to the correct list. Read the sections below to determine which list is correct for your message.
|
||||
|
||||
- Do not [top-post](https://en.wikipedia.org/wiki/Posting_style).
|
||||
|
||||
- Include a precise and informative subject line. This will allow others to easily find your thread in the future and use it as a reference.
|
||||
- Bad: "Help! Qubes problems!"
|
||||
- Good: "R2B2 Installation problem: Apple keyboard not working in installer."
|
||||
|
||||
- Be concise. Do not write an essay. Include only essential information. Please think about how many messages come to the list every day and whether people will want to read through your lengthy message (hint: they won't!).
|
||||
|
||||
- Do not apologize for your poor English. This is a waste of everyone's time, including your own. If we can't understand you, we will ask you to clarify (or ignore your message if it's a total mess ;).
|
||||
|
||||
- While we're generally open to hearing suggestions for new features, please note that we already have a pretty well defined [roadmap](https://github.com/QubesOS/qubes-issues/milestones), and it's rather unlikely that we will change our schedule in order to accommodate your request. If there's a particular feature you'd like to see in Qubes, a much more effective way to make it happen is to... contribute code to Qubes which implements it! We happily accept such contributions, provided they meet our standards. Please note, however, that it's always a good idea to field a discussion of your idea on the qubes-devel list before putting in a lot of hard work on something that we may not be able or willing to accept.
|
||||
|
||||
The `qubes-users` Mailing List
|
||||
------------------------------
|
||||
|
||||
### How to Use This List
|
||||
|
||||
This list is for helping users solve various daily problems with Qubes OS. Examples of topics or questions suitable for this list include:
|
||||
|
||||
- [HCL reports](/doc/HCL/#generating-and-submitting-new-reports).
|
||||
- Installation problems.
|
||||
- Hardware compatibility problems.
|
||||
- Bug reports.
|
||||
- How do I...?
|
||||
|
||||
### Read These First
|
||||
|
||||
Please try searching both the Qubes website and the archives of the mailing lists before sending a question. In addition, please make sure that you have read and understood the following basic documentation prior to posting to the list:
|
||||
|
||||
- [Installation guides, System Requirements, and HCL](/doc/QubesDownloads/) \<-- for problems related to Qubes OS installation
|
||||
- [Qubes User FAQ](/doc/UserFaq/)
|
||||
- [Qubes User Guides](/doc/UserDoc/) \<-- for questions about how to use Qubes OS
|
||||
|
||||
### How to Subscribe and Post
|
||||
|
||||
You don't have to subscribe in order to post to this list. However, subscribing might nonetheless be desirable, as it ensures that your messages will not be eaten by the Google Groups spam filter and allows you to receive messages which were sent directly to the list.
|
||||
|
||||
- To subscribe to the list, send a blank mail to `qubes-users+subscribe@googlegroups.com`. (Note: A Gmail account is not required. Any email address should work.)
|
||||
- To post a message to the list, address your email to `qubes-users@googlegroups.com`. (Note: You don't have to be subscribed in order to post.)
|
||||
- To unsubscribe, send a blank email to `qubes-users+unsubscribe@googlegroups.com`.
|
||||
- This list has a Google Groups web interface: [https://groups.google.com/group/qubes-users](https://groups.google.com/group/qubes-users)
|
||||
- Some users prefer to interact with the mailing list through the Google Groups web interface. This has the advantage that it allows you to search and reply to messages which were sent prior to your subscription to the list. However, a Google account is required in order to post through this interface.
|
||||
|
||||
The `qubes-devel` mailing list
|
||||
------------------------------
|
||||
|
||||
### How to Use This List
|
||||
|
||||
This list is primarily intended for people who are interested in contributing to Qubes OS or who are willing to learn more about its architecture and implementation. Examples of topics and questions suitable for this list include:
|
||||
|
||||
- Questions about why we made certain architecture or implementation decisions. ("Why did you implement XYZ this way and not the other way?")
|
||||
- Questions about code layout and where is code for certain functionality.
|
||||
- Discussions about proposed new features, patches, etc. ("I would like to implement feature XYZ.")
|
||||
- Contributed code and patches.
|
||||
- Security discussions which are relevant to Qubes in some way.
|
||||
|
||||
### How to Subscribe and Post
|
||||
|
||||
You must be subscribed in order to post to this list.
|
||||
|
||||
- To subscribe to the list, send a blank mail to `qubes-devel+subscribe@googlegroups.com`. (Note: A Gmail account is not required. Any email address should work.)
|
||||
- To post a message to the list, address your email to `qubes-devel@googlegroups.com`. (Note: You must be subscribed in order to post. If your post does not appear, please allow time for moderation to occur.)
|
||||
- To unsubscribe, send a blank email to `qubes-devel+unsubscribe@googlegroups.com`.
|
||||
- This list has a Google Groups web interface: [https://groups.google.com/group/qubes-devel](https://groups.google.com/group/qubes-devel)
|
||||
- Some users prefer to interact with the mailing list through the Google Groups web interface. This has the advantage that it allows you to search and reply to messages which were sent prior to your subscription to the list. However, a Google account is required in order to post through this interface.
|
||||
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
---
|
||||
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))
|
||||
|
||||
139
unsorted/Rxvt.md
139
unsorted/Rxvt.md
|
|
@ -1,139 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: Rxvt
|
||||
permalink: /doc/Rxvt/
|
||||
redirect_from: /wiki/Rxvt/
|
||||
---
|
||||
|
||||
Rxvt
|
||||
====
|
||||
|
||||
`rxvt-unicode` is an advanced and efficient vt102 emulator. Here is a quick guide to configuration in both dom0 and guest VM.
|
||||
|
||||
Installation
|
||||
------------
|
||||
|
||||
`yum install rxvt-unicode-256color-ml` will bring both base `rxvt-unicode` and extension. Let me also recommend excellent Terminus font: `yum install terminus-fonts`.
|
||||
|
||||
Xresources
|
||||
----------
|
||||
|
||||
In TemplateVM create file `/etc/X11/Xresources.urxvt` and paste config below. `!`-lines are comments and may be left out. `#`-lines are directives to CPP (C preprocessor) and are neccessary. This shouldn't go to `/etc/X11/Xresources`, because that file is not preprocessed by default.
|
||||
|
||||
```
|
||||
! CGA colour palette
|
||||
|
||||
!*color0: #000000
|
||||
!*color1: #AA0000
|
||||
!*color2: #00AA00
|
||||
!*color3: #AA5500
|
||||
!*color4: #0000AA
|
||||
!*color5: #AA00AA
|
||||
!*color6: #00AAAA
|
||||
!*color7: #AAAAAA
|
||||
!*color8: #555555
|
||||
!*color9: #FF5555
|
||||
!*color10: #55FF55
|
||||
!*color11: #FFFF55
|
||||
!*color12: #5555FF
|
||||
!*color13: #FF55FF
|
||||
!*color14: #55FFFF
|
||||
!*color15: #FFFFFF
|
||||
|
||||
! Qubes' favourite tango palette (improved with cyan)
|
||||
|
||||
#define TANGO_Butter1 #c4a000
|
||||
#define TANGO_Butter2 #edd400
|
||||
#define TANGO_Butter3 #fce94f
|
||||
#define TANGO_Orange1 #ce5c00
|
||||
#define TANGO_Orange2 #f57900
|
||||
#define TANGO_Orange3 #fcaf3e
|
||||
#define TANGO_Chocolate1 #8f5902
|
||||
#define TANGO_Chocolate2 #c17d11
|
||||
#define TANGO_Chocolate3 #e9b96e
|
||||
#define TANGO_Chameleon1 #4e9a06
|
||||
#define TANGO_Chameleon2 #73d216
|
||||
#define TANGO_Chameleon3 #8ae234
|
||||
#define TANGO_SkyBlue1 #204a87
|
||||
#define TANGO_SkyBlue2 #3465a4
|
||||
#define TANGO_SkyBlue3 #729fcf
|
||||
#define TANGO_Plum1 #5c3566
|
||||
#define TANGO_Plum2 #75507b
|
||||
#define TANGO_Plum3 #ad7fa8
|
||||
#define TANGO_ScarletRed1 #a40000
|
||||
#define TANGO_ScarletRed2 #cc0000
|
||||
#define TANGO_ScarletRed3 #ef2929
|
||||
#define TANGO_Aluminium1 #2e3436
|
||||
#define TANGO_Aluminium2 #555753
|
||||
#define TANGO_Aluminium3 #888a85
|
||||
#define TANGO_Aluminium4 #babdb6
|
||||
#define TANGO_Aluminium5 #d3d7cf
|
||||
#define TANGO_Aluminium6 #eeeeec
|
||||
|
||||
*color0: TANGO_Aluminium1
|
||||
*color1: TANGO_ScarletRed2
|
||||
*color2: TANGO_Chameleon1
|
||||
*color3: TANGO_Chocolate2
|
||||
*color4: TANGO_SkyBlue1
|
||||
*color5: TANGO_Plum2
|
||||
*color6: #06989a
|
||||
*color7: TANGO_Aluminium4
|
||||
|
||||
*color8: TANGO_Aluminium3
|
||||
*color9: TANGO_ScarletRed3
|
||||
*color10: TANGO_Chameleon3
|
||||
*color11: TANGO_Butter3
|
||||
*color12: TANGO_SkyBlue3
|
||||
*color13: TANGO_Plum3
|
||||
*color14: #34e2e2
|
||||
*color15: TANGO_Aluminium6
|
||||
|
||||
URxvt.foreground: #E0E0E0
|
||||
!URxvt.background: black
|
||||
!URxvt.cursorColor: rgb:ffff/0000/0000
|
||||
|
||||
URxvt.cursorColor: TANGO_ScarletRed3
|
||||
|
||||
!URxvt.font: -*-terminus-*-*-*-*-14-*-*-*-*-*-iso8859-2
|
||||
!URxvt.boldFont: -*-terminus-*-*-*-*-14-*-*-*-*-*-iso8859-2
|
||||
URxvt.font: xft:Terminus:pixelsize=14:style=Bold
|
||||
URxvt.boldFont: xft:Terminus:pixelsize=14:style=Bold
|
||||
URxvt.italicFont: xft:Terminus:pixelsize=14:style=Regular
|
||||
URxvt.boldItalicFont: xft:Terminus:pixelsize=14:style=Regular
|
||||
URxvt.scrollBar: False
|
||||
URxvt.visualBell: False
|
||||
|
||||
! Qubes X11 passthrough does not support those, but in dom0 they are nice.
|
||||
URxvt.background: rgba:0000/0000/0000/afff
|
||||
URxvt.depth: 32
|
||||
URxvt.urgentOnBell: True
|
||||
|
||||
! TODO: write qubes-rpc to handle printing
|
||||
URxvt.print-pipe: cat > $(TMPDIR=$HOME mktemp urxvt.XXXXXX)
|
||||
|
||||
! selection-to-clipboard violates
|
||||
! http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt [1],
|
||||
! but it does for greater good: urxvt has no other means to move PRIMARY to
|
||||
! CLIPBOARD, so Qubes' clipboard won't work without it. Also the rationale given
|
||||
! in [1] has little relevance to advanced terminal emulator, specifically there
|
||||
! is no need for w32-style intuition and virtually no need to "paste over".
|
||||
URxvt.perl-ext-common: default,selection-to-clipboard
|
||||
|
||||
URxvt.insecure: False
|
||||
|
||||
! some termcap-aware software sometimes throw '$TERM too long'
|
||||
!URxvt.termName: rxvt-256color
|
||||
```
|
||||
|
||||
Then create script to automatically merge those to xrdb. File `/etc/X11/xinit/xinitrc.d/urxvt.sh`:
|
||||
|
||||
```
|
||||
#!/bin/sh
|
||||
|
||||
[ -r /etc/X11/Xresources.urxvt ] && xrdb -merge /etc/X11/Xresources.urxvt
|
||||
```
|
||||
|
||||
Shortcuts
|
||||
---------
|
||||
|
||||
For each AppVM, go to *Qubes Manager \> VM Settings \> Applications*. Find `rxvt-unicode` (or `rxvt-unicode (256-color) multi-language`) and add.
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: TestPage
|
||||
permalink: /doc/TestPage/
|
||||
redirect_from: /wiki/TestPage/
|
||||
---
|
||||
|
||||
This is a test.
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: TestTest
|
||||
permalink: /doc/TestTest/
|
||||
redirect_from: /wiki/TestTest/
|
||||
---
|
||||
|
||||
This is a test page
|
||||
===================
|
||||
|
||||
Please ignore.
|
||||
|
||||
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: UsbInstallation
|
||||
permalink: /doc/UsbInstallation/
|
||||
redirect_from: /wiki/UsbInstallation/
|
||||
---
|
||||
|
||||
How to create a bootable USB stick from Qubes ISO
|
||||
=================================================
|
||||
|
||||
Qubes ISO image is already prepared to boot from USB disk, you just need to copy the ISO onto the USB device, e.g. using dd:
|
||||
|
||||
```
|
||||
dd if=Qubes-R2-Beta2-x86_64-DVD.iso of=/dev/sdX
|
||||
```
|
||||
|
||||
**Be sure to use a correct device as the target in the dd command above (instead of sdX)**
|
||||
|
|
@ -1,146 +0,0 @@
|
|||
---
|
||||
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/).
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: amChartTest
|
||||
permalink: /doc/amChartTest/
|
||||
redirect_from: /wiki/amChartTest/
|
||||
---
|
||||
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue