MIME-Version: 1.0
Date: Tue, 21 Jan 2020 18:09:30 +0000
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: "Ariadne Conill" <ariadne@dereferenced.org>
Message-ID: <25c9d7abc6500086acc511bf121b76db@dereferenced.org>
Subject: Re: repo pinning, whether to include repository name in pkg [was
 Re: new package format and repository layout changes]
To: "Timo Teras" <timo.teras@iki.fi>
Cc: "Drew DeVault" <sir@cmpwn.com>, "Natanael Copa"
 <ncopa@alpinelinux.org>, ~alpine/devel@lists.alpinelinux.org
In-Reply-To: <20200119130141.33011217@vostro>
References: <20200119130141.33011217@vostro>
 <20200118001927.3492f70d@vostro.lan> <20200117093110.13bfdc9f@vostro.lan>
 <BZY4HPQ7P5IO.32ODJBJGIGRTN@homura>
 <185d5d5ee06c85855c43c3386bae7e90@dereferenced.org>

Hello,=0A=0AJanuary 19, 2020 5:01 AM, "Timo Teras" <timo.teras@iki.fi> wr=
ote:=0A=0A> On Fri, 17 Jan 2020 23:15:08 +0000=0A> "Ariadne Conill" <aria=
dne@dereferenced.org> wrote:=0A> =0A>> January 17, 2020 4:19 PM, "Timo Te=
ras" <timo.teras@iki.fi> wrote:=0A>> =0A>> On Fri, 17 Jan 2020 09:06:38 -=
0500=0A>> "Drew DeVault" <sir@cmpwn.com> wrote:=0A>> =0A>> On Fri Jan 17,=
 2020 at 9:31 AM, Timo Teras wrote:=0A>> Having said all this. I am still=
 somewhat concerned and thinking=0A>> that putting repository name to the=
 package might be useful thing.=0A>> But perhaps in should be the origina=
lly-built-from-repository and=0A>> not the index name.=0A>> =0A>> Does an=
y of you share my concerns that the repo name should be=0A>> signed?=0A>>=
 =0A>> Still NACK on signing the repo name. Signed data should be=0A>> au=
tonomous of its original source, so long as it's signed it=0A>> doesn't m=
atter how it got to you.=0A>> =0A>> Would you be able to give some reason=
ing, arguments or use-cases why=0A>> you think this is the correct approa=
ch?=0A>> =0A>> Downstream of Alpine, we use apk fetch to compose reposito=
ries for=0A>> customers which contain the exact set of packages we provid=
e support=0A>> for. These package sets are not aligned with the repositor=
y split=0A>> that upstream Alpine uses. It would be desirable to retain t=
his=0A>> functionality without having to resign the packages.=0A>> =0A>> =
While breaking this functionality would only require some minor=0A>> rewo=
rk of our scripts (to resign the packages), it also breaks the=0A>> abili=
ty to audit the supply chain: our customer cannot verify that=0A>> their =
package has actually originated from Alpine if we resign it=0A>> at prese=
nt. Accordingly, it would be desirable in any case that=0A>> we have to r=
ewrite the control section of the package to be able to=0A>> include a si=
gned copy of the previous control section, to ensure that=0A>> the supply=
 chain audit-ability requirement is preserved.=0A>> =0A>> Being able to c=
ompose new repositories from existing ones *and*=0A>> preserve the origin=
al signatures is, unfortunately, for various=0A>> reasons, a hard require=
ment for us.=0A> =0A> Thanks for this. I suppose it this make sense.=0A> =
=0A> My next questions would be then about what kind of signing policy yo=
u=0A> are using/would like to have?=0A> =0A> There obviously is Alpine ke=
y and your key in place.=0A> =0A> So, what would be the desired policy:=
=0A> =0A> a) sign packages with both keys, check only your key? (alpine s=
ignature=0A> is more for sideband verification)=0A> =0A> b) sign packages=
 with both keys, have apk check both signatures?=0A> =0A> c) sign package=
s with alpine key, index with your key; have clients=0A> trust both?=0A> =
=0A> d) sign index with your key; include trust-delegation-signature of=
=0A> alpine key in index so that packages are signed with alpine key only=
,=0A> and client has only your key?=0A> =0A> e) something else? what?=0A=
=0AThe ideal outcome would be (c).  I don't wish to repack packages=0Aunl=
ess absolutely necessary.  Being able to sign the alpine key=0Awith our o=
wn does sound nice though, but we presently work around=0Athis by includi=
ng our keys and the Alpine keys in /etc/apk/keys,=0Aso it is not really t=
hat important.=0A=0AAriadne