4 ms·
Except you can't trust function names either. Remember the NSO iMessage exploit?[1] copyGifFromPath didn't really copy the GIF from the path. At some point, y
by throw10920 5y ago
Except you can't trust function names either.
Remember the NSO iMessage exploit?[1] copyGifFromPath didn't really copy the GIF from the path.
At some point, you do have to trust that the kernel API's documentation (or whatever) is correct[2], simply because it's physically impossible for you to exhaustively verify that each piece of software you use (transitively) has correct documentation and consistent semantics. That doesn't mean that you shouldn't audit third-party code, do code reviews, write tests, fuzz your code, and use static analysis and formal methods - in fact, you should do all of those things, if you can.
But, "don't trust comments" is a gross oversimplification. Perhaps "trust, but verify" is a better pithy saying.
[1] https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
[2] technically, if you did all of the above things, or found other people that did them, then you wouldn't have to trust documentation - but the vast majority of the time, most of the software you encounter will not have been thoroughly audited, tested, and fuzzed, with a nice formal specification
- jchw 5y agoOn one hand, I agree. On the other, this does feel a bit whatabouty. Because yeah, you can’t check the kernel code, but you can and should check the code of direct dependencies. Not every time you do anything, but certainly whenever there’s something to be feared. Running code against untrusted inputs from the Internet is one of the few places that would justify “reverse engineer the kernel to make sure it’s safe” levels of concern, in the right conditions.
- ncmncm 5y ago"Trust, but verify" is a semantically null expression that appears to have filtered out of the Soviet Union during arms reduction negotiations, and eagerly taken up by Reagan administration appointees. You can only ever trust or verify. "Trust, but verify" is functionally identical to "verify", thus, equivalently, "distrust, therefore verify", with maybe a generous helping of cynicism, doublethink, and official mollification.
- jcelerier 5y ago> "Trust, but verify" is functionally identical to "verify" is there some kind of equivalent of aphantasia but for the feeling of trusting something ?
- sk0g 5y agoIt's like the rule I forget the name of - if a sentence has a but in it, everything before the but is filler :)
- naruhodo 5y agoNot just filler. Everything before the "but" is negated. I'm not racist, but <some racist shit>.
- strken 5y agoThis is trivially stupid. "I like the Corvette, but I'd get it in red" does not mean you hate Corvettes. "I like steak, but only medium or below" does not mean you hate steak.
- ncmncm 5y agoDo you understand what the word "filler" means?
- ncmncm 5y agoSorry, I misread.
- naruhodo 5y ago> I like the Corvette, but You don't like the Corvette. Not that Corvette. However, you like Corvettes in general. Or you only like red Corvettes. > I like steak, but Turn the comma into a period: I like steak. It's unconditional; steak is a big yes for you. Except it's not. You have conditions. So sometimes you like steak and sometimes the opposite. You don't like steak. I think the interpretation of but is not as trivially stupid as you say.
- lmm 5y agoYou can't trust function names, but they have a better chance of being kept up to date than comments, since they're more likely to be in active use. But yeah, the only thing you can really trust is the type signature (and even that, only if the language has a strong culture of not doing random nonsense).