> Description: The cargo release build does not strip symbols, so they will be included in the final binary. (..) Impact: Since the code is open source, there is not much information to be gained, but removing these symbols might make reverse engineering of the binary harder. What a ridiculous finding. I can try to steelman the argument. Sure, maybe "reverse engineering of the binary" is useless most of the time for…
That is what "low" means as a vulnerability severity! "Low" means "you totally don't need to do anything about this". The reported property does make the attacker's job slightly harder, after all, since they need to go and work out where the symbols are rather than just having them right there in front of them.
The problem with the report isn’t just that it’s minor. The problem is that it’s directionally wrong. If the change makes life even slightly harder for attackers, then it makes life harder to exactly the same extent for legitimate users trying to debug their programs. The fact that debuginfo is widely distributed demonstrates that distros prioritize the benefits of debuggability over the benefits of obscurity, and there’s no reason that weighting should be different in the small versus in the large. So, if security and debuggability were the only concerns, debuggability should win and distro binaries should never be stripped. It just so happens that there is an unrelated concern, disk space, that justifies stripping them anyway, but that doesn’t justify characterizing the lack of stripping as a security flaw, not even an incredibly minor one.