TinyVMI: Porting LibVMI to Mini-OS on Xen Project Hypervisor
https://blog.xenproject.org/2018/09/05/tinyvmi-porting-libvmi-to-mini-os-on-xen-project-hypervisor/
This blog post comes from Lele Ma, a Ph.D. student at William and Mary. He was recently a Google Summer of Code Intern working on the Honeynet Project. Introduction This post introduces the project I worked on with Honeynet Project at Google Summer of Code this year. The project of TinyVMI is to port a […]
https://blog.xenproject.org/2018/09/05/tinyvmi-porting-libvmi-to-mini-os-on-xen-project-hypervisor/
This blog post comes from Lele Ma, a Ph.D. student at William and Mary. He was recently a Google Summer of Code Intern working on the Honeynet Project. Introduction This post introduces the project I worked on with Honeynet Project at Google Summer of Code this year. The project of TinyVMI is to port a […]
Introducing the Qubes U2F Proxy
https://www.qubes-os.org/news/2018/09/11/qubes-u2f-proxy/
Today we’d like to announce the Qubes U2F Proxy (https://github.com/QubesOS/qubes-app-u2f). It is a secure proxy intended
to make use of U2F two-factor authentication devices with web browsers without
exposing the browser to the full USB stack, not unlike the USB keyboard and
mouse proxies (https://www.qubes-os.org/doc/usb/) we’ve already implemented in Qubes.
What is U2F?
U2F (https://en.wikipedia.org/wiki/U2F), which stands for “Universal 2nd Factor”, is a framework for
authentication using hardware devices (U2F tokens) as “second factors”, i.e.
what you have as opposed to what you know, like a passphrase. This
additional control provides good protection (https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing/) in cases in which the
passphrase is stolen (e.g. by phishing or keylogging). While passphrase
compromise may not be obvious to the user, a physical device that cannot be
duplicated must be stolen to be used outside of the owner’s control.
Nonetheless, it is important to note at the outset that U2F cannot guarantee
security when the host system is compromised (e.g. a malware-infected operating
system under an adversary’s control).
The U2F specification defines protocols for multiple layers from USB to the
browser API, and the whole stack is intended to be used with web applications
(most commonly websites) in browsers. In most cases, tokens are USB dongles.
The protocol is very simple, allowing the devices to store very little state
inside (so the tokens may be reasonably cheap) while simultaneously
authenticating a virtually unlimited number of services (so each person needs
only one token, not one token per application). The user interface is usually
limited to a single LED and a button that is pressed to confirm each
transaction, so the devices themselves are also easy to use.
Currently, the most common form of two-step authentication consists of a numeric
code that the user manually types into a web application. These codes are
typically generated by an app on the user’s smartphone or sent via SMS. By now,
it is well-known that this form of two-step authentication is vulnerable to
phishing and man-in-the-middle attacks due to the fact that the application
requesting the two-step authentication code is typically not itself
authenticated by the user. (In other words, users can accidentally give their
codes to attackers because they do not always know who is really requesting the
code.) In the U2F model, by contrast, the browser ensures that the token
receives valid information about the web application requesting authentication,
so the token knows which application it is authenticating (for details, see
here (https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-overview-v1.2-ps-20170411.html#site-specific-public-private-key-pairs)). Nonetheless, some attacks are still possible (https://www.wired.com/story/chrome-yubikey-phishing-webusb/) even
with U2F (more on this below).
Our take on U2F
In a conventional setup, web browsers and the USB stack (to which the U2F token
is connected) are all running in the same monolithic OS. Since the U2F model
assumes that the browser is trustworthy, any browser in the OS is able to access
any key stored on the U2F token. The user has no way to know which keys have
been accessed by which browsers for which services. If any of the browsers are
compromised, it should be assumed that all of the token’s keys have been
compromised. (This problem can be mitigated, however, if the U2F device has a
special display to show the user what’s being authenticated.) Moreover, since
the USB stack is in the same monolithic OS, the system is vulnerable to attacks
like BadUSB (https://www.blackhat.com/us-14/briefings.html#badusb-on-accessories-that-turn-evil).
In Qubes OS, by contrast, it is possible to securely compartmentalise the
https://www.qubes-os.org/news/2018/09/11/qubes-u2f-proxy/
Today we’d like to announce the Qubes U2F Proxy (https://github.com/QubesOS/qubes-app-u2f). It is a secure proxy intended
to make use of U2F two-factor authentication devices with web browsers without
exposing the browser to the full USB stack, not unlike the USB keyboard and
mouse proxies (https://www.qubes-os.org/doc/usb/) we’ve already implemented in Qubes.
What is U2F?
U2F (https://en.wikipedia.org/wiki/U2F), which stands for “Universal 2nd Factor”, is a framework for
authentication using hardware devices (U2F tokens) as “second factors”, i.e.
what you have as opposed to what you know, like a passphrase. This
additional control provides good protection (https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing/) in cases in which the
passphrase is stolen (e.g. by phishing or keylogging). While passphrase
compromise may not be obvious to the user, a physical device that cannot be
duplicated must be stolen to be used outside of the owner’s control.
Nonetheless, it is important to note at the outset that U2F cannot guarantee
security when the host system is compromised (e.g. a malware-infected operating
system under an adversary’s control).
The U2F specification defines protocols for multiple layers from USB to the
browser API, and the whole stack is intended to be used with web applications
(most commonly websites) in browsers. In most cases, tokens are USB dongles.
The protocol is very simple, allowing the devices to store very little state
inside (so the tokens may be reasonably cheap) while simultaneously
authenticating a virtually unlimited number of services (so each person needs
only one token, not one token per application). The user interface is usually
limited to a single LED and a button that is pressed to confirm each
transaction, so the devices themselves are also easy to use.
Currently, the most common form of two-step authentication consists of a numeric
code that the user manually types into a web application. These codes are
typically generated by an app on the user’s smartphone or sent via SMS. By now,
it is well-known that this form of two-step authentication is vulnerable to
phishing and man-in-the-middle attacks due to the fact that the application
requesting the two-step authentication code is typically not itself
authenticated by the user. (In other words, users can accidentally give their
codes to attackers because they do not always know who is really requesting the
code.) In the U2F model, by contrast, the browser ensures that the token
receives valid information about the web application requesting authentication,
so the token knows which application it is authenticating (for details, see
here (https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-overview-v1.2-ps-20170411.html#site-specific-public-private-key-pairs)). Nonetheless, some attacks are still possible (https://www.wired.com/story/chrome-yubikey-phishing-webusb/) even
with U2F (more on this below).
Our take on U2F
In a conventional setup, web browsers and the USB stack (to which the U2F token
is connected) are all running in the same monolithic OS. Since the U2F model
assumes that the browser is trustworthy, any browser in the OS is able to access
any key stored on the U2F token. The user has no way to know which keys have
been accessed by which browsers for which services. If any of the browsers are
compromised, it should be assumed that all of the token’s keys have been
compromised. (This problem can be mitigated, however, if the U2F device has a
special display to show the user what’s being authenticated.) Moreover, since
the USB stack is in the same monolithic OS, the system is vulnerable to attacks
like BadUSB (https://www.blackhat.com/us-14/briefings.html#badusb-on-accessories-that-turn-evil).
In Qubes OS, by contrast, it is possible to securely compartmentalise the
browser in one qube and the USB stack in another so that they are always kept
separate from each other. The Qubes U2F Proxy then allows the token connected to
the USB stack in one qube to communicate with the browser in a separate qube. We
operate under the assumption that the USB stack is untrusted from the point of
view of the browser and also that the browser is not to be trusted blindly by
the token. Therefore, the token is never in the same qube as the browser. Our
proxy forwards only the data necessary to actually perform the authentication,
leaving all unnecessary data out, so it won’t become a vector of attack. This is
depicted in the diagram below (click for full size).
separate from each other. The Qubes U2F Proxy then allows the token connected to
the USB stack in one qube to communicate with the browser in a separate qube. We
operate under the assumption that the USB stack is untrusted from the point of
view of the browser and also that the browser is not to be trusted blindly by
the token. Therefore, the token is never in the same qube as the browser. Our
proxy forwards only the data necessary to actually perform the authentication,
leaving all unnecessary data out, so it won’t become a vector of attack. This is
depicted in the diagram below (click for full size).
The Qubes U2F Proxy has two parts: the frontend and the backend. The frontend
runs in the same qube as the browser and presents a fake USB-like HID device
using uhid. The backend runs in sys-usb and behaves like a browser. This is
done using the u2flib_host reference library. All of our code was written in
Python. The standard qrexec (https://www.qubes-os.org/doc/qrexec3/) policy is responsible for directing calls to the
appropriate domains.
The vault qube with a dashed line in the bottom portion of the diagram depicts
future work in which we plan to implement the Qubes U2F Proxy with a software
token in an isolated qube rather than a physical hardware token. This is similar
to the manner in which Split GPG (https://www.qubes-os.org/doc/split-gpg/) allows us to emulate the smart card model
without physical smart cards.
One very important assumption of U2F is that the browser verifies every request
sent to the U2F token — in particular, that the web application sending an
authentication request matches the application that would be authenticated by
answering that request (in order to prevent, e.g., a phishing site from sending
an authentication request for your bank’s site). With the WebUSB feature in
Chrome, however, a malicious website can bypass (https://www.wired.com/story/chrome-yubikey-phishing-webusb/) this safeguard by
connecting directly to the token instead of using the browser’s U2F API.
The Qubes U2F Proxy also prevents this class of attacks by implementing an
additional verification layer. This verification layer allows you to enforce,
for example, that the web browser in your twitter qube can only access the U2F
key associated with https://twitter.com. This means that if anything in your
twitter qube were compromised — the browser or even the OS itself — it
would still not be able to access the U2F keys on your token for any other
websites or services, like your email and bank accounts. This is another
significant security advantage over monolithic systems. (For details and
instructions, see the Advanced usage (https://www.qubes-os.org/#advanced-usage-per-qube-key-access) section below.)
For even more protection, you can combine this with the Qubes firewall (https://www.qubes-os.org/doc/firewall/) to
ensure, for example, that the browser in your banking qube accesses only one
website (your bank’s website). By configuring the Qubes firewall to prevent your
banking qube from accessing any other websites, you reduce the risk of another
website compromising the browser in an attempt to bypass U2F authentication.
Installation
The Qubes U2F Proxy tool can be installed in Qubes 3.2 and 4.0. (However, the
Advanced usage (https://www.qubes-os.org/#advanced-usage-per-qube-key-access) features are only available in 4.0.) These instructions assume
that there is a sys-usb qube that holds the USB stack, which is the default
configuration in most Qubes OS installations.
In dom0:
$ sudo qubes-dom0-update qubes-u2f-dom0
$ qvm-service --enable work qubes-u2f-proxy
In Fedora TemplateVMs:
$ sudo dnf install qubes-u2f
In Debian TemplateVMs:
$ sudo apt install qubes-u2f
Repeat qvm-service --enable (or do this in VM settings -> Services in the Qube
Manager) for all qubes that should have the proxy enabled. As usual with
software updates, shut down the templates after installation, then restart
sys-usb and all qubes that use the proxy. After that, you may use your U2F
token (but see Browser support (https://www.qubes-os.org/#templatevm-and-browser-support) below).
Advanced usage: per-qube key access
If you are using Qubes 4.0, you can further compartmentalise your U2F keys by
restricting each qube’s access to specific keys. For example, you could make it
so that your twitter qube (and, therefore, all web browsers in your twitter
qube) can access only the key on your U2F token for https://twitter.com,
regardless of whether any of the web browsers in your twitter qube or the
runs in the same qube as the browser and presents a fake USB-like HID device
using uhid. The backend runs in sys-usb and behaves like a browser. This is
done using the u2flib_host reference library. All of our code was written in
Python. The standard qrexec (https://www.qubes-os.org/doc/qrexec3/) policy is responsible for directing calls to the
appropriate domains.
The vault qube with a dashed line in the bottom portion of the diagram depicts
future work in which we plan to implement the Qubes U2F Proxy with a software
token in an isolated qube rather than a physical hardware token. This is similar
to the manner in which Split GPG (https://www.qubes-os.org/doc/split-gpg/) allows us to emulate the smart card model
without physical smart cards.
One very important assumption of U2F is that the browser verifies every request
sent to the U2F token — in particular, that the web application sending an
authentication request matches the application that would be authenticated by
answering that request (in order to prevent, e.g., a phishing site from sending
an authentication request for your bank’s site). With the WebUSB feature in
Chrome, however, a malicious website can bypass (https://www.wired.com/story/chrome-yubikey-phishing-webusb/) this safeguard by
connecting directly to the token instead of using the browser’s U2F API.
The Qubes U2F Proxy also prevents this class of attacks by implementing an
additional verification layer. This verification layer allows you to enforce,
for example, that the web browser in your twitter qube can only access the U2F
key associated with https://twitter.com. This means that if anything in your
twitter qube were compromised — the browser or even the OS itself — it
would still not be able to access the U2F keys on your token for any other
websites or services, like your email and bank accounts. This is another
significant security advantage over monolithic systems. (For details and
instructions, see the Advanced usage (https://www.qubes-os.org/#advanced-usage-per-qube-key-access) section below.)
For even more protection, you can combine this with the Qubes firewall (https://www.qubes-os.org/doc/firewall/) to
ensure, for example, that the browser in your banking qube accesses only one
website (your bank’s website). By configuring the Qubes firewall to prevent your
banking qube from accessing any other websites, you reduce the risk of another
website compromising the browser in an attempt to bypass U2F authentication.
Installation
The Qubes U2F Proxy tool can be installed in Qubes 3.2 and 4.0. (However, the
Advanced usage (https://www.qubes-os.org/#advanced-usage-per-qube-key-access) features are only available in 4.0.) These instructions assume
that there is a sys-usb qube that holds the USB stack, which is the default
configuration in most Qubes OS installations.
In dom0:
$ sudo qubes-dom0-update qubes-u2f-dom0
$ qvm-service --enable work qubes-u2f-proxy
In Fedora TemplateVMs:
$ sudo dnf install qubes-u2f
In Debian TemplateVMs:
$ sudo apt install qubes-u2f
Repeat qvm-service --enable (or do this in VM settings -> Services in the Qube
Manager) for all qubes that should have the proxy enabled. As usual with
software updates, shut down the templates after installation, then restart
sys-usb and all qubes that use the proxy. After that, you may use your U2F
token (but see Browser support (https://www.qubes-os.org/#templatevm-and-browser-support) below).
Advanced usage: per-qube key access
If you are using Qubes 4.0, you can further compartmentalise your U2F keys by
restricting each qube’s access to specific keys. For example, you could make it
so that your twitter qube (and, therefore, all web browsers in your twitter
qube) can access only the key on your U2F token for https://twitter.com,
regardless of whether any of the web browsers in your twitter qube or the
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 : -->
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.
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 […]
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. ?? ????????? ? […]
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 […]
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 […]
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!
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).
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).
Forwarded from Deleted Account
Media is too big
VIEW IN TELEGRAM
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
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!
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 […]
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
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!
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!