[mherdeg]

Oh jeez, this fixes CVE-2023-24809 - i.e. nethack on shared systems may be risk due to buffer overflow in pre-3.6.7 versions.

I was looking at the list of diffs with some confusion about why it's such a small point release ( https://github.com/NetHack/NetHack/blob/NetHack-3.6/doc/fixe... ) before I re-read the release notes and saw the security issue.

[ilyagr]

I wish it was "Becoming a demigod allows arbitrary code execution..."

[planede]

Seriously, if the security of nethack is critical to your security, then you probably do something very wrong. There is no reason to not sandbox the hell out of it.

[johnklos]

Not all security works in your oversimplified Windows-centric ways.

Since we're not building a VM per user on multi-user systems, we do care about security of the programs we install.

[planede]

You don't have to spin up a VM per user to sandbox on Linux. You could use firejail. But traditional UNIX user sandboxing could also go a long way.

I'm just saying that I would never trust nethack to not execute arbitrary code and I would have other security measures in place if my threat model required it. It's written in C. I don't expect most contributors to be security focuesed. The primary use is a user running it on their own machine, which is a completely different threat model.

[astrobe_]

You both don't need to be condescending morons ("Windows-centric security", "It's written in C") on such a minor issue.

[johnklos]

Treating multi-user separation as unimportant or unworthy of consideration is a Windows-centric view. It's common, just as Windows is common,

[kurisufag]

>It's written in C

I find it hard to believe that the rest of your network stack isn't.

The threat model point is very valid, and a big issue with gaming servers in general.