2 ms·

Python's pathlib wouldn't help you here, it can encode the necessary bits. Especially with configparser - it's 20 year old configuration reader. Java's story is

by shakna 1y ago

Python's pathlib wouldn't help you here, it can encode the necessary bits. Especially with configparser - it's 20 year old configuration reader. Java's story is worse. What part of this would be prevented by another language? You'd need to switch your data format to something like json, toml, etc. to prevent this from the outset. But JSON was first standardised 25 years ago, and AJAX wasn't invented when this was written. JSON was a fledgling and not widely used yet. I guess we had netrc - but that's not standardised and everyone implements it differently. Same story for INI. There was XML - at a time when it was full of RCEs, and everyone was acknowledging that its parser would be 90% of your program. Would you have joined the people disparaging json at the time as reinventing xml? This vulnerability is the fault of data formats not being common enough to be widely invented yet.

gpm 1y ago
> What part of this would be prevented by another language? > You'd need to switch your data format to something like json, toml, etc. The part where if you wrote this in any modern languages ecosystem you would do this. Yes, modern languages and their ecosystems likely did not exist back then. The lesson going forwards is that we shouldn't keep doing new things like we did back then. Saying smithing metal by using a pair of hand driven bellows is inefficient isn't to say the blacksmiths ages ago who had no better option were doing something wrong.
- shakna 1y ago
  Ok... So you're not saying C is a problem. You're saying every few years, we should torch our code and rewrite from scratch, using new tools. ... Enjoy your collapsing codebase. I'll stick with what works, thanks.
  - gpm 1y ago
    What an absurdly bad faith interpretation. I never said anything to even suggest abandoning old code. As demonstrated by vulnerabilities like the one in the article, C (and its ecosystem) doesn't "work", so I'm glad to hear that you won't be sticking with that for new projects going forwards.
    - shakna 1y ago
      ... Except you have already admitted that it has bupkus to do with C. You said it was a lack of "modern tooling". Modern C toolchains vastly outstrip most, for modernity. C23 is three years old. But no. I wont be breaking compatibility for everyone, just to chase a shiny nickel. That is burning the barnyard for fear of geese.
      - Dylan16807 1y ago
        This is a total strawman. Blaming old tools for a problem is not a cry to never ever use old tools. They want better choices going forward. You made up this constant rewrite crusade so you could have something to be mad at. Also a few compiler updates don't make an ecosystem modern.
        shakna 1y ago
        It's not a straw man. We were talking about git using a particular thing. They said particular thing was a dumb idea and git should change it. That's a rewrite.
        Dylan16807 1y ago
        They did not say git should replace this parser, though you can argue they implied it. They did not say git should change language. They did not say "every few years, we should torch our code and rewrite from scratch, using new tools." That's a fever dream that barely resembles their words in a way that makes you super right and them super unreasonable. A key phrase they said was "we shouldn't keep doing new things like we did back then". New things. That's not saying to rewrite anything.

by shakna 1y ago

gpm 1y ago

> What part of this would be prevented by another language? > You'd need to switch your data format to something like json, toml, etc. The part where if you wrote this in any modern languages ecosystem you would do this. Yes, modern languages and their ecosystems likely did not exist back then. The lesson going forwards is that we shouldn't keep doing new things like we did back then. Saying smithing metal by using a pair of hand driven bellows is inefficient isn't to say the blacksmiths ages ago who had no better option were doing something wrong.

shakna 1y ago
Ok... So you're not saying C is a problem. You're saying every few years, we should torch our code and rewrite from scratch, using new tools. ... Enjoy your collapsing codebase. I'll stick with what works, thanks.
- gpm 1y ago
  What an absurdly bad faith interpretation. I never said anything to even suggest abandoning old code. As demonstrated by vulnerabilities like the one in the article, C (and its ecosystem) doesn't "work", so I'm glad to hear that you won't be sticking with that for new projects going forwards.
  - shakna 1y ago
    ... Except you have already admitted that it has bupkus to do with C. You said it was a lack of "modern tooling". Modern C toolchains vastly outstrip most, for modernity. C23 is three years old. But no. I wont be breaking compatibility for everyone, just to chase a shiny nickel. That is burning the barnyard for fear of geese.
    - Dylan16807 1y ago
      This is a total strawman. Blaming old tools for a problem is not a cry to never ever use old tools. They want better choices going forward. You made up this constant rewrite crusade so you could have something to be mad at. Also a few compiler updates don't make an ecosystem modern.
      - shakna 1y ago
        It's not a straw man. We were talking about git using a particular thing. They said particular thing was a dumb idea and git should change it. That's a rewrite.
        Dylan16807 1y ago
        They did not say git should replace this parser, though you can argue they implied it. They did not say git should change language. They did not say "every few years, we should torch our code and rewrite from scratch, using new tools." That's a fever dream that barely resembles their words in a way that makes you super right and them super unreasonable. A key phrase they said was "we shouldn't keep doing new things like we did back then". New things. That's not saying to rewrite anything.