Date: Sun, 19 Jan 2020 13:01:41 +0200
From: Timo Teras <timo.teras@iki.fi>
To: "Ariadne Conill" <ariadne@dereferenced.org>
Cc: "Drew DeVault" <sir@cmpwn.com>, "Natanael Copa" <ncopa@alpinelinux.org>,
 ~alpine/devel@lists.alpinelinux.org
Subject: Re: repo pinning, whether to include repository name in pkg [was
 Re: new package format and repository layout changes]
Message-ID: <20200119130141.33011217@vostro>
In-Reply-To: <185d5d5ee06c85855c43c3386bae7e90@dereferenced.org>
References: <20200118001927.3492f70d@vostro.lan>
	<20200117093110.13bfdc9f@vostro.lan>
	<BZY4HPQ7P5IO.32ODJBJGIGRTN@homura>
	<185d5d5ee06c85855c43c3386bae7e90@dereferenced.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Fri, 17 Jan 2020 23:15:08 +0000
"Ariadne Conill" <ariadne@dereferenced.org> wrote:

> January 17, 2020 4:19 PM, "Timo Teras" <timo.teras@iki.fi> wrote:
> 
> > On Fri, 17 Jan 2020 09:06:38 -0500
> > "Drew DeVault" <sir@cmpwn.com> wrote:
> >   
> >> On Fri Jan 17, 2020 at 9:31 AM, Timo Teras wrote:
> >> Having said all this. I am still somewhat concerned and thinking
> >> that putting repository name to the package might be useful thing.
> >> But perhaps in should be the originally-built-from-repository and
> >> not the index name.
> >> 
> >> Does any of you share my concerns that the repo name should be
> >> signed?
> >> 
> >> Still NACK on signing the repo name. Signed data should be
> >> autonomous of its original source, so long as it's signed it
> >> doesn't matter how it got to you.  
> > 
> > Would you be able to give some reasoning, arguments or use-cases why
> > you think this is the correct approach?  
> 
> Downstream of Alpine, we use apk fetch to compose repositories for
> customers which contain the exact set of packages we provide support
> for.  These package sets are not aligned with the repository split
> that upstream Alpine uses.  It would be desirable to retain this
> functionality without having to resign the packages.
> 
> While breaking this functionality would only require some minor
> rework of our scripts (to resign the packages), it also breaks the
> ability to audit the supply chain: our customer cannot verify that
> their package has actually originated from Alpine if we resign it
> at present.  Accordingly, it would be desirable in any case that
> we have to rewrite the control section of the package to be able to
> include a signed copy of the previous control section, to ensure that
> the supply chain audit-ability requirement is preserved.
> 
> Being able to compose new repositories from existing ones *and*
> preserve the original signatures is, unfortunately, for various
> reasons, a hard requirement for us.

Thanks for this. I suppose it this make sense.

My next questions would be then about what kind of signing policy you
are using/would like to have?

There obviously is Alpine key and your key in place.

So, what would be the desired policy:

a) sign packages with both keys, check only your key? (alpine signature
is more for sideband verification)

b) sign packages with both keys, have apk check both signatures?

c) sign packages with alpine key, index with your key; have clients
trust both?

d) sign index with your key; include trust-delegation-signature of
alpine key in index so that packages are signed with alpine key only,
and client has only your key?

e) something else? what?

Cheers,
Timo