3 ms·

I’ve fixed so many burning hot potato security bugs in my life and your data race example has never come up, not even once. Logic errors not preventable by any

I’ve fixed so many burning hot potato security bugs in my life and your data race example has never come up, not even once. Logic errors not preventable by any language or type system (like making sure you enforce policy in a setuid process) are far more likely than that.

AnthonyMouse 1y ago
It depends what domain you're operating in. If you're only ever patching CVEs it shows up less, because if you've implemented that data race where the first and last lines are separate SQL queries, you're not going to get a CVE against the database software for it. Then it only even gets discovered if someone actually starts exploiting it or the race is so severe that it happens under normal use and then at the end of the quarter the accountants start asking why the numbers don't add up.
- pizlonator 1y ago
  No memory safe language will protect you from getting your SQL queries wrong. Races in a database are not “data races” in the programming language sense, unless we’re debating. The hat query language to use
  - AnthonyMouse 1y ago
    > No memory safe language will protect you from getting your SQL queries wrong. That's kind of the point. > Races in a database are not “data races” in the programming language sense Only in the sense that in a sufficiently large bureaucracy you get to power up the Somebody Else's Problem Field and blame the DBA for it. But that doesn't get you the missing money back.
    - pizlonator 1y ago
      This whole conversation is about memory safety of programming languages, not security vulns that no language can prevent
      - AnthonyMouse 1y ago
        Which is, again, the point. People have a new hammer but not everything is a nail. And lots of programming languages provide tools to address data races. SQL has transactions, several languages have compare-and-swap primitives, etc.

3 ms·

I’ve fixed so many burning hot potato security bugs in my life and your data race example has never come up, not even once. Logic errors not preventable by any

by pizlonator 1y ago

AnthonyMouse 1y ago
It depends what domain you're operating in. If you're only ever patching CVEs it shows up less, because if you've implemented that data race where the first and last lines are separate SQL queries, you're not going to get a CVE against the database software for it. Then it only even gets discovered if someone actually starts exploiting it or the race is so severe that it happens under normal use and then at the end of the quarter the accountants start asking why the numbers don't add up.
- pizlonator 1y ago
  No memory safe language will protect you from getting your SQL queries wrong. Races in a database are not “data races” in the programming language sense, unless we’re debating. The hat query language to use
  - AnthonyMouse 1y ago
    > No memory safe language will protect you from getting your SQL queries wrong. That's kind of the point. > Races in a database are not “data races” in the programming language sense Only in the sense that in a sufficiently large bureaucracy you get to power up the Somebody Else's Problem Field and blame the DBA for it. But that doesn't get you the missing money back.
    - pizlonator 1y ago
      This whole conversation is about memory safety of programming languages, not security vulns that no language can prevent
      - AnthonyMouse 1y ago
        Which is, again, the point. People have a new hammer but not everything is a nail. And lots of programming languages provide tools to address data races. SQL has transactions, several languages have compare-and-swap primitives, etc.