**** BEGIN LOGGING AT Fri Oct 30 02:59:57 2020 Oct 30 03:31:17 build #548 of x86/legacy is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/x86%2Flegacy/builds/548 Oct 30 05:26:44 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_tegra.html has been updated. (0% images and 100.0% packages reproducible in our current test framework.) Oct 30 13:41:11 Been fighting all morning with openssl, trying to persuade it to build with LTO, to no avail. I am disappoint. Oct 30 15:49:39 dangole: Mind if I add CONFIG_OWE=y to the basic-{openssl,wolfssl} variants? :) Oct 30 15:51:13 rsalvaterra: it's worth considering. i'd agree, but we need to watch size increase caused by that. if it's a just few kB, then we should do it. Oct 30 15:52:03 Let me do a quick build, I'll tell you the exact difference. But I know it's around 10 kiB. Oct 30 15:57:55 12 352 bytes difference for hostapd-basic-openssl (74Kc -O2). Oct 30 16:01:36 My final image size didn't change (it's padded to 64 kiB, it seems). Oct 30 16:22:47 It might also be worth noticing that enabling epoll() hasn't changed my hostapd binary size at all. Oct 30 16:38:38 rsalvaterra: i generally agree thew epoll() is of course better than select(). just make sure none of the ubus interfaces hostapd/wpa_supplicant are offering breaks with that change (which is the only breakage I would imagine could happen by such a change) Oct 30 16:39:19 dangole: If you're reading this, it's probably working, since I'm already running it on my router. ;) Oct 30 16:41:20 rsalvaterra: at least config_add/config_remove are working then... Oct 30 16:54:16 Anyway, I'm going to let it simmer for a couple of days. Oct 30 16:54:47 The OWE patch, however, is good to go. Oct 30 17:05:03 is there some work done to add amlogic SoC devices (sbc) or i would have to start from scratch with that? Oct 30 17:26:30 damex: i'm not aware of anything already done on that front. Oct 30 17:53:03 dangole i worked on my selinux presentation can you have a look? https://defensec.nl/~kcinimod/misc/Enhancing%20OpenWrt%20Security%20with%20Security-Enhanced%20Linux.pdf Oct 30 17:59:35 grift: one question I'd have is "oh, why not have root/user separation in openwrt?" and your presentation doesn't touch that at all Oct 30 18:04:36 good point i will address that SwedeMike Oct 30 18:05:19 but just to answer that here , obviously that should also be leverage (defense in depth and all) Oct 30 18:05:35 but even so, that is still DAC and subject to the flaws of DAC Oct 30 18:07:39 i mean lets say you have a service with a private identity, that service can still do a chmod o+rwx on any file it owns Oct 30 18:08:38 or even setuid bit Oct 30 18:16:45 damex: you could ask xdarklight he works on upstream amlogic Oct 30 18:17:48 SwedeMike: this is how i (briefly) addressed it on the SELinux slide: Oct 30 18:17:53 "Complements DAC (it is not a replacement, and you can -and should- also leverage DAC to the full extent)" Oct 30 18:21:50 grift: just looked at the slides and like what i see. on a meta-level, it'd be great if you'd also mention how much of a multi-stakeholder process this whole story has been, ie. first thomas and then mike getting the field prepared and then you stepped in to write the actual policy. Oct 30 18:22:18 grift: apart from the slides, did you address sysupgrade.tgz extraction in the policy? i saw that still failing when i last tried a few days ago... Oct 30 18:23:06 you mean via luci? Oct 30 18:24:15 i mean this works fine: ssh root@"$1" "sysupgrade -b -" >~/Downloads/backup-${1}-$(date +%F).tgz Oct 30 18:24:46 but if you mean via luci then yes thats still a todo item but not the only luci todo item Oct 30 18:25:22 grift: what i meant is when i do 'sysugprade openwrt.....' then it will come up after having flashed and restore stuff from sysupgrade.tgz Oct 30 18:25:42 and that triggered a few acl violations Oct 30 18:25:55 show me the avc denials please Oct 30 18:26:01 i cannot produce that issue Oct 30 18:26:26 grift: didn't log them, i'll test and send in a bit, still busy with something else right now Oct 30 18:26:46 but surely theres rough edges and loose ends Oct 30 18:26:50 goes without saying Oct 30 18:27:19 grift: just thought that sysupgrade is kinda more essential than having unbound or other things from packages feed... Oct 30 18:27:36 like i said, i cannot produce that sysupgrade issue Oct 30 18:27:53 and believe you me i do that alot Oct 30 18:28:36 grift: it works slightly different on NOR flash with jffs2, and that could be the cause for what i've been seeing Oct 30 18:29:03 but yes youre touching on the big issue Oct 30 18:29:23 it needs wide scrutiny and broad exposure testing on a wide array of configs Oct 30 18:29:34 booting from mmc probably also needs work Oct 30 18:29:48 thats just scratching the surface Oct 30 18:34:35 grift: emmc, sata and nvme should be kinda the same in the sense that it's the same type of filesystems used on top of a block device (which surely still is named differently and stuff, but the procedure is the same) Oct 30 18:35:18 yes but mmc is a removeable storage device unlike say sata and selinux is a bit more selective Oct 30 18:36:07 i differentiate between different classes of storage devices so i might have overlooked some access for that somewhere ( i think not but only way to tell for sure is to test it) Oct 30 19:12:19 build #681 of octeontx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/octeontx%2Fgeneric/builds/681 Oct 30 19:16:44 build #676 of oxnas/ox820 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/oxnas%2Fox820/builds/676 Oct 30 19:38:25 build #667 of at91/sam9x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/at91%2Fsam9x/builds/667 Oct 30 19:50:06 but yes i guess one could argue whether it makes sense to associate mmc with removable storage in this space, maybe it makes more sense to just associate these types of deviced with fixed storage devices like sata, nvme (btw nvme is not supported currently in my policy) Oct 30 19:50:48 food for thought, but not sure whether its worth it to add extra rules to support nvme Oct 30 19:51:38 build #537 of mpc85xx/p2020 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fp2020/builds/537 Oct 30 20:39:11 grift: it is worth adding rules for nvme, many people are using PCIe based SSDs with x86 based router boards such as APU3 Oct 30 20:42:16 Some of mine SATAs are hot-pluggable too, but indeed as root device of owrt removing such does not make sense even if support is there.. could make sense for generally supporting, where user wants to do such Oct 30 20:44:47 damex: stintel worked on a meson target some time ago: https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=shortlog;h=refs/heads/meson Oct 30 20:46:21 damex: we're working hard upstream to continuously add support for more hardware bits and also taking care of any bugs. personally I go with "latest = greatest" so don't test with stable kernels very often, but I think all relevant patches are backported to stable kernel versions Oct 30 20:46:41 dangole ok will adds nvme support in, its modular so can just include it be default and allow people to exclude it Oct 30 20:48:37 olmari yes same applies to mmc i guess, so i will consider associating them with fixed disks just like sda/nvme etc Oct 30 20:49:07 its just that booting from mmc isnt that widely supported Oct 30 20:49:16 but it is on raspi i guess Oct 30 21:21:26 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.) Oct 31 02:23:54 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_ar71xx.html has been updated. (99.1% images and 100.0% packages reproducible in our current test framework.) **** ENDING LOGGING AT Sat Oct 31 02:59:57 2020