Gentoo Archives: gentoo-dev

From: Alec Warner <antarus@g.o>
To: Gentoo Dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules
Date: Wed, 18 Sep 2019 19:33:24
Message-Id: CAAr7Pr_j+LTtHoBgRyxV3rUSSrg6zffV4Uroqv=AnkmV0qR87g@mail.gmail.com
In Reply to: Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules by Michael Orlitzky
1 On Wed, Sep 18, 2019 at 12:15 PM Michael Orlitzky <mjo@g.o> wrote:
2
3 > On 9/18/19 2:04 PM, Alec Warner wrote:
4 > >
5 > > I'm actually pretty fine with this wording, upstream has said not to
6 > > dynamically link in these use cases.
7 > >
8 >
9 > Respectfully, the fact that you're OK with it doesn't make it not BS. It
10 > reads like "there's no way we can fix this!" when really it means "we
11 > don't feel like doing this properly!"
12 >
13 > Upstreams suggest dumb stuff all the time. We fix it. That's, like, what
14 > we do here.
15 >
16
17 > >
18 > > So if the package *maintainer* bumps each package every time it, or a
19 > > dep has a security issue; then updating will work fine.
20 > >
21 >
22 > Simply not true. If there's a security problem in a dependency and if
23 > you bump the packages that depend on it... nothing happens. Everyone
24 > reinstalls the vulnerable dependency, because the vulnerable dependency
25
26 is bundled in every single one of those packages.
27 >
28
29
30 I think the problem I have with this conversation is that I am discussing
31 things that are technically possible (e.g. we can in fact propagate
32 security fixes to all go packages, same as dynamically linked packages)
33 with things we do not think we will do.
34
35 If A deps on B and B has a sec vuln we can modify A's go.mod files to
36 depend on B-next (with security fixes), vendor that in, and bump A.
37
38 We don't do this, not because it's not possible, but because it's expensive
39 and people don't want to do it. The benefit of such a discussion is that
40 when we don't do this work, we can describe it to end users and say "hey
41 this is what it takes to run these packages securely, Gentoo has chosen not
42 to do it, but if you want to use these packages here is the work necessary."
43
44 I think that presents a better message than "Upstream is crap" or "these
45 packages are crap but we are forced to carry them for $reason so use them
46 at your own risk!".
47
48 -A

Replies