[Bug 1783706] Re: [MIR] oath-toolkit

[Seth Arnold]

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
OpenStack, which is subscribed to oath-toolkit in Ubuntu.
https://bugs.launchpad.net/bugs/1783706

Title:
  [MIR] oath-toolkit

Status in oath-toolkit package in Ubuntu:
  New

Bug description:
  [Availability]
  In universe

  [Rationale]
  New dependency for ceph (radosgw)

  [Security]
  One CVE found:
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-7322

  Resolved in versions in Ubuntu

  [Quality assurance]
  Upstream tests run as part of package build.

  [Dependencies]
  All in main

  [Standards compliance]
  Older style CDBS package but OK.

  [Maintenance]
  Two non-maintainer uploads in Debian; A new point release is available from 2016
  ubuntu-openstack team in Ubuntu

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/oath-toolkit/+bug/1783706/+subscriptions