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

[Alec Warner <antarus@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1878 bytes --]

On Wed, Sep 18, 2019 at 12:15 PM Michael Orlitzky <mjo@gentoo.org> wrote:

> On 9/18/19 2:04 PM, Alec Warner wrote:
> >
> > I'm actually pretty fine with this wording, upstream has said not to
> > dynamically link in these use cases.
> >
>
> Respectfully, the fact that you're OK with it doesn't make it not BS. It
> reads like "there's no way we can fix this!" when really it means "we
> don't feel like doing this properly!"
>
> Upstreams suggest dumb stuff all the time. We fix it. That's, like, what
> we do here.
>

> >
> > So if the package *maintainer* bumps each package every time it, or a
> > dep has a security issue; then updating will work fine.
> >
>
> Simply not true. If there's a security problem in a dependency and if
> you bump the packages that depend on it... nothing happens. Everyone
> reinstalls the vulnerable dependency, because the vulnerable dependency

is bundled in every single one of those packages.
>


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.

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."

I think that presents a better message than "Upstream is crap" or "these
packages are crap but we are forced to carry them for $reason so use them
at your own risk!".

-A

[-- Attachment #2: Type: text/html, Size: 2786 bytes --]