**** BEGIN LOGGING AT Sun Dec 22 02:59:58 2019 Dec 22 07:12:38 * enyc meows Dec 22 10:37:18 jow: ynezz ping Dec 22 11:26:25 Will it be possible to update wireguard to its latest version in OpenWrt 19.07? Dec 22 12:04:32 ldir: pong Dec 22 12:05:58 ynezz: ha - just this second sent my solution to the uhttpd email Dec 22 12:07:13 I'm surprised coverity doesn't flag strtounsignedtype being stored in a signed type Dec 22 12:12:57 I've started with uhttpd few days ago https://gitlab.com/ynezz/openwrt-uhttpd/commits/wip Dec 22 12:13:39 it needs more work before it can be fuzzed Dec 22 12:13:50 Pepe: i can share a patch, it's pretty easy Dec 22 12:14:01 but that would involve you rolling your own build, of course Dec 22 12:19:43 ynezz: I did say an adult would be along with a sensible solution :-) Dec 22 12:32:23 ldir: i prepared branch for bisecting that fstools bug Dec 22 12:32:29 ldir: could you take a look at https://git.openwrt.org/?p=openwrt/staging/rmilecki.git;a=shortlog;h=refs/heads/fstools-split please? Dec 22 12:32:53 ldir: there are 7 commits like "fstools: update to the ..." Dec 22 12:33:04 ldir: could you find the first one that breaks fstools for you? Dec 22 12:34:27 Is it non-trivial these days to use gdbserver to get a meaningful backtrace for a userspace segfault bug like that? Dec 22 12:35:40 PaulFertser: i could use gdb but I can't reproduce that crash Dec 22 12:36:22 rmilecki: but ldir can reproduce it, and with script for remote gdb it used to be really easy to get a backtrace. I assumed that's easier than bisecting. Dec 22 12:37:17 It was really so pleasant to use it. Dec 22 17:42:21 jow: is there a way to have the wpad-*ssl packages provide for wpad-basic? I am using per_device_rootfs and this issue is biting me: https://bugs.openwrt.org/index.php?do=details&task_id=2513 Dec 22 17:54:57 rmilecki: ping Dec 22 18:06:00 Borromini: try if it works, if yes we could do it Dec 22 18:06:27 jow: will do Dec 22 18:07:47 rmilecki: I'll try - I'm quite busy over next few days so won't be for a while Dec 22 18:16:15 ldir: interestingly I am unable to reproduce the crash either after rebuilding the package locally with debug info enabled Dec 22 18:16:26 before a simple "block info" was enough to make it segfault Dec 22 18:17:24 oh you could make blkid segfault as well? Dec 22 18:18:26 Heisenbug :-) Dec 22 18:19:04 the segfault only happens if the full libblkid is installed Dec 22 18:19:18 block will dynamically load blkid.so at runtime via dlopen if it is avaialble Dec 22 18:19:33 the segfault appears to happen in blkid_probe_free_value Dec 22 18:21:19 I assume the problem is due to https://git.openwrt.org/?p=project/fstools.git;a=commitdiff;h=b82c5c109c8545da1c4fea46e102aef25896c0e4 Dec 22 18:21:49 which now causes https://git.openwrt.org/?p=project/fstools.git;a=blob;f=probe-libblkid.c;h=870965e0528faedca15dbd042a0d25feff4785e5;hb=111a43f8c64683e79859dcb3f4b7aa437e24502b#l47 to resolve the wrong function pointer Dec 22 18:22:13 which, when called, will segfault because it operates on a foreign struct layout Dec 22 18:22:33 bet that was fun to figure out Dec 22 18:23:01 it actually took only a minute or so Dec 22 18:23:04 * ldir is glad there are two adults present :-) Dec 22 18:23:19 the most time was spent rebuilding half of openwrt ... again Dec 22 18:24:36 problem is that I need to be able to reproduce it with a self built executable first Dec 22 18:34:52 jow: what i should be looking at is how libustream does it, right? Dec 22 18:37:52 is my 2nd uhttpd fix more suitable? Dec 22 18:45:29 a bit of range checking at the expense of a temporary variable Dec 22 18:50:41 ldir: what about using strol() instead of strtoul() and simply erroring on negative reuslts? Dec 22 18:52:19 I don't see how a negative content length can ever be a valid thing. Dec 22 18:53:19 and you've halved your acceptable positive range by using a signed type Dec 22 18:53:56 and it still doesn't cope with the conversion of long int to int Dec 22 18:56:25 ldir: http://sprunge.us/u2Y0gc Dec 22 18:56:50 ldir: well it will get assigned to a signed struct field, so we don't lose any range compared to before Dec 22 18:57:25 I change the type in the struct Dec 22 18:57:26 and parsing the input as signed, then discarding negative feels safer and simpler to follow than parsing to unsigned, assigning to signed and attempting to catch corner cases Dec 22 18:57:34 jow: ldir: ynezz: I would like to tag and start building of 18.06.6 on 1. Jan including these fixes Dec 22 18:57:44 Hauke: fine with me Dec 22 18:58:00 and then 19.06 final on the next weekend Dec 22 18:58:26 so tagging 19.06 on 4. Jan Dec 22 18:59:09 I will try to looks through the bug reports again Dec 22 18:59:12 s/change/changed Dec 22 19:01:23 https://paste.ubuntu.com/p/rkn5hhgwNq/ Dec 22 19:02:28 * ldir has to drive home now Dec 22 19:05:29 updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html Dec 22 19:12:50 stintel: I'm currently going through all devices in ath79/image/generic.mk and the others in this target to see which of them need smallbuffers. Dec 22 19:17:12 Thanks PaulFertser Dec 22 19:18:32 Lots of small devices out there. Would be a shame if they ran out of mem out of the box %) Dec 22 19:26:05 jow: setting wpad-openssl to and adding it to the TARGET_DEVICE_PACKAGES content makes more sense than hacking everything to smithereens :-) nevermind me. Dec 22 19:27:33 Now I see how having specs in commit message helps :) Dec 22 20:25:23 blogic: still here? Dec 22 20:30:05 jow: got home - and can confirm your patches fixes the fstools bump for me :-) Dec 22 20:35:12 ldir: regarding uhttpd, what about simply declaring the content_length member as size_t or uint64_t ? Dec 22 20:35:26 this way we do not need those additional checks at all Dec 22 20:35:52 your INT_MAX check makes sense too, but that would artificially limit the size on 64bit systems Dec 22 20:39:06 Doesn't MAX_INT change value based on whether it is a 64bit int or 32bit int system? Dec 22 20:42:25 and to answer the other question... I guess I was nervous of combining 'int' v 'long int' types in arithmetic operations, but then c should promote the smaller to larger. And then everything natively 32bit has to do all the promoting. Dec 22 20:42:36 not sure, but thats exactly what I meant with hard to follow, or rather hard to assert correct function from reading the code Dec 22 20:42:50 thats my take on a fix: http://sprunge.us/XsPEQ2 Dec 22 20:43:03 essentailly standardize on the behaviour on 64bit systems Dec 22 20:43:30 it seemed odd to me to find a 'length' going into a signed type especially when fed from a strtoul Dec 22 20:43:42 yeah, that makes no sense at all Dec 22 20:45:27 its also not used negatively anywhere Dec 22 20:45:44 indeed. Dec 22 20:46:52 so either we declare contetn_length to be identical to the return value of strtoul(), which means uint32_t on 32bit and uint64_t on 64bit systems Dec 22 20:46:59 but I've not idea how standard the 'long' in strtoul or indeed strtoull actually is Dec 22 20:47:23 or we handle it as uint64_t in all cases and also lift the 4GB (actually 2GB limit right now) while we're at it Dec 22 20:47:37 atroull() is C99 iirc Dec 22 20:47:40 *stroull() Dec 22 20:48:12 I guess 64 bit it is then :-) Dec 22 20:49:24 I vaguely remember there being a 'chunk length' as well. (it was this morning) Dec 22 20:49:45 does that need similar attention Dec 22 20:52:31 yes Dec 22 20:52:48 i also assignes the unsigned long int produced by strtoul() to int Dec 22 20:57:16 ha, oh dear. ok, I'll take a look at that tomorrow as it's been a long & tiring day today Dec 22 21:20:40 jow: pong, thanks a lot for looking at that fstools/block thing Dec 22 21:20:49 jow: i had no idea about that dlopen code Dec 22 21:21:11 ldir: actually we can't go the strtoull() route because ustream_consume() expects an init Dec 22 21:21:14 *int Dec 22 21:21:54 jow: double thanks for a fix! :) Dec 22 21:21:54 so without extensive refactoring of the surrounding code, r->content_length may never exceed 2^31 Dec 22 21:22:05 rmilecki: yw, np Dec 22 22:04:17 jow: so irony is that the original patch from the reporter is actually the best - keep the signed type and check for < 0. hilarious Dec 22 22:04:24 * ldir can't sleep Dec 22 22:12:39 ldir: indeed, I took this one now, extended it to the second instance of the bug and pushed it to all relevant branches Dec 22 22:13:32 ldir: and it highlights an issue neoraider has brought up long ago already, the damned use of `int` for size values throughout our libraries Dec 22 22:14:05 I mean take ustream_consume() as an example, it makes no sense at all that this function takes a signed int Dec 22 22:14:15 and even worse, that it even uses negative values unchecked Dec 22 22:15:41 I also want to live dangerously Dec 22 23:01:25 jow: I'm not the OP from https://forum.openwrt.org/t/wireguard-gui-in-luci-buggy/50983/2 but your referenced commit doesn't fix the wireguard peer list display issue - but there's a second max-height in cascade.css, removing that one as well indeed fixes it for me http://paste.debian.net/1122185/ Dec 22 23:43:04 ugh that libcxx commit is broken in several subtle ways Dec 22 23:43:18 I guess I'll write a fix. Dec 23 00:21:25 mangix: thanks for taking care **** BEGIN LOGGING AT Mon Dec 23 01:22:49 2019 Dec 23 02:30:59 Of course. Patch is on the mailing list Dec 23 02:31:31 next step is to deprecate uclibc++, but I'd like to do more testing. **** ENDING LOGGING AT Mon Dec 23 03:00:01 2019