[NewsaHackO]

To me, saying that there is a bug in the lean runtime means lean-zip has a bug is like saying a bug in JRE means a Java app that uses the runtime has a bug, even though the Java app code itself does have a bug. It seems like the author is being intentionally misleading about his findings.

[brabel]

No. It would be like finding a memory unsafe caused bug in a Java application that is due to a bug in the JRE. That would absolutely warrant a title like “I found memory unsafe bug in my Java code” when everyone expects Java code to be memory safe, which is analogous to the article in question.

[NewsaHackO]

I do not think you are completely grasping what you are talking about (what is a 'memory unsafe bug'?). Even in the example you give, that title would be literally wrong, as there will be no bug in your Java code; there would be a bug in the execution due to a deviation in the runtime executing your program.

[aidenn0]

I think it's ambiguous and fair game for the idea of answering the question "if we write programs in this manner, will there be exploitable bugs?

[NewsaHackO]

>I think it's ambiguous and fair game for the idea of answering the question "if we write programs in this manner, will there be exploitable bugs?

You're strawmanning the original authors' argument. The creator of lean-zip said that they proved there are no implementation bugs in the lean-zip program. A bug in lean-runtime does not contradict this claim.

[aidenn0]

I'm saying that both the headline of TFA and the statement of the lean-zip creator can be correct.

If they e.g. specially crafted a .zip file that caused it to flip bits via row-hammer like memory accesses, the same would be true.