3 ms·

Here is the crux of the issue: > Blaming the EAC developers for not keeping up with Linux ELF hash-table formats might not be entirely fair. The DT_HASH format

Here is the crux of the issue: > Blaming the EAC developers for not keeping up with Linux ELF hash-table formats might not be entirely fair. The DT_HASH format is mandated by the System V ABI specification, the DT_GNU_HASH format is undocumented, and there has been no deprecation campaign to get users to move on. Most problems like this are communication and co-ordination problems.

rwmj 4y ago
> communication and co-ordination problems Which only exist in this case because the software isn't open source. This would have been spotted years ago in open source.
- Spivak 4y ago
  Unless there’s bots out there scanning public code repos for esoteric stuff like this I kinda doubt it. If you mean it would have gotten caught by packagers then yeah but that presumes a world where `apt install eac` makes any sense.
  - rwmj 4y ago
    We do actually have a way to rebuild Fedora with particular changes (eg. when we change the baseline x86-64 version). I guess other distros can do that too. Of course it goes almost without saying that EAC would make about as much sense as an open source project as it does as a closed source project, which is to say none whatsoever because it's conceptually nonsense :-)
- Narishma 4y ago
  An open source anti-cheat system doesn't make much sense.
  - akira2501 4y ago
    Neither does a closed source one, it is running on _my_ computer after all. Cynically.. keeping it closed just allows you to call it "anti-cheat" with a straight face, rather than what it actually is.. "mildly successful cheat mitigation and frustration techniques." Which is obvious once you notice there is an active "anti-anti-cheat" marketplace.
jcranmer 4y ago
That's a poor argument because, even going strictly by the specification, DT_HASH isn't authoritative--the symbol table is provided by DT_SYMTAB. Personally, I feel that by the time you're messing with the _DYNAMIC entries of an ELF file, you need to be prepared to actually follow and keep up with ELF handling rules. Deleting DT_HASH feels no different than, say, changing the format of the structure pointed to by DT_DEBUG, which happened just last year (https://sourceware.org/bugzilla/show_bug.cgi?id=15971 https://sourceware.org/bugzilla/show_bug.cgi?id=15971, https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=a93d9e03a31ec14405cb3a09aa95413b67067380 https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=a93d9e03...). Which, you know, breaks debuggers--but no one's running around saying "oh no glibc's ABI story is complete and utter trash!" because of that change (I daresay most of the people commenting on this issue aren't even aware that it happened).

rwmj 4y ago

> communication and co-ordination problems Which only exist in this case because the software isn't open source. This would have been spotted years ago in open source.

Spivak 4y ago
Unless there’s bots out there scanning public code repos for esoteric stuff like this I kinda doubt it. If you mean it would have gotten caught by packagers then yeah but that presumes a world where `apt install eac` makes any sense.
- rwmj 4y ago
  We do actually have a way to rebuild Fedora with particular changes (eg. when we change the baseline x86-64 version). I guess other distros can do that too. Of course it goes almost without saying that EAC would make about as much sense as an open source project as it does as a closed source project, which is to say none whatsoever because it's conceptually nonsense :-)
Narishma 4y ago
An open source anti-cheat system doesn't make much sense.
- akira2501 4y ago
  Neither does a closed source one, it is running on _my_ computer after all. Cynically.. keeping it closed just allows you to call it "anti-cheat" with a straight face, rather than what it actually is.. "mildly successful cheat mitigation and frustration techniques." Which is obvious once you notice there is an active "anti-anti-cheat" marketplace.

jcranmer 4y ago

That's a poor argument because, even going strictly by the specification, DT_HASH isn't authoritative--the symbol table is provided by DT_SYMTAB. Personally, I feel that by the time you're messing with the _DYNAMIC entries of an ELF file, you need to be prepared to actually follow and keep up with ELF handling rules. Deleting DT_HASH feels no different than, say, changing the format of the structure pointed to by DT_DEBUG, which happened just last year (https://sourceware.org/bugzilla/show_bug.cgi?id=15971 https://sourceware.org/bugzilla/show_bug.cgi?id=15971, https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=a93d9e03a31ec14405cb3a09aa95413b67067380 https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=a93d9e03...). Which, you know, breaks debuggers--but no one's running around saying "oh no glibc's ABI story is complete and utter trash!" because of that change (I daresay most of the people commenting on this issue aren't even aware that it happened).