Academy Software Foundation Technical Advisory Council (TAC) Meeting - February 19, 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 / 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

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
JT Nelson, Pasadena Open Source consortium / SoCal Blender group
Lorna Dumba, Framestore
Lee Kerley, Apply
Rob Rowe, Cinepain

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
- OpenAPV - defining 6 month milestones #877
- Dev Days - May 2025 #966
- Security Threat model analysis for ASWF projects #615
- Feedback on Open Source Forum 2025 #960
rawtoaces #475

Notes

rawtoaces #475
- Not heard back. Larry: we may want to reach out to Anton? Carol: Scott is on the call. Scott: I’ll track down Alex, what is the objective? John: we just need a project update, or if someone else should be doing this. Larry: there are other people contributing, such as Anton, he’s also on OIIO TSC.
OpenAPV - defining 6 month milestones #877
- John: at 6 month point, there was going to be a report to TAC. TAC approval was to have a specific set of guidelines on how to gauge the project after 6 months. Youngkwon what is the deadline? John: end of March. Youngkwon: that’s good.
Security Threat model analysis for ASWF projects #615
- Jonathan: 7 issues flagged against MaterialX, 4 were straightforward (crashing project with wrong data), but 3 are more subtle, waiting for feedback from OSTIF team, what’s the best path forward for these more subtle categories.
- Cary: they reported 4 issues against OpenEXR, “garden variety” crash bugs, they fixed GitHub security advisories, Kimball fixed them. Not sure what to do with the security advisories, they are like GitHub issues but private. Not sure the steps needed to resolve them. GitHub seems to want to get you to file a public CVE, if that’s what we need to do we will. Unless the bug is particularly exploitable, not clear what to do? Also no suggestions about other findings, like our statement of policy, GitHub Actions… Are we “doing it right”? Answer so far has been specific crashing bug reports. Have been working on other things, but will get back to them.
- John: have a regular sync meeting with Amir and Derrick next week, let me know if there’s something specific I can escalate with them.
- Cary: they’ve expanded our fuzz testing, and given us pointers on how to make our fuzz testing more thorough. Larry had discussion with Foundry, appropriate to discuss these bugs to known vendors using OpenEXR in a private channel so they can get a new version out before we make something public. Larry: Phil at Foundry would like a heads up before we publish a full report. Security Analysis folks said it was standard procedure, there is still a gap where we decide what to say publicly, how is the vulnerability exploitable, and give time to downstream user to update. May want to take a step further to pro-actively involve them, not just give them lead time, but would like to hear feedback from a downstream recipient, which bugs do they consider important and why. Is there a rationale we can use to help go forward.
- Gordon: from Autodesk perspective, we have an internal security threat analysis framework we use to work out what we need to take action on. We would love a window to react. Challenge is that it shouldn’t just be vendors, studios may want to know as well. How do you prevent bad actors from signing up? Larry: we can keep it “in the family”. Most of the studios are working on segregated networks where we trust the inputs, so our confusion as authors of this software working in studios, we typically don’t think about these issues. So it’s an open question for us, we haven’t had to think about it like vendors. Gordon: it simplifies things if we can narrow the scope. John: projects can come up with a standard policy on how to deal with these disclosures, “what’s the circle of trust”. Called “coordinated vulnerability disclosure”. Might be something for the TAC to think about, is this something that we should put some structure around to help all our projects.
- Michael: at a studio, won’t be exposed, but as public projects, the intention is to get broader adoption and usage, we have to go towards that perspective. These projects can be used in other projects. Larry: of course, goals not in question, just our experience. Michael: there are groups paid to expose these vulns. Different tiers of certifications, one can be “in family”, vs wider.
- Carol: a timing schedule is going to be tricky since vendors are often not up to date with our most recent versions in their software releases, so do we need to backport, that gets tricky. We need to come up with a way to have an internal decision, a place where we can publish these vulns to the group, can be quite a delay between a report and an updated release. John: coordinated release, after a fix, how do we get vendors aware.
- JC (chat): ossf vulnerability disclosure is full of good resources on the subject
- Carol: we need information specific to our types of projects. We don’t want to make a big splash about things that aren’t a big deal. How much is this worth to us.
- Gordon: delay to a release depends on how “exciting” the issue is, for instance we pushed out releases for Heartbleed vuln quickly. Important is to have time to look at this together. We spend a lot of time on this, we have our own dependency registry so when something pops up, we know which versions of our projects are affected. Dependency chain is important, especially when projects (such as USD) use other projects. As an Open Source foundation, do we want to have a graph of dependencies. Also when our libraries get integrated in OSes and web browsers, all eyes are on us.
- Cary: our Jira backlog at ILM has dozens / hundreds of “crashing” bugs, we fix important ones, but a lot of the time we just say “don’t do that”, we operated behind the firewall, and control our data. If we ingest data from random public, our stance would be different. Some of the bugs reported by OSTIF against OpenEXR are low priority. These processes exist for a good reason, OpenEXR integration into macOS is what the public disclosure process is for. But would there be a benefit to a precursor to that for the trusted members of our community. But I don’t have a sense that this is so critical a problem.
- Gordon: have to apply diligence to small number of cases where it is a problem. We had a “Maya Virus” a few years ago. Need enough monitoring so you can find exceptional issues that have to be addressed right away. Open source doesn’t mean you have to fix every single issue someone reports. If something is very important to someone, they can always fix it themselves. We don’t want to sign up to fix anything that anyone ever finds.
- Scott Wilson (chat): I remember that Maya virus. By the way, props for the virus scanner that Autodesk came out with. I think we need something like that for all DCCs/more tooling to help screen scene files without having to run the scripting engine.
- Cary: this determination is what I would like to get out of audit process. OpenEXR isn’t doing any kind of high risk / high vulnerability functions, not a prime vehicle for a virus. Was hoping that someone who knows what they are talking about would help us with that.
- Gordon: didn’t we talk about having a “Security Council” so every project doesn’t have to have its own security expertise? Have a group that projects can come to to discuss these issues. We could find someone on the Autodesk side who could contribute. John: one of the ideas of working with OSTIF was to see if we could get value from an outside firm, tricky part of “office hours” can make it hard to disclose things. People doing the work are finding stuff and reporting them. Groups are giving some recommendations, but are we getting to the end product of guidance for projects. And how do we disclose what has been found. How do you get the right people to the table. Need to disclose responsibly. Maybe a Security WG, don’t want to be overly prescriptive, but we’re seeing things where a WG could be of value.
- Jonathan: Cary brought up that no individual issue found by OSTIF was as important as the process by which they found them, would like to know how they found them. Looks like some were found by fuzz testing, I’d like to be able to reproduce that. Would like to emphasize process over individual reports. John: they should be giving you access to that in final reports.
Dev Days - May 2025 #966
- Carol: doing 2 this year, tried to pick dates that work with the list of events presented by David. May 15th and Sept 25 2025. We welcome feedback for next year.
- Doing multiple Dev Days events per year, but single day event for the full 24H depending on your timezone (previously was 2 days). Should be enough heads up for the projects and member companies. Wanted to do multiple so that it’s not such a problem if you can’t participate at a specific date. Technically you can contribute at any time, but people don’t do that. We are trying to create more targeted opportunities to contribute.
- Carol: also we’re not doing ASWF project registration, we’re doing Dev Days as a foundation, includes all ASWF projects. Some projects are harder to jump into than others, but we wanted to avoid extra admin work of tracking who is participating to what project. Also we want to give people opportunity to participate to projects they want.
- Larry: previous 2 years were more experimental, allowing projects to “sit it out”, now we expect every project to participate. Just need to have “good for newcomers” issues, and decent build documentation. On the day of, pay more attention to channels of communication. We expect that all projects are willing to take a PR at any time, not “pushing anybody into the deep end”. Up to the projects how much they want to promote it in their community. Some projects were scrambling to release around Dev Days last year.
- Carol: have new member of Dev Days leadership team from Animal Logic, did a great job last year to organize a company internally, and written great documentation that lives on Dev Days wiki. Will provide for Q&A with company leads for instance. Larry: in the past had information sessions for the participants, but might be good to have a group call with people from companies, how the company can get value from their employees participating.
- Carol: expect to hear from us earlier, as well as office hours for participants and projects.
Planning Session for TAC [#792]
- John: TAC has done a lot of project review / bring in new projects
- Sometimes instead of just being “reactionary”, what are challenges we want to tackle.
- Could be TAC meeting in 2 weeks, open planning session, what do we want to address as a TAC.
- Carol: feedback on process, how we run things, is it useful to you and your company.
- Larry: if all TAC meetings are process votes and annual reviews, this can get boring. Want to have space to have more useful information sharing. If there are people from a project or company who want to present something, this is a forum where we can do this, have the “right people in the room”.
- John: I see TACs get to the point of wanting to figure out “what do we want to do next.”
- Next TAC meeting is pretty open, so could be a good time to do this.
Feedback on Open Source Forum 2025 #960
- John: different structure than what we have done in the past. Want feedback on whether you liked it, what do we need more of / less of.
- Larry: I thought the content was really good. Was inspired, and thought a lot about it afterwards. People from my company attending remotely also enjoyed the content. I think we “nailed id”.
- Carol: as someone who attended remotely, the content was great, but realized I missed a lot of stuff happening on site. If we’re going to make it an in-person first event, we need a lot of heads up and a change of timing. Nothing is going to be perfect, and LA is likely the best place, but if we want in person focus going forward, need to be purposeful about it. Or we want to be as friendly to the remote side of things.
- David: we focussed on the people in person, and reduced number of online participants due to sensitivity of AI topic (for discussion part). Studios have tight restrictions on AI. This is not a trend, we are open source focussed, and will be open in general, this was an exception for this year due to the topic. In future we want to be open, including with the media. So expect more openness in the future.
- Carol: I can see benefits to being in person. David: we will keep making things member focussed, with some additional invites.
- David: would like to ask more about the core of the event, what we can do at the foundation about AI, if anything. Does anyone have comments / thoughts? We are taking steps to engage in the “what should we do” with AI in our projects.
- John: questions came up on C2PA group around content provenance. Lots of overlay with the industry and some projects. Would some of this work be interesting for this group?
- Larry: some of the groups have had contacts, had someone from C2PA talk to OpenEXR TSC, and I’ve talked at conferences. Desire to do something about obvious intersection when reading / writing formats involved.
- John: anything specific would be helpful?
- Carol: have a basic discussion in TSCs, create issues, put on backlog, will require someone in most projects to step forward and decide to work on this.
- JF: any LF level tools to help between foundations to coordinate? John: that’s usually me, I have understanding of multiple projects / foundations, we have a landscape tools. Myself and rest of staff can be of support. We have models where projects cross-collaborate, lots of different avenues. Not a one side fits all.
- Larry: we know about them, do they know about us? The C2PA speaker, had she heard of OpenEXR before? How can we be relevant to them? John: major LF events (Open Source Summit) are some of the good places for project intersection, member summits as well. Designed to be a bit like “COMDEX of open source”, that’s where we create opportunities to link communities. Maybe a call to look at ASWF presence at some of larger LF events.
- David: relative to our side, we are quite well known within LF, our demo reel plays at top of every LF conference, gets us known. ASWF is known, then it depends if another foundation has something to do with us. Large companies which have TAC / board representatives across multiple projects could be helpful with cross-foundation collaboration. There are 1200 projects at LF, and over 100 groups, we are known but can do better.