> You keep repeating this without providing any actual statistics. I provided statistics about Qubes vulnerabilities, https://www.qubes-os.org/security/xsa/. Show me the numbers please.
You can find this yourself. For any software running in the guest OS, you can look up it's security history.
> This just shows that you don't understand the security approach of Qubes. You do not store anything important in a disposable. You run it specifically for one task of opening something untrusted and then it's destroyed. It
I understand it perfectly, but you seem to be missing my point. Yes, the qubes are disposable, but you need to have information in them while you are using them, yes? So, you make a new qubes to do your taxes, your tax information is in the qubes because you need it to do that. While the qube is running, if it is vulnerable, then that information is at risk. I get that it is no longer at risk once the qube is destroyed, but that is irrelevant to my point.
Consider an example, back in 2024 if you were running SSH in a Qubes for some reason, you would likely be vulnerable to the regreSSHion vulnerability. Sure, an attacker could only access what was on the disposable VM, but that could still be a lot.
> This is not a robust system designed for security first. You can use this to be (much) more secure than otherwise, but it's not a security-oriented design, unlike Qubes.
Neither is qubes. It's designed for specific use cases, and doesn't do much to protect the information running within a qube aside from destroying it after disposing of it.
> Which means nothing. Disposable can't store anything, it's destroyed every time you stop it.
It's at risk while the VM is running, which is the point.
No, it doesn't. Those points are rather nonsense. Malware that can bridge airgapped systems? Sure, if you have a compromised USB stick and stupidly run something from it, I guess. The disposable VM would be at risk also.
> Do I have to trust you on this, or do you have any reasonable reference to security people? You don't even provide your threat model when saying this, which clearly shows how amateur your approach to security is.
You have no security knowledge at all, though, you just repeat your chosen solution because it's FLOSS. It makes this discussion very frustrating. Do you understand anything about capabilities, mandatory access controls or formal verification?
> Relying on professionals in the field is not zealotry.
You are exaggerating claims you can't backup in a field you don't understand due to the software meeting your only real criteria, being FLOSS. That is absolutely zealotry.
> This is plain false:
Not only do your links not support your exaggerated claims at all, meaning I am correct the author would absolutely not agree with you, but the FAQ entry dismissing formal verification and safe languages refers to a paper from 2010 - back when Rust didn't even exist. You might not know this, but the tech world moves pretty fast...
Do me a favor, spend some time with your favorite FLOSS AI and ask it why SEL4 would be considered superior to Qubes from a security perspective.
You refuse to provide any references. I don't see a reason to continue the discussion.
You also reply to my references with shallow dismissals with no substance presenting that as facts ("Not only do your links not support your exaggerated claims at all")
You give examples how Qubes can't save you from absolutely everything. It's true. Yet your original claim is that Flatpac is similarly secure and you failed to explain how it would protect from the same problems.
Why is there a need for references? Do you not understand how VMs work? Do you dispute that software running in the VM can be vulnerable?
> You also reply to my references with shallow dismissals with no substance presenting that as facts ("Not only do your links not support your exaggerated claims at all")
Because your 'references' don't support your claims, it's that simple. You can't just copy and paste links and act like you have provided evidence when the links don't match. Your claim doesn't appear on the Bubblewrap github page at all.
> Yet your original claim is that Flatpac is similarly secure and you failed to explain how it would protect from the same problems.
Vulnerable software running in a Bubblewrap sandbox and in a Qubes VM are both similarly vulnerable to software vulnerabilities, and it is unlikely an attacker would be able to escape the sandbox or the VM. I grant that escaping the sandbox is easier and more common, but not by much.
Your first key point was that Bubblewrap vulnerabilities happen all the time, and you've yet to support that. The only 'reference' you provided was to the Bubblewrap github page.
> They do not exist, only open-weight ones do.
And of course you don't trust anything that isn't FLOSS, right?
You can find this yourself. For any software running in the guest OS, you can look up it's security history.
> This just shows that you don't understand the security approach of Qubes. You do not store anything important in a disposable. You run it specifically for one task of opening something untrusted and then it's destroyed. It
I understand it perfectly, but you seem to be missing my point. Yes, the qubes are disposable, but you need to have information in them while you are using them, yes? So, you make a new qubes to do your taxes, your tax information is in the qubes because you need it to do that. While the qube is running, if it is vulnerable, then that information is at risk. I get that it is no longer at risk once the qube is destroyed, but that is irrelevant to my point.
Consider an example, back in 2024 if you were running SSH in a Qubes for some reason, you would likely be vulnerable to the regreSSHion vulnerability. Sure, an attacker could only access what was on the disposable VM, but that could still be a lot.
> You never give any actual reference, only I have to. Here you go: https://github.com/containers/bubblewrap.
This source doesn't support your claim.
> This is not a robust system designed for security first. You can use this to be (much) more secure than otherwise, but it's not a security-oriented design, unlike Qubes.
Neither is qubes. It's designed for specific use cases, and doesn't do much to protect the information running within a qube aside from destroying it after disposing of it.
> Which means nothing. Disposable can't store anything, it's destroyed every time you stop it.
It's at risk while the VM is running, which is the point.
> Yes, it does: https://doc.qubes-os.org/en/latest/introduction/faq.html#how...
No, it doesn't. Those points are rather nonsense. Malware that can bridge airgapped systems? Sure, if you have a compromised USB stick and stupidly run something from it, I guess. The disposable VM would be at risk also.
> Do I have to trust you on this, or do you have any reasonable reference to security people? You don't even provide your threat model when saying this, which clearly shows how amateur your approach to security is.
You have no security knowledge at all, though, you just repeat your chosen solution because it's FLOSS. It makes this discussion very frustrating. Do you understand anything about capabilities, mandatory access controls or formal verification?
> Relying on professionals in the field is not zealotry.
You are exaggerating claims you can't backup in a field you don't understand due to the software meeting your only real criteria, being FLOSS. That is absolutely zealotry.
> This is plain false:
Not only do your links not support your exaggerated claims at all, meaning I am correct the author would absolutely not agree with you, but the FAQ entry dismissing formal verification and safe languages refers to a paper from 2010 - back when Rust didn't even exist. You might not know this, but the tech world moves pretty fast...
Do me a favor, spend some time with your favorite FLOSS AI and ask it why SEL4 would be considered superior to Qubes from a security perspective.