Hi,
Op zaterdag 25 juli 2020 om 11u28 schreef Petr Štetiar <yn...@true.cz>:
Stijn Segers <f...@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@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
