**** BEGIN LOGGING AT Fri Feb 21 02:59:57 2020 Feb 21 08:15:47 jow: jow, related to https://github.com/openwrt-routing/packages/issues/548 it's somehow sensitive data, how can I sent it to you? Feb 21 08:16:55 OK, posted, heh Feb 21 09:28:21 jow: any idea what could cause `command timed out: 3600 seconds without output running` on some targets for 18.06/19.07 packages? Feb 21 09:29:53 should I just trigger new builds for those failed targets? Feb 21 09:30:31 I mean just those which were building fine before the ppp fixes? Feb 21 09:31:03 ah, it's only on 19.07 Feb 21 09:31:07 18.06 is fine Feb 21 09:47:17 ynezz: it happens if the stadio does not change for over an hour Feb 21 09:47:40 there's some gems like nodejs whose compile process can take very long, depending on the host Feb 21 09:48:22 ah, nice, thanks :) Feb 21 09:48:37 *stdio Feb 21 09:48:55 we had a similar issue for rsync transfers on master Feb 21 09:48:57 yep, I understood that form the original error message Feb 21 09:49:04 s/form/from/ Feb 21 09:49:08 or on phase1 rather... there we worked around with pv Feb 21 09:49:40 * ynezz lookups pv Feb 21 09:49:40 pv has a mode where it prints a timestamp ever N seconds Feb 21 09:50:41 if you pipe the package/compile's stadout through `pv -t -i 60 -f` it should print a timestamp every 60s, avoiding the stdio timeout error after 3600 Feb 21 09:51:05 of course it can be that the buildworker is genuinely dead, due to connection issues or whatever Feb 21 09:51:29 so it's buildmaster killing the stuck buildworker? Feb 21 09:51:56 from the log is not that clear, looks like it was killed by the worker itself Feb 21 09:53:13 right, the killing happens worker side but I am unsure whether the timeout is asserted on the master or the worker Feb 21 09:53:26 but I suppose on the worker, so disregard my connection issue remark Feb 21 09:53:41 seems like the master is some weird state as well, at http://buildbot.openwrt.org/openwrt-19.07/packages/grid I can see, that `arm_cortex-a9_vfpv3` is marked as `building` on the main page Feb 21 09:54:16 but under http://buildbot.openwrt.org/openwrt-19.07/packages/builders/arm_cortex-a9_vfpv3 there is no such build in progress Feb 21 09:56:06 anyway it's just i386_pentium and mips32 (lantiq/ase) failing, which are probably some niche targets, so we're probably good to go to release that SA about ppp, what do you think? Feb 21 09:56:06 yeah that happens sometimes Feb 21 09:56:30 ynezz: do you want to do a point release or solely rely on package updates? Feb 21 09:57:21 I would like to get SA out ASAP, which means package updates Feb 21 09:57:35 point release depends on the release manager(s) :) Feb 21 09:58:27 I believe, that its realy just a DoS, not RCE Feb 21 09:58:53 I mean in OpenWrt case Feb 21 10:00:19 okay, then put out the sa and add it here: https://openwrt.org/advisory/start Feb 21 10:00:33 yep, nice work, thanks :) Feb 21 10:00:56 ideally do a short summary in the mail and link to the wiki page, that allows us to ad updates later Feb 21 10:01:18 I'll likely follow up with point releases during the weekend Feb 21 10:02:38 ldir: could you please check/correct my czechnglish in the ppp SA? Feb 21 10:03:28 guifipedro[m]: can you increase PKG_RELEASE to 6 in https://github.com/openwrt-routing/packages/blob/82ec94c80d8b5a8da2972b9a9ede6247e3f1d0a5/luci-app-bmx6/Makefile Feb 21 10:03:42 guifipedro[m]: then I can merge and backport that pr Feb 21 10:03:43 jow: would be nice to announce that point release plan on the mailing list Feb 21 10:04:09 I'll try to look at that libubox breakage hopefully soon Feb 21 10:04:12 was the pppd fix backported to 18.06 ? Feb 21 10:04:17 yes Feb 21 10:04:20 good Feb 21 10:04:40 ynezz: I'm ahppy to help test there. Feb 21 10:05:03 karlp: there is probably fix/test case in that bug report Feb 21 10:06:01 jow: done Feb 21 10:06:10 well, "/etc/init.d/umdns restart" is enough :) Feb 21 10:06:24 hm, how is that? Feb 21 10:06:30 gives error? still broken. no error? probably fixed Feb 21 10:06:46 from my understanding it shouldn't work all the time Feb 21 10:06:54 well, it doesn't work at all right now, no. Feb 21 10:07:10 presumably, when libubox fixed, it will start working again Feb 21 10:07:32 but it gives an error on the restart, so it's an easy test path. Feb 21 10:19:12 ynezz: sure, where should I look ? Feb 21 10:42:01 ldir: it's in the mail contact@openwrt.org Feb 21 10:42:10 should I put it somewhere online? Feb 21 10:44:45 If you could that would be great 'cos some of those contact@ end up in my spam folder etc etc. Feb 21 10:49:59 ldir: https://pad.riseup.net/p/QFlitrbN9868jcKBA8Fr-tmp Feb 21 11:42:35 ` * opkg_install_cmd: Cannot install package luci-compat.` why? Feb 21 11:43:12 in `.config` it appears as `CONFIG_PACKAGE_luci-compat=m` Feb 21 12:00:50 (recompiling from scratch) Feb 21 12:08:13 ynezz: ok, I've had a try, I think it's better..... but who knows if I've introduced further issues :-) Feb 21 12:10:46 ldir: thanks! Feb 21 12:14:24 guifipedro[m]:it normally says something else after that? Feb 21 12:25:05 errr, I think I got confused, and I was doing wrong things (startin again, but I think there is no trouble with luci-compat) Feb 21 14:10:18 can somebody quickly explain me what pad-rootfs is doing? Feb 21 14:13:54 AFAICT, it pads to the nearest erase block and places jffs2 erase marker so that an attempt to mount rootfs_data on the first boot would automatically lead to proper results. When sysupgrade is keeping configs, it tars them and replaces the erase marker with minimal jffs2 system containing just the archive. Feb 21 14:18:57 okay, because I was a little surprised that the image after pad-rootfs has a size which cannot be divided by 1024, but pad refers to something different here then Feb 21 14:19:25 is it a multiple of 1024 + 4 ? Feb 21 14:20:09 5898244 Feb 21 14:20:21 so yes Feb 21 14:20:23 yes Feb 21 14:20:46 are the 4 extra bytes 0xdeadbeef ? Feb 21 14:23:12 sorry, 0xdeadc0de Feb 21 14:23:22 deadc0de, yes Feb 21 14:23:59 thats the signature for the first block after rootfs where the kernel starts erasing Feb 21 14:24:09 and formatting jffs2 in Feb 21 14:24:21 it also marks the beginning of the virtual rootfs_data mtd partition Feb 21 14:24:30 So my description was accurate Feb 21 14:24:54 I see Feb 21 14:27:14 thanks Feb 21 14:30:17 d00dbeef Feb 21 15:40:44 beefcace Feb 21 15:45:33 Hi. I need some help, I can see that "uci" registers the function "apply" to ubus Feb 21 15:45:39 ubus -v list uci Feb 21 15:45:58 "apply":{"rollback":"Boolean","timeout":"Integer","ubus_rpc_session":"String"} Feb 21 15:46:14 but where is the definition of such function? Feb 21 15:46:21 I connot find it anywhere Feb 21 15:46:27 ANybody can help? Feb 21 15:47:23 user95: that function is hosted by rpcd Feb 21 15:48:14 https://git.openwrt.org/?p=project/rpcd.git;a=blob;f=uci.c#l1561 Feb 21 15:48:37 jow, thanks a lot Feb 21 15:48:44 will look into it Feb 21 16:53:06 ynezz: thanks for handling the ppp matter. A very minor nitpick... can you mention the CVE id somewhere in the commit message next time? That makes tracking it easer Feb 21 16:53:54 problem right now is that we neither increased the usptream version nor mention the ID in the commit. The patch filenames and their contents do not contain the ID either, so its impossible to see from the outside that it is fixed Feb 21 16:54:02 we'll likely receive further reports due to that Feb 21 16:55:09 what we could do is renaming the patches in new commit to contain the CVE refs Feb 21 16:55:14 you can choose the ugly way: revert and apply again with CVE id Feb 21 16:56:02 Would be the easiest to understand IMO, though Feb 21 16:56:33 or a noop commit with the CVE mentioned Feb 21 16:57:00 like git.openwrt.org/2375e279 Feb 21 16:57:30 :D Feb 21 16:57:39 be my guests Feb 21 16:57:48 In principle, you could even do --allow-empty Feb 21 16:57:56 I'll do an empty commit Feb 21 16:58:05 oh cool, did not know about --allow-empty Feb 21 16:58:09 TIL! Feb 21 16:58:39 I'd personally prefer the revert solution if I did it, but don't care if someone does something else Feb 21 16:58:43 actually... no-op is bad because it has no relation to the package being patched Feb 21 16:59:00 ah, that's true Feb 21 16:59:02 well, I've probably misread that email, it looked like a private info Feb 21 16:59:15 so thats why I've commited it that way Feb 21 16:59:50 ynezz: no problem at all. I'll do as adrianschmutzler suggested and will revert + recommit with CVE ID Feb 21 17:00:00 then later when got more time, I've re-read it again and found out, that Debian patched it 14 days before us... Feb 21 17:00:12 there is something wrong in there Feb 21 17:01:09 or does Debian monitor all upstream Git logs for certain commit messages/patterns? Feb 21 17:01:23 ynezz: there is an invite-only oss-security list where representatives of large distro projects are subscribed Feb 21 17:01:30 ah Feb 21 17:01:34 thats why the large projects usually get some headway Feb 21 17:01:43 one need to apply for that to gain access Feb 21 17:02:03 well, it would be certainly nice Feb 21 17:03:35 wow, that tcpdump dot release had a lot of cves :) I guess that was automated testing Feb 21 18:43:44 jow: can you pin this for a few days (3?) https://forum.openwrt.org/t/security-advisory-2020-02-21-1-ppp-buffer-overflow-vulnerability-cve-2020-8597 Feb 21 18:47:09 ynezz: pinned until tuesday **** ENDING LOGGING AT Sat Feb 22 02:59:57 2020