XSA-235 does not affect the security of Qubes OS
https://www.qubes-os.org/news/2017/08/23/xsa-235/
The Xen Project has published Xen Security Advisory 235 (XSA-235).
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/#235
https://www.qubes-os.org/news/2017/08/23/xsa-235/
The Xen Project has published Xen Security Advisory 235 (XSA-235).
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/#235
My GSoC experience: Fuzzing the hypervisor
https://blog.xenproject.org/2017/08/25/my-gsoc-experience-fuzzing-the-hypervisor/
This blog post was written by Felix Schmoll, currently studying Mechanical Engineering at ETH Zurich. After obtaining a Bachelor in Computer Science from Jacobs University he spent the summer working on fuzzing the hypervisor as a Google Summer of Code student. His main interests in code are low-level endeavours and building scalable applications. Five months ago, […]
https://blog.xenproject.org/2017/08/25/my-gsoc-experience-fuzzing-the-hypervisor/
This blog post was written by Felix Schmoll, currently studying Mechanical Engineering at ETH Zurich. After obtaining a Bachelor in Computer Science from Jacobs University he spent the summer working on fuzzing the hypervisor as a Google Summer of Code student. His main interests in code are low-level endeavours and building scalable applications. Five months ago, […]
My GSoC Experience: Allow Setting up Shared Memory Regions between VMs from xl Config File
https://blog.xenproject.org/2017/08/29/my-gsoc-experience-allow-setting-up-shared-memory-regions-between-vms-from-xl-config-file/
This blog was written by Zhongze Liu. Zhongze Liu is a student studying information security in Huazhong University of Science and Technology in Wuhan, China. He recently took part in GSoC 2017 where he worked closely with the Xen Project community on “Allowing Sharing Memory Regions between VMs from xl Config.” His interests are low-level hacking and […]
https://blog.xenproject.org/2017/08/29/my-gsoc-experience-allow-setting-up-shared-memory-regions-between-vms-from-xl-config-file/
This blog was written by Zhongze Liu. Zhongze Liu is a student studying information security in Huazhong University of Science and Technology in Wuhan, China. He recently took part in GSoC 2017 where he worked closely with the Xen Project community on “Allowing Sharing Memory Regions between VMs from xl Config.” His interests are low-level hacking and […]
Xen Project 4.8.2 is available
https://blog.xenproject.org/2017/09/06/xen-project-4-8-2-is-available/
I am pleased to announce the release of Xen 4.8.2. Xen Project Maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of the 4.8 stable series update to the latest point release. The release is available from its git repository xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.8 (tag RELEASE-4.8.2) or from the XenProject download […]
https://blog.xenproject.org/2017/09/06/xen-project-4-8-2-is-available/
I am pleased to announce the release of Xen 4.8.2. Xen Project Maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of the 4.8 stable series update to the latest point release. The release is available from its git repository xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.8 (tag RELEASE-4.8.2) or from the XenProject download […]
RT @golemproject: We are going to livestream our Berlin event @blueyard, Thursday Sep 7! Feat. @QubesOS @streamrinc & @omise_go #compute #security #ethereum https://t.co/OcSzcBZqgN
Twitter
golem
We are going to livestream our Berlin event @blueyard, Thursday Sep 7! Feat. @QubesOS @streamrinc & @omise_go #compute #security #ethereum
RT @rootkovska: Yesterday I discussed the (long-term) vision of @QubesOS running on top of @golemproject decentralized compute cloud, announced cooperation.
RT @julianzawist: I am excited & think this will result in great advancements for both @QubesOS and @golemproject https://t.co/vqal5Hf5hw
Twitter
Joanna Rutkowska
Yesterday I discussed the (long-term) vision of @QubesOS running on top of @golemproject decentralized compute cloud, announced cooperation.
Forwarded from Pavel Durov
If you haven’t read it yet, here’s the full story about the US agencies’ attempts to infiltrate Telegram last year: https://thebaffler.com/salvos/the-crypto-keepers-levine
It tells how the FBI tried to influence me and bribe our engineer in May 2016 to make Telegram less secure. Luckily, since neither of us are US citizens, we could afford to refuse their offers and I was able to tell the public about these attempts. If we were American citizens, the FBI would have likely tried to silence us using a legal procedure called a "gag order" – when the US authorities can not only demand that you do something (like plant a backdoor into your app), but also prohibit you from telling the public about it (otherwise you can end up in jail).
That whole story made me ask myself this question: if our team experienced such pressure during just one week’s trip to America, what kind of pressure are US-based tech companies facing every day? How can a privacy oriented company permanently operate from America? We can hope that the open US legal system would defend them, but due to the secrecy of these “gag orders” we would never even know if things went wrong. And unfortunately, Edward Snowden’s revelations confirm some of the worst fears.
The article also provides facts that confirm something that I always feared could be true – that some of the famous and most vocal US-based influencers within the cryptography world are sponsored by the US government to push the agenda of its agencies. Some past cases are widely known (like NSA infiltrating RSA), but it looks like the level of collaboration between US agencies and these influential “privacy advocates” is much deeper.
All of this makes protecting privacy really hard, particularly considering the fact that Google and Apple – the two companies which we are dependent on for mobile operating systems – are based in the US. I don't see any easy recipe or solution to fix this. I wish one day huge companies like Apple and Google can become independent of any government that can distort the mission of their founders (maybe start their own countries?).
Until then, I’ll continue doing my part building Telegram and protecting our users, even if that will require speaking out under gag orders. I know this can probably get me into trouble some day, as it did in the past when I was living in Russia. But this is the only way I can imagine myself going forward, so I don't have and won’t have any regrets. It’s all worth it because of you guys – the millions of users who entrusted their private data to Telegram.
It tells how the FBI tried to influence me and bribe our engineer in May 2016 to make Telegram less secure. Luckily, since neither of us are US citizens, we could afford to refuse their offers and I was able to tell the public about these attempts. If we were American citizens, the FBI would have likely tried to silence us using a legal procedure called a "gag order" – when the US authorities can not only demand that you do something (like plant a backdoor into your app), but also prohibit you from telling the public about it (otherwise you can end up in jail).
That whole story made me ask myself this question: if our team experienced such pressure during just one week’s trip to America, what kind of pressure are US-based tech companies facing every day? How can a privacy oriented company permanently operate from America? We can hope that the open US legal system would defend them, but due to the secrecy of these “gag orders” we would never even know if things went wrong. And unfortunately, Edward Snowden’s revelations confirm some of the worst fears.
The article also provides facts that confirm something that I always feared could be true – that some of the famous and most vocal US-based influencers within the cryptography world are sponsored by the US government to push the agenda of its agencies. Some past cases are widely known (like NSA infiltrating RSA), but it looks like the level of collaboration between US agencies and these influential “privacy advocates” is much deeper.
All of this makes protecting privacy really hard, particularly considering the fact that Google and Apple – the two companies which we are dependent on for mobile operating systems – are based in the US. I don't see any easy recipe or solution to fix this. I wish one day huge companies like Apple and Google can become independent of any government that can distort the mission of their founders (maybe start their own countries?).
Until then, I’ll continue doing my part building Telegram and protecting our users, even if that will require speaking out under gag orders. I know this can probably get me into trouble some day, as it did in the past when I was living in Russia. But this is the only way I can imagine myself going forward, so I don't have and won’t have any regrets. It’s all worth it because of you guys – the millions of users who entrusted their private data to Telegram.
The Baffler
The Crypto- Keepers
If apps like Signal really posed a threat to the NSA’s surveillance power, why would the U.S. government continue to fund them?
RT @golemproject: Video report & @julianzawist's blogpost on Berlin https://t.co/w366VGaRdC #Ethereum #TrueCloud #Cooperation @omise_go @QubesOS @streamrinc
The Golem Project
After Berlin — the Spirit of Cooperation
We hope you enjoyed Golem’s meetup in Berlin as much as we did. Reflecting on it over the weekend, the team thought it was a great event…
QSB #33: Xen hypervisor (XSA-231 through XSA-234)
https://www.qubes-os.org/news/2017/09/12/qsb-33/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #33:
Xen hypervisor (XSA-231 through XSA-234).
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack (qubes-secpack).
View QSB #33 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-033-2017.txt
Learn about the qubes-secpack, including how to obtain, verify, and read it:
https://www.qubes-os.org/security/pack/
View all past QSBs:
https://www.qubes-os.org/security/bulletins/
View XSA-231 through XSA-234 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/
---===[ Qubes Security Bulletin #33 ]===---
September 12, 2017
Xen hypervisor (XSA-231 through XSA-234)
Summary
========
The Xen Security Team released several Xen Security Advisories today
(XSA-231 through XSA-234). The impact of these advisories ranges from
system crashes to privilege escalations. See our commentary below for
details.
Technical details
==================
Xen Security Advisory 231 [1]:
| The function `alloc_heap_pages` allows callers to specify the first
| NUMA node that should be used for allocations through the `memflags`
| parameter; the node is extracted using the `MEMF_get_node` macro.
|
| While the function checks to see if the special constant
| `NUMA_NO_NODE` is specified, it otherwise does not handle the case
| where `node >= MAX_NUMNODES`. This allows an out-of-bounds access
| to an internal array.
|
| An attacker using crafted hypercalls can execute arbitrary code within
| Xen.
Xen Security Advisory 232 [2]:
| The function `__gnttab_cache_flush` handles GNTTABOP_cache_flush grant
| table operations. It checks to see if the calling domain is the owner
| of the page that is to be operated on. If it is not, the owner's grant
| table is checked to see if a grant mapping to the calling domain
| exists for the page in question.
|
| However, the function does not check to see if the owning domain
| actually has a grant table or not. Some special domains, such as
| `DOMID_XEN`, `DOMID_IO` and `DOMID_COW` are created without grant
| tables. Hence, if __gnttab_cache_flush operates on a page owned by
| these special domains, it will attempt to dereference a null pointer
| in the domain struct.
|
| The guest can get Xen to dereference a NULL pointer.
|
| For ARM guests, and x86 HVM guests, and x86 PV guests on systems with
| SMAP enabled, this will cause a host crash (denial-of-service).
|
| For x86 PV guests on systems without SMAP enabled, an attacker can map
| a crafted grant structure at virtual address 0. This can be leveraged
| to increment an arbitrary virtual address, which can then probably be
| leveraged into a full privilege escalation.
Xen Security Advisory 234 [4]:
| When removing or replacing a grant mapping, the x86 PV specific path
| needs to make sure page table entries remain in sync with other
| accounting done. Although the identity of the page frame was
| validated correctly, neither the presence of the mapping nor page
| writability were taken into account.
|
| A malicious or buggy x86 PV guest could escalate its privileges or
| crash the hypervisor.
The Xen Security Team also released Xen Security Advisory 233 [3], with
only DoS impact:
| When shutting down a VM with a stubdomain, a race in cxenstored may
| cause a double-free.
|
| The xenstored daemon may crash, resulting in a DoS of any parts of the
| system relying on it (including domain creation / destruction,
| ballooning, device changes, etc).
Commentary from the Qubes Security Team
========================================
This batch of Xen security advisories reassures us in our decision to
abandon default para-virtualization (PV) in Qubes 4.0. Indeed, only
https://www.qubes-os.org/news/2017/09/12/qsb-33/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #33:
Xen hypervisor (XSA-231 through XSA-234).
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack (qubes-secpack).
View QSB #33 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-033-2017.txt
Learn about the qubes-secpack, including how to obtain, verify, and read it:
https://www.qubes-os.org/security/pack/
View all past QSBs:
https://www.qubes-os.org/security/bulletins/
View XSA-231 through XSA-234 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/
---===[ Qubes Security Bulletin #33 ]===---
September 12, 2017
Xen hypervisor (XSA-231 through XSA-234)
Summary
========
The Xen Security Team released several Xen Security Advisories today
(XSA-231 through XSA-234). The impact of these advisories ranges from
system crashes to privilege escalations. See our commentary below for
details.
Technical details
==================
Xen Security Advisory 231 [1]:
| The function `alloc_heap_pages` allows callers to specify the first
| NUMA node that should be used for allocations through the `memflags`
| parameter; the node is extracted using the `MEMF_get_node` macro.
|
| While the function checks to see if the special constant
| `NUMA_NO_NODE` is specified, it otherwise does not handle the case
| where `node >= MAX_NUMNODES`. This allows an out-of-bounds access
| to an internal array.
|
| An attacker using crafted hypercalls can execute arbitrary code within
| Xen.
Xen Security Advisory 232 [2]:
| The function `__gnttab_cache_flush` handles GNTTABOP_cache_flush grant
| table operations. It checks to see if the calling domain is the owner
| of the page that is to be operated on. If it is not, the owner's grant
| table is checked to see if a grant mapping to the calling domain
| exists for the page in question.
|
| However, the function does not check to see if the owning domain
| actually has a grant table or not. Some special domains, such as
| `DOMID_XEN`, `DOMID_IO` and `DOMID_COW` are created without grant
| tables. Hence, if __gnttab_cache_flush operates on a page owned by
| these special domains, it will attempt to dereference a null pointer
| in the domain struct.
|
| The guest can get Xen to dereference a NULL pointer.
|
| For ARM guests, and x86 HVM guests, and x86 PV guests on systems with
| SMAP enabled, this will cause a host crash (denial-of-service).
|
| For x86 PV guests on systems without SMAP enabled, an attacker can map
| a crafted grant structure at virtual address 0. This can be leveraged
| to increment an arbitrary virtual address, which can then probably be
| leveraged into a full privilege escalation.
Xen Security Advisory 234 [4]:
| When removing or replacing a grant mapping, the x86 PV specific path
| needs to make sure page table entries remain in sync with other
| accounting done. Although the identity of the page frame was
| validated correctly, neither the presence of the mapping nor page
| writability were taken into account.
|
| A malicious or buggy x86 PV guest could escalate its privileges or
| crash the hypervisor.
The Xen Security Team also released Xen Security Advisory 233 [3], with
only DoS impact:
| When shutting down a VM with a stubdomain, a race in cxenstored may
| cause a double-free.
|
| The xenstored daemon may crash, resulting in a DoS of any parts of the
| system relying on it (including domain creation / destruction,
| ballooning, device changes, etc).
Commentary from the Qubes Security Team
========================================
This batch of Xen security advisories reassures us in our decision to
abandon default para-virtualization (PV) in Qubes 4.0. Indeed, only
one of the potential privilege-escalation bugs discussed in this
advisory affects non-PV virtualization: XSA-231. This bug is a prime
example of the common problems associated with expanding the codebase
in order to implement "exotic" functionality (in this case, NUMA
support). While the Xen Project has made some progress recently in
allowing extra features to be disabled at compile time, the code for
NUMA support could not easily be deactivated, which is the reason for
the inclusion of this bug in today's advisory.
While the departure from para-virtualization (PV) in Qubes 4.0 will
obviate many such vulnerabilities in the future, please note that
Qubes 3.2 (the current, stable version of Qubes) still uses PV mode
for most of the VMs. Therefore, all the bugs in this bulletin affect
Qubes 3.2, and users should patch immediately.
Compromise Recovery
====================
Starting with Qubes 3.2, we offer Paranoid Backup Restore Mode, which
was designed specifically to aid in the recovery of a (potentially)
compromised Qubes OS system. Thus, if you believe your system might have
been compromised (perhaps because of the bugs discussed in this
bulletin), then you should read and follow the procedure described here:
https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-30
For Qubes 4.0:
- Xen packages, version 4.8.2-2
The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command, as follows:
For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update
For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
A system restart will be required afterwards.
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
Credits
========
See the original Xen Security Advisories.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-231.html
[2] https://xenbits.xen.org/xsa/advisory-232.html
[3] https://xenbits.xen.org/xsa/advisory-233.html
[4] https://xenbits.xen.org/xsa/advisory-234.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
advisory affects non-PV virtualization: XSA-231. This bug is a prime
example of the common problems associated with expanding the codebase
in order to implement "exotic" functionality (in this case, NUMA
support). While the Xen Project has made some progress recently in
allowing extra features to be disabled at compile time, the code for
NUMA support could not easily be deactivated, which is the reason for
the inclusion of this bug in today's advisory.
While the departure from para-virtualization (PV) in Qubes 4.0 will
obviate many such vulnerabilities in the future, please note that
Qubes 3.2 (the current, stable version of Qubes) still uses PV mode
for most of the VMs. Therefore, all the bugs in this bulletin affect
Qubes 3.2, and users should patch immediately.
Compromise Recovery
====================
Starting with Qubes 3.2, we offer Paranoid Backup Restore Mode, which
was designed specifically to aid in the recovery of a (potentially)
compromised Qubes OS system. Thus, if you believe your system might have
been compromised (perhaps because of the bugs discussed in this
bulletin), then you should read and follow the procedure described here:
https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-30
For Qubes 4.0:
- Xen packages, version 4.8.2-2
The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command, as follows:
For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update
For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
A system restart will be required afterwards.
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
Credits
========
See the original Xen Security Advisories.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-231.html
[2] https://xenbits.xen.org/xsa/advisory-232.html
[3] https://xenbits.xen.org/xsa/advisory-233.html
[4] https://xenbits.xen.org/xsa/advisory-234.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
Joanna Rutkowska: Reasonably Secure Computing in the Decentralized World
https://www.qubes-os.org/news/2017/09/13/joanna-rutkowska-secure-computing-decentralized-world/
Joanna Rutkowska (https://www.qubes-os.org/team/#joanna-rutkowska) recently gave a presentation noscriptd
“Reasonably Secure Computing in the Decentralized World (An Operating System
Architect’s Perspective)” at a public event hosted by
The Golem Project (https://golem.network/) in Berlin, Germany
called “Golem and Friends: Data, Security, Scaling and More….”
The slides from her presentation are available
here (https://www.qubes-os.org/attachment/wiki/slides/Secure_Computing_in_Decentralized_World.pdf).
The event was streamed live, and the video is available
here (https://www.youtube.com/watch?v=B1QCm09BvP4&feature=youtu.be&t=31m52s).
https://www.qubes-os.org/news/2017/09/13/joanna-rutkowska-secure-computing-decentralized-world/
Joanna Rutkowska (https://www.qubes-os.org/team/#joanna-rutkowska) recently gave a presentation noscriptd
“Reasonably Secure Computing in the Decentralized World (An Operating System
Architect’s Perspective)” at a public event hosted by
The Golem Project (https://golem.network/) in Berlin, Germany
called “Golem and Friends: Data, Security, Scaling and More….”
The slides from her presentation are available
here (https://www.qubes-os.org/attachment/wiki/slides/Secure_Computing_in_Decentralized_World.pdf).
The event was streamed live, and the video is available
here (https://www.youtube.com/watch?v=B1QCm09BvP4&feature=youtu.be&t=31m52s).
Thank You for Supporting Qubes!
https://www.qubes-os.org/news/2017/09/15/thank-you-for-supporting-qubes/
Dear Qubes Community,
When we reflect on how the Qubes userbase has grown (https://www.qubes-os.org/statistics/) over
the past few years, we are humbled by the number of people who have
chosen to join us in entrusting the security of their digital lives to
Qubes. We recognize the immense responsibility this places on us. This
sense of duty is what drives our work to make Qubes as secure as it can
be.
We are further humbled by the many generous donations that have been
made this year. Qubes is protecting real people around the world in ever
greater numbers, and many of you have shown your appreciation by giving
back to the project. We are truly grateful for your support. Thank you.
Top Donors of 2017
We’d like to take this opportunity to thank the top donors of 2017 (so
far!):
50,000 EUR from Mullvad!
10 BTC from an anonymous donor!
10,000 USD from zby, angel investor!
1,000 USD recurring annual donation from Eric Grosse!
Thank you to these donors and to everyone who has donated to the Qubes
Decentralized Bitcoin Fund (https://www.qubes-os.org/news/2016/07/13/qubes-distributed-fund/) and the Qubes Open Collective (https://opencollective.com/qubes-os)!
Your donations continue to fund work on Qubes OS. Thanks to your
support, we’ve just released Qubes 4.0-rc1 (https://www.qubes-os.org/news/2017/07/31/qubes-40-rc1/), and we’re getting
ever closer to a stable release!
Our Work Continues
Today, Qubes safeguards tens of thousands of users around the globe in
their work and personal lives, including every member of the Qubes Team.
But the path here has been a long and difficult one, in terms of both
the great dedication required of the team and the monetary costs that
Invisible Things Lab has borne, and continues to bear, so that the
project could continue throughout the years.
Without a doubt, it’s all been worth it. Qubes is our passion. It’s part
of our lives. We’re gratified and exhilarated to see Qubes bringing real
value to people around the world, and we’re more determined than ever to
make Qubes the best free and open-source secure operating system it can
be – for everyone. We know that many of you feel the same way we do.
If Qubes is important to you, please consider joining us in supporting
its ongoing development (https://www.qubes-os.org/donate/). Everyone’s support is valuable to
us, no matter how large or how small. Together, we can ensure that Qubes
is around to protect us all for a long time to come.
Sincerely,
The Qubes OS Team
https://www.qubes-os.org/news/2017/09/15/thank-you-for-supporting-qubes/
Dear Qubes Community,
When we reflect on how the Qubes userbase has grown (https://www.qubes-os.org/statistics/) over
the past few years, we are humbled by the number of people who have
chosen to join us in entrusting the security of their digital lives to
Qubes. We recognize the immense responsibility this places on us. This
sense of duty is what drives our work to make Qubes as secure as it can
be.
We are further humbled by the many generous donations that have been
made this year. Qubes is protecting real people around the world in ever
greater numbers, and many of you have shown your appreciation by giving
back to the project. We are truly grateful for your support. Thank you.
Top Donors of 2017
We’d like to take this opportunity to thank the top donors of 2017 (so
far!):
50,000 EUR from Mullvad!
10 BTC from an anonymous donor!
10,000 USD from zby, angel investor!
1,000 USD recurring annual donation from Eric Grosse!
Thank you to these donors and to everyone who has donated to the Qubes
Decentralized Bitcoin Fund (https://www.qubes-os.org/news/2016/07/13/qubes-distributed-fund/) and the Qubes Open Collective (https://opencollective.com/qubes-os)!
Your donations continue to fund work on Qubes OS. Thanks to your
support, we’ve just released Qubes 4.0-rc1 (https://www.qubes-os.org/news/2017/07/31/qubes-40-rc1/), and we’re getting
ever closer to a stable release!
Our Work Continues
Today, Qubes safeguards tens of thousands of users around the globe in
their work and personal lives, including every member of the Qubes Team.
But the path here has been a long and difficult one, in terms of both
the great dedication required of the team and the monetary costs that
Invisible Things Lab has borne, and continues to bear, so that the
project could continue throughout the years.
Without a doubt, it’s all been worth it. Qubes is our passion. It’s part
of our lives. We’re gratified and exhilarated to see Qubes bringing real
value to people around the world, and we’re more determined than ever to
make Qubes the best free and open-source secure operating system it can
be – for everyone. We know that many of you feel the same way we do.
If Qubes is important to you, please consider joining us in supporting
its ongoing development (https://www.qubes-os.org/donate/). Everyone’s support is valuable to
us, no matter how large or how small. Together, we can ensure that Qubes
is around to protect us all for a long time to come.
Sincerely,
The Qubes OS Team
RT @andrewdavidwong: On behalf of our entire team:
Thank you for supporting Qubes!
https://t.co/tmtjvmfOJr
Thank you for supporting Qubes!
https://t.co/tmtjvmfOJr
Qubes OS
Qubes OS is a security-oriented, open-source operating system for personal computers. It uses virtualization to implement security by compartmentalization and supports both Linux and Windows virtual environments.
RT @mullvadnet: We hope our donation to @QubesOS will inspire others to support this vital #itsec project. https://t.co/SG9PgTAFTg #security #opensource
mullvad.net
Mullvad
Mullvad is a VPN service that helps keep your online activity, identity and location private. Only €5/month. We accept Bitcoin, cash, bank wire, credit card (PayPal), and Swish
XSA-245 does not affect the security of Qubes OS
https://www.qubes-os.org/news/2017/09/28/xsa-245/
The Xen Project has published Xen Security Advisory 245 (XSA-245).
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/#245
https://www.qubes-os.org/news/2017/09/28/xsa-245/
The Xen Project has published Xen Security Advisory 245 (XSA-245).
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/#245
RT @kennwhite: Periodic shout out to @rootkovska and the @QubesOS team for *years* of hard work to improve desktop security. Qubes is the real deal.