And the context here is that OpenBSD people were really mad about OpenSSL in the aftermath of Heartbleed. It was around this time they forked it into LibreSSL.
I thought the prose was meant to be more humorous than cynical.
I took it as the author cracking jokes about the simple mistakes made. Thought it was funny myself.
I find the lack of tests pretty appalling for this code. How do people ship code and never see something like a user login failure case etc. People talk a lot of trash about TDD, but I feel like a lot of senior devs make this highly egotistical "I know better" argument all the time and I've seen a lot of hot garbage for code because people were too busy to write the test.
I think the challenge is that unless you consider and write the tests first, it is easy to create tests that pass. Test ssl verify? Easy, just mock it returning 1 and the code passes. In real life, however, maybe the return value is -1 and maybe that doesn't work.
Maintaining tests for these sizes of projects is probably quite arduous too. I don't disagree but I still think there are many genuine reasons there are no/not enough tests around this sort of code.
Genuine reasons but ones that still aren't good enough right? There shouldn't be some bar where it was just so difficult on the developer to ship broken security code. If it's that hard, stop writing critical software components and go home.
> I've seen a lot of hot garbage for code because people were too busy to write the test.
I've seen a lot of hot garbage for code because people were too busy writing the tests and ignoring the readability and idiomatic norms of the production code they were writing.
I firmly believe in TDD where you write the test, watch if correctly fail, make the test in the simplest possible way, and then refactor to make it more readable or idiomatic. Red, green, refactor. I'd rather try and fix ugly code that has tests than try and fix ugly code with no tests. Doing the latter is almost impossible sometimes because you don't even know the exact intent of the code or why some edge case is there etc.
> I was fairly certain the sarcasm (or satire as I prefer to call it; sounds more intellectual) would be obvious.
I get that the author was being sarcastic, but I don't get what purpose they serve other than be obnoxious.
Yeah, I found it hard to understand too.
Was the sarcasm the bit about the bracing, when the actual bug has nothing to do with the goto but instead is the missing post-increment (++)?
Every 'how is this possible' was sarcastic
If you follow the link at the bottom you get to a more analytical blog post: https://flak.tedunangst.com/post/thoughts-on-style-the-TLS-a...
And the context here is that OpenBSD people were really mad about OpenSSL in the aftermath of Heartbleed. It was around this time they forked it into LibreSSL.
I thought the prose was meant to be more humorous than cynical. I took it as the author cracking jokes about the simple mistakes made. Thought it was funny myself.
Yeah, the sarcasm is completely counterproductive (as it usually is). The same sentiments expressed sincerely would be a much better read
I love these. The best one I saw recently was an off-by-one error that fixed ADC read accuracy on ARM ..
https://lore.kernel.org/all/20210322121923.804433865@linuxfo...
That Wilfried (my boss at the time) got into the CONTRIBUTORS file for that fix is a constant source of amusement ..
I find the lack of tests pretty appalling for this code. How do people ship code and never see something like a user login failure case etc. People talk a lot of trash about TDD, but I feel like a lot of senior devs make this highly egotistical "I know better" argument all the time and I've seen a lot of hot garbage for code because people were too busy to write the test.
I think the challenge is that unless you consider and write the tests first, it is easy to create tests that pass. Test ssl verify? Easy, just mock it returning 1 and the code passes. In real life, however, maybe the return value is -1 and maybe that doesn't work.
Maintaining tests for these sizes of projects is probably quite arduous too. I don't disagree but I still think there are many genuine reasons there are no/not enough tests around this sort of code.
Genuine reasons but ones that still aren't good enough right? There shouldn't be some bar where it was just so difficult on the developer to ship broken security code. If it's that hard, stop writing critical software components and go home.
Would tests have found the 1-in-256 password issue for MySQL?
Perhaps property testing, like QuickCheck. I don't think that is exactly TDD.
But I agree with tests and TDD in general.
> I've seen a lot of hot garbage for code because people were too busy to write the test.
I've seen a lot of hot garbage for code because people were too busy writing the tests and ignoring the readability and idiomatic norms of the production code they were writing.
I firmly believe in TDD where you write the test, watch if correctly fail, make the test in the simplest possible way, and then refactor to make it more readable or idiomatic. Red, green, refactor. I'd rather try and fix ugly code that has tests than try and fix ugly code with no tests. Doing the latter is almost impossible sometimes because you don't even know the exact intent of the code or why some edge case is there etc.
"the lack of tests pretty appalling" => "your lack of tests disturbing". You're welcome :)
Re: memset - "It's so trivial, it doesn't need a test" And yet... someone managed to get it wrong.
My personal one liner was a static keyword in a web application.
It was working perfectly when they was only one user and this is why it was so difficult to debug.