On Wed, Apr 01, 2020 at 04:14:48PM -0400, Michael Orlitzky wrote: > On 4/1/20 4:03 PM, Samuel Bernardo wrote: > > > > Couldn't security issue in a Go library be solved with keyword mask and > > announce in portage? > > If there's an ebuild for the library, then yeah, you've got the right > idea. But with the Go eclasses, there are no ebuilds for any of the > dependencies. The problem goes deeper than that, and is more of an upstream concern than a Gentoo concern: because the Go module ecosystem pins exact versions, not version ranges, and this is a crucial part of reproducible builds.
Let the library be "L", with versions 1,2. The vulnerable version is L-1, and L-2 contains the fix. Let the package that uses the library be "P", with version 1 only. If you wanted to USE L-2 in P-1, you generally must make modifications to the consumers of that library. At the very least you have to modify the go.mod file to use the new version. To satisfy the package checksums/security in the Go ecosystem, you ALSO need to update the go.sum file. If the vulnerable library is a transitive dependency (e.g. indirect via another library), then you ALSO need to update that other consumer. At the point that there IS a reliable way to get lists of vulnerable versions of Go modules, including the horrible timestamped v0.0.0 versions, the EGO_SUM work does contain enough data to identify ALL vulnerable outputs on your system. That listing isn't available yet, due to upstream working on it still: https://github.com/golang/go/issues/24031 That listing would be transformed into a GLSA input criterion, to identify vulnerable Gentoo packages (at which point upstream Golang has hopefully also provided a cleaner way to bump/patch the dependency in the scope of reproducible versions). -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
signature.asc
Description: PGP signature
