Re:CVE-2021-27135: xterm flaw may allow remote code executio...
by toast0 on Saturday March 20, 2021 @03:23PM
(#26525417)
You would need a dedicated team (starting with a dedicated person), willing to rewrite so much existing C code in a less unsafe language.
And they would need to be willing to spend a lot of time on making sure the new implementation was just the same as the old version, and can compile and run on all the same platforms and what not.
I don't think it would be easy to get funding for that, so your dedicated team is going to have to be independently wealthy, or not spend a lot of time on it.
If rust is your selected less unsafe language, as I understand it, it doesn't have as full platform support as gcc or clang, so that's a challenge (which gets easier over time as non-x86 and non-arm die out). Other languages have other challenges, but I don't think there's a clear winner here, which is part of the issue.
The new utilities will be judged on functionality (should be exactly the same), and cpu/memory/binary size which should all be the same or less. It's hard to guarantee that.
Not a whole lot of people want to develop with that framework. You don't see a whole lot of Show HN: I made a replica of X, with no changes to functionality. Everyone always wants to change things.
Anyway: be the change you want to see and all that. Pick a small package, reimplement it in rust (or whatever), and see if you can get it in distributions or convince the upstream to switch to your implementation. Then tell us how it went, and repeat with another package, etc.
And they would need to be willing to spend a lot of time on making sure the new implementation was just the same as the old version, and can compile and run on all the same platforms and what not.
I don't think it would be easy to get funding for that, so your dedicated team is going to have to be independently wealthy, or not spend a lot of time on it.
If rust is your selected less unsafe language, as I understand it, it doesn't have as full platform support as gcc or clang, so that's a challenge (which gets easier over time as non-x86 and non-arm die out). Other languages have other challenges, but I don't think there's a clear winner here, which is part of the issue.
The new utilities will be judged on functionality (should be exactly the same), and cpu/memory/binary size which should all be the same or less. It's hard to guarantee that.
Not a whole lot of people want to develop with that framework. You don't see a whole lot of Show HN: I made a replica of X, with no changes to functionality. Everyone always wants to change things.
Anyway: be the change you want to see and all that. Pick a small package, reimplement it in rust (or whatever), and see if you can get it in distributions or convince the upstream to switch to your implementation. Then tell us how it went, and repeat with another package, etc.