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 4098E138334 for ; Wed, 18 Sep 2019 19:33:24 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 38A0CE09AB; Wed, 18 Sep 2019 19:33:20 +0000 (UTC) Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (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 EF54AE0950 for ; Wed, 18 Sep 2019 19:33:19 +0000 (UTC) Received: by mail-io1-xd44.google.com with SMTP id b19so2000433iob.4 for ; Wed, 18 Sep 2019 12:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gentoo-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=UTkjf9kxbSmn4/aoWAMM/a3pVYrX60JKGKqSfaqNMqs=; b=Zhc5uYluZB19J5Yvyi6MSRVWwkyfGjizkMMSMDfLkc/Ivd3YFwO5zv61U7r131vg5l 82rqZqB2Ba2u1M9n4SwhPXVV2nDnLVGrEL/3nm649OXLKQajC1HmobrPrJQokEZTeTFH BLmqgYdPfi+ofx3Iy1RzHg+SAmWDaD4mIh0VQymX6MlxWxfc8jj7hUx59gSc3QyB7gSK y+TSY1IKKBLY8TiDXIUaOM4FKbrw7KfcKN2ufgdbAkd9gCRONhh75J3iPxqIDvFPLyNi qHRETH8ANW3w2YmbL0twCYp0iCD10AMsMsKsRFZzBxv9CGsGJFFsoTJ87ttoCpaaGD5h 3ScA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=UTkjf9kxbSmn4/aoWAMM/a3pVYrX60JKGKqSfaqNMqs=; b=EQhKPeu0RNEUVRkqtgEuFtRxCzMdB1zMpdsosWGwaUB3B7+tWafrUa7bmcWsFf8u6v 84+36kD2JXr1ZsVkXX/kDeRmV+5FuUSEITiV5Adyp9jwEsqoqGsxhJfjEoxK/CNLX0z4 gaChEDw2P2mJVxp3QnCKyoyGPly7+NFFC3sbPQ/ZL8Boic3X0KpRmzZgfQvX70tTnGMx TtDyjadahQr7ep58kexy7wJdJKTZiptdWtxAixkwXI8PQ9sOBUJqwQCM6HitqKZ5nFi+ rw1rhDSze2r1qV1DYvCDnNu2B1mom9dmbJ3+1IsxbA3HA86HhOyHWk5DzenIAm3b+GXK ZgfA== X-Gm-Message-State: APjAAAWrk62dx7hScPMUXYdh7NalZYb5rOYMTD9Sgk6BbU1/HMW1Gj8i OE1MHZiUKZuIc0U55zJHWDdUS+lorm+DabzfNJRTqZqcSmA= X-Google-Smtp-Source: APXvYqwFQ7ju7MBF3s29oh4ceXYSA4Do8trCPV1ow9zN4X5eIu+eMvVgVk48kIXa5kAI7JcDq6YkPiv7Upd5UWJH0Kw= X-Received: by 2002:a02:344a:: with SMTP id z10mr6615762jaz.123.1568835198564; Wed, 18 Sep 2019 12:33:18 -0700 (PDT) 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 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> In-Reply-To: <5ee9a16b-1709-4f79-4308-2b01f13e91d0@gentoo.org> From: Alec Warner Date: Wed, 18 Sep 2019 12:33:06 -0700 Message-ID: Subject: Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules To: Gentoo Dev Content-Type: multipart/alternative; boundary="000000000000b8d4530592d8e806" X-Archives-Salt: 48f3fc42-8585-480c-9bca-6f5b33b0132c X-Archives-Hash: 13f65def557d914d818f52f5b28ce638 --000000000000b8d4530592d8e806 Content-Type: text/plain; charset="UTF-8" On Wed, Sep 18, 2019 at 12:15 PM Michael Orlitzky 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 --000000000000b8d4530592d8e806 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Sep 18, 2019 at 12:15 PM Mich= ael Orlitzky <mjo@gentoo.org> w= rote:
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.
> =C2=A0

Respectfully, the fact that you're OK with it doesn't make it not B= S. It
reads like "there's no way we can fix this!" when really it m= eans "we
don't feel like doing this properly!"

Upstreams suggest dumb stuff all the time. We fix it. That's, like, wha= t
we do here.

>
> So if the package *maintainer* bumps each package every time it, or a<= br> > 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=C2= =A0
is bundle= d in every single one of those packages.
=C2=A0
<= div>
I think the problem I have with this conversation is tha= t 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 pa= ckages) 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 dep= end 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 descri= be it to end users and say "hey this is what it takes to run these pac= kages securely, Gentoo has chosen not to do it, but if you want to use thes= e packages here is the work necessary."

I thi= nk that presents a better message than "Upstream is crap" or &quo= t;these packages are crap but we are forced to carry them for $reason so us= e them at your own risk!".

-A

<= /div>
--000000000000b8d4530592d8e806--