4 ms·

Which is exactly why we need to use safe languages. People can't even prevent vulnerabilities in the code they are scrutinizing, much less the other 90% they ar

Which is exactly why we need to use safe languages. People can't even prevent vulnerabilities in the code they are scrutinizing, much less the other 90% they aren't. (Beating a dead horse, I know, and not blaming the devs because this utility has been around forever, but regardless)

perardi 5y ago
It’s a horse worth beating, or at least kicking, because it’s a tough set of incentives. Even if you have functionally unlimited money like Apple, it’s tough to prioritize rewriting a somewhat obscure piece of the OS solely to prevent security issues. Because if you have a team that’s capable of fully reimplementing this component, and getting it through a QA process to make sure it doesn’t break another component of the OS…well damn, that’s a team you probably want on a higher-profile project, and not doing cleanup, right?
- brundolf 5y ago
  Yeah, rewriting is hard and involves lots of complex cost tradeoffs. But at least when writing new software, with today's options, I think it's much harder to justify starting out with an unsafe language.
  - perardi 5y ago
    Well, web apps. But that’s me being argumentative. 100% agree for “system software” like this.
  - pjmlp 5y ago
    Today's options? The options were always there since around 1958, then about 15 years later, a group of folks doing their tiny OS decided to ignore them when creating their fun little language, because it was more fun to do their own thing. The problem is that this tiny OS and accompaning language grew to be everywhere thanks to its license, so now we are in this mess. But options? They have always been there for those that actually care.
  - newaccount74 5y ago
    The hard part is interoperability. Apple is writing lots of things in Swift today, but low level libraries that are used in many places are hard to do in Swift. Interoperability with C often requires very difficult casts, and if you do them incorrectly you'll have the same kinds of bugs as in C.
- glhaynes 5y ago
  And, on top of that, how much confidence do you have that your brand new code doesn’t introduce more security issues than the ancient “battle-tested” code?
jjtheblunt 5y ago
or use safe libraries, strncpy rather than strcpy, and so on?
- saagarjha 5y ago
  strncpy is not a really meant to be a “safe” function.
  - tialaramex 5y ago
    In a sense strncpy() is exactly the sort of unsafe nonsense that got C into trouble. C's strings are zero byte terminated, but the strings strncpy() is intended to target are not, they're file names in a fixed length buffer. So, it's fine to fill the entire buffer with text and no terminator, or to write a single byte of text, and fill the rest with zero bytes. If that's the exact problem you have, strncpy() is the exact feature you wanted. Otherwise it isn't. If you aren't aware of why Unix wanted this feature it's a very strange thing to find in C's small standard library.

perardi 5y ago

It’s a horse worth beating, or at least kicking, because it’s a tough set of incentives. Even if you have functionally unlimited money like Apple, it’s tough to prioritize rewriting a somewhat obscure piece of the OS solely to prevent security issues. Because if you have a team that’s capable of fully reimplementing this component, and getting it through a QA process to make sure it doesn’t break another component of the OS…well damn, that’s a team you probably want on a higher-profile project, and not doing cleanup, right?

brundolf 5y ago
Yeah, rewriting is hard and involves lots of complex cost tradeoffs. But at least when writing new software, with today's options, I think it's much harder to justify starting out with an unsafe language.
- perardi 5y ago
  Well, web apps. But that’s me being argumentative. 100% agree for “system software” like this.
- pjmlp 5y ago
  Today's options? The options were always there since around 1958, then about 15 years later, a group of folks doing their tiny OS decided to ignore them when creating their fun little language, because it was more fun to do their own thing. The problem is that this tiny OS and accompaning language grew to be everywhere thanks to its license, so now we are in this mess. But options? They have always been there for those that actually care.
- newaccount74 5y ago
  The hard part is interoperability. Apple is writing lots of things in Swift today, but low level libraries that are used in many places are hard to do in Swift. Interoperability with C often requires very difficult casts, and if you do them incorrectly you'll have the same kinds of bugs as in C.
glhaynes 5y ago
And, on top of that, how much confidence do you have that your brand new code doesn’t introduce more security issues than the ancient “battle-tested” code?

jjtheblunt 5y ago

or use safe libraries, strncpy rather than strcpy, and so on?

saagarjha 5y ago
strncpy is not a really meant to be a “safe” function.
- tialaramex 5y ago
  In a sense strncpy() is exactly the sort of unsafe nonsense that got C into trouble. C's strings are zero byte terminated, but the strings strncpy() is intended to target are not, they're file names in a fixed length buffer. So, it's fine to fill the entire buffer with text and no terminator, or to write a single byte of text, and fill the rest with zero bytes. If that's the exact problem you have, strncpy() is the exact feature you wanted. Otherwise it isn't. If you aren't aware of why Unix wanted this feature it's a very strange thing to find in C's small standard library.