Vulnerability Management for Go

Re:Vulnerability Management for Go by jrockway on Tuesday September 06, 2022 @04:33PM (#32742836)

It's important to read the caveats: 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.

[ Parent | on HN ]

Re:Vulnerability Management for Go by biomcgary on Thursday September 08, 2022 @01:35PM (#32768870)

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.

[ Parent | on HN ]

Re:Vulnerability Management for Go by barsonme on Thursday September 08, 2022 @02:38PM (#32770011)

The fmt package should not put the compiler into conservative mode. If it does, file a bug report.

[ Parent | on HN ]

Re:Vulnerability Management for Go by tucnak on Wednesday September 07, 2022 @12:44AM (#32746400)

The autogenerated APIs aren't something as prevalent as one may think.

[ Parent | on HN ]