[Smaug123]

> I'd say Go largely lacks the footguns some other languages have

With the glaring exception of "I forgot to check the error code", which you need a linter (e.g. as provided by golangci-lint) for. It's critically important for security that you know whether the function you just called gave you a meaningful result! Most other languages either have sum types or exceptions.

[tptacek]

No it's not. This is what I meant, cross-thread, when I suggested being wary of arguments trying to draw significant distinctions between memory-safe-language X and memory-safe-language Y. Error checking idioms and affordances have profound implications for correctness and for how you build and test code. Programmers have strong preferences. But those implications have only incidental connections to security, if any. Nevertheless "security" is a good claim to throw into a "my language is better" argument.

[Smaug123]

I don't even use Golang, I maybe read two Golang repos a year, I find these errors in almost every repo I look at (probably because of the selection effect: I only look at the code for tools I find bugs in). One of them I remember was a critical vulnerability of exactly this form, so :shrug: Perhaps I'm just grotesquely unlucky in the Golang projects I see, but that makes maybe 10% of the Golang error-handling bugs I've found to be security bugs.

[tptacek]

Sounds memorable. Say more about this critical vulnerability?

[Smaug123]

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.

[foldr]

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]

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

[goodlinks]

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]

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!

[jerf]

Mmm, that's fair. I tend to forget about it because it's not something I personally struggle with but that doesn't mean it's not a problem.

I'd still rate it well below a string eval or a default shell interface that takes strings and treats them like shell does. You assert down below that you've seen this lead to a critical vulnerability and I believe you, but in general what happens if you forget to check errors is that sooner or later you get a panic or something else that goes so far off the rails that your program crashes, not that you get privs you shouldn't. As I say in another comment, any sort of confusing bit of code in any language could be the linchpin of some specific security vulnerability, but there are still capabilities that lead to more security issues than some other capabilities. Compared to what I've seen in languages like Perl this is still only "medium-grade" at best.

And I'm not trying to "defend" Go, which is part of why I gave the laundry list of issues it still has. It's just a matter of perspective; even missing the odd error check here or there is just not the same caliber problem as an environment where people casually blast user-sourced input out to shell because the language makes it easier than doing it right.

(Independent of language I consider code that looks like

    operation = determineOperation()
    if !canIDoOperation(operation) {
        // handle failures
    }
    doOperation(operation)

architecturally broken anyhow. It seems natural code to write, but this is a form of default allow. If you forget to check the operation in one place, or even perhaps forget to write a return in the if clause, the operation proceeds anyhow. You need to write some structure where operations can't be reached without a positive affirmation that it is allowed. I'd bet the code that was broken due to failing to check an error amounted to this in the end. (Edit: Oh, I see you did say that.) And, like I said, this is independent of Go; other than the capabilities-based languages this code can be written in pretty much anything.)

[tptacek]

I think it's a reasonable observation but it isn't a fair comparative security criteria. The subtext behind error checking critiques is that languages with idiomatic sum type returns avoid authz vulnerabilities, in the same way that memory-safety in Go eliminates UAF vulnerabilities. But authz vulnerabilities are endemic to the mainstream sum type languages, too; they're much more complicated as a bug class than just "am I forced to check return codes before using return values".

Sum types are one of the few things I miss when switching from other languages back to Go. I like them a lot. But I think they're wildly overstated as a security feature. Sum type languages have external tooling projects to spot authz vulnerabilities!

[randomdata]

> "I forgot to check the error code"

How is it that people "forget to check errors" but not other types, even though they are all just 1s and 0s? Or, to put it another way, why do programmers forget how to program as soon as they see the word "error"?

It seems to be a real phenomenon, but I can't make sense of how it can happen. It is not some subtle thing like misspelling a word in a string constant. You are leaving out entire functionality from your application. It is almost on the order of forgetting to add the main function.

[vacuity]

I would think it's a mix of not being sure exactly what to do on error and not wanting to undergo the effort of writing error logic. You have to switch from "basic skeletal structure of the program" to "cover all bases", which isn't simple. So it's easy to have no or rudimentary error handling, and by the time you want to change it, it's hard to change. Like, "malloc can fail, but it would be a lot easier right now if I assume it won't".

[arccy]

as if DoS by exception is any better...

[Smaug123]

Depends on the application! There's a reason we have the concept of "failing closed" vs "failing open": sometimes (very often, in fact) it's correct to shut down under attack, rather than to open up under attack.

[tptacek]

The subtext of that comment cuts against the argument you're trying to make here: a panic following a missed error check is always fail-closed, but exception recovery is not.