| 1 |
On 9/18/19 3:33 PM, Alec Warner wrote: |
| 2 |
> |
| 3 |
> I think the problem I have with this conversation is that I am |
| 4 |
> discussing things that are technically possible (e.g. we can in fact |
| 5 |
> propagate security fixes to all go packages, same as dynamically linked |
| 6 |
> packages) with things we do not think we will do. |
| 7 |
> |
| 8 |
> If A deps on B and B has a sec vuln we can modify A's go.mod files to |
| 9 |
> depend on B-next (with security fixes), vendor that in, and bump A. |
| 10 |
> |
| 11 |
|
| 12 |
How does the Gentoo maintainer find out that there's a security |
| 13 |
vulnerability in a dependency that was statically linked onto my system |
| 14 |
when that dependency was specified in a text file using a commit hash in |
| 15 |
a tarball in SRC_URI? |
| 16 |
|
| 17 |
Without an answer to that question, even calling it "technically |
| 18 |
possible" is disingenuous. |
| 19 |
|
| 20 |
|
| 21 |
> We don't do this, not because it's not possible, but because it's |
| 22 |
> expensive and people don't want to do it. The benefit of such a |
| 23 |
> discussion is that when we don't do this work, we can describe it to end |
| 24 |
> users and say "hey this is what it takes to run these packages securely, |
| 25 |
> Gentoo has chosen not to do it, but if you want to use these packages |
| 26 |
> here is the work necessary." |
| 27 |
|
| 28 |
And the message in the patch says none of that. Instead, it tries to |
| 29 |
shift the blame to upstream and lies to you about how to fix it (there |
| 30 |
is no way to fix it). |
Archives