I remember mentions of Fedora providing a broader hardware support than say, Debian at any point in time.
I didn’t search specifically for that, so I’m sure it will show up in one of the main conversations on the topic if you do… IIRC it might have been in the corresponding “why not using ” issue in GitHub.
I remember mentions of Fedora providing a broader hardware support than say, Debian at any point in time.
I remember that too but it is rather related to functionality, not to trustworthiness in the context of security, as a project goal.
I didn’t search specifically for that, so I’m sure it will show up in one of the main conversations on the topic if you do… IIRC it might have been in the corresponding “why not using ” issue in GitHub.
I don’t know which issue you mean (I found only this one), but from what I read here, I understand that it actually is what one person liked at certain point in time and that’s it. No more info. Compare that to the excellent work of Whonix devs. It is not particularly focused on trust but it provides enough detail about criteria in relation to project goal, current status and future considerations.
Right. I arrived at the same conclusion. While I do respect and appreciate the work put into creating QubesOS, I don’t like the OS choice for Dom0.
Speaking strictly for me in particular, I can achieve the same level of privacy and security by running Void Linux + kvm + Whonix for kvm, on the same hardware!
Unfortunately that wouldn’t scale for the security level some users need. That would be hard for you to create something such as sys-net or sys-usb.
Qubes OS has flaws, but it offers the best privilege separation an OS can offer, and it does for free.
Up to the users to decide if they really need this, or if running VMs from Linux would be enough for them. I guess this setup is underrated / overlooked by many Qubes OS users.
Correct! That’s why I wrote “Speaking strictly for me in particular” 
There is no reasonable security if your hardware doesn’t work.
One reason, I guess, to choose Fedora might be that the package metadata are signed:
Another point is that Fedora supported the efforts toward reproducible builds (but not anymore).
Another relevant discussion:
How much does Qubes really trust Fedora anyway? By default, dom0 doesn’t have network access. I guess, as dom0, Fedora could attach itself to a network qube, but then the questions become:
I think the piece of software that QubesOS must trust above all others is Xen. And there, the only answer I can think of is that, to the best of my knowledge, none of Xen’s competitors are libre.
Proxmox is build on open source software.
There is no reasonable security if your hardware doesn’t work.
This makes no sense, forgive me - neither as an argument in the current context, nor in general. Because:
InfoSec simply has no meaning without the technology which handles it - neither “reasonable”, nor any other. It is like discussing the most suitable swimming styles in the middle of a desert.
A working hardware per se is not the ultimate factor for security (“reasonable” or any other). Example: Some hardware can be used only with Windows. Other hardware can be used only with VMS. Both cases have working hardware but the level of security (and the purpose) are very different.
So, the overuse of the magic word “reasonable” as an universal argument is not always reasonable.
Another relevant discussion:
Same link from above 
- How would someone get a piece of malware into dom0?
Through updates.
- Once the malware is there, how would someone trigger it?
Through a system process or user initiated event.
This essentially means that you expect active malicious actions from Fedora. This can’t be excluded of course, but looks very unlikely to me. Do you have any examples like this in the FLOSS world?
It is in the particular example of Qubes OS and average journalist/activist. If they can’t run Qubes at all, they will run another, much less secure OS. If you personally require a much higher security level, you should be able to ask a professional to tweak Qubes for you (or do it yourself). Decreasing the security for average people while increasing it for the heavy threat models is AFAIK not the goal of Qubes OS. Hence “reasonably secure OS”.
A malicious package doesn’t need dom0 to end the game. Updates could affect a template VM just as easily as dom0 (maybe even more easily, considering the number of packages that get installed). If a template VM installs an infected package, then all app VMs based on that template will inherit the infection. At that point, an attacker might not even care about dom0.
What an attacker “might not” do is of little consequence in InfoSec. Every attack “path”, be it a narrow pathway or a 100m wide boulevard, has to be addressed.
This essentially means that you expect active malicious actions from Fedora.
No, it means I answered the question and nothing more.
I don’t know what your understanding of “active malicious actions” is. Things can be quite invisible.
This can’t be excluded of course, but looks very unlikely to me.
It is neither likely or unlikely to me. To evaluate that, I would start with considering the environment where it may happen: a centralized controlled one (company with publicly declared state partnership) vs a decentralized community of volunteers. Each one has its pros and cons.
Remember also that Fedora is somewhat latest-greatest style distro. Usually stable well-tested distros are preferred where security is important which adds to the mystery of the current choice.
Do you have any examples like this in the FLOSS world?
It is in the particular example of Qubes OS and average journalist/activist.
There was no example in what I answered.
I think the point was that packages from official distro repositories are trusted in dom0 as they are in templates. While that may not be ideal, there is really no alternative; let’s say the Qubes team had 1000 times more resources available than is the case and so could produce its own linux distribution or even some other OS for dom0 as well as the templates; this would still only shift the problem, as now the Qubes team would be 1000 times larger, so instead of trusting the teams of QubesOS, Fedora, Debian and a whole bunch of other people who contribute to the Linux kernel and the various packages etc., you now have to trust the thousands of new Qubes team members. How do you know that they are more trustworthy than the other mentioned groups?
It would be great if there is eventually some kind of audited, proven AI white hat / source code auditor, as that may allow some kind of more or less objective measure of how problematic a complex piece of software is. But until then…you’ll have to trust many people.
Given that the QubesOS devs intentionally choose distro versions that have ceased receiving updates, “latest and greatest” with a short lifecycle is what you want. Simply think about all the hardware issues etc. if an old Debian distro version were used, given their much longer support cycles.
Your links are also a bit nebulous…the first actually explicitly mentions PyPi and NPM in the “what is a malicous package” section, as those are indeed the most problematic in my understanding, but neither of those are the kind of repos that are relevant to this discussion IMO; the second link also mentions NPM as being the most problematic, while the claim of “1 in 5 bugs were planted maliciously” is not substantiated and their link to the report that is supposed to prove it is dead (links to a different report)…intention is not easy to prove so I’m very skeptical of that claim. The last link produces only 3 examples, 1 from 2003 and 1 not maliciously planted (at least no one has proven that it was maliciously planted); the remaining example is indeed interesting, but was detected before it could spread far and wide.
In conclusion these examples have not shaken my trust in the approach used by QubesOS, but as I said above, it would of course be nice to have some kind of objective and comprehensive measure of code quality that can be trusted.
I think the point was that packages from official distro repositories are trusted in dom0 as they are in templates.
They are not. Read the paragraph quoted in the OP.
Given that the QubesOS devs intentionally choose distro versions that have ceased receiving updates, “latest and greatest” with a short lifecycle is what you want.
I don’t know what you are talking about. The info others shared above clarified there were no devs, no intention was explained and nobody was asked “what do you want?”
Simply think about all the hardware issues etc. if an old Debian distro version were used, given their much longer support cycles.
The fact is: in Qubes OS I cannot use a well-known FOSS-friendly hardware, which I have been able to use without issues on 15+ years old computers running other distros (including 32-bit). If hardware utilization is really a priority, this is quite confusing, especially considering all the talk about how careful one should be with USB.
Your links are […]
a short way to avoid off-topic, so you are right:
neither of those are the kind of repos that are relevant to this discussion IMO;
In conclusion these examples have not shaken my trust in the approach used by QubesOS
Since I still haven’t seen the approach explained anywhere, I really don’t know what you mean.
What I get from that paragraph is that there is implied trust that Fedora packages (and Debian as regards templates, for that matter) are not crafted by the Fedora team to infect the computer when being installed. Using them is another matter, of course, and Marek has said that once dom0 is truly only an admin VM (so stable sys-gui, sys-audio and some other thing IIRC) then a minimal dom0 will be considered.
It would also be nice if you were a little more charitable or at least follow the thread…the post I quoted was a reply to this post, which talks about AppVMs getting infected as a result of a package update of their template. So we are talking exactly about the kind of case where Fedora / Debian packages are trusted (their installation, not their use). I was trying to explain the implication of what that user was saying.
Consent doesn’t have to be explicit and articulated, though it usually is a good thing if it is. Clearly the devs didn’t have a problem with Fedora-based dom0. There is also no general principle saying that non-members have a right to vote on this or that aspect of the project…even members don’t necessarily.
Just because a distro is more up to date regarding hardware compatibility doesn’t mean it now supports all hardware. And it’s not just about hardware, either…lots of packages are more up to date in Fedora 37 than in e.g. Debian Stretch.
I’m not sure what the point of continuing this discussion is.
The topic started with a question about why Fedora was chosen. It seems like that question has been answered: it was a somewhat arbitrary decision, but most people are fine with it because it’s a large/well-known project meaning that there are a lot of eyes on it and a lot of people depending on it being secure.
There are valid reasons to want to use a different distribution just as there are valid reasons to want to use Fedora. The QubesOS project is not responsible for catering to any particular person’s preferences, and where a decision is ambiguous the maintainers need to be able to make judgement calls based on the relevant tradeoffs and available resources. If they cannot do this then there is no QubesOS at all.
Personally, I would also like a different base distribution. The project graciously provides all of its source code under free licenses meaning that anyone is free to do the work required to support a different distribution. Yes this is difficult work which takes a lot of time and expertise. That is not a burden that the QubesOS is imposing on anyone, it is simply the nature of the situation we are in. There is no justification for demanding that this burden is taken on by the QubesOS. It might make sense for this to happen at some point under some specific circumstances, but a general “I think Fedora is sketchy” is not an argument, it’s fearmongering.
What distribution with pre-2012 Xen dom0 kernel support would you pick?
Your options would probably be limited to RHEL/CentOS, SUSE, Debian, or Fedora.
Picking one of the enterprise distribution for a desktop system doesn’t make much sense.
I’m a Debian user, I don’t have a single Fedora VM except for dom0, I would probably still pick 2012 Fedora over 2012 Debian do to hardware support and the release cycle.
Sorry, maybe I’ve missed something obvious/well-known. I’m pretty new to Xen. Why is 2012 important? Both the Xen and Fedora versions that QubesOS runs are much more recent than that.