A new ISO with the just released Qubes
Beta 3 is now available for download here.
Beta 3 fixes lots of annoying problems
discovered in Beta 2 and earlier releases, and also implements a
bunch of useful feature:
This includes the qvm-block tool and infrastructure for easy attachment of block devices to any AppVM,
no matter which system VM is handling the actual USB controller. So,
this allows to have untrusted USB domain(s), almost seamlessly
integrated in the desktop system. One can consider to use it in order
to prevent various USB attacks. The
next release (the 1.0) will bring this feature to the Qubes GUI
manager as well, making it easy to use for non-command-line users
too.
Also, we have now introduced fully
automatic Qubes build system, that allows to build all the Qubes
packages, and also create the installation ISO, with just one
command. More information on this system and on how to use it can be found in
the wiki.
We have also updated to Fedora 15-based
template as a default. Unfortunately F16-based template would require
too much work to get all the Gnome 3 stuff working correctly. (The challenge here, is that we don't run a normal Windows and Desktop manager in every domain, in order to make the VMs light weight, and so we need to sometimes work around various problems this causes...).
Finally, we have added two new
Qubes-specific applications:
- A plugin for Thunderbird (it is automatically installed in the template), that allows for one click opening of attachments in Disposable VMs, as well as one-click saving of the attachment to select VM.
- And something we call “split GPG”, that I will describe in a separate article later.
This is likely the last release before
the “final 1.0”, that is scheduled to follow soon
(TM). The only major work for 1.0 is GUI manager improvements to
expose most of the Qubes functionality via clickable GUI, and command
line tools cleanup and documentation. Plus testing and bugfixing :)
And
then, the next thing we will be working on will be support for HVM
domains, e.g. Windows. This work is starting actually just about now, but code will be released only after Qubes 1.0.
13 comments:
Hi !
I was wondering whether 1.0 will get fc16 template ?
Keep up the good work !
Great! Congratulations to the Qubes team!
A lot of progress indeed.And you are already starting to work on a windows VM!!! wow. You are moving very fast! Thanks!! Since release beta 1 this is my main system
Francesco
@cyplo: no, we're not planning to add support for fc16 now. As said above, 1.0 is mainly final polishing on what's currently available, with maybe some minor new features only.
You guys are awesome! Keep up all the good work.
Joanna, why not release a torrent version? The download keeps being interrupted. It would help with bandwidth too.
Regarding torrent download -- can people try the following link:
http://s3-eu-west-1.amazonaws.com/qubes-os/iso/Qubes-R1-Beta3-x86_64-DVD.iso?torrent
This apparently should work, according to Amazon website...
Torrent link will download to iso_Qubes-R1-Beta3-x86_64-DVD.iso
Renaming it to Qubes-R1-Beta3-x86_64-DVD.iso and running gpg -v on asc file results in a good signature.
gpg: armor header:
gpg: assuming signed data in `Qubes-R1-Beta3-x86_64-DVD.iso'
gpg: Signature made Thu Feb 2 23:37:56 2012 UTC using RSA key ID AC1BF9B3
gpg: using PGP trust model
gpg: Good signature from "Qubes OS Release 1 Signing Key"
gpg: binary signature, digest algorithm SHA1
SHA256 = 81105ab8b061868737ddfb93a67947f5ce78950946f6d084d01dd3d37ccaab63
MD5 = 2e4a8fc8ae924c67e09ce3c12544a5a1
Don't hurry. It is better if it takes a while longer, than to forget something important. Maybe there are some things that could be more polished before release?
I would also like to ask some questions. This page http://wiki.qubes-os.org/trac/wiki/SoftwareUpdateDom0 mentions some software components, that may be important for security of whole Qubes system, and then it says
"Of course we believe this software is reasonably secure, and we hope it will not need patching."
Im confused after reading this...do you assume there will be no critical vulnerabilities in that software components, and will not monitor information sources about security vulnerabilites/disclosures, so there will be no urgent security updates in Qubes? Only fixes for bugs reported to Qubes project?
What about Xen kernel? It is not mentioned on that page, but even if it is unlikely, a security vulnerability in it could also be used to compromise of a whole Qubes OS. Will there also be security updates in Qubes for Xen kernel, and for all other software components not mentioned that are important for security of a whole system?
Maybe it will be good if it that page will be made more clear. :/
@dont_hurry_anon: I don't quite follow the logic of your questions... Perhaps try re-reading the mentioned page? What is "Xen kernel"? Try be more precise.
Xen kernel=Xen hypervisor???? If I understand correctly, Xen hypervisor or as I called it "Xen kernel" is the program that isolates virtual machines and manages cpu and memory sharing and communication between Virtual machines (domains). I don't know much technical details, but if that hypervisor runs in kernel space, is it wrong to call it kernel?
I will try to clarify my questions:
1.Is there assumption that there will be no need for security updates, in all those "reasonably secure software" and therefore there is no preparation for such possibility because that software components are extremely secure and will not need security updates?
2.Is Xen hypervisor one of those "reasonably secure software"?
I tried to explain my questions as clearly as possible... I hope I explained it well enough :)
@Confused_anonymous:
But we *do* support updates of all the software, including the one running in Dom0 (which also includes the hypervisor, which leaves on Dom0 fs):
https://wiki.qubes-os.org/trac/wiki/SoftwareUpdateDom0
BTW, qubes-devel is a proper place for such discussions. Here is a place for commenting on the direct content of the blog articles.
Is Qubos a yet another linux distro? Whatever is the case, people should not invent the wheel again, and just use already developed OS (which are being developed during 15-20 years) and had been revised my others. It's like about crypto algorythms, you should not invent an algorithm by your own, just use the standards which are verified by lots of people who have tried to break it and failed.
I think someone's have too much spare time ;)
Post a Comment