[PATCH 2/3] treewide: use wpad-basic-wolfssl as default

[Petr Štetiar]

Stijn Segers <foss at volatilesystems.org> [2020-07-25 10:24:42]:

Hi,

> I read Adrian's reply as 'we'll keep ath79/tiny out of the wpad SSL push?'
> but I might be mistaken of course.

the idea of this patch series is to have the _same_ baseline in _all_ images,
so HTTPS and WPA3-Personal by default. It wouldn't make much sense to
announce, that OpenWrt release 20.09.0 (made that up) adds HTTPS and
WPA3-Personal security features, but they're missing on some devices like
those in ath79/tiny, bcm47xx/legacy, lantiq/xway_legacy, rt288x, rt305x,
rt3883 and tegra (all those with wpad-mini).

It would be support and maintenance nightmare, probably like having release
with two different kernel versions.

> > I'm going to switch those to wpad-basic-wolfssl variant as well, since it
> > seems that the only difference is CONFIG_IEEE80211R=n in wpad-mini.
> > 
> 
> I think that will kill even more tiny images (master has been seeing a lot
> of those being disabled lately). On my TL-WR841ND v7, e.g., I have stripped
> some more stuff from master, after the 5.4 bump (which was to be expected).
> I was able to squeeze in wpad-basic again for the 802.11r (PPP removed
> though), but it's not like those tiny targets have 20 kB to spare, from what
> I can tell.

 "as we've dropped support for 4/32M devices officialy with 19.07 and it's
  time to move on and improve the default security features in official images."

TL-WR841ND v7 has `IMAGE_SIZE := 3904k`, so it's 4/32M device which we've
decided to not support anymore. It's an uphill battle, nobody has simply time
for this and we need to bite the bullet and move on.

> (I heard through the grapevine older flash/RAM constrained devices might
> just stick with kernel 4.19 btw? ath79/tiny is already on 5.4.)

Yep, 19.07 is the last release with official support for 4/32M devices.

> Since ath79/tiny is a separate subtarget altogether, it makes sense to offer
> them with fewer features. Unless I'm mistaken we'll see a lot of
> ramips/mt76{20,x8} stuff going the same route in the near future, they have
> similar flash constraints.

We simply disable image generation for devices which fall above the cliff, we
don't remove them from the tree so people should still be able to build images
for those devices with Image Builder for example.

> I don't think feature parity with more recent targets (or ones with more
> space) is what one should aim for, with a separate subtarget.

I consider HTTPS/WPA3-Personal as important _base_ feature in next release.

> P.S. Is there a way to use mbedtTLS with wpad? 

 "wolfSSL and mbed TLS were pre-selected as possible crypto libraries due to
  the size. mbed TLS currently lacks support in hostapd so I went with wolfSSL
  for the start."

It would mean adding TLS crypto module for mbed TLS into hostapd. This is not
trivial timewise and would probably need some crypto person to do that
properly (or at least have that properly reviewed). This means it wouldn't be
possible to finish that task before 20.09.0 release in acceptable quality.

> That would be neat since one could have LuCI SSL and wpad lean on the same
> crypto library. I am now building images with mbedTLS for LuCI and wolfssl
> for wpad; it's still smaller than having both build with OpenSSL but a bit
> cumbersome nonetheless.

Yes, LuCI is going to benefit from the libustream-wolfssl package, as uhttpd
could use that library to perform SSL/TLS, so it could finally work over HTTPS
by default in next release. We're going to have fun with self-signed
certificate, but that's different story :-)

-- ynezz