From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 6AAB9138334 for ; Thu, 19 Sep 2019 01:09:11 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D0EB2E094B; Thu, 19 Sep 2019 01:09:07 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 909DEE092B for ; Thu, 19 Sep 2019 01:09:07 +0000 (UTC) Received: from [192.168.1.100] (c-98-218-46-55.hsd1.md.comcast.net [98.218.46.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mjo) by smtp.gentoo.org (Postfix) with ESMTPSA id A547E34B357 for ; Thu, 19 Sep 2019 01:09:05 +0000 (UTC) Subject: Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules To: gentoo-dev@lists.gentoo.org References: <20190916141719.12922-1-williamh@gentoo.org> <20190916141719.12922-2-williamh@gentoo.org> <397fd9bd-d439-1876-c677-8e4a7ee8c7cf@gentoo.org> <5ee9a16b-1709-4f79-4308-2b01f13e91d0@gentoo.org> From: Michael Orlitzky Message-ID: Date: Wed, 18 Sep 2019 21:09:03 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Archives-Salt: 92deb1fb-8f92-4991-b58c-181dcc9b99cd X-Archives-Hash: 85ba2824e62f581114c53b1c2bd72cc3 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).