Date: Sun, 11 Oct 2020 14:14:39 +0300
From: Timo Teras <timo.teras@iki.fi>
To: "Paul Spooren" <mail@aparcar.org>
Cc: <~alpine/apk-tools@lists.alpinelinux.org>
Subject: Re: Support for alternative crypto libraries
Message-ID: <20201011141439.6f5dacba@vostro.wlan>
In-Reply-To: <C69WAPL9SHXO.36XTXYSB2UCOJ@dawn>
References: <20201011100031.005fbd8c@vostro.wlan>
	<C69WAPL9SHXO.36XTXYSB2UCOJ@dawn>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Sat, 10 Oct 2020 21:49:11 -1000
"Paul Spooren" <mail@aparcar.org> wrote:

> On Sat Oct 10, 2020 at 9:00 PM HST, Timo Teras wrote:
> > > Are there any intentions or interest to allow different libraries
> > > for either use case? I'm asking because I'd like to see APK as a
> > > replacement for OpenWrts current package manager (`opkg`), but the
> > > libssl/libcrypto combination is to heavy for most WiFi routers.  
> >
> > I understand you are interested running on even more resource
> > constrained environment. And I'd be happy to support where
> > possible. I understand this might also mean additional options to
> > reduce index size etc.  
> 
> Yes, it would be very helpful if you could give me some pointers where
> other parts could be stripped down.

That really depends on what requirements you have. We can consider
making optional everything that is considered extra (e.g. not needed
for package dependencies or installation). Could include
description, maintainer, origin, reference urls, etc. Or is some of
this something you need to display somewhere?

> I think the `libhydrogen` could be *too modern*[1], as in not trivial
> to use with openssl. It's maybe more of a all or nothing approach,
> which I'd be fine with, as v3 seems to change things from group up
> anyway.
> 
> [1]:
> https://github.com/jedisct1/libhydrogen/wiki/Generic-hashing#algorithm
> 
> > It might make sense to make Ed25519 the default for both builds.  
> 
> So maybe it makes more sense to use tweetnacl[2] instead of
> libhydrogen. It's also small, uses ed25519[3] and sha-512[4], would
> therefore be a compatible with tools like signify and usign.
> 
> Maybe someone with more cryptographic insights should step up here and
> make a statement.
> 
> [2]: https://tweetnacl.cr.yp.to/
> [3]: https://nacl.cr.yp.to/sign.html
> [4]: https://nacl.cr.yp.to/hash.html

I have currently no strong opinion what the alternative library should
be. As long as it satisfied your size requirement and is suitable
enough API to be usable in the current code base without major
refactoring.

> > I assume the same crypto primitives are available also from openssl?
> > Preferable then the openssl would be exetended to support also
> > these.  
> 
> Openssl does seem to support ed25519[5], however CLI support is
> currently missing.

Yes.

> Apart from the primitives, we should agree on a key and signature
> format. I'd suggest to follow the same structure as signify does[6]. 
> 
> [5]: https://www.openssl.org/docs/manmaster/man7/Ed25519.html
> [6]: https://github.com/aperezdc/signify/blob/master/signify.c#L54

Currently key generation is not in scope for apk. And I think I would
like to keep it like that. Make apk use keys generated by other tools

We could fairly easily support multiple key formats if needed. But
currently it's using openssl pkey infrastructure to load PEM private
keys which seems to be fairly standard solution. I think adding support
for signify keys should not be a problem.

However, the signatures are embedded as part of the file structures, so
trying to make them compatible when you cannot anyway use the external
tool sounds little bit unnecessary complication. The code for adb
signatures has already been written. But if there's strong(er) reasons
to adjust that, it is still possible.

> >  
> > > Looking at the APK code some wrappers around the hashing/verifying
> > > could do the trick, some `ifndef` within `libfetch` could disable
> > > HTTPS support (and thereby lose the `libopenssl` dependency.
> > > 
> > > As v3 seems to be changing quite some things, if now is the right
> > > time to discuss such changes.  
> >
> > Yes. Thin wrappers in separate file, perhaps in the new apk_trust.h
> > or separate apk_crypto.h depending how much it ends up being in
> > code lines.  
> 
> I'll look into that, good pointer.
> 
> >
> > Optionally disabling https in libfetch also sounds acceptable.  
> 
> Great. In fact we're looking libfetch entirely with a smaller OpenWrt
> libary, but that shouldn't be scope of this thread.

Right. That may deserve it's own thread. I would be happy to look at
replacing the libfetch too. I am not full satisfied with it as-is.
Options being fixing libfetch, finding something else, or in worst case
writing something to replace it.

The history is that originally apk fork+execed wget with fallback to
busybox wget. We sought for library that would be easy enough to link
in statically and support enough of http things. We ended up with
libfetch and it's fairly ok. Though we've needed to fix certain things
in it in-tree for linux.

I think the current feature set is basic http support, https support
which should be optional, basic authentication, if-modified-since,
cache-control, netrc, connection pooling, proxy support (via
environment variables).

The things I am additional looking for are no extra memcpys, so the
data could be directly received to user given buffer when possible;
automatic retries in case of connections problems (potentially
supporting switching mirrors), proper buffering for request sending,
and potentially http/2 support.


> > As noted the v3 is currently in state of flux, and I'm hoping to
> > next start reworking the info/search/list type applets that do
> > read-only operations.
> >
> > So for the adb format these are welcome now. I still need let some
> > time to pass to see if we can make the new package format (Adb
> > based) happen sooner than later, and the adb changes alone would be
> > enough. Depending on time pressure and how things go, we can
> > consider also amending the current .apk format (but obviously I'd
> > want to avoid that if possible).  
> 
> I looked shortly into that and we could simply add another signature
> in the format `.SIGN.SIGNIFY.<fingerprint>.sig`. But as the whole
> migration process within OpenWrt takes easily a year, I'd focus on v3
> only.

Yes, I think adding the new signature in v2 packages is not problem.
Anything with new signature specifier there should be ok. I would just
like to avoid getting these package out at all if possible.

The main motivation in V3 package format is that the manifest is
signed, and the signed-manifest is directly copied to installed-db.
This allows later on 'apk audit' to verify the signatures and whole
filesystem retroactive against the original asymmetric signatures.

Timo