Hacker News Reader

This is WILD!

The sentence before the one you quote is

> Sometimes versions of the game are also intentionally shipped with debug symbols to generate better error reports.

You remove that context, quote him saying sometimes it's a mistake and criticise him with the preface he already provided!?

With context then the quote is

> Sometimes versions of the game are also intentionally shipped with debug symbols to generate better error reports. However, sometimes programmers forget to remove the debug symbols from the final binaries of the game. Programmers are humans, and humans make mistakes.

It looks like the author is saying shipping final binaries with debug symbols is a mistake, and that's what @ho_schi is criticising.

The author is noting that in this particular case, Valve made a mistake in releasing the debug symbols for a particular build, as noted by them releasing them in a 2017 build, and then removing them in a subsequent build.

The author did not say that "shipping with debug symbols is always a mistake", they noted that it can happen unintentionally and provided evidence of that in this case.

I'm sick of this weird HN trend where readers pick out a single sentence only tangentially related to the rest of the article and then try to prove how smart they are by rebutting it.

you mean that's not the whole point of posting here?

These Reddit-like comment sections with public vote counters highly incentivize this type of thing. I don't even know why HN has a voting system? I think sorting comment threads by number of replies would be more useful. Vote counters only make sense when you have a massive amount of comments to sort through, which really only happens on posts about Apple afaik. However, those comment threads tend to be filled with useless arguing anyways.

Would people stop using this site if it stopped offering dopamine hits in the form of a number next to your name?

Reply count can be more of an indicator of controversy, rather than value. The best comment might provide me deep me deep new insight, but all I have to say is "that's great!". Saying something inflammatory results in lots of replies.

In fact, the HN algorithm downranks threads with a high comment-to-point ratio.

I choose to believe there exists an old guard that use the site without points visible, either through frontend modification or mobile apps.

This is a good form habit. Discussion is largely about creating narratives and arguments to try to come to a consensus on reality. This is ostensibly useful.

When someone makes a statement and that statement is innaccurate or untrue, it is helpful to correct it so that they can change their post/future-posts to ensure they are making the strongest argument/most compelling narrative possible. Sometimes this is misused or misunderstood to be combative, but it is not constructive to approach conversation this way.

I’m sorry. You are right! I missed to quote the sentence before :(

As pointed out by jpmoral, I consider debug symbols generally a good thing. Exceptions apply as usual e.g. embedded computing.

Another approach is using stuff like debuginfod to ship debug symbols automatically when needed. Archlinux and Fedora do that and it improved debugging and reporting - especially regarding dependencies.

You don't need to ship your debug symbols to have stack traces. You just need to uniquely identify published binaries, and link them to stored debug symbols. See also breakpad, of which Chrome and Firefox use a variant of.

You should absolutely never release a commercial binary to public with debug symbols.

There are ways to convert symbol names on the crash report server, so the claim that you can get better crash report with debug symbols is not correct.

Why you shouldn’t release debug symbols:

* It helps patent/copyright trolls litigate you easier.

* Makes it easier to reverse engineer your binaries, which will help malicious actors and competitors.

* You might lose some trade secrets.

If you are a startup owner, please ensure to never release commercial/close-source binaries with debug symbols. You can thank me later.

> Some people still argue that security by obscurity works and hide everything. I doubt that.

Most things involving security also use and greatly care about obscurity of implementation. The principle is that the security should not "rely solely" on obscurity, not that obscurity has no benefits.

Usually, making software such that one can have a high confidence of it being secure is not economical. One relies on being harder to break than the competition, for which obscurity can be a big deal, and on offloading or mitigating damage when flaws are inevitably exploited anyway.

Security by obscurity very obviously works, in the sense that it raises the bar of effort required by potential attackers. You can't rely on it to be your only security, but there's no reason why it wouldn't help.

It’s the engineering definition of “works”: if a solution merely mitigates the frequency or severity of a problem, but does not completely solve it in all cases, obviously the solution is useless and no better than doing nothing at all. Only the platonically ideal solution has any value at all.

What are you talking about? It's the engineering definition of "works" because engineers live in the real world and incorporate economic factors into their decision making to make something that works better under real-world conditions. If a solution merely mitigates the frequency or severity of a problem, the solution is obviously not better than doing nothing at all, since you just admitted it mitigates the severity or frequency of a problem. Would you rather have 100 0-days or one? Would you rather have a high-impact 0-day or a low-impact one?

You're kidding? That's opposite to the spirit of engineering.

Perhaps, but many engineers have personalities that are in conflict with what you’re calling the spirit of engineering. Binary thinking is a too-common thing.

> Binary thinking is a too-common thing.

It's engineering after all, isn't it?

Nobody argues that anymore, but this post is evidence that attackers value debug symbols and that should be a factor in deciding whether or not to strip them.

> Delivering software with debug symbols - wether commercial or non-profit - isn’t a mistake. It is a decision for better bug reports, traces and convenience.

Yes, it is a mistake. None of those things require symbols on the customer’s machine.

> Some people still argue that security by obscurity works and hide everything. I doubt that.

It is certainly true for games. There are only very expensive cheats for eg R6S and Overwatch 2, and the encryption of those games is a headache.

This is such a weird answer because on Windows, the default is to simply split out the debug data from the binary. And then, shock horror the technology, serve the right debug data from a (build) server on demand!

In any case, this is an online video game, if you want to have a billion cheaters, feel free to ship debug data (for no reason) with the binary.

On windows, debug symbols are distinct files that match with a specific version of a binary. When your crash reports get sent off to Valve, they have the appropriate PDB file to match and have full source level debuggablity.

They might reveal trade secrets though.