1. 10 Jun, 2020 3 commits
  2. 15 Apr, 2020 3 commits
  3. 08 Apr, 2020 7 commits
    • evpobr's avatar
      Silence some CMake build MSVC useless warnings · 4d963fe0
      evpobr authored
      Supress warnings about unsafe and deprecated functions like this: strcat is unsafe, use `strcat_s` instead and so on.
      Signed-off-by: Ralph Giles's avatarRalph Giles <giles@thaumas.net>
    • evpobr's avatar
      Export public function on MinGW platform · 1ffc217c
      evpobr authored
      MinGW produces DLLs, but exports nothing.
    • evpobr's avatar
      Fix CMake include install directory · 7fd53df5
      evpobr authored
    • evpobr's avatar
      Fix CMake config-file package generation · de8dc5af
      evpobr authored
    • Ralph Giles's avatar
      travis-ci: Build on the xcode11 macOS image. · e2887fca
      Ralph Giles authored
      Fix the macOS builds on the travis-ci.org continuous integration
      system by requiring a more recently-created system image where
      homebrew packages install correctly.
      Also switch to declarative syntax for the homebrew package
      dependencies, using the built-in Brewfile support instead
      of invoking `brew` explicitly.
      Travis doesn't update the homebrew three on their default macOS
      images, so over time available packages become out-of-date, or
      any explicit update step takes longer and longer, slowing the
      testing feedback loop.
      In this particular instance jobs were failing because homebrew
      on the default macOS image wasn't working at all. Without an
      update, package installation failed because the `brew bundle`
      subcommand had itself bitrotted, while running `brew update`
      would time out, taking more than the allowed job time.
      Requiring a more recent (non-default) macOS image gets out
      tests working again. In the future this will probably need
      to be bumped again or rest...
    • Ralph Giles's avatar
      win32: Update VS2010 project files for ogg library name. · ef3a5dae
      Ralph Giles authored
      The ogg project changed the default target, making libogg.lib
      a static library instead of libogg_static.lib. Update our
      build to match.
      The VS2005 and VS2008 projects are left as-is, because
      I have no way to test them and they likely aren't in
      active use.
    • Ralph Giles's avatar
      appveyor: Use the correct ogg solution file. · c4fa0fac
      Ralph Giles authored
      In ogg commit 6d55ddf64b65, the static build was made the
      default, removing the separate static target solution file,
      breaking our build on the Appveyor continuous integration system.
  4. 07 Apr, 2020 3 commits
  5. 18 Jan, 2020 1 commit
  6. 29 Jan, 2019 3 commits
  7. 28 Jan, 2019 6 commits
  8. 05 Jul, 2018 1 commit
  9. 23 May, 2018 3 commits
  10. 17 May, 2018 2 commits
  11. 09 May, 2018 1 commit
  12. 09 Apr, 2018 1 commit
  13. 21 Mar, 2018 1 commit
  14. 16 Mar, 2018 4 commits
  15. 11 Dec, 2017 1 commit
    • Guido Günther's avatar
      CVE-2017-14632: vorbis_analysis_header_out: Don't clear opb if not initialized · c1c2831f
      Guido Günther authored
      If the number of channels is not within the allowed range
      we call oggback_writeclear altough it's not initialized yet.
      This fixes
          =23371== Invalid free() / delete / delete[] / realloc()
          ==23371==    at 0x4C2CE1B: free (vg_replace_malloc.c:530)
          ==23371==    by 0x829CA31: oggpack_writeclear (in /usr/lib/x86_64-linux-gnu/libogg.so.0.8.2)
          ==23371==    by 0x84B96EE: vorbis_analysis_headerout (info.c:652)
          ==23371==    by 0x9FBCBCC: ??? (in /usr/lib/x86_64-linux-gnu/sox/libsox_fmt_vorbis.so)
          ==23371==    by 0x4E524F1: ??? (in /usr/lib/x86_64-linux-gnu/libsox.so.2.0.1)
          ==23371==    by 0x4E52CCA: sox_open_write (in /usr/lib/x86_64-linux-gnu/libsox.so.2.0.1)
          ==23371==    by 0x10D82A: open_output_file (sox.c:1556)
          ==23371==    by 0x10D82A: process (sox.c:1753)
          ==23371==    by 0x10D82A: main (sox.c:3012)
          ==23371==  Address 0x68768c8 is 488 bytes inside a block of size 880 alloc'd
          ==23371==    at 0x4C2BB1F: malloc (vg_replace_malloc.c:298)
          ==23371==    by 0x4C2DE9F: realloc (vg_replace_malloc.c:785)
          ==23371==    by 0x4E545C2: lsx_realloc (in /usr/lib/x86_64-linux-gnu/libsox.so.2.0.1)
          ==23371==    by 0x9FBC9A0: ??? (in /usr/lib/x86_64-linux-gnu/sox/libsox_fmt_vorbis.so)
          ==23371==    by 0x4E524F1: ??? (in /usr/lib/x86_64-linux-gnu/libsox.so.2.0.1)
          ==23371==    by 0x4E52CCA: sox_open_write (in /usr/lib/x86_64-linux-gnu/libsox.so.2.0.1)
          ==23371==    by 0x10D82A: open_output_file (sox.c:1556)
          ==23371==    by 0x10D82A: process (sox.c:1753)
          ==23371==    by 0x10D82A: main (sox.c:3012)
      as seen when using the testcase from CVE-2017-11333 with
      008d23b782be09c8d75ba8190b1794abd66c7121 applied. However the error was
      there before.