Yeah, but why is this a security issue?
It seems extremely unlikely that any actual deployed Rust code exhibits this bug since the default implementation of type_id is the only reasonable one, and so there’s no reason to override it.
Hence, it’s not exploitable at all and thus not a security issue.
You can “exploit” it by writing code with this issue, but then you might as well just write code with the exploit payload itself.
@bill_myers I think the main difference here is that safe Rust promises soundness, while other languages do not make any promises in this regard. That is, a lot of Rust code is expected to be relying on these “soundness promises”, while, for example, C++ code is not (e.g. it is expected to be more paranoid).
We can force people to write comments, but we can’t force the comments to be correct.
I do think we should enforce a comment requirement with tidy on all unsafe fn and unsafe { ... } both in the standard library as well as in the compiler. We can’t force the comments to be correct, but we can reduce chances with reviews.
Is there a clippy lint for that, maybe?
Is there a clippy lint for that, maybe?
I don't see one, but that would be a start.
We can’t force the comments to be correct, but we can reduce chances with reviews.
This API did not appear to touch any unsafe code though, so I am not sure how comments in unsafe blocks / unsafe functions would have helped prevent this particular issue. Those reviewing the API would have had to go through the whole module looking for unsafe blocks to figure out whether this API is safe.
A comment on this safe API stating why it is safe given the presence of some unsafe code somewhere else would have been helpful, but a lint for that would need to require safety comments on all safe APIs of any module requiring unsafe.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.