@Quser59 you misunderstood the conversation. It was about some people advocating the project to switch to a different distribution for dom0.
I do not think there is any way for you to have any other distribution in dom0 than Fedora at this time, short of you single-handedly doing all the porting and development work needed to get there.
Also there is little value in doing this beyond " I don’t like fedra" … which is not a reason at all.
You are free to run all your qubes on Debian, Ubuntu, Arch … whatever you’d like and is supported. I use all debian-minimal and love it. Don’t like Fedora either, but it’s in dom0 and the reasons I don’t like it don’t apply there. Also I have basically no interaction with it … so what’s the problem?
Sorry if I was unclear, I just think (as I belive @ppc does, (correct me if I’m wrong there)), that fedora in dom0 is clunky: IF:(it is little work to port to alpine).
Hence my earlier question(s) about what is needed to be done. I know @adw referred me to some build-dependencies for the kernel, but I’m talking about comprehensively.
I’m guessing there has been some non-public conversation about this which I am not savvy to? What I’m asking is, if there’s anything I can do which is a good use of time to help migrate from fedora in dom0, please let me know.?
Perhaps I have misinterpreted this, but do you have a sys-gui enabled, or can you run dom0 headless(without gui)?
Reduce vulns in dom0; (yes, I know what I am implying there).
I recommend you check your assumptions and make a clear case.
No, but perhaps we should create a new thread?
You are of course free to do so, but may I recommend reading all the discussion that already happened about this topic here in the forum and on github. Personally I have no appetite in going through all that once more.
A few hints:
the choice of distribution in dom0 matters little today and will matter even less in the future
dom0 is always offline / no remote attack surfaces
as more and more hardware interfacing is moved into dedicated system qubes (sys-net, sys-usbm sys-audio, sys-gui etc.) the tasks for dom0 become less and less
at some distant point in the future dom0 might be a Qubes OS specific minimal distribution
Short of real and major security benefits in moving dom0 to another distribution it is simply not important enough at the moment to distract from other more urgent development tasks.
Personal likes or dislikes for this or that packet manager / distribution are irrelevant.
What I should have said, instead of ‘reduce vulns in dom0’, is this:
switching dom0 distro to lower TCB such as alpine has many advantages, (which I’m sure have already been discussed).
If something atop dom0 chains flaws to exploit the actual distro chosen, then it follows that a more secure distro reduces vulns - this is what I meant, (sorry I mis-spoke and wrote ‘in dom0’ - it was shorthand for what I meant).
cmiiw, I think you missunderstood, there’s nothing to do with fedora in dom0, what qubes provides is xen virtualization, in any case xen is more important than what any security that apply in dom0.
As example this attack Project Zero: Pandavirtualization: Exploiting the Xen hypervisor
But as you’ve said, this has probably been discussed already - however I felt emoldened by @ppc comment r/e alpine (i.e: they seem to agree alpine is better than fedora).
So I suppose it was more of a question than a statement - in reference to: how different are the libraries of fedora and alpine*?
*(because if they are radically different, then IMHO switching from fedora to alpine is a massive security increase - but of-course you will know far better than me the cost of the increase, and hence what the ROI/priority is).
I agree 100%, xen is more important than anything else - so if there’s more to do there I don’t mean to distract you - sorry if I have.
Xen project undergoes a Synopsis Coverity scan which should also be the case for QubesOS. What types of attacks would Xen be subject to if it isn’t network facing?