02:01 <KGB-1> https://tests.reproducible-builds.org/openwrt/openwrt_lantiq.html has been updated. (96.2% images and 100.0% packages reproducible in our current test framework.)

04:27 <tersono> I'm looking at the samba4 Makefile as an example of a package that needs python3 on the host and it's using `include ../../lang/python/python3-host.mk` to pull in the relevant definitions. It seems like this relative path works within `feeds/packages` but would no longer be correct once the package is symlinked into `package/feeds/packages'... and how do I go about using python3-host.mk from a package that's in a custom feed?

04:31 <tersono> Hm lol of course I find the relevant README right after posting the question

07:52 <robimarko> Now that new WLAN vuln has been mitigated, are there plans for new point releases?

07:56 <slh> robimarko: there were plans to do that already before the vulnerability, http://lists.infradead.org/pipermail/openwrt-devel/2023-March/040749.html, I (can only-) assume that the vulnerability might delay the situation a week though, to see if that needs further fixups (e.g. only iwlwifi and mt76 have gotten driver specific changes, are the others covered just by the mac80211 side change or do they need

07:57 <slh> further improvements/ fixes)

08:14 <KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_mediatek.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)

08:18 <olmari> robimarko: bit offtopic, bit interested, what was vulnerable in wifi this time?

08:19 <dwfreed> a nearby attacker could trick an AP into thinking a client was requesting powersave, and then clear the client's pairwise key by half-completing renegotiation; then when the client cleared powersave, the AP would send the buffered packets without any encryption

08:19 <robimarko> olmari: https://www.usenix.org/system/files/sec23summer_355-schepers-prepub.pdf

08:22 <olmari> dwfreed, robimarko: ah, so this would be the "WNM Sleep Mode Fixes"

08:29 <f00b4r0> dwfreed: although correct me if I'm wrong but said "attacker" would have to be already authenticated to the AP.

08:30 <f00b4r0> this affects client isolation, but the attack is rather irrelevant in a typical home wifi setup.

08:33 <Znevna> there's no option to make mss clamping apply to ipv4 only, is it?

08:34 <Znevna> (easy option that is)

08:35 <f00b4r0> Znevna: with iptables you would just add the rule to the v4 ruleset, I would expect a similar restriction can be achieved with nftables?

08:35 <dwfreed> sure, but can't do that with fw3/fw4

08:36 <Znevna> I did turn off mss clamping in LuCI and added a manual rule

08:36 <Znevna> inserted*

08:36 <dwfreed> doing it manually works, but I don't think you can do it via fw3/fw4

08:36 <Znevna> but my wan restarted last night and I forgot about doing that and was about this close to call the ISP about my somewhat broken internet ;P

09:01 <dwfreed> Znevna: you can configure a script that does that addition for you

09:09 <Znevna> thought of that, I'll have to look into it. Not that MSS clamping is that bad for IPv6 but it might hide other problems like broken ISPs

09:51 <dwfreed> Znevna: honestly MSS clamping is good in general; it's the internet, there's going to be connectivity sometimes where the MTU is less than 1500; IPv6 allows as low as 1280

10:06 <Znevna> sure, but it shouldn't be needed for IPv6

10:08 <dwfreed> it can be

10:10 <f00b4r0> broken ISPs will always be a thing ;P

10:11 <robimarko> They are a feature, I would be worried if everything worked

10:12 <f00b4r0> ;)

12:08 <hgl> is it possible to set a list with uci set? "uci show" gives something like network.wan.dns='1.1.1.1' '8.8.8.8', but prefix it with "set " in batch doesn't seem do set a list.

12:09 <hgl> Ansuel, do you have time to take a look at the nginx PR? I'm still looking for a green light from a maintainer.

12:15 <Ansuel> Do you have a link? Is it the bump or nginx-util?

12:18 <hgl> Ansuel, here you go https://github.com/openwrt/packages/pull/19884, I'm looking to ditch nginx-util in favor of dynamic conf, want to know if you would give blessing to this approach. Also I want to model after uhttpd where http and https are separately offered, but Peter thinks it's better to only offer https. Would like your thought on that too.

12:20 <Ansuel> For Https I agree with Peter. Nginx already require openssl and it's a big package. Not much sense to ship stuff with no SSL support if the bin is already big enough to not be suitable for space constraints devices

12:21 <Ansuel> I need some time to read all the backlog for that pr

12:21 <hgl> cool, so we will make nginx redirect to https by default

12:22 <hgl> Ansuel: let me know if it's ok to proceed with further developing the PR.

12:23 <hgl> jow: I looked at the source code if uci. it seems "uci set" can only set an option and not a list?

12:31 <hgl> Ansuel: actually, there might be some misunderstanding, by "separately offering http and https", I don't mean compile nginx with or without openssl. I mean a solely difference in the default config we offer, you can find more info if you search "offer both http and https" in that PR comments.

12:33 <Ansuel> Nono i got it right and for me I would set the redirect by default

12:34 <hgl> ok

12:44 <nick[m]12> hauke: I can try starting from a very clean state again. However, I thought I did this already.

12:56 <rmilecki> hgl: i think "uci set" is for setting option value only (not a list)

12:56 <rmilecki> some options may be interpreted by init.d scripts or UI code as lists anyway but i'd suggest to keep config files correct instead of depending on some extrae behaviour

12:56 <rmilecki> hgl: so "uci add_list"

12:57 <hgl> rmilecki: got it. so if I want to ensure a list only contains the values I want, i should do "uci delete" and "uci add_list" I guess?

12:57 <rmilecki> hgl: yes I believe so

12:57 <hgl> cool, thanks

13:31 <KGB-0> https://tests.reproducible-builds.org/openwrt/openwrt_omap.html has been updated. (11.1% images and 100.0% packages reproducible in our current test framework.)

23:32 <tersono> It seems like when `python3/host` has been installed into `hostpkg/bin` subsequent dl_github_archive.py calls will fail due to lack of pyOpenSSL. Seems like dl_github_archive.py should be called with a different PATH that excludes hostpkg/bin?

23:55 <dwfreed> python3/host should be fixed or eliminated

23:56 <dwfreed> at the same time, I don't see any mention of pyopenssl in dl_github_archive.py ?

23:58 <dwfreed> a build log would be helpful