Academy Software Foundation Technical Advisory Council (TAC) Meeting - August 6, 2025

Join the meeting at https://zoom-lfx.platform.linuxfoundation.org/meeting/97880950229?password=81d2940e-c055-43b9-9b5a-6cd7d7090feb

Voting Representative Attendees

Premier Member Representatives

Project Representatives

Carol Payne - Diversity & Inclusion Working Group Representative, OpenColorIO Representative
Cary Phillips - OpenEXR Representative
Chris Kulla - Open Shading Language Representative
Diego Tavares Da Silva - OpenCue Representative
Jonathan Stone - MaterialX Representative
Ken Museth - OpenVDB Representative
Nick Porcino - Universal Scene Description Working Group Representative
Rachel Rose - Diversity & Inclusion Working Group Representative

Industry Representatives

Jean-Francois Panisset - Visual Effects Society

Non-Voting Attendees

Non-Voting Project and Working Group Representatives

LF Staff

David Morin - Academy Software Foundation
Emily Olin - Academy Software Foundation
John Mertic - The Linux Foundation
Michelle Roth - The Linux Foundation
Yarille Ortiz - The Linux Foundation

Other Attendees

Doug Walker, Autodesk / OCIO
John McCarten, WetaFX
Lorna Dumba, Framestore
Josh Brainbride, Framestore
JT Nelson, Pasadena Open Source consortium / SoCal Blender group
Robin Rowe, CinePaint
Jim Helman, MovieLabs
Cory Ormand, Pixar
Lee Kerley, Apple
Olga Avramenko, Sony Imageworks / D&I WG

Antitrust Policy Notice

Linux Foundation meetings involve participation by industry competitors, and it is the intention of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws.

Examples of types of actions that are prohibited at Linux Foundation meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy available at linuxfoundation.org/antitrust-policy. If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation.

Agenda

General Updates
- OpenQMC #434
- Security Review report for OpenEXR/MaterialX #1021

Notes

Security Review report for OpenEXR/MaterialX #1021
- Published last Thursday, blog posts on OSTIF
- Talk by Amir at Open Source Days on some of the work that was done, he will be in person. If projects leads want to talk to him about the process.
- Cary: I think everybody should do this, you won’t know the specifics of what will be uncovered until you do it. For OpenEXR there was a team of security experts from Shielder who took the software, went off, didn’t ask many questions, but discovered 4 bugs. We fixed them (would have called them bugs), they referred to them as vulns. We used the GitHub Security Advisory mechanism to host the bugs, we rolled out the fix, made a release, and well after that, in sync with OSTIF report release, we published the CVEs. Vast majority of focus / attention was around their investigation and discovery of bugs in the library. I was kind of hoping for more of a holistic analysis of the security of the hole project, vulnerability to social engineering, are there other processes we should be implementing. But they did look at the project as a whole, and didn’t come up with something else to comment on. The process was quite long, first started in January, overall a positive experience.
- Jonathan: agree with Cary. We thought about things we hadn’t thought about before, including recursion, where you can craft a 10,000 level file. Valuable to have this perspective, anything that’s possible will happen and needs to be handled. When the publication went out describing the Shielder process, the response was “there are vulnerabilities in OpenEXR and MaterialX”, instead of “OpenEXR and MaterialX take security seriously”. I wish the framing would be that the projects take security seriously.
- Larry: “the Internet does its Internet thing”. This isn’t cheap, both in terms of actual money, also time from the team. We did it as a test run for these 2 projects, we both said this is valuable, but not sure every project can do this, especially with great regularity. Are there lessons learned from these 2 projects we could learn to apply to other projects without having to go through a full audit?
- Cary: a disappointing aspect is that it is an analysis of a moment in time, they found a bug as of a commit in January, we could be adding new bugs. They identified current problems, without doing much to help us avoid doing this in the future. The bugs were buffer overruns, the kind which can creep into your code. Be mindful of testing, reviewing changes. John: I think they also added fuzz testing? Cary: they proposed a new fuzzing mechanism based on a Google service (protobuf based), and gave us a bit of a stub of a new fuzzer, but it’s not complete.
- Jonathan: they used a strategy to mutate XML files based on the rules of XML to create valid but problematic data sets. But they didn’t give us the code they used. Would like to incorporate this approach in the future.
- Gordon: even when you set these things up, these investments are “for life”, you have to look at all the errors generated over time, have to update the framework over time. I’m supportive of the questions around ‘what can we share’.
- Cary: there was little communication from the team about the percentage of coverage in our test suite, their testing was mostly fuzz testing or manual inspection. OpenEXR has 80% test coverage, surprised they didn’t say that needed to be higher.
- Larry: in many of OpenSSF badging, we often hear “can you articulate what the threat model is”: what is a bug? what is a vulnerability? Do you feel you are closer to being able to articulate the threat model?
- Cary: the buffer overrun was labeled critical. There is another variety of flaws where you can construct an OpenEXR file with an impossibly large image with a very small file through compression, if the library loads that, it will run out of memory and crash. We provide mechanisms for applications to put a limit on the image size, but the library leaves that to the calling application. That’s a grey area, our test suite either imposes restrictions that don’t reflect the real world. We’re not sure of the right approach.
- Gordon: a great example of some of the variance I’ve seen in third party security audits. You give them a system description, they look for API, network traffic, and apply standard tools. I see less frequently trying to figure out “what does this thing do”? Constructing an image with “weird” sizes is domain specific, and typically never done by third parties, you have to do this in your team. In Maya we know our plugin system, a command port, these didn’t get the focus from 3rd party audit. It is often very boiler plate.
- Larry: Autodesk products incorporate our projects, what do you expect from us? DCCs, OSes like macOS deal with OpenEXR files. We don’t want to be the weak link, but we’re not in the heads of the consumers of our projects. Gordon: OSes and web browsers evaluate at another level, they want zero defects. For Maya we want to squash as many bugs as possible, but “you” have the answer for Maya (the studios). We want to deliver a security posture that works for the studios rather than tick the box. Larry: at our studio we are separate, control the inputs, if the DCC crashes, we restart it. We don’t run an external facing web service. Gordon: when we do a threat model, it’s about identifying trust boundaries in the system. What things do you trust since they are controlled by the user, where do I cross into an untrusted zone: third party plugins, download from the web. We try to have a high level of security for things we don’t trust (plugins for instance), if you trust it, we want to get out of the way. But we are moving to more cloud facing workflows. We had a security issue with USD which had us “stop the presses”, we also had the “Maya virus”. But yes we often run in a high trust environment, we don’t want to lock down our API.
- John: maybe worth doing an offline discussion, maybe at Open Source Days. We will have Amir at OSS, maybe good questions to bounce off him, figure out what makes sense.
OpenQMC #434
- John / Framestore: we have been working towards the goal of having NVIDIA sign off on the patent concerns.
- Eric: we have a “covenant not to assert” to declare that what is in the OpenQMC project as of a specific date has nothing that NVIDIA would object to. This was code that NVIDIA has patents to, but hasn’t written. Hope that lets everybody breathe easily and use the project.
- Josh: thank you Eric, has been a good collaboration. Looking for advice on next step towards getting on track towards an ASWF sandbox stage project, and the vote for that.
- Carol: do you want to do a quick summary of the project to remind people?
- Slide Set: OpenQMC ASWF Sandbox Proposal
- OpenQMC Background
  - Original idea for open source from 2018 ACM TOG on rendering
  - OpenQMC is park of Freak, Framestore’s production renderer
  - Considerable amount of experience in this area
- OpenQMC Problem Case
  - Reducing noise in production rendering is expensive
  - OpenQMC is one way of making this more efficient
  - APplies methods from Quasi Monte Carlo (QMC)
  - Critical component to physically based renderers
- Overview
  - OpenQMC includes
    - Library for sampling low discrepancy points
      - C++ with no dependencies
      - …
- Summary
  - C++ library for graphics engines
  - Reduces noise and optimises performance
  - …
- Motivation for Sandbox
  - Framestore became an ASWF member
  - Common mission with ASWF
    - Collaborate to build quality tools
    - Have an open forum for contribution
    - Provide governance for a standard solution
  - Benefit for the community
    - Provide a test and high quality solution for point sampling
    - Document workflows for common use cases and integration
  - Project benefits from ASWF sandboxing
    - Provide exposure to a larger community to grow
    - Help steer the project to meet the community needs
    - USe the sandbox stage to allow for API breaking changes
- Project alignment
  - Built from the beginning for open source
  - Based on the ASWF sample project
  - Issue tracking, meeting notes etc
  - Uses VFX Reference Platform
  - Contribution process
    - Apache License 2.0
    - DCO sign off required
    - Digitally signed commits
    - PRs and CI
- Summary
  - Framestore are committed to continue contributing further improvements from production to this open initiative. We think the project’s mission to standardize such technology across our industry, together to collaborate and achieve ever greater tools for content creation, aligns with the goals of ASWF.
- Larry: when previously presented, only concern was legal issues which are now squared away.
- Jonathan: excited about having this an ASWF project, in same way that OCIO / OIIO are leveraged, are there opportunities to leverage OpenQMC in other ASWF projects? Josh: definite opportunities, the people who have come in to early access have echoed this. OSL would be a great candidate. We’ve taken design decisions such as inline directly, CUDA compatible, so if you can JIT compile a shader graph, it has the sampling API where you can create domain trees in an optimal way. Don’t build parts of the tree you don’t use. Also MaterialX.
- Larry: OSL angle is interesting. We have a toy renderer which is not suitable for production but useful for testing, would be interesting to hook up. Also as a scaled down renderer could provide an implementation example. Another potential OSL tie in would be for shader writers who want a library for well distributed sampling points. What’s the interface between MaterialX, OSL, with OpenQMC underneath. So can expose language features for shader writers.
- Josh: we want to keep the API open, since we need input from other groups. We are open to steering the API in the direction it needs to go.
- Gordon: very cool project, happy to see it happening. On the legal front, the proposed model has been reviewed? Eric: we haven’t run it through LF legal. Gordon: has this been involved? Eric: no, so far only involved NVIDIA and Framestore model. Gordon: the patent was the sticking point, would be good to have it review. Also is the grant only for studio use, for any open use, or commercial software? Eric: similar to Apache 2.0 license that OpenQMC is open.
- David: John will have the data on this, but my recollection is that had flagged this issue to the TAC, we can ask him offline to check on how we handled it. Gordon: good to close the loop with LF legal, “are we all good”. Matthew: language is already in the repo but repo is private, could this be shared to make sure everyone is comfortable? Johsn: we can make the project repo open now.
- Michelle: sounds like it’s not an issue / already addressed, but will have him address it. Larry: I think you can open up the repo for people to look at, the spirit of what NVIDIA is trying to do is unambiguous, even if some language needs to be tightened up. But the repo can be open. If the code had been written by NVIDIA under Apache 2, that would have not been a problem. It’s clear what everyone intends, but want to make sure it says that in the language.
- Gordon: the intention is wonderful, but this is a new pattern for us, so a good place for legal reps to agree this is the right way to do this.
- Matthew Low: MoonRay has been enthusiastic and fully support the project.
- Josh: we will open up the repo, share the project, and get feedback.
- Larry: are we ready to schedule an LFX vote (from John), or do we want to wait until we have that nailed down? You can vote to accept the project and not use it. Gordon: would support a vote contingent on LF legal approval. I’m not the right person to comment on that, but would be OK with vote contingent. Larry: we will chase that down, then get a vote started offline. David: makes sense.
David: new member announcement
- Welcome Sean Cooper from Skydance Animation who has just joined us, will be announced just before SIGGRAPH.
- Sean Cooper: have been involved with OCIO, may be some ACES related announcements. Happy to be here and help as much as I can.
- David: ACES project in ASWF was announced this morning, Sean will be involved with this transfer.
Larry: keep your eyes open for the town halls, BoFs, KeyNotes… There are a flurry of announcements of new members, new members, a busy time for us.