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

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:

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

Attachment: signature.asc
Description: PGP signature

Reply via email to