4 ms·

I'll gesture at it. It's not an open source tool, so I can't point at the code (and in fact I just checked and I don't have perms to see the Jira ticket I cause

I'll gesture at it. It's not an open source tool, so I can't point at the code (and in fact I just checked and I don't have perms to see the Jira ticket I caused to be raised!), and I am wary of describing security bugs in company-internal code. But in general terms it was a service that attempted to check whether a request was allowed, and it ignored errors from that check. (I just searched history for a bit to find the error in the absence of any actual details about it, but it was a while ago and I failed.) Sorry this is not a very satisfying answer.

deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
foldr 2y ago
Any language where errors are returned as values will allow you to ignore errors (if you don’t have proper linting set up, and unless it has something fancy like linear types). I’ve even seen a similar error in Haskell code, where someone called an isLoggedIn function inside a monad with the expectation that it would short-circuit evaluation, whereas in fact it just retuned a Bool.
- thinkharderdev 2y ago
  Very true, but I do think there is an issue in the margin about how easy it is to ignore errors. For example, in Java you might have something like ``` void checkPermissions() throws AuthException ``` so you have to actively ignore errors by catching the exception. Likewise in Rust you can do ``` fn check_permissions() -> Result<(),AuthError> ``` In that case you can just use the `?` operator to short-circuit (and clippy will warn you if your forget to do that). In other words, while language design can't fully prevent you from ignoring precondition checks, it can make it harder to forget or even force you to actively ignore precondition failures
  - foldr 2y ago
    Go linters do a pretty good job of spotting where error return values have been ignored, so I'd suggest that the kind of bug the OP is referring to is pretty unlikely to happen in a Go project that's properly configured.
    - Smaug123 2y ago
      Sure - my question is "why do you need to set up the third party linters when they're so critical to the correctness of your program" really. It's the general "yeah we'll give you these footguns which are the first thing every developer will learn about during their first incident; good luck, and I hope you know you need to do things this way!" attitude I object to.
      - deleted 2y ago
        [deleted]
      - randomdata 2y ago
        > my question is "why do you need to set up the third party linters when they're so critical to the correctness of your program" really. No doubt the same reason it is also critical in Haskell (see comment about isLoggedIn function): Developers not knowing what they are doing. If you work within the idioms and generally accepted programming practices this isn't a problem. It only becomes a problem when you get a developer who wants to "go their own way" without understanding why the norms exist. The linter is a crutch to support their "bad habits".
      - foldr 2y ago
        There’s no simple solution when it comes to ignoring errors. Some errors should be ignored and some shouldn’t. So your only lines of defense are linting heuristics and tests. I would agree that languages which handle errors via exceptions have an advantage here, as they make not ignoring errors the default behavior. But even then, it’s obviously still possible to indicate error conditions of various kinds via return values, in which case they can still be ignored thoughtlessly. (And you also have all the bugs caused by unhandled exceptions to deal with.)
goodlinks 2y ago
Isnt this the same as any language though.. check if have permission then ignore the result seems like something that the language cannot protect you from?
- Smaug123 2y ago
  I mean, Golang has an unused variables compile error, which presumably is trying to do precisely this. It's like they got so close to forcing the user to acknowledge the possibility of errors, and then stopped just before the end!

deleted 2y ago

[deleted]

deleted 2y ago

[deleted]

foldr 2y ago

Any language where errors are returned as values will allow you to ignore errors (if you don’t have proper linting set up, and unless it has something fancy like linear types). I’ve even seen a similar error in Haskell code, where someone called an isLoggedIn function inside a monad with the expectation that it would short-circuit evaluation, whereas in fact it just retuned a Bool.

thinkharderdev 2y ago
Very true, but I do think there is an issue in the margin about how easy it is to ignore errors. For example, in Java you might have something like ``` void checkPermissions() throws AuthException ``` so you have to actively ignore errors by catching the exception. Likewise in Rust you can do ``` fn check_permissions() -> Result<(),AuthError> ``` In that case you can just use the `?` operator to short-circuit (and clippy will warn you if your forget to do that). In other words, while language design can't fully prevent you from ignoring precondition checks, it can make it harder to forget or even force you to actively ignore precondition failures
- foldr 2y ago
  Go linters do a pretty good job of spotting where error return values have been ignored, so I'd suggest that the kind of bug the OP is referring to is pretty unlikely to happen in a Go project that's properly configured.
  - Smaug123 2y ago
    Sure - my question is "why do you need to set up the third party linters when they're so critical to the correctness of your program" really. It's the general "yeah we'll give you these footguns which are the first thing every developer will learn about during their first incident; good luck, and I hope you know you need to do things this way!" attitude I object to.
    - deleted 2y ago
      [deleted]
    - randomdata 2y ago
      > my question is "why do you need to set up the third party linters when they're so critical to the correctness of your program" really. No doubt the same reason it is also critical in Haskell (see comment about isLoggedIn function): Developers not knowing what they are doing. If you work within the idioms and generally accepted programming practices this isn't a problem. It only becomes a problem when you get a developer who wants to "go their own way" without understanding why the norms exist. The linter is a crutch to support their "bad habits".
    - foldr 2y ago
      There’s no simple solution when it comes to ignoring errors. Some errors should be ignored and some shouldn’t. So your only lines of defense are linting heuristics and tests. I would agree that languages which handle errors via exceptions have an advantage here, as they make not ignoring errors the default behavior. But even then, it’s obviously still possible to indicate error conditions of various kinds via return values, in which case they can still be ignored thoughtlessly. (And you also have all the bugs caused by unhandled exceptions to deal with.)

goodlinks 2y ago

Isnt this the same as any language though.. check if have permission then ignore the result seems like something that the language cannot protect you from?

Smaug123 2y ago
I mean, Golang has an unused variables compile error, which presumably is trying to do precisely this. It's like they got so close to forcing the user to acknowledge the possibility of errors, and then stopped just before the end!