To be fair, it’s because you have a big part in writing history and you cut the single most important person out of it because evaluating their work was a little too hard for you (their paper wasn’t officially published and their work wasn’t packaged for immediate reproduction).

From afar, it just appears you should accept responsibility for your mistake and try to correct it, but you just keep doubling down and trying to blame the other person—because they made it easier for you to make a mistake.

Hu? We give credit in our papers for an idea to restrict control flow. After RAP was published we tried several times to evaluate it, likely for 20+ hours without success. The author is unwilling to help and keeps yelling at us, yet it is our mistake? Tell me where I'm wrong :)

Now, if you emailed him I’m perfectly willing to admit I’m wrong. But he seems to publicly offer help all the time and nobody EVER refutes his claims that he never got any emails asking for help. Is this any different?

You desperately need to answer this as well.

You talk about how it was difficult to evaluate his work, but isn’t it your job to evaluate all the important, practical implementations available? How did you feel happy publishing an incomplete paper? Was it because LLVM was clearly better? How did you know?

Does LLVM even have any sort of efficient shadow stack mechanism for x86/x64? As far as I can remember it’s decently slow and not as secure as PaxTeam’s return address protections. Maybe PaxTeam’s implementation also suffers from mild speed issues in this area.

clang.llvm.org/docs/ShadowCa… clang.llvm.org/docs/SafeStac…

I’m aware of the documents. You didn’t answer my questions.

"but isn’t it your job to evaluate all the important, practical implementations available?" No. If we publish new work we compare against available implementations of the state of the art. RAP is neither the state of the art nor available.