Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules

[Michael Orlitzky <mjo@gentoo.org>]

On 9/18/19 3:33 PM, Alec Warner wrote:
> 
> I think the problem I have with this conversation is that I am
> discussing things that are technically possible (e.g. we can in fact
> propagate security fixes to all go packages, same as dynamically linked
> packages) with things we do not think we will do.
> 
> If A deps on B and B has a sec vuln we can modify A's go.mod files to
> depend on B-next (with security fixes), vendor that in, and bump A.
> 

How does the Gentoo maintainer find out that there's a security
vulnerability in a dependency that was statically linked onto my system
when that dependency was specified in a text file using a commit hash in
a tarball in SRC_URI?

Without an answer to that question, even calling it "technically
possible" is disingenuous.


> We don't do this, not because it's not possible, but because it's
> expensive and people don't want to do it. The benefit of such a
> discussion is that when we don't do this work, we can describe it to end
> users and say "hey this is what it takes to run these packages securely,
> Gentoo has chosen not to do it, but if you want to use these packages
> here is the work necessary."

And the message in the patch says none of that. Instead, it tries to
shift the blame to upstream and lies to you about how to fix it (there
is no way to fix it).