**** BEGIN LOGGING AT Mon Feb 08 03:01:12 2021
Feb 08 05:55:45 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 98.3% packages reproducible in our current test framework.)
Feb 08 08:01:00 <owrt-snap-builds> build #737 of omap/generic is complete: Failure [failed tools]  Build details are at http://buildbot.openwrt.org/master/images/builders/omap%2Fgeneric/builds/737  blamelist: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>, Adrian Schmutzler <freifunk@adrianschmutzler.de>, Daniel Golle <daniel@makrotopia.org>, Szabolcs Hubai <szab.hu@gmail.com>, INAGAKI
Feb 08 08:01:00 <owrt-snap-builds> Hiroshi <musashino.open@gmail.com>
Feb 08 09:30:05 <ynezz> nbd: from your mail it's not clear which wolfssl version bump breaked the ABI, was it the latest 4.5.0 -> 4.6.0 ?
Feb 08 09:34:06 <Borromini> nbd: you might be right about there still being issues with MT7613 and radar detection, it seems one of my APs is now seeing radar events on channel 36 (5180 MHz). I guess it's seeing neighbouring APs and wrongfully thinks that's radar stuff? https://paste.debian.net/1184504/ - the weird thing is the other test AP is on channel 36 as well and no DFS error messages like these there yet. that one
Feb 08 09:34:12 <Borromini> has been brought up earlier though. I've seen it complain about possible radars on channel 52 as well yesterday, which other APs are using, and they just stay on that channel without radar reports.
Feb 08 09:34:16 <Borromini> sorry for the wall of text.
Feb 08 09:35:29 <ynezz> nbd: it would be nice if you could find some time and report it to wolfssl, they're quire responsive. wolfssl also think, that the current versions remain backward compatible https://github.com/wolfSSL/wolfssl/issues/3709#issuecomment-771746537
Feb 08 09:36:39 <ynezz> nbd: it might help them during consideration of some kind of stable releases/security backports
Feb 08 11:29:45 <nbd> ynezz: latest broke the ABI, but that wasn't the cause of my runtime issues
Feb 08 11:30:21 <nbd> ynezz: the bigger issue is that openwrt config changes affect the ABI too
Feb 08 11:42:39 <ynezz> lechner: ^
Feb 08 11:44:03 <nbd> the ABI changes between 4.5.0 and 4.6.0 are listed here: https://abi-laboratory.pro/index.php?view=compat_report&l=wolfssl&v1=4.5.0&v2=4.6.0&obj=0a67c&kind=abi
Feb 08 11:48:41 <ynezz> yep, but as you said, they're probably not diffing every possible config combination
Feb 08 11:48:55 <ynezz> which might provide quite different results
Feb 08 11:52:14 <ynezz> nbd: I've added your links to that issue https://github.com/wolfSSL/wolfssl/issues/3709#issuecomment-775090227
Feb 08 11:54:00 <figgyc> i'm doing some debugging for a spi-nor flash chip. is there a good way to send and recieve raw commands to/from it from inside openwrt? or will i need to hook it up to an external device eg a raspberry pi and do it from there? Thanks
Feb 08 12:02:37 <PaulFertser> figgyc: it's probably easier to connect it to rpi and use flashrom to check if the chip is good, what ID it has etc.
Feb 08 12:02:53 <figgyc> cool thanks
Feb 08 12:03:40 <PaulFertser> figgyc: depends on what kind of debugging you're doing of course, and what does the kernel spinor driver prints you currently.
Feb 08 12:04:26 <nbd> Borromini: it shouldn't even be running the radar detector on channel 36
Feb 08 12:04:39 <nbd> since it's not a DFS channel
Feb 08 12:04:40 <PaulFertser> figgyc: spi is not really command-oriented protocol, but you can write a simple userspace application using spidev to transmit/receive whatever you want. Shouldn't be needed with a regular m25p80 device.
Feb 08 12:05:42 <figgyc> yea I'm aware - not planning on looking at data, specifically just some obscure technical details about manufacturer ID's and stuff
Feb 08 12:07:55 <PaulFertser> figgyc: flashrom also supports jlink, ft232 and ch341 devices for that purpose, if you have one handy probably that'd be faster.
Feb 08 12:09:00 <nbd> ynezz: in general, even if wolfssl aims to remain ABI compatible, i'm still worried about the failure case if an ABI change is missed
Feb 08 12:09:46 <nbd> hard to debug segfaults or data corruption is so much worse than some extra churn on the buildbots
Feb 08 12:15:44 <ynezz> nbd: I've nothing against your proposal
Feb 08 12:16:42 <ynezz> it doesn't matter if it's wolfssl, openssl or mbedtls
Feb 08 12:16:48 <ynezz> or any other library
Feb 08 12:40:00 <Borromini> nbd: no, it shouldn't. might https://paste.debian.net/1184533/ play a role here? (is_mt7663 was replaced by mt7615_firmware_offload)
Feb 08 12:40:29 <Borromini> ie the filter for mt7663 isn't needed anymore once dfs is enabled for that as well right?
Feb 08 12:40:48 <Borromini> so just line 4 & 5 would suffice in that case i think?
Feb 08 15:12:50 <Borromini> nbd: i removed the if clause and now 36 isn't scanned for radar signals anymore. still seems to mistake other APs for radars, from what I can tell though. when you got time to have me test stuff or anything, let me know.
Feb 08 16:26:00 <owrt-snap-builds> build #738 of omap/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/omap%2Fgeneric/builds/738
Feb 08 20:07:42 <Hauke> There is a new vurnability in wolfssl, CVE-2021-3336 the linked pull request is not yet merged, should we integrate it into openwrt anyway?
Feb 08 21:14:25 <blogic> aparcar[m]: ;)
Feb 08 21:15:22 <blogic> I am worried about htis wolfssl convergence
Feb 08 21:15:43 <blogic> why not stay with ossl an dride the CVE wave as all other distros do
Feb 08 21:15:58 <blogic> *and ride*
Feb 08 21:16:36 <Borromini> frankly, i'm happy I moved my 16 MiB flash devices to openssl, seeing the wolfssl mess every time
Feb 08 21:16:52 <blogic> i role ossl always
Feb 08 21:17:14 <Borromini> blogic: openssl isn't a sensible option for 8 MiB devices I think... not when you need SSL for wpad etc
Feb 08 21:17:44 <blogic> well, its a crap vs crap formula
Feb 08 21:18:15 <blogic> sahll we support any old device or try to provide sane functionality
Feb 08 21:18:40 <blogic> it suddenly converges into a philosophical discussion
Feb 08 21:19:01 <blogic> sorry about the typos, fat finger + android display
Feb 08 21:20:37 <Borromini> no i understand. the middle ground is difficult.
Feb 08 21:21:21 <blogic> options are good but the question is what shall be the default
Feb 08 21:31:54 <stintel> WEP
Feb 08 21:31:56 * stintel hides
Feb 08 21:42:20 <Hauke> OpenSSL is the ssl lib with the best security support in my opineon
Feb 08 21:42:29 <Hauke> but it needs much more memory
Feb 08 21:42:36 <Hauke> compared to wolfssl and mbedtls
Feb 08 21:44:43 <karlp> wolfssl's openssl compat api layer is/was pretty flaky too. does it even still exist?
Feb 08 21:44:55 <karlp> I've not tried using it for a while, and it was just not worth even trying.
Feb 08 21:51:55 <owrt-snap-builds> build #649 of ath79/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Fgeneric/builds/649
Feb 08 22:07:34 <dorf> ugh. debugging Luci is an absolute pain in the ass.
Feb 08 22:08:22 <dorf> I see an element is off, and by the time I've highlighted it in the developer console to examine it, bingo, gone, ajax refreshed.
Feb 08 22:08:48 <dorf> And if I disable ajax, the element doesn't even display. Horrible.
Feb 08 22:09:51 <dorf> What would be 30s to correct in any sane interface takes minutes.
Feb 08 22:10:27 <dorf> The absence of a configuration option in the UI to determine refresh interval should be fixed.
Feb 08 22:11:29 <dorf> The whole model of using javascript to draw html elements is whack.
Feb 08 22:16:31 <dorf> pause at execution was what I wanted. what a dance to correct alignment!
Feb 08 22:18:20 <ynezz> speaking of wolfssl, the same could be said about dnsmasq, dropbear, uhttpd, <put anything network facing with "micro" in description here>
Feb 08 22:20:55 <karlp> well, dnsmasq is actually _used_ heavily by heappppps of people inside container world
Feb 08 22:21:01 <karlp> woflssl.... not so much?
Feb 08 22:21:06 <karlp> uhttpd, way even less?
Feb 08 22:21:10 <ynezz> https://github.com/guidovranken/cryptofuzz#bugs-found-by-cryptofuzz
Feb 08 22:24:26 <ynezz> "I've written a Cryptofuzz module that tests their cryptography API. 7000 lines of harnessing code. I honestly can't think of any software that is fuzzed so deeply."
Feb 08 22:24:38 <ynezz> that's about wolfssl BTW
Feb 08 22:24:58 <ynezz> that guy is author of opkg mitm CVE
Feb 08 22:25:41 <ynezz> and I assume this CVEs are result of this effort
Feb 08 22:28:42 <hurricos> ynezz: so this sweat over wolfssl convergence is basically just this one guy eating the whole thing for breakfast and heading to the loo?
Feb 08 22:29:07 <hurricos> good for wolfssl, beat the CVEs out early
Feb 08 22:30:42 <karlp> meh, if it gets beaten on, it will get beaten on,
Feb 09 00:59:35 <Grommish> karlp: people don't realize it's not a "if" something will be broken, but how, and how badly.  No "security" solution stands up against time and persistence
Feb 09 01:00:49 <Grommish> Even air-gapped systems are vulnerable to side-channel exfil of data if they really want it and have the time
Feb 09 01:15:57 <karlp> I think we agree :)
Feb 09 01:16:23 <karlp> I was trying to say that it might be nice if wolfssl has some fuzzing, but if it gets used a lot, it will get targetted and broken.
**** ENDING LOGGING AT Tue Feb 09 03:00:29 2021