10 ms·

GoKart: A static analysis tool for securing Go code

• the-smug-one 5y ago
  Go has some nice tooling which is quite easy to use w.r.t. static analysis. I started writing a nil pointer analysis tool which was going to take advantage of and provide some more advanced information*. I "unfortunately" had a lot more fun stuff to do during my vacation, but it was very easy to get started with! So kudos to the Go team for making this kind of stuff possible for a 1-man team. * Just a forward-style abstract interpretation living on-top of Go's type system as an additional layer so you get explanations for why the tool believes that a nil-pointer dereference may occur, etc.
  • SquishyPanda23 5y ago
    > I started writing a nil pointer It still boggles my mind that Go decided to force programmers to worry about nil pointers.
    • dabfiend19 5y ago
      as opposed to?
      • streblo 5y ago
        Optionals would have been a way to solve this problem
        • logical42 5y ago
          You know what's fun? Getting a nil where you are supposed to have an Optional.
          • joshdev 5y ago
            Somebody has used Scala
            • still_grokking 5y ago
              More likely a Java lib form Scala than Scala as such. In "pure" Scala (not in the FP sense, but just without mixing with Java) something like that is almost impossible.
              • marwis 5y ago
                Unless something drastically changed in Scala 3, there is nothing to protect you from null in Scala. In fact even Java is effectively safer thanks to all the null checking done by IntelliJ
                • still_grokking 5y ago
                  Null is basically non-existent in idiomatic Scala. So technically you're right but besides calling Java libs there is only an infinitesimal small chance to get NPEs form Scala code. (Scala's NPE is the MatchException ;-)). For Scala 3 there are improvements. It's "null safe" as long as you opt-in (modulo Java libs, and of course doing stupid things like casting a null to some other type). https://docs.scala-lang.org/scala3/reference/other-new-features/explicit-nulls.html https://docs.scala-lang.org/scala3/reference/other-new-featu...
                  • joshdev 5y ago
                    Idiomatic scala yes, but while on boarding engineers hit many cases, where they ended up returning null in places they shouldn’t.
                    • still_grokking 5y ago
                      So you actually complaining about people who don't know what they're doing? How is this related to Scala? When you have people without clue on the team no language will safe you. You can also crash Haskell programs by throwing exceptions or just using List.head…
          • mattnewton 5y ago
            Afaik this is impossible in swift and kotlin, only optional values can contain nill.
            • tbarbugli 5y ago
              Try Core Data with Swift and you will see that happening. Lazy objects (vaults) are mapped from objc into Swift and will happily crash on something like a = b where both are not optional.
              • mattnewton 5y ago
                This is happening in objc code or in the swift part? I'm not terribly surprised though, my one experience with core data was miserable once we strayed even a little from the happy path and I ended up rolling my own since we didn't need full functionality anyways. And this was for an internal app, at Apple ┐( ∵ )┌
            • logical42 5y ago
              It's possible in Java.
              • mattnewton 5y ago
                Right, because the language has the "million dollar mistake" of nullable references by default, which you cannot change without breaking code. And the original comment was bemoaning that Go choose to to have nullable references by default too.
          • rowanG077 5y ago
            so... Just make that impossible. It's not like this is unprecedented at this point. It's a standard feature even C++ of all languages supports.
        • magicalhippo 5y ago
          So you get an Optional which haven't been set instead of a nil pointer. What's better about that?
          • SquishyPanda23 5y ago
            The type system knows about it and you're forced to check it
            • magicalhippo 5y ago
              Right, but my point is, the code which would raise an error because the pointer is nil now raises an error because the Optional is not set. Is there really that much of a difference between those cases? I agree though that in an interface, Optional conveys a more explicit meaning than something pointer-like, which is always a good thing.
              • SquishyPanda23 5y ago
                In practice it does make a big difference because if the type system knows about it then it can enforce handling of the exception. (Or more generally, it can just force you to pattern match on the optional time and make sure you handle the empty case.) Go programs crash at runtime. In general, program failures and bugs should surface as soon as possible. Ideally no later than compile time. Instead, Go makes you wait until the app is running. For an app that has a lot of configuration options, for example, there can be a latent bug that crashes the binary for some options. And that bug may not be detected for months because nobody was using that combination of config options. The only real defense of this is to pepper your code with a bunch of nil checks. But these nil checks are also hard to test, so Go devs just learn to ignore missing code coverage. In fact, your code coverage metrics look better if you don't check for nil. I'm sure at some point Go or a library will offer a version of optional types that is well-adopted. But my point is that by the time Go was designed, null references were already widely considered a bad idea and the source of a huge class of computer bugs. Go still deliberately designed them into the type system.
              • drvd 5y ago
      • SquishyPanda23 5y ago
        Most modern languages have solved the problem. There are a variety of ways to do it.
        • pkaye 5y ago
          Can you list the variety of ways?
          • mattnewton 5y ago
            Usually it's forcing the programmer to handle the null case statically, by wrapping the underlying value in something like an optional type and defining the operations that access the underlying value. Think of swift's optional unwrapping in "if let" statements
          • SquishyPanda23 5y ago
            Basically if you need to manipulate pointers, use safe pointers and keep track of pointer ownership. This is how modern C++ and Rust work. If you don't need to manipulate pointers then nil really just represents a degenerate or optional value. For optional values these can be encoded any number of ways depending on the type system. One common pattern is an optional type. Another is to annotate the type to indicate that it might be null. The idea is that if a programmer doesn't check that an nullable or optional type is missing then the program should fail at compile time instead of crashing at runtime. Golang chose to crash programs at runtime. So for whatever reason, Go has decided that null pointer dereferences are not a big deal. But God help you if you try to comment out a variable use without assigning it to "_". Then the program fails to compile.
            • Zababa 5y ago
              > So for whatever reason, Go has decided that null pointer dereferences are not a big deal. But God help you if you try to comment out a variable use without assigning it to "_". Then the program fails to compile. I think that's a good explanation of why people are so frustrated with this. There are lots of features like go fmt, go vet, the compiler checking that you use all variables and all imports that can feel a bit restrictive. But for something like null pointers, there is nothing. It's incoherent.
      • still_grokking 5y ago
        As opposed to some modern type system feature that would catch such bugs at compile time rather than let them happen at runtime.
    • SPBS 5y ago
      It’s not as bad as Java’s NullPointerException because primitive types and compound primitive types are much more prevalent (which are guaranteed to never be nil).
    • izgzhen 5y ago
      Golang doesn’t have a proper generics support at its beginning. It is too late now.
      • masklinn 5y ago
        You don't even need generics to avoid nullable pointers, you can special-case it as they special-cased slices, maps, channels, etc… e.g. `*int` -> non-nullable pointer to int; `?int` -> nullable pointer to int, and a tiny bit of flow analysis in nil checks so e.g. `if foo != nil` implicitly creates a new non-nullable version of `foo` inside the block body.
    • tptacek 5y ago
      Then it boggles your mind that Go functions the way most popular languages work. You don't see so much dunking on Python, Java, Clojure, Ruby, &c, over this, even though these languages dominate the leaderboards. Which is fine, except that this is probably the second-most boring critique of Go, one virtually everyone has heard before, and it has little if anything to do with the story we're actually commenting on, despite having spawned a huge thread about option types. If GoKart had been my project, I'd be annoyed.
      • nyanpasu64 5y ago
        - MyPy doesn't have pervasive nullability, but distinguishes nullable and non-nullable types in the type system. A function declared to return int but randomly returns None has a bug in its type hints. - I dunk on Java for pervasive nullability too (though there are tools that add @Nullable xor @NonNull annotations used for analysis, possibly sound). But Go has over a decade more hindsight and should've known better. I haven't used the other languages.
        • deleted 5y ago
          [deleted]
        • hnlmorg 5y ago
          > [Python] distinguishes nullable and non-nullable types in the type system. A function declared to return int but randomly returns None has a bug in its type hints. Go distinguishes between the two too. You cannot pass nil as a value to int. In fact in Go you'd get a compiler warning[0] so you don't even need to rely on type hints and a properly set up CI/CD pipeline to catch said faults: The problem with Go is that pointers can be nullable[1] as well as interfaces[2] (interfaces, crudely speaking, being Go's solution to generics and inheritance. Crudely speaking. So interfaces get used a lot). There is some logic to them being nullable if you think about the code from a hardware perspective but given how opinionated the compiler and language is, I feel they could have done more to catch accidental nils to save the developer from having to consciously consider them each time. [0] https://play.golang.org/p/BADNnw08hoo https://play.golang.org/p/BADNnw08hoo [1] https://play.golang.org/p/b39tY1SDQtZ https://play.golang.org/p/b39tY1SDQtZ [2] https://play.golang.org/p/Fsjsa_-o7Qb https://play.golang.org/p/Fsjsa_-o7Qb
    • drvd 5y ago
      Programming in Go since 10 years and I do not have to worry about nil pointers. You seem to assume that the possibility of a pointer being nil is something that is complicated, a burden to the programmer and a source of runtime bugs. It's not. At least not in Go. At least not something you have to worry about in practice.
      • SquishyPanda23 5y ago
        I'm glad you've had a good experience, but yes it is a source of runtime bugs. One piece of code from a well established tech company would just crashloop if authentication failed. I've seen others just die if the RPC service couldn't make a connection. So in practice, yes I do have to spend my time tracking down nil pointer runtime bugs both from colleagues and also from other organizations.
      • conradludgate 5y ago
        In my experience I've not had too many issues because of it (due to good testing) but it definitely requires more effort of me. If they didn't exist I'd be much more productive
• brundolf 5y ago
  I've wondered what it would be like to write a thin language that compiles to Go and mainly serves to introduce a reasonable type system on top, while benefitting from its performance and garbage-collection. Could prevent null dereferencing, among other things
  • hardwaregeek 5y ago
    Like a TypeScript for Go? We could call it Tolang.
    • brundolf 5y ago
      That's the idea! I use Rust for a lot of personal projects mainly because of the type system, not because it doesn't have GC. I think GC's totally livable for a great many things, and it would help iteration speed a lot to not have to deal with the borrow-checker, but I just can't stand working in a language with a shaky type system these days. So Go-with-good-types sounds fantastic to me.
      • smabie 5y ago
        How about OCaml?
        • brundolf 5y ago
          I've heard the tooling and general ecosystem are not great (similar to Haskell), though I don't know firsthand
          • smabie 5y ago
            I've personally found it really good, probably better than Haskell. Not Go level though I imagine.
          • Zababa 5y ago
            The tooling is good, the ecosystem is where it's lacking.
• shp0ngle 5y ago
  That seems nice. I stopped using gosec (or whatever was the name) because of all that noise
  • ggu 5y ago
    Yeah, I was on the team that came up with GoKart and one of the main motivating factors was that gosec is just waay too noisy to be useful
• jannetalex 5y ago
  . I've suffered with HIV/AIDS ever since I was a child but it's only been the last few years I discovered that I also have herpes virus . So I started looking for a way to get cure permanently from this deadly virus I visited so many hospitals in search for a solution.Few month ago I came across a site where a lady was sharing a testimony about Dr Godwin and how he cured HIV/AIDS virus and all kinds of diseases with natural herbs so I decided to give it a try and i messaged Doctor Godwin he told me how I was going to get the herbs so I did as he instructed few days later I received the herbs and I started taking the herbs as instructed by the Dr.I was shocked two weeks later my doctor told me that I was free from HIV/AIDS so I decided to let the world know how I was cured from HIV/AIDS by Dr godwin. you can reach him through his drgodwinharbs@gmail.com Or WhatsApp/call +234 8089906968.If you also want cure for your herpes or any of the disease listed below Dr godwin also cure the listed diseases below 1,Weight loss 2,cancer 3,herpes virus 4,high blood presure 5,diabetes 6,Skin rashes 7,Swollen lymph glands 8,Pneumonia Memory loss 9,Sores of the mouth, anus, or genitals 10,HIV/AIDS 11,Penis enlargement etc Goodluck call or wattsapp [+2348089906968 ] dr godwin website link --- [ https://drgodwinharbalhomecure22.simdif.com/ https://drgodwinharbalhomecure22.simdif.com/ ] God bless you dr Godwin for what you did for me and my family he is so real and reliable