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

[Stijn Segers]

Hi,

Op zaterdag 25 juli 2020 om 11u28 schreef Petr Štetiar <ynezz at true.cz>:
> 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).

Understandably so. But like you said, they already have limited 
functionality
at this point: wpad-mini versus wpad-basic. At the same time, a lot of 
those
devices are EOL with 19.07, as you pointed out. So it would make more 
sense to
just keep them on wpad-mini - and maybe, to make the end of support 
crystal
clear, to disable builds for 4/32 images altogether from 20.0x on.

I think one would be spending way more time on disabling 4/32 devices 
one by
one, based on broken buildbot reports, than by just doing it in a 
one-off
operation. Disabling them all right from the start for 20.0x would send 
a clear
message: support has been ended. Keeping a few images here and there 
just makes
the whole 4/32 more protracted, increases support burden and will 
confuse a lot
of people.

Again: this is just as a user thinking out loud. I assume the playbook 
for 20.0x
has been finalised already.


> 
> 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.

To be clear: I was merely pointing that out as an example. Not as a 
request to keep
it (or 4/32 devices across the board) actively maintained.

Cheers

Stijn


> 
>>  (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
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel