<f00b4r0>
so 2nd-classing hundreds of devices is decided by you alone?
<f00b4r0>
that's interesting.
<ynezz>
what is going to change?
<f00b4r0>
you tell me, since you call the shots.
<ynezz>
we didn't dropped support for anything
<ynezz>
just make OpenSSL default on targets which can afford it
<f00b4r0>
2nd-class implies lesser treatment. That's the very definition of the term.
<ynezz>
I didn't switched to broken mbedTLS
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jow>
personally I'd ditch any TLS functionality on targets that can't afford OpenSSL
<ynezz>
:D
<jow>
it just introduces persistent issues
<stintel>
ah so we go back to open wifi
<jow>
we have the choice between an abi-unstable version, a version that is somewhat okay but weird, and a kitchensink that needs patching ever other week
<jow>
a horrible ux due to selfsigned certs
<jow>
various "helpful" browser heuristics and quirks that make http accesibility randomly work or not work
<jow>
cert deprecation issues that are not dealt with
<jow>
and an uncontrolled growth of tls-library- and feature variants in packages like hostapd, curl etc.
<jow>
and advanced hostapd features that require openssl *anyway*
<f00b4r0>
let's stop pretending to support 3 TLS implementation then
<f00b4r0>
at least it would bring clarity
<robimarko>
Which one gets the short end then?
<ynezz>
having 3 TLS implementations is fine with me as long as there are users and maintainers, no problem with me
<jow>
the current regressions at least show that we lack the manpower/dedication/insight/tact to properly deal with maintainining or switching tls implementations
<f00b4r0>
there's no point in having 3 if the other 2 are considered 2nd-class and will likely get the short end when any conflict arises
<robimarko>
mbedtls is all nice and great but its still lacking TLS 1.3
<ynezz>
I've made this issue explict several times, folks switched to mbedTLS anyway
<jow>
or maybe the switch was rushed, then it could be rolled back and tackled for 24.x or 23.05.1
<robimarko>
I also dont like the fact that mbedtls support is not upstream in hostapd but rather a downstream patchset
<f00b4r0>
but wasn't switching implementation during release a big no-no?
<ynezz>
its rc phase, we're still good
<ynezz>
I would backport that OpenSSL to fix TLSv1.3 in 23.05
<ynezz>
thats the main reason I've created it BTW
<ynezz>
robimarko: it was submitted, but it seems like upstream is not interested?
<f00b4r0>
the need for TLS is for WPA3?
<ynezz>
uclient-fetch, uhttpd
<f00b4r0>
i mean, we could have secure wifi without TLS libs? that was the case up to 21.02 or am I mistaken?
<f00b4r0>
asking because if so, then why not have WPA3 only on these devices which can fit openssl. Then stop bothering with unmaintainable alternatives
<robimarko>
ynezz: It was never sent as a patcheset to hostapd
<robimarko>
It was couple of informational emails, like here is the tree
<robimarko>
f00b4r0: That would remove WPA3 from a large number of devices, most of which are the affordable ones
<robimarko>
And thus regress for a lot of users
<f00b4r0>
robimarko: I hear you, however if support for WPA3 on those devices was shoehorned against all odds, then maybe it's time to face the truth?
<f00b4r0>
I don't use WPA3 so I don't know how bad the "regression" would look like ;)
<robimarko>
f00b4r0: It wasnt shoehorned, we had WolfSSL at that time and its fully supported in hostapd
<f00b4r0>
yeah but wolfssl is a clusterfuck, as we've seen
<ynezz>
indeed
<robimarko>
I am saying that in 2023 it shouldnt really be acceptable to drop WPA3
<f00b4r0>
imho wolfssl should already be out of the supported implementations list, since we *know* we won't be able to securely maintain it for the duration of the release lifetime.
<f00b4r0>
robimarko: that's not what I'm saying. Supporting WPA3 on hardware that was designed to support it is perfectly reasonable. Supporting WPA3 on hardware that largely predates it and cannot feasibly support it was a nice bonus, but not necessarily something we should feel bound to.
<ynezz>
robimarko: or do you think, that posting the patches would make the situation better?
<f00b4r0>
consider that the problem will arise again at the next turn when our kernel gets bigger and some devices which fit today won't tomorrow.
<robimarko>
ynezz: It couldnt hurt, these kinds of informational emails never end anywhere
<robimarko>
f00b4r0: WPA3 is a SW feature, why not support it?
<robimarko>
We are hitting the flash size issue everywhere
<f00b4r0>
robimarko: best effort basis.
<f00b4r0>
if it doesn't work, it doesn't work.
<robimarko>
Thats the thing, it does work now, so removing it is a regression
<f00b4r0>
and what happens when the flash size means we can't fit tls anymore in the base image?
<f00b4r0>
would you rather entirely drop the device or fall back to something that's still usable?
<robimarko>
Then we nuke it
<f00b4r0>
well what was the point then.
<f00b4r0>
nuke it already.
<robimarko>
You can apply the same thing to devices with small flash, why bother now when we can just drop them and avoid the headache later
<f00b4r0>
no, precisely I'm advocating the opposite
<f00b4r0>
don't enable features on devices where we know we won't be able to sustain the feature
<f00b4r0>
it's a clearer signal to users too
<robimarko>
Why not move to mbedtls 3 instead of removing WPA3?
<f00b4r0>
but the bottomline is: we clearly don't have the resources to maintain multiple TLS implementations, supporting WPA3 on smaller devices requires these multiple TLS implementations and so logically we shouldn't support WPA3 on those smaller devices.
schwicht has joined #openwrt-devel
<robimarko>
Ok, we disagree here, I just dont think its normal to remove WPA3 after having it from the start on all devices
goliath has joined #openwrt-devel
<f00b4r0>
well here's what I foresee with the dual-class citizenship: comes a bug in the 2nd-class TLS implementation; we can't fix it (in reasonable time / without bumping a major version that will break everything else - wolfssl-style / without exceeding flash size / <insert other plausible reason>). We now have devices with broken implementation and users are on their own.
<f00b4r0>
do you think that's a better alternative that not having the feature in the first place?
<f00b4r0>
s/that not/than not/
<robimarko>
What you are proposing is also first class/second class thing
<f00b4r0>
no. It's featureset
<robimarko>
You may see it like that, users wont
<f00b4r0>
the featureset of non-WPA3 devices is maintained to the same standard as the WPA3 ones
<f00b4r0>
I still think it's largely preferable to the situation described above, which is a matter of when, not if, and will badly reflect on the project ;P
<f00b4r0>
anyhow, lunch time, bbl :)
<robimarko>
Dropping WPA3 from a huge number of devices will reflect badly instantly
<jow>
that reminds me that I wanted to look into statically link the required crypto lib support into wpad/hostapd
<jow>
to get a feeling for the size increase
<f00b4r0>
(and I don't know why we still bother with wolfssl at all btw, because what happened will happen again)
<jow>
if it's acceptable, we might go that route to decouple hostapd requirements fro mthe preferred tls implementation we ship for the rest of the system
<jow>
in such a scenario, wolfssl's instability would be less of an issue
<f00b4r0>
robimarko: the fact that we can drop wpa3 for some devices for a new release can simply be explained as hardware constraint (which it is).
<f00b4r0>
anyway, really off now, bbl :)
<f00b4r0>
(robimarko: in the same way that we move some devices to smallflash when the new release is too big)
<robimarko>
I dont see it that way as we first intentionally added WolfSSL for that purpose and then even mbedTLS to further cut down the size
<robimarko>
And avoid WolfSSL breaking ABI
<mrkiko>
hauke: I don't know if it makes any sense to do so, but you might cite the nbg7815 due to it having an allegedly 10GB port. But not sure if it makes sense because current performance should be quite lower at the moment in vanilla openwrt
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<f00b4r0>
robimarko: maybe we should acknowledge that things were done in the past that were suboptimal? Again, the point is that we simply cannot afford to maintain multiple TLS implementations, I think everyone agrees with that in hindsight.
<robimarko>
f00b4r0: I agree it was not optimal, but only supporting OpenSSL does not fit most of the supported HW
<robimarko>
I wont suffer from it as all my HW has larger storage, but a lot of users will
<robimarko>
Again, why not update to MbedTLS 3.x since that seems to have TLS 1.3 in some way
goliath has quit [Quit: SIGSEGV]
<mrkiko>
robimarko: I tend to agree with you; that said, wpa3 adoption seems slower
<mrkiko>
but I am not sure about the openssl grand flash idea: nowadays the rythm of security patches seems to be slowing down, but otherwise I don't see users updating so frequently
<mrkiko>
ok, we love openwrt and all - but n some cases these devices are used as ... routers. :) You might not check periodically for updates (I admit I don't know if some components of the system is already doing so)
<Tapper>
Dropping WPA3 will make OpenWrt look like a joke from a outside point of view.
<f00b4r0>
Tapper: nobody suggests "dropping WPA3"
minimal has joined #openwrt-devel
* f00b4r0
discovers that ujail'd dnsmasq drastically limits what can be done in custom DHCP script
<schmars[m]>
f00b4r0 can you send ubus calls though?
<f00b4r0>
not everything can be done over ubus though
<schmars[m]>
right, of course, was just curious myself because i'll need to do custom dhcp scripts too sometime soon :)
<f00b4r0>
hmm. And the custom script must be a shell script too; not sure why that is.
goliath has joined #openwrt-devel
<f00b4r0>
that feature is completely crippled as it is, *sigh*
<Christophe[m]1>
Out of curiosity, can someone give me an example for a somewhat recent, popular device device with limited flash?
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
schwicht has quit []
schwicht has joined #openwrt-devel
<Mangix>
robimarko: mbedtls 3.x includes breaking API changes. It's also not LTS. That being said, I prefer this to using OpenSSL.
<Mangix>
Also, WPA3 might be a software feature but AFAIK mwlwifi is incompatible. No idea if that's been fixed.
<robimarko>
Mangix: I know, but its going to be LTS
<robimarko>
I dont think we should care about mwlwifi
<robimarko>
Its been on life support for years
<Mangix>
There's new activity by some french guy. He's fixed a bunch of bugs recently. Wouldn't surprise me if WPA3 too
<robimarko>
Yes, he made it for OpenWrt and then upstreamed it
<robimarko>
Driver is just using so much legacy stuff its crazy
<Mangix>
Looks like WPA3 is still no. Oh well.
<robimarko>
Its probably broken 802.11w
<robimarko>
Like broken in the FW
tersono has quit [Read error: Connection reset by peer]
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
schwicht has quit [Read error: Connection reset by peer]
schwicht has joined #openwrt-devel
schwicht has quit [Ping timeout: 480 seconds]
<rmilecki>
folks, we have DT binding for base MAC addresses stored in NVMEM :)
<rmilecki>
both: binary and ASCII
<rmilecki>
we can use that for relative addresses and for parsing ASCII format
Misanthropos has quit [Read error: Connection reset by peer]
schwicht has joined #openwrt-devel
schwicht has quit []
Misanthropos has joined #openwrt-devel
schwicht has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
RoganDawes has joined #openwrt-devel
schwicht has quit []
<RoganDawes>
hi folks. I am trying to build an openWrt image for the Wink Hub v1 - an imx28-based board with 128MB FLASH formatted as UBI. I have figured out that I should create a stanza in target/linux/mxs/image/Makefile (can pastebin what I added) to get it to show up in menuconfig, but I am strugggling to get it to use my custom DTB file, and ultimately build a ubifs image.
<RoganDawes>
I get this error, indicating that it knows nothing about the dtb:
RoganDawes has quit [Remote host closed the connection]
<minimal>
when SSHing into OpenWRT 23.05-SNAPSHOT, where openssh rather than dropbear is server, I notice the logs contain multiple lines like this:
<minimal>
authpriv.warn sshd[4271]: pam_unix(sshd:setcred): unrecognized ENCRYPT_METHOD value [BCRYPT]
<minimal>
is this a known issue? I search Github and found some issues discussing whether or not to build shadow with bcrypt but nothing relating to these messages
<minimal>
this is where I ssh'ed using a key rather than a password
RoganDawes has joined #openwrt-devel
RoganDawes has quit [Remote host closed the connection]
RoganDawes has joined #openwrt-devel
Borromini has joined #openwrt-devel
goliath has joined #openwrt-devel
goliath has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
Borromini has quit [Quit: leaving]
<Tapper>
If a device can not run full fat OpenWrt, because of low mem or flash then they can still be run as an AP. It would be nice if there was a build of OpenWrt just to be a plug and play AP. With a luci app to be run on the mane router that could push configs to a AP. I don't know who or if this could be dun, but it would be cool. I do know that OpenWrt does not have the resources to do this.
<Tapper>
It wold be cool to have a app for APs like DAWN to push the stats of a AP back to the mane router. One witch any jowblogs can understand because dawn to me mite as well be in friench!
<minimal>
found the issue with openssh/pam, linux-pam's /etc/login.defs has "ENCRYPT_METHOD BCRYPT" which should be changed to something else like SHA256