[HN Gopher] Don't trust comments ___________________________________________________________________ Don't trust comments Author : xx_ns Score : 31 points Date : 2022-01-31 20:49 UTC (2 days ago) (HTM) web link (nns.ee) (TXT) w3m dump (nns.ee) | zatarc wrote: | Don't trust this comment. | xwdv wrote: | You can definitely trust comments on Hackernews more than other | sources such as Reddit. | monetus wrote: | 4 days between notification and propagation of the fix. Thank you | for poking around OP. Sanitizing your inputs isn't always simple. | spicybright wrote: | I kind of wish there was a verifier for function/statement | comments to flag inaccurate comments (besides interface | descriptions + general comment at the top of a function.) | | Sort of a combination of a reverse github auto-pilot metric and | checking how old a comment is based on it's surrounding code. | | You could even syntax highlight based on how accurate it thinks | it is like how down voted HN comments fade out. | xwdv wrote: | People don't care about accurate comments, they care about | comments they agree with. | tomcam wrote: | OK well you just rewrote my worldview. That observation can | goes deep as one wishes go go with it... | roylez wrote: | Yes, rst is more powerful. So powerful that it can cause CVE. | throw10920 wrote: | 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-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 wrote: | On 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. | longivitate wrote: | Especially this one. | capableweb wrote: | You're missing a `.. include :: ./arc-admin-credentials.json` | SahAssar wrote: | Comments state intent, code states reality. If those do not match | one of them needs to change. | | When it comes to security no one should trust that intent matches | reality. | nathias wrote: | trust but verify | nerdponx wrote: | Can someone help me understand what actually happened here? As | far as I can gather, the comment in the code wasn't a lie, but | the overall system was complicated enough that there _was_ a way | for the thing-that-shouldn 't-happen to happen anyway. So the | docs weren't wrong, but there was a bug in the code that led to | incorrect behavior that deviated from the docs. | | Or am I misunderstanding something? | wahern wrote: | Thus the hacker refrain, "lies, damned lies, and comments", for | which oddly I'm unable to find any examples despite having seen | it recited several times over the years. In fact, I believe I | came across that rephrasing before learning of Twain's famous | original. I always found it a more pithy justification for why | source code comments should only explain why, not how or what. ___________________________________________________________________ (page generated 2022-02-02 23:00 UTC)