> should never see production use.
I have an issue with high strung opinions like this. I wrote plenty of crappy delphi code while learning the language that saw production use and made a living from it.
Sure, it wasn't the best experience for users, it took years to iron out all the bugs and there was plenty of frustration during the support phase (mostly null pointer exceptions and db locks in gui).
But nobody would be better off now if that code never saw production use. A lot of business was built around it.
Buggy code that just crashes or produces incorrect results are a whole different category. In C a bug can compromise a server and your users. See the openssl heart bleed vulnerability as a prime example.
Once upon a time, you could put up a relatively vulnerable server, and unless you got a ton of traffic, there weren't too many things that would attack it. Nowadays, pretty much anything Internet facing will get a constant stream of probes. Putting up a server requires a stricter mindset than it used to.
There are minimum standards for deployment to the open web. I think - and you're of course entirely free to have a different opinion - that those are not met with this code.
Yes, I have lots of opinions!
I guess the question at spotlight is: At what point would your custom server's buffer overflow when reading a header matter and would that bug even exist at that point?
Could a determined hacker get to your server without even knowing what weird software you cooked up and how to exploit your binary?
We have a lot of success stories born from bad code. I mean look at Micro$oft.
Look at all the big players like discord leaking user credentials. Why would you still call out the little fish?
Maybe I should create a form for all these ahah.
> Could a determined hacker get to your server without even knowing what weird software you cooked up and how to exploit your binary?
Yes.
Yes but how? After the overflow they still have to know the address of the next call site and the server would be in a UB state.
The code is on github. Figure out a way to get a shell through that code and you're hosed if someone recognizes it in active use.
I mean tha hacker won't know what software is running on the server, unless the server announces itself which can be traced to the repo, but then, why ?? Who cares about this guy's vps? This whole thread makes no sense to me and I'm the only one questioning.
> This whole thread makes no sense to me and I'm the only one questioning.
That may well be because this isn't your field?
Or maybe well thought out, intelligent responses are a rare thing. Occam's razor suggests the latter.
UB state doesn’t mean totally uncontrollable or opaque.
There are lots of ways the server could leak information about its internal state, and exploits have absolutely been implemented in the past based only on what was visible remotely.