Comment on Xen Project Celebrates Unikraft Unikernel Project’s One Year Anniversary by Xen Project Celebrates Unikraft Unikernel Project’s One Year Anniversary |
https://blog.xenproject.org/2019/01/31/xen-project-celebrates-unikraft-unikernel-projects-one-year-anniversary/#comment-575

[…] This article originally appeared at Xen Project. […]

QSB #47: Insecure default DisposableVM networking configuration
https://www.qubes-os.org/news/2019/02/19/qsb-47/

We have just published Qubes Security Bulletin (QSB) #47: Insecure default
DisposableVM networking configuration. The text of this QSB is reproduced below.
This QSB and its accompanying signatures will always be available in
the Qubes Security Pack (qubes-secpack).

View QSB #47 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-047-2019.txt

Learn about the qubes-secpack, including how to obtain, verify, and read
it:

https://www.qubes-os.org/security/pack/

View all past QSBs:

https://www.qubes-os.org/security/bulletins/



---===[ Qubes Security Bulletin #47 ]===---

2019-02-19

Insecure default DisposableVM networking configuration

Summary
========

In Qubes OS, one can attempt to limit the network access of a qube by
either completely disconnecting it from any NetVM or by setting its
firewall rules to disallow access. A malicious qube can circumvent these
limits by launching a DisposableVM [1], which, in the default
configuration, would have unrestricted network access.

Moreover, even when a non-default DisposableVM is configured to have no
network access (or limited access), other DisposableVMs started from
_that_ DisposableVM can have full network access (unless explicitly
configured otherwise).

While limiting network access in this manner should not be considered to
be an effective leak-prevention mechanism [1], we still consider this
type of potentially ineffective network isolation to be a problem.

Details
========

In Qubes 4.0, each DisposableVM is based on a DVM Template [2] with the
`template_for_dispvm` property set to "True". The DisposableVM inherits
all of its settings from the DVM Template, including the `netvm`
property and firewall rules. Neither the network settings nor any other
settings of the calling qube are considered. This design is intentional,
as it allows much more flexibility over the previous model. For example,
one could create different DVM Templates for different purposes, such as
opening links (internet access), viewing documents (offline), printing
(drivers installed), etc. Each DVM Template has appropriate network
settings for its purpose.

The important part of this design is the `default_dispvm` qube property.
The value of this property is the DVM Template that will be used when
starting new DisposableVMs from that qube. In the default configuration,
Qubes OS has one default DVM Template, which has unrestricted network
access. The default DVM Template is the default value of the global
`default_dispvm` property, which is accessible via "Global settings" in
the Qube Manager or via the `qubes-prefs` tool. This global property
serves as the default value for the `default_dispvm` property for every
qube. If the user creates a non-default DVM Template with limited
network access, the user must also set the `default_dispvm` value
(either globally or on a per-qube basis) in order for any new
DisposableVM to be based on this non-default DVM Template.

In the Whonix configuration shipped with Qubes, this issue is avoided by
creating a separate DVM Template that uses the Whonix Gateway
(`sys-whonix`) as its NetVM. The `default_dispvm` property of this DVM
Template is set to itself. This DVM Template is the value of the
`default_dispvm` property for every Whonix Workstation.

This problem is partially mitigated when restoring a backup from Qubes
3.2. For each qube that has the `dispvm_netvm` property set to "none", a
separate DVM Template named `disp-no-netvm` is created. This DVM
Template has no direct network access. However, this DVM Template itself
has the default value for its own `default_dispvm` property, so
DisposableVMs started from it or from DisposableVMs based on it would
have full network access.

Vulnerable systems
==================

This issue affects only Qubes 4.0. In Qubes 3.2, the network settings of
DisposableVM are inherited from the calling qube's settings (more
specifically, from its `dispvm_netvm` property, which defaults to the
`netvm` property's value).

The Whonix configuration shipped with Qubes 4.0 is not affected by this
issue. If you have installed Whonix using a method other than the
recommended `qubesctl` command [4], you should review the settings of
your Whonix qubes. Specifically:

- whonix-ws-14-dvm should have `netvm` set to sys-whonix
- whonix-ws-14-dvm should have `default_dispvm` set to whonix-ws-14-dvm
- anon-whonix and any other Whonix Workstations should have
`default_dispvm` set to whonix-ws-14-dvm

See the Whonix documentation [4] for details.

Systems in which the default DVM Template is disconnected from the
network (by settings its `netvm` property to "none") are not affected by
this issue.

Resolution
==========

To mitigate this problem, we are implementing two changes:

1. When a DisposableVM is started, automatically set its
`default_dispvm` to the DVM Template on which it is based. This means
that, when a DisposableVM is started from another DisposableVM, they
will both be based on the same DVM Template. Hence, they will have
all the same settings, including the same network settings. This
change will not affect DVM Templates for which user has manually
modified the `default_dispvm` property.

2. Add a warning message in the Qube Settings GUI when the NetVM of a
qube in the "Basic" tab is set to a different value than the NetVM of
the default DVM Template set in the "Advanced" tab.

Note that these changes concern only NetVM settings, not firewall
settings. If you want your DisposableVMs to have the same firewall
settings as the calling qube, you must adjust the firewall settings of
appropriate DVM Template yourself.

In the next version of Qubes, we will ship two DVM Templates by default:
one with network access and one without. This was already previously
discussed in issue #1121 [5].

Patching
=========

The specific packages that resolve the problems discussed in this
bulletin are as follows:

For Qubes OS 4.0:
- qubes-core-dom0 version 4.0.39
- qubes-manager version 4.0.28

The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command as follows:

For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update

For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.

Credits
========

The issue was reported by Vít 'v6ak' Šesták.

References
===========

[1] https://www.qubes-os.org/doc/disposablevm/
[2] https://www.qubes-os.org/doc/data-leaks/
[3] https://www.qubes-os.org/doc/glossary/#dvm-template
[4] https://www.whonix.org/wiki/Qubes/Install
[5] https://github.com/QubesOS/qubes-issues/issues/1121

--
The Qubes Security Team
https://www.qubes-os.org/security/

Qubes OS 3.2 approaching EOL on 2019-03-28
https://www.qubes-os.org/news/2019/02/20/qubes-3-2-approaching-eol/

Qubes OS releases are normally supported (https://www.qubes-os.org/doc/supported-versions/) for six months after each
subsequent major or minor release (https://www.qubes-os.org/doc/version-scheme/). However, in light of the more
demanding system requirements (https://www.qubes-os.org/doc/system-requirements/#qubes-release-4x) of Qubes 4.0, we previously announced
that we were extending (https://www.qubes-os.org/news/2016/09/02/4-0-minimum-requirements-3-2-extended-support/#extended-support-for-qubes-os-32) the support period for Qubes 3.2 to one full
year after the release of Qubes 4.0. Since Qubes 4.0 was released (https://www.qubes-os.org/news/2018/03/28/qubes-40/) on
2018-03-28, support for Qubes 3.2 is extended until 2019-03-28 (https://www.qubes-os.org/news/2018/03/28/qubes-40/#the-past-and-the-future).

Therefore, we strongly urge all current Qubes 3.2 users to upgrade to
Qubes 4.0 (https://www.qubes-os.org/doc/upgrade-to-r4.0/) before Qubes 3.2 reaches end-of-life (EOL) on 2019-03-28.
As always, the latest release is available on the downloads (https://www.qubes-os.org/downloads/) page.

Xen Project 4.10.3 and 4.9.4 are available
https://blog.xenproject.org/2019/02/26/xen-project-4-10-3-and-4-9-4-are-available/

I am pleased to announce the release of Xen 4.10.3 and 4.9.4. Xen Project Maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of the 4.10 and 4.9 stable series update to the latest point release. These releases are available from their git repositories xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.10 (tag RELEASE-4.10.3) xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.9 […]

Talk about Qubes in Stockholm tonight: https://www.meetup.com/Stockholm-Cybersecurity-Meetup/events/dwjxrqyzdbkc/

QSB #048: Multiple Xen vulnerabilities
https://www.qubes-os.org/news/2019/03/05/qsb-048/

We have just published Qubes Security Bulletin (QSB) #048:
Multiple Xen vulnerabilities.
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack (qubes-secpack).

View QSB #048 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-048-2019.txt

Learn about the qubes-secpack, including how to obtain, verify, and read it:

https://www.qubes-os.org/security/pack/

View all past QSBs:

https://www.qubes-os.org/security/bulletins/

View the Xen Security Advisory (XSA) Tracker:

https://www.qubes-os.org/security/xsa/



---===[ Qubes Security Bulletin #48 ]===---

2019-03-05

Multiple Xen vulnerabilities

Summary
========

On 2019-03-05, the Xen Security Team published the following Xen
Security Advisories (XSAs):

XSA-285 [1] "race with pass-through device hotplug":
| When adding a passed-through PCI device to a domain after it was
| already started, IOMMU page tables may need constructing on the fly.
| For PV guests the decision whether a page ought to have a mapping is
| based on whether the page is writable, to prevent IOMMU access to
| things like page tables. Writablility of a page may, however, change
| at any time. Failure of the relevant code to respect this possible
| race may lead to IOMMU mappings of, in particular, page tables,
| allowing the guest to alter such page tables without Xen auditing the
| changes.
|
| Malicious PV guests can escalate their privilege to that of the
| hypervisor.

XSA-287 [2] "x86: steal_page violates page_struct access discipline":
| Xen's reference counting rules were designed to allow pages to change
| owner and state without requiring a global lock. Each page has a page
| structure, and a very specific set of access disciplines must be
| observed to ensure that pages are freed properly, and that no writable
| mappings exist for PV pagetable pages.
|
| Unfortunately, when the XENMEM_exchange hypercall was introduced,
| these access disciplines were violated, opening up several potential
| race conditions.
|
| A single PV guest can leak arbitrary amounts of memory, leading to a
| denial of service.
|
| A cooperating pair of PV and HVM/PVH guests can get a writable
| pagetable entry, leading to information disclosure or privilege
| escalation.
|
| Privilege escalation attacks using only a single PV guest or a pair of
| PV guests have not been ruled out.
|
| Note that both of these attacks require very precise timing, which may
| be difficult to exploit in practice.

XSA-288 [3] "x86: Inconsistent PV IOMMU discipline":
| In order for a PV domain to set up DMA from a passed-through device to
| one of its pages, the page must be mapped in the IOMMU. On the other
| hand, before a PV page may be used as a "special" page type (such as a
| pagetable or denoscriptor table), it _must not_ be writable in the IOMMU
| (otherwise a malicious guest could DMA arbitrary page tables into the
| memory, bypassing Xen's safety checks); and Xen's current rule is to
| have such pages not in the IOMMU at all.
|
| Until now, in order to accomplish this, the code has borrowed HVM
| domain's "physmap" concept: When a page is assigned to a guest,
| guess_physmap_add_entry() is called, which for PV guests, will create
| a writable IOMMU mapping; and when a page is removed,
| guest_physmap_remove_entry() is called, which will remove the mapping.
|
| Additionally, when a page gains the PGT_writable page type, the page
| will be added into the IOMMU; and when the page changes away from a
| PGT_writable type, the page will be removed from the IOMMU.
|
| Unfortunately, borrowing the "physmap" concept from HVM domains is
| problematic. HVM domains have a lock on their p2m tables, ensuring

| synchronization between modifications to the p2m; and all hypercall
| parameters must first be translated through the p2m before being used.
| Trying to mix this locked-and-gated approach with PV's lock-free
| approach leads to several races and inconsistencies.
|
| An untrusted PV domain with access to a physical device can DMA into
| its own pagetables, leading to privilege escalation.

XSA-292 [4] "x86: insufficient TLB flushing when using PCID"
| Use of Process Context Identifiers (PCID) was introduced into Xen in
| order to improve performance after XSA-254 (and in particular its
| Meltdown sub-issue). This enablement implied changes to the TLB
| flushing logic. The particular case of context switch to a vCPU of a
| PCID-enabled guest left open a time window between the full TLB flush,
| and the actual address space switch, during which additional TLB
| entries (from the address space about to be switched away from) can be
| accumulated, which will not subsequently be purged.
|
| Malicious PV guests may be able to cause a host crash (Denial of
| Service) or to gain access to data pertaining to other guests.
| Privilege escalation opportunities cannot be ruled out.
|
| Additionally, vulnerable configurations are likely to be unstable even
| in the absence of an attack.


Impact on Qubes OS
===================

XSA-285 and XSA-288 do not affect Qubes OS 4.0 in its default
configuration, since they require a PV domain with a PCI device.
Moreover, in order to take advantage of XSA-285, the user would have to
assign a PCI device to a PV domain while it was running. Such an
operation is disabled in the Qubes GUI tools and discouraged in the
Qubes documentation. [5]

XSA-287 and XSA-292 affect only PV domains, which are used only for
stubdomains in the default Qubes OS 4.0 configuration. This means that
an attacker would first have to compromise a stubdomain in order to
attack Xen by exploiting these vulnerabilities. Nevertheless, since it
is possible to manually create PV domains in Qubes OS 4.0, we consider
XSA-287 and XSA-292 to affect Qubes OS 4.0.

All four of these XSAs affect Qubes OS 3.2.

Patching
=========

The specific packages that resolve the problems discussed in this
bulletin are as follows:

For Qubes OS 4.0:
- Xen packages version 4.8.5-3

For Qubes OS 3.2:
- Xen packages version 4.6.6-46

The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command as follows:

For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update

For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.

If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.

Credits
========

See the original Xen Security Advisories.

References
===========

[1] https://xenbits.xen.org/xsa/advisory-285.html
[2] https://xenbits.xen.org/xsa/advisory-287.html
[3] https://xenbits.xen.org/xsa/advisory-288.html
[4] https://xenbits.xen.org/xsa/advisory-292.html
[5] https://www.qubes-os.org/doc/assigning-devices/

--
The Qubes Security Team
https://www.qubes-os.org/security/

XSAs 284, 290, 291, 293, and 294 do not affect the security of Qubes OS
https://www.qubes-os.org/news/2019/03/05/xsa-284-290-291-293-294-qubes-not-affected/

The Xen Project has published Xen Security Advisories 284, 290, 291,
293, and 294 (XSA-284, XSA-290, XSA-291, XSA-293, and XSA-294,
respectively). These XSAs do not affect the security of Qubes OS,
and no user action is necessary.

These XSAs have been added to the XSA Tracker (https://www.qubes-os.org/security/xsa/):

https://www.qubes-os.org/security/xsa/#284
https://www.qubes-os.org/security/xsa/#290
https://www.qubes-os.org/security/xsa/#291
https://www.qubes-os.org/security/xsa/#293
https://www.qubes-os.org/security/xsa/#294

Xen Project 4.10.3 and 4.9.4 are available
https://xenproject.org/2019/02/25/xen-project-4-10-2-and-4-9-3-are-available-2/

Revolutionizing the Auto Industry with Open Source: EPAM’s Xen Powered Virtual Cockpit
https://xenproject.org/2019/03/12/revolutionizing-the-auto-industry-with-open-source-epams-xen-powered-virtual-cockpit/

EPAM, a global provider of software engineering and IT consulting services, is making strides in the auto industry by connecting the infotainment side of the car and the safety side...

Qubes Tor onion services will no longer be maintained
https://www.qubes-os.org/news/2019/03/24/tor-onion-services-no-longer-maintained/

We regret to announce that the Qubes Tor onion services will no longer
be maintained due to lack of resources. This includes all Qubes onion
services, including the Qubes website onion mirror and the onion package
repos.

We would like to thank the Whonix Project for generously maintaining
these services for over a year (https://www.qubes-os.org/news/2018/01/23/qubes-whonix-next-gen-tor-onion-services/). Maintaining the Tor
onion services requires labor, servers, and bandwidth. Unfortunately,
none of these resources are available to the Qubes OS or Whonix projects
in sufficient quantities to allow us to continue offering these
services.

We recommend that users who currently rely on any Qubes onion addresses
transition to the corresponding clearnet addresses immediately.

Qubes OS 3.2 has reached EOL
https://www.qubes-os.org/news/2019/03/28/qubes-3-2-has-reached-eol/

Qubes OS 3.2 has officially reached end-of-life (EOL). We strongly urge
all current Qubes 3.2 users to upgrade to Qubes 4.0 (https://www.qubes-os.org/doc/upgrade-to-r4.0/) immediately.
As always, the support statuses of all Qubes OS and TemplateVM versions
are available on the Supported Versions (https://www.qubes-os.org/doc/supported-versions/) page, and the latest release
is available on the Downloads (https://www.qubes-os.org/downloads/) page.

Previous announcements:
Extended Support for Qubes OS 3.2 (https://www.qubes-os.org/news/2016/09/02/4-0-minimum-requirements-3-2-extended-support/#extended-support-for-qubes-os-32)
Qubes 4.0: The Past and the Future (https://www.qubes-os.org/news/2018/03/28/qubes-40/#the-past-and-the-future)
Qubes 3.2 approaching EOL on 2019-03-28 (https://www.qubes-os.org/news/2018/02/20/qubes-3-2-approaching-eol)

Xen Project Hypervisor 4.12 Offers Smaller Code Size and Improved Security
https://xenproject.org/2019/04/02/xen-project-hypervisor-4-12-offers-smaller-code-size-and-improved-security/

Major release makes Xen an attractive option for automotive and embedded technologies. SAN FRANCISCO – April 2, 2019 — The Xen Project, an open source hypervisor hosted at the Linux...

What’s new in Xen 4.12
https://xenproject.org/2019/04/02/whats-new-in-xen-4-12/

I am pleased to announce the release of Xen Project Hypervisor 4.12. This latest release adds impressive feature improvements around security and code size, x86 architectural renewal (one of our...

Qubes Canary #19
https://www.qubes-os.org/news/2019/04/08/canary-19/

We have published Qubes Canary #19. The text of this canary is
reproduced below. This canary and its accompanying signatures will
always be available in the Qubes Security Pack (qubes-secpack).

View Qubes Canary #19 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-019-2019.txt

Learn about the qubes-secpack, including how to obtain, verify, and read
it:

https://www.qubes-os.org/security/pack/

View all past canaries:

https://www.qubes-os.org/security/canaries/



---===[ Qubes Canary #19 ]===---


Statements
-----------

The Qubes core developers who have digitally signed this file [1]
state the following:

1. The date of issue of this canary is April 3, 2019.

2. There have been 48 Qubes Security Bulletins published so far.

3. The Qubes Master Signing Key fingerprint is:

427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494

4. No warrants have ever been served to us with regard to the Qubes OS
Project (e.g. to hand out the private signing keys or to introduce
backdoors).

5. We plan to publish the next of these canary statements in the first
two weeks of July 2019. Special note should be taken if no new canary
is published by that time or if the list of statements changes without
plausible explanation.

Special announcements
----------------------

None.

Disclaimers and notes
----------------------

We would like to remind you that Qubes OS has been designed under the
assumption that all relevant infrastructure is permanently
compromised. This means that we assume NO trust in any of the servers
or services which host or provide any Qubes-related data, in
particular, software updates, source code repositories, and Qubes ISO
downloads.

This canary scheme is not infallible. Although signing the declaration
makes it very difficult for a third party to produce arbitrary
declarations, it does not prevent them from using force or other
means, like blackmail or compromising the signers' laptops, to coerce
us to produce false declarations.

The news feeds quoted below (Proof of freshness) serves to demonstrate
that this canary could not have been created prior to the date stated.
It shows that a series of canaries was not created in advance.

This declaration is merely a best effort and is provided without any
guarantee or warranty. It is not legally binding in any way to
anybody. None of the signers should be ever held legally responsible
for any of the statements made here.

Proof of freshness
-------------------

$ date -R -u
Wed, 03 Apr 2019 15:10:59 +0000

$ feedstail -1 -n5 -f '{noscript}' -u https://www.spiegel.de/international/index.rss
A Precarious Alliance: Patience Wears Thin with Germany's NATO Spending
Interview with NATO Secretary General Stoltenberg: The U.S. and President Trump 'Are 100 Percent Behind' Us
Interview with Sir David Attenborough: 'Collecting Memories Isn't the Same as Collecting Ammonites'
'I'm Just Being Me': British House Speaker Bercow on His Brexit Role
France's Golden Boy Learns How to Fight: Macron Debates His Way Out of The Yellow-Vest Crisis

$ feedstail -1 -n5 -f '{noscript}' -u https://rss.nytimes.com/services/xml/rss/nyt/World.xml
Theresa May and Jeremy Corbyn Consider Something New on Brexit: Cooperation
Egypt’s Soap Opera Clampdown Extends el-Sisi’s Iron Grip to TV
Najib Razak, Malaysian Leader Toppled in 1MDB Scandal, Faces First Graft Trial
Saudi Arabia Giving Jamal Khashoggi’s Children Money and Real Estate
Trudeau and Liberal Party Expel 2 Ex-Ministers at Center of Storm

$ feedstail -1 -n5 -f '{noscript}' -u https://feeds.bbci.co.uk/news/world/rss.xml
Brunei implements stoning to death under anti-LGBT laws
Charges dropped in deadly US biker brawl
Paris transgender woman 'humiliated' at protest
Jeffree Star says $2.5m worth of his cosmetic line stolen
1MDB: Superyacht linked to financial scandal sold for $126m

$ feedstail -1 -n5 -f '{noscript}' -u http://feeds.reuters.com/reuters/worldnews
Italy PM denies Tria could quit over 5-Star attacks
Brexit gamble: UK's May to meet opposition leader to seek a deal
EU would begin customs controls right after no-deal Brexit
Turkey says proposed working group to ease U.S. worries over Russian S-400s
Britain scrambles jets after Russian bombers approach UK airspace

$ curl -s 'https://blockchain.info/blocks/?format=json' |\
python3 -c 'import sys, json; print(json.load(sys.stdin)['\''blocks'\''][10]['\''hash'\''])'
00000000000000000010e57bfbfcbb49bdae6212789c51447316c4652bd6fcf3

Footnotes
----------

[1] This file should be signed in two ways: (1) via detached PGP
signatures by each of the signers, distributed together with this
canary in the qubes-secpack.git repo, and (2) via digital signatures
on the corresponding qubes-secpack.git repo tags. [2]

[2] Don't just trust the contents of this file blindly! Verify the
digital signatures!

Qubes Tor onion services are available again!

https://t.co/dURC3rug4Y

Qubes Tor onion services are available again!
https://www.qubes-os.org/news/2019/04/17/tor-onion-services-available-again/

We previously announced that the Qubes Tor onion services were no
longer being maintained (https://www.qubes-os.org/news/2018/01/23/qubes-whonix-next-gen-tor-onion-services/) due to lack of resources.
However, Unman (https://www.qubes-os.org/team/#unman) generously agreed to bring them back, and they’re now
available once again!

Here are the new onion service URLs:

Website: www.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion
Yum repo: yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion
Deb repo: deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion
ISOs: iso.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion


Soon, you will be able to get the new, correct repo definitions just by
updating dom0 and your TemplateVMs. However, if you can’t wait, you can
edit your repository definitions by following the instructions below.

Instructions

Follow these instructions only if you wish to update dom0 and your
TemplateVMs over Tor (via sys-whonix). This is an opt-in feature. If,
instead, you wish to update over your regular network connection (aka
“clearnet”), or if you are not sure, then do not follow these
instructions.

In order to use the new onion services, you must ensure that every
line that contains an onion address uses the appropriate new address
above. We’ll go through this for dom0, Fedora templates, and Debian
templates. Whonix templates do not require any action; their onion
addresses are still the same as before. For additional information, see
Onionizing Repositories (https://www.whonix.org/wiki/Onionizing_Repositories) on the Whonix wiki.

dom0


In dom0, open /etc/yum.repos.d/qubes-dom0.repo in a text editor.


Comment out all the baseurl = https://yum.qubes-os.org/[...] and
metalink lines.


Uncomment all the baseurl = [...].onion lines.

Update every .onion address to
yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion.
The affected lines should look like this:
#baseurl = https://yum.qubes-os.org/r$releasever/current/dom0/fc25
baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r$releasever/current/dom0/fc25
#metalink = https://yum.qubes-os.org/r$releasever/current/dom0/fc25/repodata/repomd.xml.metalink



Open /etc/yum.repos.d/qubes-templates.repo in a text editor and
repeat steps 2-4.

In Qubes Global Settings, set Dom0 UpdateVM to sys-whonix.
Fedora TemplateVMs


In the TemplateVM, open /etc/yum.repos.d/qubes-r4.repo in a text
editor.


Comment out every line that contains yum.qubes-os.org.


Uncomment every line that contains .onion.

Update every .onion address to
yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion.
The affected lines should look like this:
#baseurl = https://yum.qubes-os.org/r4.0/current/vm/fc$releasever
baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/current/vm/fc$releasever


In dom0, ensure that the first non-comment line in
/etc/qubes-rpc/policy/qubes.UpdatesProxy is:
$type:TemplateVM $default allow,target=sys-whonix


Debian TemplateVMs


In the TemplateVM, open /etc/apt/sources.list.d/qubes-r4.list in a
text editor.


Comment out every line that contains deb.qubes-os.org.


Uncomment every line that contains .onion.

Update every .onion address to
deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion.
The affected lines should look like this:
# Main qubes updates repository
#deb [arch=amd64] https://deb.qubes-os.org/r4.0/vm stretch main
#deb-src https://deb.qubes-os.org/r4.0/vm stretch main


# Qubes Tor updates repositories
# Main qubes updates repository