twitter qube itself are compromised. If your twitter qube makes an
authentication request for your bank website, it will be denied at the Qubes
policy level.

To enable this, create a file in dom0 named
/etc/qubes-rpc/policy/policy.RegisterArgument+u2f.Authenticate with the
following content:

sys-usb @anyvm allow,target=dom0


Next, empty the contents of /etc/qubes-rpc/policy/u2f.Authenticate so that it
is a blank file. Do not delete the file itself. (If you do, the default file
will be recreated the next time you update, so it will no longer be empty.)
Finally, follow your web application’s instructions to enroll your token and use
it as usual. (This enrollment process depends on the web application and is in
no way specific to Qubes U2F.)

The default model is to allow a qube to access all and only the keys that were
enrolled by that qube. For example, if your banking qube enrolls your banking
key, and your twitter qube enrolls your Twitter key, then your banking qube
will have access to your banking key but not your Twitter key, and your
twitter qube will have access to your Twitter key but not your banking key.

TemplateVM and browser support

The large number of possible combinations of Qubes version (3.2, 4.0),
TemplateVM (Fedora 27, 28; Debian 8, 9), and browser (multiple Google Chrome
versions, multiple Chromium versions, multiple Firefox versions) made it
impractical for us to test every combination that users are likely to attempt
with the Qubes U2F Proxy. In some cases, you may be the first person to try a
particular combination. Consequently (and as with any new feature), users will
inevitably encounter bugs. We ask for your patience and understanding in this
regard. As always, please report any bugs you encounter (https://www.qubes-os.org/doc/reporting-bugs/).

Please note that, in Firefox before Quantum (e.g. Firefox 52 in Debian 9), you
have to install the U2F Support Add-on (https://addons.mozilla.org/en-US/firefox/addon/u2f-support-add-on/?src=api). In Firefox post-Quantum
you may have to enable the security.webauth.u2f flag in about:config. Chrome
and Chromium do not require any special browser extensions.

Future work

The U2F specification foresees not only USB tokens, but also smartcard-like
(ISO 7816) devices, including NFC devices (mainly used with smartphones).
Our qrexec (https://www.qubes-os.org/doc/qrexec3/) API should work with these, but the backend has not been
implemented.

In theory, U2F tokens are not limited to web applications, though much of the
standardisation work was done with that use case in mind. Fedora, the
distribution we use in dom0, has packages intended to allow user authentication
using the same tokens, and the U2F proxy also works in dom0, though we haven’t
tested it. (The package is provided, though.) If you’d like to try it yourself,
by all means please do and share your experiences on the qubes-devel (https://www.qubes-os.org/support/#qubes-devel) mailing
list.

Acknowledgements

We’d like to thank Google’s Enterprise Infrastructure Protection Team (aka the
Google Security Team) for supporting this project. As part of this
collaboration, we’ve also developed another piece of software, which we intend
to announce in the near future. Stay tuned.

<!-- vim: set ft=markdown tw=80 ts=4 sts=4 sw=4 et : -->

Whonix version support policy
https://www.qubes-os.org/news/2018/09/13/whonix-version-support-policy/

With the recent release of Whonix 14 (https://www.qubes-os.org/news/2018/08/07/whonix-14-has-been-released/) and subsequent announcement that Whonix
13 will reach EOL (end-of-life) on 2018-09-30 (https://www.qubes-os.org/news/2018/08/24/whonix-13-approaching-eol/), we have updated
the Supported Versions (https://www.qubes-os.org/doc/supported-versions/) page with a new section (https://www.qubes-os.org/doc/supported-versions/#whonix) explaining the Whonix
support policy. For your convenience, the content of that section, as it
currently appears, is reproduced below. In the future, users are advised to
consult the Supported Versions (https://www.qubes-os.org/doc/supported-versions/) page for the current version of the policy.

Whonix (https://www.qubes-os.org/doc/whonix/) is an advanced feature in Qubes OS. Those who wish to use it must
stay reasonably close to the cutting edge by upgrading to new stable versions
of Qubes OS and Whonix TemplateVMs within a month of their respective releases.
To be precise:


One month after a new stable version of Qubes OS is released, Whonix
TemplateVMs will no longer be supported on any older version of Qubes OS.
This means that users who wish to continue using Whonix TemplateVMs on Qubes
must always upgrade to the latest stable Qubes OS version within one month
of its release.


One month after new stable versions of Whonix TemplateVMs are released,
older versions of Whonix TemplateVMs will no longer be supported. This
means that users who wish to continue using Whonix TemplateVMs on Qubes must
always upgrade to the latest stable Whonix TemplateVM versions within one
month of their release.

We aim to announce both types of events one month in advance in order to remind
users to upgrade.

Comment on What’s New in the Xen Project Hypervisor 4.11 by A Recap of the Xen Project Developer and Design Summit: Community Health, Development Trends, Coding Changes and More | Xen Project Blog
https://blog.xenproject.org/2018/07/10/whats-new-in-the-xen-project-hypervisor-4-11/#comment-538

[…] can see the progress of our re-architecture in our latest release, Xen Project hypervisor 4.11. Also, the following summit presentations were relevant: here (Xen and automotive at Samsung) here […]

Comment on What’s New in the Xen Project Hypervisor 4.11 by ????? ??????????? Xen 4.11
https://blog.xenproject.org/2018/07/10/whats-new-in-the-xen-project-hypervisor-4-11/#comment-539

[…] ???? ??????? ?????????? ????????? ????? ?????????? ??????????? Xen 4.11. ?? ????????? ? […]

Comment on Xen Project Spectre/Meltdown FAQ by Security Info: Meltdown & Spectre – gravierende Sicherheitslücke in Prozessoren || thingybob.de
https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/#comment-556

[…] Xen […]

Xen Project 4.10.2 and 4.9.3 are available
https://blog.xenproject.org/2018/09/25/xen-project-4-10-2-and-4-9-3-are-available/

I am pleased to announce the release of Xen 4.10.2 and 4.9.3. 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.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.10 (tag RELEASE-4.10.2) xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.9 […]

Qubes OS 3.2.1-rc1 has been released!
https://www.qubes-os.org/news/2018/10/05/qubes-321-rc1/

We’re pleased to announce the first release candidate for Qubes 3.2.1!
This is the first and only planned point release for version 3.2.
Features:

Fedora 28 TemplateVM
Debian 9 TemplateVM
Whonix 14 Gateway and Workstation TemplateVMs
Linux kernel 4.14
Qubes 3.2.1-rc1 is available on the Downloads (https://www.qubes-os.org/downloads/#qubes-release-3-2-1-rc1) page.

What is a point release?

A point release does not designate a separate, new version of Qubes OS.
Rather, it designates its respective major or minor release (in this
case, 3.2) inclusive of all updates up to a certain point. Installing
Qubes 3.2 and fully updating it results in the same system as installing
Qubes 3.2.1.

What should I do?

If you’re currently using an up-to-date Qubes 3.2 installation, then
your system is already equivalent to a Qubes 3.2.1 installation. No
action is needed.

Regardless of your current OS, if you wish to install (or reinstall)
Qubes 3.2 for any reason, then the 3.2.1 ISO will make this more
convenient and secure, since it bundles all Qubes 3.2 updates to date.
It will be especially helpful for users whose hardware is too new to be
compatible with the original Qubes 3.2 installer.

As a reminder, Qubes 3.2 (and, therefore, Qubes 3.2.1) is scheduled to
reach EOL (end-of-life) on 2019-03-28 (https://www.qubes-os.org/doc/supported-versions/#qubes-os).

Release candidate planning

If no major problems are discovered with this release candidate in the
next two weeks, it will be designated the final 3.2.1 release. Please
report any bugs you find. (https://www.qubes-os.org/doc/reporting-bugs/)

What about Qubes 4.0.1?

The Qubes developers are hard at work on 4.0.1, which will be the first
point release for Qubes 4.0. We hope to have further news about this
within the next few weeks. Stay tuned!

Whonix support ending for Qubes 3.2
https://www.qubes-os.org/news/2018/10/05/whonix-support-ending-for-qubes-32/

Due to limited developer time and resources, the Whonix Project (https://www.whonix.org/) will
end support for Qubes 3.2 on 2018-11-15.

Whonix support for Qubes OS

Please note that there is a distinction between Qubes supporting Whonix
and Whonix supporting Qubes.


Qubes supporting Whonix means that Qubes OS allows the secure
installation and use of Whonix TemplateVMs (https://www.qubes-os.org/doc/whonix/) inside of Qubes OS. In
this case, the Qubes developers work to ensure that code on the Qubes
side is set up to accommodate Whonix TemplateVMs. (This is the same
sense in which Qubes supports Fedora and Debian TemplateVMs.) Here is
a table (https://www.qubes-os.org/doc/supported-versions/#templatevms) of the TemplateVM types that Qubes
supports.


Whonix supporting Qubes means that Whonix is designed to be
installable and usable as a pair of TemplateVMs inside of Qubes OS.
In this case, the Whonix developers work to ensure that code on the
Whonix side is set up to work inside of Qubes OS. (Similarly, the
Whonix Project also works to ensure that Whonix can be installed
inside of VirtualBox, for example.) Here is the Whonix version
support policy (https://www.qubes-os.org/doc/supported-versions/#whonix) for Qubes OS.

Both directions of support are necessary in order to ensure that Whonix
functions properly inside of Qubes, and the Qubes and Whonix developers
work together toward this shared goal.

This particular announcement concerns the second direction of support:
Whonix supporting Qubes (in particular, ending support for Qubes 3.2).

Difference from EOL

Whonix 13 recently reached EOL (end-of-life) on
2018-09-30 (https://www.qubes-os.org/news/2018/08/24/whonix-13-approaching-eol/). When a an OS or TemplateVM version reaches
EOL, it no longer receives support from its maintainer. In this
announcement, however, nothing is reaching EOL. Whonix is ending support
for Qubes 3.2 2018-11-15, but the Qubes OS Project will continue to
support Qubes 3.2 as planned until 2019-03-28 (https://www.qubes-os.org/news/2018/03/28/qubes-40/#the-past-and-the-future).

What this means for you as a user

If you are using Qubes 4.0, this announcement does not affect you. If
you are using Qubes 3.2, the Whonix Project will no longer support your
system after 2018-11-15. This means that no developers from the Whonix
Project will be monitoring or working on issues that pertain solely to
Qubes 3.2. Therefore, the Whonix Project cannot guarantee that Whonix
will continue to function as expected on Qubes 3.2.

However, since Qubes 3.2 is a mature platform, it is likely that Whonix
will continue to work normally until Qubes 3.2 reaches EOL on
2019-03-28. Users who decide to continue using Whonix on Qubes 3.2 do so
at their own risk. It is possible that an upgrade could break certain
functionality, such as apt-get upgrading, networking, VM booting, or VM
graphics. The Whonix Project believes it is unlikely (though not
impossible) that a clearnet leak would result from continued use. For
further assistance, please consult the Whonix support page (https://www.whonix.org/wiki/Support).

Qubes #TemplateVM #Recovery - Part 1

Qubes Canary #17
https://www.qubes-os.org/news/2018/10/15/canary-17/

Dear Qubes Community,

We have published Qubes Canary #17. 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 #17 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-017-2018.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 #17 ]===---


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

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

1. The date of issue of this canary is October 15, 2018.

2. There have been 43 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 January 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
Mon, 15 Oct 2018 12:56:41 +0000

$ feedstail -1 -n5 -f '{noscript}' -u https://www.spiegel.de/international/index.rss
Merkel's Bavaria Headache: Berlin Coalition Emerges Even Weaker
A European IMF: The New Face of the Eurozone Bailout Fund
Social Design Award: Vote For Your Favorite Neighborhood Project
Rape Allegations: Ronaldo's Defense Team Develops a Strategy
Operation Mekong: China Solidifies Its Influence in Southeast Asia

$ feedstail -1 -n5 -f '{noscript}' -u https://rss.nytimes.com/services/xml/rss/nyt/World.xml
‘Our Hands Can Reach You’: Khashoggi Case Shakes Saudi Dissidents Abroad
Brazil Edges Toward Bolsonaro as a ‘Last Resort’ Leader
How to Attract a Killer Tigress? Try a Man’s Cologne
Kim Jong-un Invites Pope Francis to North Korea
Bulgarian Journalist, Host of Anticorruption TV Show, Is Raped and Killed

$ feedstail -1 -n5 -f '{noscript}' -u https://feeds.bbci.co.uk/news/world/rss.xml
Jamal Khashoggi: Turkey to search Saudi consulate in Istanbul
France weather: Red alert as flash floods kill 13 in south-west
Buckethead the bear cub's head freed from jar after three days
Hostage held at Cologne main train station
China star detained for 'anthem insult'

$ feedstail -1 -n5 -f '{noscript}' -u http://feeds.reuters.com/reuters/worldnews
Jordan and Syria reopen Nassib border crossing

U.S. still aiming to cut Iran oil sales to zero, market well-supplied: U.S. envoy for Iran
Saudi king orders probe in Khashoggi case, Turkey to search consulate
Bavaria election shakes Merkel's coalition, far-right rejoices
Merkel vows to regain trust after conservative losses in Bavaria


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

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!

Celebrating 15 Years of the Xen Project and Our Future
https://blog.xenproject.org/2018/10/23/celebrating-15-years-of-the-xen-project-and-our-future/

In the 1990s, Xen was a part of a research project to build a public computing infrastructure on the Internet led by Ian Pratt and Keir Fraser at The University of Cambridge Computer Laboratory. The Xen Project is now one of the most popular open source hypervisors and amasses more than 10 million users, and […]

XSA-278 does not affect the security of Qubes OS
https://www.qubes-os.org/news/2018/10/24/xsa-278-qubes-not-affected/

Dear Qubes Community,

The Xen Project has published Xen Security Advisory 278 (XSA-278). This
XSA does not affect the security of Qubes OS, and no user action is
necessary.

This XSA has been added to the XSA Tracker (https://www.qubes-os.org/security/xsa/):

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

Thank you, Joanna!
https://www.qubes-os.org/news/2018/10/25/thank-you-joanna/

The Qubes OS project was founded by Joanna Rutkowska in 2009 (https://blog.invisiblethings.org/2010/04/07/introducing-qubes-os.html).
I joined the project in its early days, before Qubes 1.0, and have been part of
the team under Joanna’s leadership since then. Over the past nine years, the
system architecture has been enhanced multiple times, including major changes
like HVM with stubdomain support (https://blog.invisiblethings.org/2012/12/14/qubes-2-beta-1-with-initial-windows.html), the Hypervisor Abstraction Layer
(HAL) (https://blog.invisiblethings.org/2013/03/21/introducing-qubes-odyssey-framework.html), and finally, in Qubes 4.0, the Admin API (https://blog.invisiblethings.org/2017/06/27/qubes-admin-api.html) and switch
to PVH (https://www.qubes-os.org/news/2016/09/02/4-0-minimum-requirements-3-2-extended-support/) as the main VM type. The project has also matured a lot. We
started as a set of a few (https://github.com/QubesOS/qubes-doc/blob/6ac51fb134093168ec3900c9bed22c3a86bcd021/SourceCode.md) manually built (https://groups.google.com/d/msg/qubes-devel/cQ9yVxPMfoo/CTIXml3B_NcJ) packages
installed on top of Fedora 12 (https://github.com/QubesOS/qubes-doc/blob/d6639edf47a7b85e54cd470380de25e1b7403407/InstallationGuide.md). Now, we have a build
infrastructure (https://github.com/QubesOS/qubes-infrastructure/blob/master/README.md#detailed-denoscription-of-the-infrastructure), documented versioning scheme (https://www.qubes-os.org/doc/version-scheme/)
and release schedules (https://www.qubes-os.org/doc/releases/schedules/), coding guidelines (https://www.qubes-os.org/doc/coding-style/),
and automated tests (https://www.qubes-os.org/doc/automated-tests/). The core part of Qubes has also been
rewritten a few times since its original release. The project’s success can be
measured by its growing community, including deployments like SecureDrop (https://securedrop.org/news/road-towards-integrated-securedrop-workstation/) and
Let’s Encrypt (https://twitter.com/RMLLsec16/status/749982515948027904).

Today Joanna announced (https://www.qubes-os.org/news/2018/10/25/the-next-chapter/) that she is stepping down from the
project’s leadership role and nominating me as her successor. I have been the
project’s lead engineer for a few years now, and I’m honored to officially lead
the project as a whole. I plan to continue the direction in which Qubes OS has
been going, providing defenses well ahead (https://twitter.com/rootkovska/status/530416582426902528) of new attacks.

On behalf of the whole Qubes team, I’d like to thank Joanna for all of her
years of work on the project. Under her leadership, Qubes OS has accomplished a
lot, with only some of its many successes mentioned above. We look forward to
continuing to benefit from her expertise as an advisor. At the same time, we
wish her all the best in her new role on the Golem Project!

The Next Chapter: From the Endpoint to the Cloud
https://www.qubes-os.org/news/2018/10/25/the-next-chapter/

Earlier this year, I decided to take a sabbatical. I wanted to reflect on my
infosec work and decide what I would like to focus on in the coming years. As
you probably know, I’ve spent the last nine years mostly fighting the battle to
secure the endpoint, more specifically creating, developing, architecting, and
promoting Qubes OS (https://www.qubes-os.org/), as well as the more general
concept of “Security through
Distrusting” (https://www.blackhat.com/eu-17/briefings.html#security-through-distrusting).

Over these past nine years, Qubes OS has grown from a research-inspired
proof-of-concept into a reasonably mature, large open-source project with
dozens of contributors (https://www.qubes-os.org/team/) and tens of thousands
of users (https://www.qubes-os.org/statistics/), including some high-profile
security experts (https://www.qubes-os.org/experts/).

There are still many challenges ahead for Qubes, however. The primary two are
improving hardware compatibility and UX. I think addressing these challenges
will mostly be an iterative process of gradual improvement, but it will
nonetheless require a lot of time and resources.

Another challenge is the trustworthiness of the x86
platform (https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf). Again,
I remain optimistic that many things could be improved on this front, as well
(see, for example, my proposal for a stateless laptop
design (https://blog.invisiblethings.org/papers/2015/state_harmful.pdf)).
Admittedly, such work will require significantly more resources, but I know
there is a lot of interest in this area, and it just needs proper coordination
to happen.

Despite all of these interesting challenges (especially with platform
trustworthiness), I’ve decided I’d like to switch my focus to something other
than endpoint security. While I still believe that the security of our digital
lives starts and ends with the trustworthiness of the client devices we use
(which today include much more than just laptops and desktops, of course), I
also recognize that the state of endpoint device security has significantly
improved over the past decade. At the same time, most of our data and activities
have migrated from local devices to the cloud.

And yet, there are fundamental problems with cloud
trustworthiness (https://twitter.com/rootkovska/status/1051392157096001536), or
the lack thereof. These problems could be summarized as the need for users (i.e.
all of us) to be forced to trust three different entities: (1) the service
providers who own our data (e.g. the vendor of your fitness tracking app), (2)
the hosting infrastructure owners, who can both access our data as well as deny
us use of the service at their discretion (e.g. AWS, Azure, GCP), and (3) the
networking infrastructure operators, who can also selectively cut us off from
the services (e.g. to implement some form of censorship).

These are very important problems, in my opinion, and I’d like to work now on
making the cloud more trustworthy, specifically by limiting the amount of trust
we have to place in it.

So, this month I’ve joined the Golem Project (https://golem.network/) as a
Chief Strategy Officer, also doubling as Chief Security Officer (conveniently,
both roles have the same CSO acronym :) The double nature of my role emphasizes
the close relationships among the long-term roadmap, technical architecture,
as well as product- and operations-security in Golem.

Why Golem? Because Golem is a very unique project. Golem has been on a mission
to build a “decentralized computer” out of a heterogeneous network of
third-party provided computers. Founded two years ago through a very successful
crowdfunding campaign, it instantly gained an impressive amount of funding,
which allowed it to build a strong development team (incidentally, mostly based
in my favorite city – Warsaw).

The distributed funding model has also essentially eliminated two common
obstacles most tech startups face: lack of money to hire enough people and the
need to implement investors’ (rather than the founders’) agenda. In this
respect Golem seems to be as independent as one could realistically imagine.

Most importantly, we (ITL), have already been
working (https://blog.invisiblethings.org/2018/06/11/graphene-ng.html) with
Golem over the past year. During that time I’ve had enough time to get to know
some of the key people in the project, understand their personal agendas, and
conclude they might be very much inline with my own.

As for the future of Qubes, I don’t think much will change here. In recent
years, Marek
Marczykowski-Górecki (https://www.qubes-os.org/team/#marek-marczykowski-g%C3%B3recki)
has been effectively leading most of the day-to-day efforts with Qubes OS
development, while I’ve focused mostly on long-term architecture planning and
various research activities, such as our SGX-related work. Marek will continue
to lead Qubes now, so I’m reassured about the future of the project. I will also
remain as an advisor to the Qubes OS Project, as well as… its user, though I’ve
recently also been embracing other systems, including – of course – the cloud.

Finally, I’d like to thank my (present and past) ITL colleagues. We have
undertaken quite a few projects together, of which Qubes OS is probably the most
challenging and spectacular. Yet it was hardly the only one. There was also all
the (allegedly
pioneering (https://twitter.com/dwizzzleMSFT/status/1006733071511519232))
offensive system security research done together with Rafał Wojtczuk and Alex
Tereshkin. This research was instrumental in our subsequent work on Qubes OS,
and I think it will again prove useful for my work on Golem.

Qubes OS 4.0.1-rc1 has been released!
https://www.qubes-os.org/news/2018/11/05/qubes-401-rc1/

We’re pleased to announce the first release candidate for Qubes 4.0.1!
This is the first of at least two planned point releases for version 4.0.
Features:

All 4.0 dom0 updates to date
Fedora 29 TemplateVM
Debian 9 TemplateVM
Whonix 14 Gateway and Workstation TemplateVMs
Linux kernel 4.14
Qubes 4.0.1-rc1 is available on the Downloads (https://www.qubes-os.org/downloads/#qubes-release-4-0-1-rc1) page.

What is a point release?

A point release does not designate a separate, new version of Qubes OS.
Rather, it designates its respective major or minor release (in this
case, 4.0) inclusive of all updates up to a certain point. Installing
Qubes 4.0 and fully updating it results in the same system as installing
Qubes 4.0.1.

What should I do?

If you’re currently using an up-to-date Qubes 4.0 installation, then
your system is already equivalent to a Qubes 4.0.1 installation. No
action is needed.

Regardless of your current OS, if you wish to install (or reinstall)
Qubes 4.0 for any reason, then the 4.0.1 ISO will make this more
convenient and secure, since it bundles all Qubes 4.0 updates to date.
It will be especially helpful for users whose hardware is too new to be
compatible with the original Qubes 4.0 installer.

Release candidate planning

We expect that there will be a second release candidate (4.0.1-rc2) following
this one (4.0.1-rc1). The second release candidate will include a fix for the
Nautilus bug reported in #4460 (https://github.com/QubesOS/qubes-issues/issues/4460) along with any other available fixes for bugs
reported against this release candidate. As usual, you can help by reporting
any bugs you encounter (https://www.qubes-os.org/doc/reporting-bugs/).

What about Qubes 3.2.1?

We announced the release of 3.2.1-rc1 one month ago (https://www.qubes-os.org/news/2018/10/05/qubes-321-rc1/). Since no serious
problems have been discovered in 3.2.1-rc1, we plan to build the final version
of Qubes 3.2.1 at the end of this week.