Ralph,
Comments below.
Length-checks are directly related to security, because they protect
against buffer-overruns which are often directly exploited by attackers.
It is much harder to see how reliance on wrap-around could contribute to
the security of an application.
The original impetus for this came from a check in a sprint() function
from Plan 9. Because of the API, there was no way to test if the len
was out of bounds, but the developers wanted to make sure they weren't
wrapping the stack on some architectures that have their stacks in high
memory.
It seems like a reasonable test to make, the code used to work, and they
got burned on the silent change in behavior.
But it is hard to see what reason you have for picking on this
particular feature of this particular compiler.
This may not have been the poster child issue to go after, but we were
responding to the report.
What features of which compilers do you think we should be reporting on?
Yes, you have dramatically improved the wording from previous
versions. However, you still say:
"avoid using compiler implementations that perform the offending
optimization"
I agree this is worded badly, we'll correct this.
I must admit, given the problems that have been identified with the
advisory (how many versions has it been through?),
we've only revised it once so far, but we'll change it as many times as
we need to.
I would be far
happier if you subjected it to independent third-party expert review,
we are an independent third party. who else would we ask?
and withdrew the advisory until that is completed in a satisfactory
manner (rather than repeatedly incrementally tweaks).
withdrawing vulnerability notes (this is not an advisory that is emailed
out) is not as good a solution as you might think, as this usually draws
more attention to the vulnerability note than just about anything else
you can do.
rCs
