openexr_2: fix CVE-2021-3933, enable tests

[henrirosten]

Description of changes

Apply a patch for CVE-2021-3933 on openexr 2.x. Also, enable tests the same way they have been enabled in openexr 3.x.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.05 Release Notes (or backporting 22.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[risicle]

Are we still unable to kill openexr_2?

[henrirosten]

@riscle:

Are we still unable to kill openexr_2?

The current default is openexr_2: https://github.com/NixOS/nixpkgs/blob/2de862f1467fe5f89e2d6895b1e97fabc443cd14/pkgs/top-level/all-packages.nix#L23397. Many packages depend on openexr, so the first step in killing openexr_2 would be to move all those reverse dependency packages to openexr_3 one by one.

In a very quick test I see at least opencv and libjxl fail to build with openexr_3.

[risicle]

Hmm. I wonder why upstream haven't included this patch themselves, because they're supposedly still doing releases for the 2.x branch. Oh wait, the last release was March 2022. That worries me further then, because I'm sure there have been other vulnerabilities since then.

[henrirosten]

@risicle:

Oh wait, the last release was March 2022. That worries me further then, because I'm sure there have been other vulnerabilities since then.

I think most of the ~recent openexr CVEs have been fixed in openexr 2.5.x with PRs AcademySoftwareFoundation/openexr@4212416 and AcademySoftwareFoundation/openexr#1040.

The only fixes I found missing from openexr 2.5.x are CVE-2021-3933 and CVE-2021-26945.

This PR is an attempt to patch CVE-2021-3933 in nixpkgs. As you wrote, CVE-2021-3933 has not been patched upstream in 2.5.x branch, so we might also not want to backport this fix in nixpkgs openexr_2. I'm fine either way, but wanted to raise this PR since I could not find any earlier discussion about CVE-2021-3933 in nixpkgs.

The upstream fix for CVE-2021-26945 is in PR AcademySoftwareFoundation/openexr#930, which I think, does not apply to openexr_2.

[risicle]

@ofborg build pkgsi686Linux.openexr

Fails too.

[henrirosten]

@risicle:

@ofborg build pkgsi686Linux.openexr
Fails too.

Thanks, I somehow managed to not notice that earlier.

I see that test fails also without the CVE-2021-3933 patch from this PR.

In testing the sse enforcement from 3.x I see it would fix the OpenEXR.IlmImf failure but I couldn't fix the IlmBase.Imath failure on i686. Therefore, 7b78245 now simply disables the tests on i686.

[risicle]

LGTM. Built opencv, openimageio, gegl on macos 10.15 & nixos x86_64. Built pkgsStatic & pkgsCross.aarch64-multiplatform variants, x86_64.

[risicle]

For 22.11 & 23.05 we probably want the patch without the test additions.

[henrirosten]

@risicle : backport for 23.05 without the test additions is in #236043.
Do you still want this for 22.11 also?

[alyssais]

The tests seem to fail most of the time, with a timeout in OpenEXR.IlmImf. When the package does successfully build for me, it still takes a long time, so maybe the timeout for that test just needs to be increased?

[henrirosten]

@alyssais :

The tests seem to fail most of the time, with a timeout in OpenEXR.IlmImf. When the package does successfully build for me, it still takes a long time, so maybe the timeout for that test just needs to be increased?

Below is an example test run from OfBorg / openexr_2, openexr_2.passthru.tests on x86_64-linux:

...
[100%] Built target IlmImfTest
running tests
check flags: SHELL=/nix/store/xfb3ykw9r5hpayd05sr0cizwadzq1d8q-bash-5.2-p15/bin/bash VERBOSE=y test
Running tests...
/nix/store/bnmxyb30n6b5fq1gj3f4jzwxf7z8b4ls-cmake-3.25.3/bin/ctest --force-new-ctest-process 
Test project /build/source/build
   Start 1: IlmBase.Half
   Start 2: IlmBase.Iex
   Start 3: IlmBase.Imath
   Start 4: OpenEXR.IlmImf
   Start 5: OpenEXR.IlmImfUtil
1/5 Test #2: IlmBase.Iex ......................   Passed    0.00 sec
2/5 Test #1: IlmBase.Half .....................   Passed    1.11 sec
3/5 Test #3: IlmBase.Imath ....................   Passed    4.04 sec
4/5 Test #5: OpenEXR.IlmImfUtil ...............   Passed   31.02 sec
5/5 Test #4: OpenEXR.IlmImf ...................   Passed  337.72 sec
100% tests passed, 0 tests failed out of 5
Total Test time (real) = 337.73 sec
checkPhase completed in 5 minutes 38 seconds
...

Do you have example logs you could point me to from when the tests fail with a timeout?

[alyssais]

Sure. OfBorg on #240296 has failed three times on x86_64-linux so far due to openexr. Here's an example:

error: builder for '/nix/store/gk65p5cw1r60fc8cgn6syyd95mscq7fg-openexr-2.5.8.drv' failed with exit code 2;
       last 10 log lines:
       >
       >
       > 80% tests passed, 1 tests failed out of 5
       >
       > Total Test time (real) = 1501.89 sec
       >
       > The following tests FAILED:
       >          4 - OpenEXR.IlmImf (Timeout)
       > Errors while running CTest
       > make: *** [Makefile:71: test] Error 8
       For full logs, run 'nix log /nix/store/gk65p5cw1r60fc8cgn6syyd95mscq7fg-openexr-2.5.8.drv'.

I suspect the difference is that, in your example, OfBorg has been told to build openexr, so once it gets to that point, that's the only thing that machine is building. Whereas in my example, it's building other things at the same time, so there'll be more load over all. That matches my experience on my personal machine too, where every build of dependent packages I've done recently has failed due to openexr, but when I build it on its own, the problem goes away, and I can then finish the rest of my build with no probelm.

[henrirosten]

@alyssais :

I suspect the difference is that, in your example, OfBorg has been told to build openexr, so once it gets to that point, that's the only thing that machine is building. Whereas in my example, it's building other things at the same time, so there'll be more load over all. That matches my experience on my personal machine too, where every build of dependent packages I've done recently has failed due to openexr, but when I build it on its own, the problem goes away, and I can then finish the rest of my build with no probelm.

Here's an attempt to fix the problem by splitting the OpenEXR.IlmImf test into smaller parts: #240660.

Alternatively, we could simply disable the openexr_2 tests again, the same way they were disabled before this PR.