Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

F-Droid Board of Directors nominations 2026

f-droid.org

Post reply on HN
Print view View original

151–160 of 160 posts

Re: F-Droid Board of Directors nominations 2026

#151

Post by fsflover »

handedness wrote: post #145
fsflover wrote: post #107

Earlier quoted context omitted.

> In addition to all that, by the nature of the respective code bases it presents a significantly smaller attack surface than a computer running Qubes OS. I critisize precisely because I don't understand what you're talking about. The last relevant VM escape was in 2006, discovered by Rutkowska herself. Since then, nothing could access my secrets in an offline vault VM. I would appreciate a clarification, how Graphen…

Attempting to compare line counts of 'security-related code' in isolation, if such a thing can even be framed that way, as if that's a useful metric indicates a fundamental misunderstanding of the issue. Making very selective hardware comparisons while attempting to compare the relative strengths of the operating systems running on said hardware also indicates the same. Framing closed blobs as fatal flaws while advoc…

I really appreciate your detailed, good-faith responses.

> Attempting to compare line counts of 'security-related code' in isolation, if such a thing can even be framed that way, as if that's a useful metric indicates a fundamental misunderstanding of the issue.

I didn't invent this. Isn't this exactly how Qubes developers frame it? Are you saying their approach is wrong? https://doc.qubes-os.org/en/latest/introduction/faq.html#wha... and https://doc.qubes-os.org/en/latest/developer/system/security...

> Framing closed blobs as fatal flaws while advocating for other situations also containing different closed blobs is disingenuous

Isn't this an important milestone, when the OS has no proprietary bits at all? This not the end, but something worth celebrating, I guess. Apart from that, doesn't Librem 5 has a lower number of blobs in general? I might be wrong of course.

> hand-waving IME (or PSP to whatever degree) as being "disabled,"

It seems you misunderstand me or didn't really read my previous posts carefully. I never considered "disabled" ME sufficiently secure. I strongly prefer "disabled and neutralized" instead, which I btw have on my laptop. It doesn't completely kill it, but it certainly makes it quite unlikely to make any harm.

> yet ignoring it when it doesn't isn't

I guess if I ignored something, I did not notice that it was relevant. Therefore I have no idea what you are talking about, i.e., which exact posts of mine you mean. If you actually want to be helpful, this is not how it's done.

> but "the last relevant VM escape" overly relies on "relevant,"

I admit that, and I specifically mentioned my threat model with passwords in relation to this. You didn't show how my threat model was wrong or not secured against.

Your other points are well articulated, although the corresponding threat model you mentioned is definitely not for everyone. Thanks again.

Re: F-Droid Board of Directors nominations 2026

#152

Post by handedness »

fsflover wrote: post #150
handedness wrote: post #148

Earlier quoted context omitted.

You still need to address this part: "Qubes is great but at the end of the day cannot protect against evil maid attacks to the level that pixel or apple phones can. Its great at making sure a browser exploit cannot steal your banking credentials you have open in a different virtual machine but cannot overcome the limitations of the platforms it builds off of." That's the crux of it you blow past every single time it…

> "Qubes is great but at the end of the day cannot protect against evil maid attacks to the level that pixel or apple phones can" Yes, it can. Heads, TPM with a hardware key do exactly that, don't they? I'm not sure what you mean by "level". You would need to use a nail polish, too, to be sure your laptop wasn't tampered with. > but cannot overcome the limitations of the platforms it builds off of Yes, it can, if you…

Comprehensive verified boot with hardware attestation, a secure element, no dependency on USB for AEM. It's an entirely different ballgame.

Qubes AEM hasn't had an update in years, either.

Re: F-Droid Board of Directors nominations 2026

#153

Post by upboundspiral »

fsflover wrote: post #150
handedness wrote: post #148

Earlier quoted context omitted.

You still need to address this part: "Qubes is great but at the end of the day cannot protect against evil maid attacks to the level that pixel or apple phones can. Its great at making sure a browser exploit cannot steal your banking credentials you have open in a different virtual machine but cannot overcome the limitations of the platforms it builds off of." That's the crux of it you blow past every single time it…

> "Qubes is great but at the end of the day cannot protect against evil maid attacks to the level that pixel or apple phones can" Yes, it can. Heads, TPM with a hardware key do exactly that, don't they? I'm not sure what you mean by "level". You would need to use a nail polish, too, to be sure your laptop wasn't tampered with. > but cannot overcome the limitations of the platforms it builds off of Yes, it can, if you…

Heads + TPM is solid but I suspect it is not at the level of Google/Apple secure enclave. And a strong secure enclave provides benefits outside of first boot to secure certain processor state and continuosly ensure integrity.

For desktop TPM at least to me they seem a bit of a black box with many past vulnerabilities https://en.wikipedia.org/w/index.php?title=Trusted_Platform_....

I think at cold boot as long as one doesn't store the encryption key in the TPM (external hardware key?) then one should be secure. I am not so sure about post boot however, once the system is already running.

This actually prompted me to research a bit on the scale of the security impact of SMM

https://en.wikipedia.org/wiki/System_Management_Mode

https://doc.coreboot.org/security/smm.html

It seems that coreboot is aware and supposedly for some computers can be implemented to catch calls to SMM (ideally this would prevent the attacker from triggering SMM - if they do it's game over).

I do suspect though that if the system bus is not protected from malicious calls then someone can trigger SMM and have carte blanche to one's computer.

https://www.infoworld.com/article/2167684/hackers-find-a-new...

https://hothardware.com/news/researchers-discover-rootkit-ex...

I don't know what processes Apple / Android use but I suspect ARM chips don't have SMM and that they tie certain functions to their secure enclave. In X86 its backwards, with SMM having control over the TPM (at least in some implementations).

Though some SMM vulnerabilities are patched by now given its history I take X86 security with a grain of salt. I think the potential for a secure platform is there, but I suspect one would want to make their own boards engineered with security in mind to be certain (I hope this happens in the future - it seems to be happening in the server space already).

Re: F-Droid Board of Directors nominations 2026

#154

Post by fsflover »

upboundspiral wrote: post #153
fsflover wrote: post #150

Earlier quoted context omitted.

> "Qubes is great but at the end of the day cannot protect against evil maid attacks to the level that pixel or apple phones can" Yes, it can. Heads, TPM with a hardware key do exactly that, don't they? I'm not sure what you mean by "level". You would need to use a nail polish, too, to be sure your laptop wasn't tampered with. > but cannot overcome the limitations of the platforms it builds off of Yes, it can, if you…

Heads + TPM is solid but I suspect it is not at the level of Google/Apple secure enclave. And a strong secure enclave provides benefits outside of first boot to secure certain processor state and continuosly ensure integrity. For desktop TPM at least to me they seem a bit of a black box with many past vulnerabilities https://en.wikipedia.org/w/index.php?title=Trusted_Platform_... . I think at cold boot as long as one…

> external hardware key?

Yes: https://en.wikipedia.org/wiki/Librem#Librem_Key

Re: F-Droid Board of Directors nominations 2026

#155

Post by fsflover »

handedness wrote: post #152
fsflover wrote: post #150

Earlier quoted context omitted.

> "Qubes is great but at the end of the day cannot protect against evil maid attacks to the level that pixel or apple phones can" Yes, it can. Heads, TPM with a hardware key do exactly that, don't they? I'm not sure what you mean by "level". You would need to use a nail polish, too, to be sure your laptop wasn't tampered with. > but cannot overcome the limitations of the platforms it builds off of Yes, it can, if you…

Comprehensive verified boot with hardware attestation, a secure element, no dependency on USB for AEM. It's an entirely different ballgame. Qubes AEM hasn't had an update in years, either.

Perhaps you are right, and the hardware attestation is more reliable on a Pixel. However, doesn't it rely on proprietary hardware, unlike Heads? coreboot with Heads is not the same as Qubes AEM. Heads is updated regularly: https://github.com/linuxboot/heads/

Re: F-Droid Board of Directors nominations 2026

#156

Post by handedness »

fsflover wrote: post #151
handedness wrote: post #145

Earlier quoted context omitted.

Attempting to compare line counts of 'security-related code' in isolation, if such a thing can even be framed that way, as if that's a useful metric indicates a fundamental misunderstanding of the issue. Making very selective hardware comparisons while attempting to compare the relative strengths of the operating systems running on said hardware also indicates the same. Framing closed blobs as fatal flaws while advoc…

I really appreciate your detailed, good-faith responses. > Attempting to compare line counts of 'security-related code' in isolation, if such a thing can even be framed that way, as if that's a useful metric indicates a fundamental misunderstanding of the issue. I didn't invent this. Isn't this exactly how Qubes developers frame it? Are you saying their approach is wrong? https://doc.qubes-os.org/en/latest/introducti…

Noting that they have deliberately added as little code as possible to dom0 to minimize the risk of introducing bugs or attack surface and quantifying it in service of their point is a sensible way of effectively conveying how they're approaching the problem. You attempted to use the same thing as a tool by which to make comparative value judgement, like seeing someone using a hammer to drive a nail and then attempting to use a hammer to drive a screw.

You also continue to shift the goalposts on things which I trust is not from malice but a hazy grasp of some basic fundamental concepts. You've already had it explained to you by people much more qualified than I how the Librem 5 has some entirely closed-source components running woefully outdated firmware, but now it's about celebrating something else entirely.

"Disabled and neutralized" IME is still IME that's highly privileged hardware running a closed-source operating system outside of your ability to monitor it. By the standards of evaluation you set in other comments baselessly criticizing Pixel hardware, you should object all the more to the x86 architecture, even with your ultimately insufficient attempts to reduce harm. The hand-wringing over the possibility that Google has embedded a still-undiscovered way to exfiltrate data from their phones even when running GrapheneOS, is misguided and unfair at best, and if nothing else you should be consistent in your application of these principles.

I trust I shouldn't need to cite every point you repetitiously make in order for you to stop complaining that I'm not limiting the scope of my reply perfectly to one particular comment of yours, as if this is some kind of contest of form.

If you kept current or really spent any time at all researching XSAs you'd know that its shared memory architecture alone has resulted in numerous XSAs, some of which could very much apply to your threat model. Hardware MTE would go a long way to mitigating that, which Pixels have. In the hypothetical scenario of Qubes OS running on more secure hardware than even your home brew situation, that would be a significant improvement over the status quo which you say you can't even imagine. You're defining your threat model overly narrowly by excluding all kinds of relevant factors and then declaring it wholly met. That's not how this stuff works.

If, after all this, you still can't imagine how Qubes could be improved upon for your particular threat model (having passwords in a vault appVM exfiltrated) after hearing just a couple hypothetical benefits of running it on more secure hardware, it's unsurprising you can't recognize the comparative advantages of GrapheneOS and instead want to rely on things like counting lines of security code because you once saw someone else do it in a different context.

My goal here is not to change your mind, that part is up to you and you've already had one of the finest minds in the field address your issues point by point elsewhere (that was a fun surprise to see). My goal is to reduce the ease with which you can continue to filibuster people into moving on with their lives so you can then continue making the same unjustifiable claim that nobody ever offers a meaningful explanation to you when you merely ask simple questions about the benefits of the project. Unstoppable Force Meets Argumentum ad nauseam.

Re: F-Droid Board of Directors nominations 2026

#157

Post by fsflover »

handedness wrote: post #156
fsflover wrote: post #151

Earlier quoted context omitted.

I really appreciate your detailed, good-faith responses. > Attempting to compare line counts of 'security-related code' in isolation, if such a thing can even be framed that way, as if that's a useful metric indicates a fundamental misunderstanding of the issue. I didn't invent this. Isn't this exactly how Qubes developers frame it? Are you saying their approach is wrong? https://doc.qubes-os.org/en/latest/introducti…

Noting that they have deliberately added as little code as possible to dom0 to minimize the risk of introducing bugs or attack surface and quantifying it in service of their point is a sensible way of effectively conveying how they're approaching the problem. You attempted to use the same thing as a tool by which to make comparative value judgement, like seeing someone using a hammer to drive a nail and then attempti…

> Noting that they have deliberately added as little code as possible to dom0 to minimize the risk of introducing bugs or attack surface and quantifying it in service of their point is a sensible way of effectively conveying how they're approaching the problem. You attempted to use the same thing as a tool by which to make comparative value judgement

I guess you only opened my first link but not the second. Here is a quote from the second link for you:

> The size of the current TCB is on the order of hundreds of thousands of lines of C code, which is several orders of magnitude less than other OSes. (In Windows, Linux, and Mac OSes, the amount of trusted code is typically on the order of tens of millions of lines of C code.)

Re: F-Droid Board of Directors nominations 2026

#158

Post by handedness »

fsflover wrote: post #154
upboundspiral wrote: post #153

Earlier quoted context omitted.

Heads + TPM is solid but I suspect it is not at the level of Google/Apple secure enclave. And a strong secure enclave provides benefits outside of first boot to secure certain processor state and continuosly ensure integrity. For desktop TPM at least to me they seem a bit of a black box with many past vulnerabilities https://en.wikipedia.org/w/index.php?title=Trusted_Platform_... . I think at cold boot as long as one…

> external hardware key? Yes: https://en.wikipedia.org/wiki/Librem#Librem_Key

Versus storing the encryption key on a device requiring USB with its many vulnerabilities (even on Qubes OS), storing the key in a dedicated eSE is beneficial.

Beyond that, there have been known vulnerabilities of NitroKey's Librem Key, to say nothing of the Nitro Key App.

Nothing's perfect but I would vastly prefer something like the Titan M2's implementation over a USB key with all of the complexity and attack surface that introduces.

Re: F-Droid Board of Directors nominations 2026

#159

Post by fsflover »

handedness wrote: post #156
fsflover wrote: post #151

Earlier quoted context omitted.

I really appreciate your detailed, good-faith responses. > Attempting to compare line counts of 'security-related code' in isolation, if such a thing can even be framed that way, as if that's a useful metric indicates a fundamental misunderstanding of the issue. I didn't invent this. Isn't this exactly how Qubes developers frame it? Are you saying their approach is wrong? https://doc.qubes-os.org/en/latest/introducti…

Noting that they have deliberately added as little code as possible to dom0 to minimize the risk of introducing bugs or attack surface and quantifying it in service of their point is a sensible way of effectively conveying how they're approaching the problem. You attempted to use the same thing as a tool by which to make comparative value judgement, like seeing someone using a hammer to drive a nail and then attempti…

> running woefully outdated firmware

This is just false. Looks like you mix false accusations with reasonable arguments.

I still didn't receive any reply concerning the lines of code for the Trusted Computing Base (TCB) of GrapheneOS.

Re: F-Droid Board of Directors nominations 2026

#160

Post by cxr »

AnthonyMouse wrote: post #127
cxr wrote: post #126

Earlier quoted context omitted.

Apologies—when I mentioned the insincerity and indulgence before, I should have said tediously insincere indulgence.

I mean, do you want the realpolitik version? If you're doing something to be controversial/oppositional then you need people to feel troubled by it. Labeling Reddit as NSFW is something many of them want , which is the opposite.

> I mean, do you want the realpolitik version?

No, I don't. (How could I have been any clearer?)

Post reply on HN