Skip to content Skip to footer
0 items - $0.00 0

Show HN: Globstar – Open-source static analysis toolkit by sanketsaurav

Show HN: Globstar – Open-source static analysis toolkit by sanketsaurav

8 Comments

  • Post Author
    pdimitar
    Posted February 28, 2025 at 5:58 pm

    Wow this looks great. I will be giving it a go VerySoon™!

    Looking forward to writing some enhanced linters.

  • Post Author
    henning
    Posted February 28, 2025 at 6:01 pm

    Is there a way to add a comment to disable the check rule similar to what you can do in ESLint to ignore a rule?

  • Post Author
    xxpor
    Posted February 28, 2025 at 6:20 pm

    Another rule engine checker that doesn't support the language that needs this type of thing the most: C

    In this case, it's inexplicable to me since tree-sitter supports C fine.

  • Post Author
    codepathfinder
    Posted February 28, 2025 at 6:52 pm

    Nothing comes closer to CodeQL!

    If anyone is interested please checkout, codepathfinder.dev, truly opensource CodeQL alternative.

    Feedbacks are appreciated!

  • Post Author
    markrian
    Posted February 28, 2025 at 7:45 pm

    Interesting! Do you have a page which compares globstar against other similar tools, like Semgrep, ast-grep, Comby, etc?

    For instance, something like https://ast-grep.github.io/advanced/tool-comparison.html#com….

  • Post Author
    etyp
    Posted February 28, 2025 at 8:00 pm

    I really love that static analyzers are pushing in this direction! I loved writing Clippy lints and I think applying that "it's just code" with custom checks is a powerful idea. I worked on a static analysis product and the rules for that were horrible, I don't blame the customers for not really wanting to write them.

    Is there a general way to apply/remove/act on taint in Go checkers? I may not be digging deeply enough but it seems like the example just uses some `unsafeVars` map that is made with a magic `isUserInputSource` method. It's hard for me to immediately tell what the capabilities there are, I bet I'm missing a bit.

  • Post Author
    micksmix
    Posted March 1, 2025 at 12:48 am

    This is a really interesting project!

    I'd love to hear how this project differs from Bearer, which is also written in Go and based on tree-sitter?
    https://github.com/Bearer/bearer

    Regardless, considering there is a large existing open-source collection of Semgrep rules, is there a way they can be adapted or transpiled to tree-sitter S-expressions so that they may be reused with Globstar?

  • Post Author
    micksmix
    Posted March 1, 2025 at 1:15 am

    One of the main benefits of Semgrep is its unified DSL that works across all supported languages. In contrast, using the Go module "smacker/go-tree-sitter" can expose you to differences in s-expression outputs due to variations and changes in independent grammars.

    I've seen grammars that are part of "smacker/go-tree-sitter" change their syntax between versions, which can lead to broken S-expressions. Semgrep solves that with their DSL, because it's also an abstraction away from those kind of grammar changes.

    I'm a bit concerned that tree-sitter s-expressions can become "write-only" and rely on the reader to also understand the grammar for which they've been generated.

    For example, here's a semgrep rule for detecting a Jinja2 environment with autoescaping disabled:

      rules:
      - id: incorrect-autoescape-disabled
        patterns:
          - pattern: jinja2.Environment(... , autoescape=$VAL, ...)
          - pattern-not: jinja2.Environment(... , autoescape=True, ...)
          - pattern-not: jinja2.Environment(... , autoescape=jinja2.select_autoescape(...), ...)
          - focus-metavariable: $VAL
    
      

    Now, compare it to the corresponding tree-sitter S-expression (generated by o3-mini-high):

      (
        call
          function: (attribute
                      object: (identifier) @module (#eq? @module "jinja2")
                      attribute: (identifier) @func (#eq? @func "Environment"))
          arguments: (argument_list
                        (_)*
                        (keyword_argument
                          name: (identifier) @key (#eq? @key "autoescape")
                          value: (_) @val
                            (#not-match @val "^True$")
                            (#not-match @val "^jinja2\.select_autoescape\("))
                        (_)*)
      ) @incorrect_autoescape
    
    

    People can disagree, but I'm not sure that tree-sitter S-expressions as an upgrade over a DSL. I'm hoping I'm proven wrong ;-)

Leave a comment

In the Shadows of Innovation”

© 2025 HackTech.info. All Rights Reserved.

Sign Up to Our Newsletter

Be the first to know the latest updates

Whoops, you're not connected to Mailchimp. You need to enter a valid Mailchimp API key.