On Tue, Oct 23, 2018 at 02:41:44PM -0000, Mathieu Trudel-Lapierre wrote: > Confirming, we've used this change (_IO_ftrylockfile replaced by > _IO_EOF_SEEN) in other packages that FTBFS with the new toolchain. > > Please also make sure _IO_IN_BACKUP is defined (to 0x100) if it's being > used.
This raises the question *why* it is using glibc internal datastructures. I'm really skeptical of all the code in the gl/ directories: https://sources.debian.org/src/oath-toolkit/2.6.1-1.2/oathtool/gl/parse- datetime.y/?hl=1254#L1254 This routine looks pretty subtle, and while it's got the benefit of (a) starting from Steven M. Bellovin (b) thirty years of refinement, I'm skeptical how it would handle malicious inputs. It also appears in gnulib: https://sources.debian.org/src/gnulib/20140202+stable-3/lib/parse- datetime.y/?hl=1254#L1254 which may or may not have had fixes applied to it over the years. Certainly it'd be easier to fix it only in one place regardless of if the two versions are identical or have diverged. Here's a big gob of disgusting memory allocation wrapper around malloc(3): https://sources.debian.org/src/oath-toolkit/2.6.1-1.2/oathtool/gl/malloca.c/ https://sources.debian.org/src/oath-toolkit/2.6.1-1.2/oathtool/gl/xalloc.h/ This *looks* like it tries to avoid integer overflow issues in an nmalloca(n,s) macro: https://sources.debian.org/src/oath- toolkit/2.6.1-1.2/oathtool/gl/malloca.h/#L78 But why on earth wouldn't you just use calloc(3) and let the system library handle it? (I can't tell you if it's actually done the math correctly or not. It's subtle.) Did I overlook something from gl/ that *wasn't* from gnulib? While I don't want to just drag gnulib into main on a whim, I wonder how many other packages might have vendored in some or all of gnulib anyway. There's 35 packages that have a function named parse_datetime in C sources on Debian Code Search: https://codesearch.debian.net/search?q=parse_datetime+filetype%3Ac&perpkg=1 Of that list, coreutils, dovecot, tar, patch, libdbi-drivers, unixodbc, python-numpy, lftp, gnutls28, bluez, cpio, findutils, libdbi, are in main. Maybe gnulib is vendored in a lot more places than we thought? I've so far decided to skip reviewing everything in gl/ directories because (a) it's entirely too subtle and likely too brittle (b) if it *is* "just" gnulib then maybe we can or should remove all of it anyway. Thanks -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1783706 Title: [MIR] oath-toolkit To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/oath-toolkit/+bug/1783706/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
