On 07/01/2016 04:03 PM, Duncan Guthrie wrote: > > Thanks for your reply! However, I think I need to clarify some things > here. > Freed-ora is a repository produced by the Linux-libre project which > provides a kernel without the proprietary firmware programs, and a > package which removes and prevents installation of non-free programs > (mostly firmware packages for various devices, such as bluetooth > dongles). It would not require any modification to Fedora in dom0 > other than enabling and installing the freed-ora packages. I do not > know if Qubes makes any modification to the kernel, or it just uses > stock Fedora kernel. > Regarding graphics, I am not talking about the Nvidia binary drivers - > Nouveau works perfectly for most people, and can be used without > proprietary firmware (although recent Nvidia cards require signed > firmware from Nvidia, but the driver is open source). (The Nvidia > binary drivers, if installed in dom0 are running in kernel space, > which is utterly stupid. I can't see a way that people would be able > to put them in a special GUI domain). It is their computer and they > can install what they want. > > What I really want is for Qubes not to include the proprietary > components by default. This is as simple as the installer saying > something like: > "The installer detected your computer requires proprietary firmware. > Your computer may work fine without the firmware. As Qubes does not > have access to the source code or is unable to modify these firmware > programs due to license restrictions, we can make no guarantees > regarding security, although we have taken steps to mitigate the > problem through Qubes' design. Would you like to enable the firmware? > [recommended: no]" > > Keep in mind this is by default. It is not as if we are saying these > people can't use Qubes without the firmware, and indeed we are giving > them an easy way to enable it at installation, and they can install it > later through the package manager. > I stand my ground that this would not increase security against targeted attacks. I concede that it would be a nice goal for the FOSS movement, but nothing more. Let me explain.
In normal linux distro, opaque binary blobs are disliked mainly because they may contain unintended security holes that cannot be verified nor easily patched, and become unmaintainable shuld the providing entity disappear out of business. Then there is the FOSS promotion stuff and so. Last and least, there is the intentional malware inclusion possibility; which is rarely practical, because opaque binary blob makers do have economical incentives in keeping it simple, working and in defending their brand name from such allegations. In qubes, the driving philosophy is taking those opaque binary blobs as necessary evil, and isolating them as much as possible in a way to contain their danger. The NetVM is a brilliant example, as is the GuiVM (which is not nearly as impossible as you make it sound). So yes, there may be opaque binary blobs, and it may be a better world without, but in Qubes they cannot do much damage *by design*. They are disliked in dom0, and the general direction is to get rid of them from dom0 as much as possible: the only elephant remaining in the room is GPU drivers, and GuiVM will work around that point. As for what can be hidden by *intentional* means in open source software, I invite you to read and understand the spirit of the Underhanded C Contest: http://underhanded-c.org/ . My take on FOSS is that having open source software is absolutely nice when it comes to fixing bugs faster in production code, and that it is a guarantee on the writer going out of business, but no, having FOSS is not by itself a guarantee against targeted attacks. Or are you really, seriously going to audit a linux distribution for underhanded intended effects? Did you remember that someone already tried to do that to the linux kernel (http://lwn.net/Articles/57135/) ? So my take on the strength of Qubes is the philosophy of 1) living with necessary evil, and containing the damage or eliminating it by design and architecture and 2) preferring less code instead of more, even if supposedly more secure, because all code contains bugs, and some bugs may be security holes. The vast majority of the bugs may be unintended, but FOSS alone is not a guarantee of no intended bug being present. TL;DR: I understand your point, but I don't agree with that, and I will be completely ok with opaque binary blobs once we'll have a GuiVM. -- Alex -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/11692511-74b4-24cc-b3d4-bbf83320d3c0%40gmx.com. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
