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.

Qubes Security Team Update
https://www.qubes-os.org/news/2018/11/05/qubes-security-team-update/

As we recently announced, Joanna Rutkowska (https://www.qubes-os.org/team/#joanna-rutkowska) has turned over leadership of the
Qubes OS Project to Marek Marczykowski-Górecki (https://www.qubes-os.org/team/#marek-marczykowski-g%C3%B3recki) (see Joanna’s announcement (https://www.qubes-os.org/news/2018/10/25/the-next-chapter/)
and Marek’s announcement (https://www.qubes-os.org/news/2018/10/25/thank-you-joanna/)). In this post, we’ll discuss the implications of
these changes for the Qubes Security Team and how we’re addressing them.

What is the Qubes Security Team?

The Qubes Security Team (QST) (https://www.qubes-os.org/security/#the-qubes-security-team) is the subset of the Qubes Team (https://www.qubes-os.org/team/) that is
responsible for ensuring the security of Qubes OS and the Qubes OS Project.
In particular, the QST is responsible for:

Responding to reported security issues (https://www.qubes-os.org/security/#reporting-security-issues-in-qubes-os)
Evaluating whether Xen Security Advisories (XSAs) (https://www.qubes-os.org/security/xsa/) affect the security of
Qubes OS
Writing, applying, and/or distributing security patches to fix
vulnerabilities in Qubes OS
Writing, signing, and publishing Qubes Security Bulletins (QSBs) (https://www.qubes-os.org/security/bulletins/)
Writing, signing, and publishing Qubes Canaries (https://www.qubes-os.org/security/canaries/)
Generating, safeguarding, and using the project’s PGP keys (https://keys.qubes-os.org/keys/)
As a security-oriented operating system, the QST is fundamentally important to
Qubes, and every Qubes user implicitly trusts the members of the QST by virtue
of the actions listed above.

How does the recent change in leadership affect the QST?

Until now, the two members of the QST have been Joanna and Marek. With Joanna’s
new role at the Golem Project, she will no longer have time to function as a QST
member. Therefore, Joanna will officially transfer ownership of the Qubes
Master Signing Key (QMSK) (https://www.qubes-os.org/security/verifying-signatures/#1-get-the-qubes-master-signing-key-and-verify-its-authenticity) to Marek, and she will no longer sign QSBs.

However, due to the nature of PGP keys, there is no way to guarantee that Joanna
will not retain a copy of the QMSK after transferring ownership to Marek. Since
anyone in possession of the QMSK is a potential attack vector against the
project, Joanna will continue to sign Qubes Canaries (https://www.qubes-os.org/security/canaries/) in perpetuity.

With Joanna’s departure from the QST, Marek would remain as its sole member.
Given the critical importance of the QST to the project, however, we believe
that a single member would be insufficient. Therefore, after careful
consideration, we have selected a new member for the QST from among our
experienced Qubes Team members: Simon Gaiser (aka HW42) (https://www.qubes-os.org/team/#simon-gaiser-aka-hw42).

About Simon

Simon (https://www.qubes-os.org/team/#simon-gaiser-aka-hw42) has been a member of the Qubes Team for over two years and has been a
contributor to the project since 2014. He has worked on many different parts of
the Qubes codebase, including core, Xen, kernel, and GUI components. Earlier
this year, he joined Invisible Things Lab (ITL) and has been gaining experience
with other security projects. His thorough knowledge of Qubes OS, ability to
assess the severity of security vulnerabilities, and experience preparing Xen
patches make him very well-suited to the QST. Most importantly, both Joanna and
Marek trust him with the responsibilities of this important role. We are pleased
to announce Simon’s new role as a QST member. Congratulations, Simon, and thank
you for working to keep Qubes secure!

Comment on Celebrating 15 Years of the Xen Project and Our Future by fbifido
https://blog.xenproject.org/2018/10/23/celebrating-15-years-of-the-xen-project-and-our-future/#comment-561

Hi,
To me, it does not seem like Xen is doing all that it can to get more people using it.
you seem to try and not compete with hyper-v or VMware, but openly tell customers that they can move from VMware to XenServer, but not from hyper-v to XenServer.
needed feature:
-built-in VM network micro-segmentation must be part of the core of Xen.
-- you can use simple access list or network list AWS but per VM.
-built-in security guard must be part of the core of Xen.

(Xen does not need add-ons for these features, they need to bake into the core of XEN)

thanks.

Comment on Celebrating 15 Years of the Xen Project and Our Future by fbifido
https://blog.xenproject.org/2018/10/23/celebrating-15-years-of-the-xen-project-and-our-future/#comment-562

correction:
"— you can use simple access list or network list, like AWS, but per VM"

Comment on Celebrating 15 Years of the Xen Project and Our Future by fbifido
https://blog.xenproject.org/2018/10/23/celebrating-15-years-of-the-xen-project-and-our-future/#comment-563

future point 3:
if you can get Xen booted in under 10 seconds, then how about trying to put Xen in server or pc BIOS/UEFI or onboard EPROM.
I am sure you can talk Intel/IBM/AMD to create a new onboard UEFI/BIOS chip that uses 3D-NVDIMM & NVMe, that way the pc/server only has one bios/efi and that is Xen.

thanks.

XSA-282 does not affect the security of Qubes OS
https://www.qubes-os.org/news/2018/11/06/xsa-282-qubes-not-affected/

Dear Qubes Community,

The Xen Project has published Xen Security Advisory 282 (XSA-282). 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/#282

Qubes OS 3.2.1 has been released!
https://www.qubes-os.org/news/2018/11/12/qubes-321/

We’re pleased to announce the stable release of Qubes 3.2.1! As we previously
announced (https://www.qubes-os.org/news/2018/10/05/qubes-321-rc1/), this is the first and only planned point release for
version 3.2. Since no major problems were discovered with 3.2.1-rc1, this stable
release is not significantly different from the release candidate. Features:

Fedora 28 TemplateVM
Debian 9 TemplateVM
Whonix 14 Gateway and Workstation TemplateVMs
Linux kernel 4.14
Release 3.2.1 has replaced Release 3.2 on the Downloads (https://www.qubes-os.org/downloads/) 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).

What about Qubes 4.0.1?

We recently announced the release of 4.0.1-rc1 (https://www.qubes-os.org/news/2018/11/05/qubes-401-rc1/). You can help us test (https://www.qubes-os.org/doc/testing/) this
release candidate and report any bugs you encounter (https://www.qubes-os.org/doc/reporting-bugs/) so that they can be fixed
before the stable release.