Date: Fri, 17 Jan 2020 03:41:11 +0200
From: Timo Teras <timo.teras@iki.fi>
To: Natanael Copa <ncopa@alpinelinux.org>
Cc: "Drew DeVault" <sir@cmpwn.com>, <~alpine/devel@lists.alpinelinux.org>
Subject: Re: apk-tools plans
Message-ID: <20200117034111.2afdcaec@vostro>
In-Reply-To: <20200116154250.2b1d1fda@ncopa-desktop.copa.dup.pw>
References: <20200116151947.63f7ade8@ncopa-desktop.copa.dup.pw>
	<BZXA7BCRF3I4.1S1I48FFFZ1KD@homura>
	<20200116154250.2b1d1fda@ncopa-desktop.copa.dup.pw>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu, 16 Jan 2020 15:42:50 +0100
Natanael Copa <ncopa@alpinelinux.org> wrote:

> On Thu, 16 Jan 2020 09:22:30 -0500
> "Drew DeVault" <sir@cmpwn.com> wrote:
> 
> > On Thu Jan 16, 2020 at 3:19 PM, Natanael Copa wrote:  
> > > I think it as been mentioned before but I think it would be nice
> > > if we could have 2 operational install modes:
> > >
> > > - quick: in-the-air extraction/verification of packages (current
> > > style)
> > > - safe: store all packages locally and verify before trying to
> > > extract them
> > >
> > > safe mode is useful when the network connection is unreliable. In
> > > case of network error it could continue where it left off last
> > > time, rather than try fetch it all from scratch. Something like
> > > `apk upgrade --fetch-first` or `apk upgrade --safe`.    
> > 
> > In my opinion, the "quick" mode is so unsafe that I find it really
> > objectionable to have at all. It's not just an unreliable network to
> > consider - what if a signature check fails partway through and the
> > upgrade aborts half-finished? What if an man in the middle
> > orchestrates this situation? "Quick" mode also makes it difficult
> > to reckon if there'll be sufficient disk space in advance - today
> > apk just breaks your system if it hits ENOSPC.  

True. This is something we want to fix also in the "fast" version. To
support rollback to the original state regardless of what happens and
where. I believe this was mentioned in one of the earlier mails, or in
one of the tickets.

> That is how current apk works, and is part of reason why it is
> significantly faster than other package managers. In general, when the
> other package managers are done with fetching the package and is about
> to start unpack them, apk is already done with it all.
> 
> What apk does is that it extracts each file into a temp file without
> execute permissions until the signature is verified. If signature
> matches it renames all the files in one go, or deletes on failure.
> Rename and set permissions are very quick operation, while read/write
> all the data once again is not.
> 
> Disk usage is available in the index so it can be calculated before
> anything is downloaded.
> 
> But you are right to be worried. CVE-2018-1000849 is a proof of that.

That is also partially due to tar-format and perhaps even how we do
signing on it. Those were implemented more than a decade ago as an
"optional" feature for apk.

Times have changes. We are looking to make security and performance
first class citizens in the file formats. This is driving the whole
development spurt.

Timo