OpenImageIO

We continue to support a prior stable production release (different from the master where ongoing development happens), and as needed by major users will also backport important fixes to the major release prior to that.

GitHub issues https://github.com/OpenImageIO/oiio/issues

https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/master/SECURITY.md https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/master/CHANGES.md

We report fixed vulnerabilities in the release notes.

https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/master/SECURITY.md

Coding style guide in the https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/master/CONTRIBUTING.md

We use clang-format to enforce formatting aspects of the coding guidelines, and having no required clang-format changes is one of the CI tests! So we don't accept any patches that aren't in the preferred formatting style.

CMake build system honors the usual settings.

Debug build mode is supported, and even optimized release build mode does not strip symbols.

No recursive build

Repeatable build process using CMake

Most major distros have OpenImageIO in their package managers. Also, we generate python wheels, so people can "pip install openimageio."

Standard POSIX conventions.

We have scripts (used for our own CI) that will install the major dependencies, download test data, do builds and tests, etc. Also, there is a build-time option to automatically download and locally install dependencies if they are not already found on the system.

The project has very few fixed external dependencies, in the sense that it is a practical requirement that this package be buildable by studios who may use different versions of major dependencies. Rarely or never may we dictate particular dependency versions, but instead we need to accommodate a wide range. So we aren't overly prescriptive. We do make recommendations about the best/minimum/recommended versions to use if there are no other constraints, and we do monitor and update these for events (including vulnerabilities) in those packages that would cause us to update our recommendations.

We tend to to accommodate a wide range of versions of all the dependencies, and are very vigilant about being sure that at all times we can build against the very latest released version of each dependency.

We do this.

Test suite is part of CI on every commit.

We do this.

We're currently around 82% coverage.

It is even in the pull request template that new functionality requires tests.

The github pull request template includes these instructions.

We build CI tests with -Werr and -Wall (with only a few warnings disabled, generally to deal with 3rd party library issues).

No crypto is needed in this package.

No crypto is needed in this package.

No crypto is needed in this package.

No crypto is needed in this package.

No crypto is needed in this package.

No crypto is needed in this package.

No crypto is needed in this package.

We cryptographically sign release tags.

Starting with OIIO 3.0, we cryptographically sign release tags. Instructions for signing are here: https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/docs/dev/RELEASING.md Instructions for verifying a signed tag are here: https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/SECURITY.md

We don't think this really applies to the way the OIIO libraries work.

The build system includes a CMake option OIIO_HARDENING, which defaults to a set of hardening options that have low runtime cost, with the option to raise the hardening level further (with performance tradeoffs). https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/src/cmake/compiler.cmake

clang-tidy tests include basic security-oriented tests. We also use Sonar static analysis.

We currently have the per-commit testsuite on GitHub Actions run one test matrix entry with the build enabling "address sanitizer" and "undefined behavior sanitizer." We don't yet use a fuzzing tool, but we plan to do so in the future.