4 ms·

This seems like a lot of work to identify the vulnerable functions that are called transitively. Could this work be reused to perform tree-shaking, so that Go o

This seems like a lot of work to identify the vulnerable functions that are called transitively. Could this work be reused to perform tree-shaking, so that Go only compiles the code you actually need? (Or, does Go already do this at compilation?)

lukax 4y ago
Go is a compiled language that uses a linker which means that only the functions that are called end up in the final binary. So yes, go does "tree-shaking".
- jrockway 4y ago
  It's important to read the caveats: https://github.com/golang/go/blob/master/src/cmd/link/internal/ld/deadcode.go#L298 https://github.com/golang/go/blob/master/src/cmd/link/intern..., the most important of which is: // The third case is handled by looking to see if any of: // - reflect.Value.Method or MethodByName is reachable // - reflect.Type.Method or MethodByName is called (through the // REFLECTMETHOD attribute marked by the compiler). // // If any of these happen, all bets are off and all exported methods // of reachable types are marked reachable. Basically, if you do certain kinds of reflection, then more code is theoretically reachable and will be included in your binary. In practice, you end up with a large binary in anything that calls into autogenerated APIs.
  - tucnak 4y ago
    The autogenerated APIs aren't something as prevalent as one may think.
  - biomcgary 4y ago
    That is a useful clarification. It seems to explain why the use of the fmt Go's std lib formatting and printing package, seems to pull in so much. Surely, it is performing a fair amount of reflection under the hood.
    - barsonme 4y ago
      The fmt package should not put the compiler into conservative mode. If it does, file a bug report.
adonovan 4y ago
govulncheck builds a static approximation of the call graph using Variable Type Analysis (VTA), which dynamically tabulates the set of interface method calls and the set of concrete types that each interface value may hold, to discover the set of functions potentially reachable from main. (VTA is a refinement of Rapid Type Analysis (RTA), which holds only one set of concrete types for all interface values in the whole program.) The result should be more precise than the linker. See: - https://pkg.go.dev/golang.org/x/tools/go/callgraph/vta https://pkg.go.dev/golang.org/x/tools/go/callgraph/vta - https://pkg.go.dev/golang.org/x/tools/go/callgraph/rta https://pkg.go.dev/golang.org/x/tools/go/callgraph/rta

lukax 4y ago

Go is a compiled language that uses a linker which means that only the functions that are called end up in the final binary. So yes, go does "tree-shaking".

jrockway 4y ago
It's important to read the caveats: https://github.com/golang/go/blob/master/src/cmd/link/internal/ld/deadcode.go#L298 https://github.com/golang/go/blob/master/src/cmd/link/intern..., the most important of which is: // The third case is handled by looking to see if any of: // - reflect.Value.Method or MethodByName is reachable // - reflect.Type.Method or MethodByName is called (through the // REFLECTMETHOD attribute marked by the compiler). // // If any of these happen, all bets are off and all exported methods // of reachable types are marked reachable. Basically, if you do certain kinds of reflection, then more code is theoretically reachable and will be included in your binary. In practice, you end up with a large binary in anything that calls into autogenerated APIs.
- tucnak 4y ago
  The autogenerated APIs aren't something as prevalent as one may think.
- biomcgary 4y ago
  That is a useful clarification. It seems to explain why the use of the fmt Go's std lib formatting and printing package, seems to pull in so much. Surely, it is performing a fair amount of reflection under the hood.
  - barsonme 4y ago
    The fmt package should not put the compiler into conservative mode. If it does, file a bug report.

adonovan 4y ago

govulncheck builds a static approximation of the call graph using Variable Type Analysis (VTA), which dynamically tabulates the set of interface method calls and the set of concrete types that each interface value may hold, to discover the set of functions potentially reachable from main. (VTA is a refinement of Rapid Type Analysis (RTA), which holds only one set of concrete types for all interface values in the whole program.) The result should be more precise than the linker. See: - https://pkg.go.dev/golang.org/x/tools/go/callgraph/vta https://pkg.go.dev/golang.org/x/tools/go/callgraph/vta - https://pkg.go.dev/golang.org/x/tools/go/callgraph/rta https://pkg.go.dev/golang.org/x/tools/go/callgraph/rta