Academy Software Foundation - Technical Advisory Council (TAC) Meeting - April 3, 2024

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 - OpenColorIO Representative
Cary Phillips - OpenEXR Representative
Chris Kulla - Open Shading Language (OSL) 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
Tom Slanda - The Linux Foundation
Yarille Ortiz - The Linux Foundation

Other Attendees

Ben Giles, Calligra
Jim Helman, MovieLabs / Zero Trust WG
Daryll Strauss, MovieLabs / Zero Trust WG
Doug Walker, Autodesk / OCIO
Matt Daw, MovieLabs / Zero Trust WG
Spencer Stephens, MovieLabs / Zero Trust WG
JT Nelson, Pasadena Open Source consortium / SoCal Blender group
Phil Parsonage, Foundry
Robin Rowe, CinePaint
Timothy Porter
Toby Scales, Google / ZT WG
Bill Ballew, Dreamworks
Deke Kincaid, Digital Domain

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
- FMX 2024 Open Source Track #595
- Project Proposal - OpenQMC #434
- Security Threat model analysis for ASWF projects #615
Zero Trust Working Group #621
Follow-up discussion on New Project Proposal - Pillow -#631
Continue discussion on Swift WG proposal #578
Volunteer for SLP 2024! #645
Security Threat model analysis for ASWF projects #615
Start definition of TAC Chairperson roles #632
Open Source Days 2024 #650
Implications of xz Backdoor #652

Meeting Notes

Open Source Days 2024
- CFP opens today
- July 28th, day after DigiPro, similar to next year, open to everybody, at the official SIGGRAPH hotel (Hyatt)
- Series of town halls for projects in week leading up
- Day of BoFs for interested projects
- Kimball: is there a program committee? Emily: no, not yet, send me a note if you are interested
- John: earliest we’ve had the date locked down!
- Ken: are we doing cross promotion for projects outside of ASWF? We have some papers related to OpenVDB, so if we can promote them, that would help? David: yes, we do, if we know about these papers, we are glad to promote the “brotherhood of open source”, let Emily know
FMX
- Emily: that’s situated, we have talks around ORI, JF, David. Let us know if you are planning to be there. On the Wednesday of FMX, 3 presentations, part of trying to grow our presence in Europe, a lot will be doing on around that. If you know someone going to FMX, send them our way.
Volunteer for SLP (Carol)
- “Insert guilt trip here”
- Coming up very quickly, we’ve done a great job getting applications and web site up and running, earlier than we ever have.
- We’ve moved up timelines around SLP to give us more breathing room. We have over 130 valid learner applications, have already done some filtering. Program is focused on people from under represented people in the technical side of the industry.
- Looking for volunteers at various levels of commitment in hours
- Even if you can’t contribute over the summer, there’s one category coming soon (in the next week or so) is that we need people to review applications. We do a double blind review process, remove identifying information. Each application is reviewed by 2 or 3 people, with 100+ applications, we need people to review applications.
- Application may seem long, but you can skip sections for positions you aren’t interested in.
- SLP Volunteer Application Form
- As TAC members, please all sign up to review applications, and share the blurb in the agenda item with your company and social channels.
- A great way to get new people involved in our community!
Start definition of TAC chairperson roles - John
- Everyone on the TAC encouraged to review the item, reviews greatly appreciated
- Want to start getting this operational before too long
Implications of xz hack - Larry
- Does everyone know what it is?
- Blog Post on OpenSSF site
- 3 year social engineering effort
- Kimball: leveraging peer pressure
- John: we could spin off a separate group to bring TAC recommendations
- Larry: special call out to Cary Philips who has been way ahead of the curve staying on top of these issues for OpenEXR
- Larry: we often talk about engineering resources on projects, “there’s lots of projects out in the world where only 1 or 2 people are doing the work, maybe it’s not so bad”. When there’s a discrepancy between the goals of the project and available resources, that can make it tempting to accept any contributions without giving them the proper scrutiny. So incentive to get projects properly staffed. Also we have programs to get new people involved, but we need to think carefully about how much effort we put into recruiting new people we don’t know / don’t have industry connections vs putting more effort into people already in the “circle of trust” and who may better correspond to the people who have the required expertise for our projects. I am not turning down outside help, but we need to think about the pros and cons.
- John: would it make sense to have a group that digs into this to bring recommendations to the TAC?
- Kimball: the Security WG which has been quiet for a while should get involved, whether we need to modify the OpenSFF badging requirements. Perhaps also ask the D&I committee for input. Bullying was used to get the initial patches into the xz project, so how do we make sure that doesn’t happen. Spencer: the oss-fuzzing project was convinced to turn off some tests that would have found the backdoor. Is the combination of social engineering and manipulation of test tools that resulted in going undetected.
- John: we currently don’t have a Security WG, had felt WG CI might be the place to discuss this? Larry: CI WG is poorly attended by projects. JC: would be happy if there was a separate group of people who wanted to look at it, I wrote some thoughts on this. It’s important to figure out as a group how we can protected ourselves against this. If someone wants to participate, that would be great. John: I can help you get this going if you want.
- Cary: OpenEXR chipping away at OpenSFF requirements, dependabot, had been questioning whether this was worth it, but with the xz incident, it makes it clear it was worth it. Our projects are resource starved, and we do get some random contributions with small fixes. Natural inclination is to bend over backward to accept contributions, but something that looks innocuous may not be.
- Kimball: that’s why we have the PR review process
- Cary: there’s nothing I’ve done on OpenEXR that can’t be deployed to other projects, nothing is complicated. I’m going to report back at next OpenEXR TAC, and could be deployed to other project.
- Is there something happening at the LF level? John: there’s the blog post on OpenSFF web site. There is a Community Day at next week’s SOSS conference where a “desktop simulation” of a supply chain attack will be run. Can follow some of the guidance from there.
- Phil: every project will be looking at these techniques, and already doing most of them, but may not be enough to protect ourselves. Every open source project has the same challenges.
- John: a lot of great tooling and documentation within OpenSSF, leveraged by OpenEXR. Let’s get a playbook for the other projects based on what Cary did for OpenEXR.
- Cary: a lot of the work is boiler plate
- John: will work with JC to get a separate group going
- Thoughts from JC on xz hack implications
- JC (Chat): There is no security-wg right?
  - John: Not presently - I think it somewhat part of the CI WG
  - Scott: There is a slack channel, but I think the group was having troubles with trying to figure out what the scope of the group is.
  - JC: That’s because we don’t… Last time we talked about it, it was decided that wg-ci would take the security stuff.
  - Kimball: There’s a slack channel, maybe I was overzealous in calling it a WG
  - Ben Giles: Threat analysis would be good as a start. I have done this in the past for … actors that have the ability to create or use cover. We’re not there, but there would be commercial/IP equivalent prior art. Reminds me of Ken Thompson’s C compiler backdoor for login
  - Kimball: I like the idea of this WG as we need to balance performance with security, and need to understand the implications to large fields of bespoke pipeline scripts… 🙂
Zero Trust Working Group - Jim Helman / Daryll Stauss
- ASWF Zero Trust WG Slide Deck
- Background and Purpose
  - Legacy solutions relied on perimeter security for media creation: secure the facility with firewalls and have artists work entirely inside the perimeter with minimal additional security checks
  - the complexity of productions has increased and attacks have evolved, the perimeter security model has become less effective. Zero Trust solutions, which add end to end security between the user and the service, improve both the efficiency and security of the production.
  - This working group will develop standards and best practices for implementing zero trust solutions in media production applications
  - Proposal
- Today’s production infrastructure: datacenter and hybrid cloud
  - See diagram on page 3
- Production in the cloud
  - See diagram on page 4
  - The cloud is a global production resource outside of facilities’ infrastructures
  - The application is moved to the data. Workflows run in the cloud
  - Everything happens outside of facility security perimeters
- The Problem
  - Multiple facilities, data centers, cloud computing, and SaaS applications make defining perimeters difficult
  - Passing data between vendors on the production makes perimeters porous
  - BYOD, work from home, and working on location increase efficiency but are all challenges to perimeter security
  - VPNs require security management, lower performance, and provide little to no granularity of access
  - Applications and plugins increasingly rely on network services making defining and managing the perimeter more difficult
  - Automation and software-defined workflows improve efficiency but also increase the API connections across infrastructures and organizations
- The Solution: Zero Trust (ZT)
  - In ZT nothing is trusted without first being authenticated
  - ZT authenticates a user, and perhaps a machine, rather than just trusting everything inside a perimeter
  - In ZT, authentication is mutual. The service authenticates the user/client. The client authenticates the server.
    - Client applications and plug-ins using network services need to incorporate ZT, acquiring and transmitting authentication tokens, and authenticating the server (eg via its HTTPS certificate)
    - Network services incorporate ZT by authenticating the user/client and checking that the user is authorized to do the activity
  - Sharing authentication data between media applications, with a single sign on, reduces friction for the artist
- Standardization Benefits
  - Make implementing ZT solution easier
  - Avoid duplication of efforts for software ASWF projects
  - Increase security by having trusted implementations and recommended policies
  - Lower the impact on artists by reducing the number of separate authentication requests from applications
  - There may be future projects that involve code / libraries. But also things can be done around best practices, OS-level key stores.
- Engagement
  - Participation
    - MovieLabs, Daryll Strauss, Chris Vienneau, Spencer Stephens, Matt Daw
    - Amazon, Blake Franzen
    - Google, Toby Scales
    - Foundry, Dan Hutchinson
    - Autodesk, Claude Robillard
    - Adobe, TBD
  - Relevant ASWF Projects
    - Used with plug-ins accessing network services: OpenAssetIO
    - Client/Server systems: OpenCue (cf issues 218, 344, 425)
    - For currently non-core use cases: OpenReview (already patched w/one approach), OpenImageIO (if I/O proxy used to access network resources)
    - Potential projects waiting in the wings: Google OpenProductionDataIO
- TAC #621 has proposed charter
- JF: would a manifest of resource access be in scope? Daryll: I don’t know of a standard to document this stuff. Spencer: that’s the problem with pulling the security to the perimeter. ZT simplifies the problem, that reduces complexity and increases security. Jim: we are working with TPN for a draft of Zero Trust controls, will be out before the end of the year.
- Eric: Would it be in scope to advocate with DCC vendors to adopt some of this? From a project perspective, we just look at paths on disk, we don’t handle a lot of authorization. Jim: that’s why we’ve been talking with Adobe and Autodesk, as long as DCC uses plugins to allow data to come in, there needs to be a common way to do this. Having every plugin pop up an HTML widget to request (redundant) authentication is not a good user experience. JF: “SSO within an application”? Gordon: ideally want SSO within a session, if you want the full benefit of Zero Trust, there’s going to be a lot we need to solve. For the WG, did we consider one of the goals to come back with a proposal to the TAC for a code project? Jim: yes, that’s a goal. Gordon: would it be a common library, what should be the role of our open source projects be. Maybe a recommendation rather than a proposal, multi-phase recommendation. How should the ASWF think about ZT, what does it mean? Or does it affect the DCCs, would love to see that.
- Jim: second deliverable talks about next steps, and whether a library is needed, or can just use existing OS infrastructure (key stores)
- Daryll: likely leads to building libraries to avoid redundancy
- Spencer: also what existing libraries we could already use. Want to leverage libraries developed by security-conscious developers. Code we produce would leverage existing libraries.
- Jim: WG typically don’t generate code, it’s more of an incubation / sandbox project. This is why we scoped it this way.
- Eric: to me ZT lies on how studios implement their pipelines, they have to understand what their roles are. At Netflix we have an OAuth framework for this. Why is this best housed at the ASWF rather than within a WG at MovieLabs for instance? Jim: that’s another possibility, we thought it would be good in ASWF since focussed in good software practices, and relevant to a number of the projects. Also you already have most of the major DCCs participating, and a more public venue than some of MovieLabs projects.
- Eric: we have people representing all the parties, and a good framework for collaboration.
- Cary: will echo what Eric was saying, most of our projects are “computation engines”, from an OpenEXR perspective, we don’t “do most of that”, for instance I don’t have to worry about authentication. Same for MaterialX for instance. Most of our projects don’t deal with those issues, but the DCC vendors who rely on our infrastructure. Obviously this is a good initiative that should be supported, maybe ASWF is the right forum. Don’t think we strictly prescribe the types of projects we take on. But a lot of project maintainers here may think it doesn’t really affect their project.
- Jim: it may be that some of the file manipulation projects may need to become network savvy, same as how ffmpeg can take URLs. You can mount a bucket locally, but that may not be the best solution.
- Larry: asking to Cary, do you imagine that it’s that far a stretch for an application using OpenEXR might want to call open() passing a URL rather than a filename on disk?
- Cary: if we got a PR adding that kind of functionality a couple of years ago, we would perhaps have accepted it. But we realize “we don’t know what we don’t know”, and we aren’t steeped in security issues. Guiding us in that direction is a good thing.
- Toby: the idea of doing it here rather than studio side, you have a lot more power and influence over the devices, but here was want to focus on decentralized ZT, how do we take all the security benefits of the ZT model and spread it to all the solutions here. Spelling out that this is the preferred way going forward for projects under ASWF looking to take on the benefits of ZT models.
- Spencer: the way infrastructure is being used is changing, we’re moving towards decentralized infrastructure.
- John: sounds like we have a lot of interest, not sure we have quorum? Should we take this offline and discuss at next TAC meeting?
- Cary: I think at WG is a good idea, if a year in we decide
- Wave: presenting a motion, Carol seconds
- No oppose / abstain: vote passes
- Gordon: we should have a 3 month check in, not just wait a year, since it’s new for us. And maybe TAC can provide feedback, would like to see touch points.
- John: good idea, we’ll adjust the schedule.
- Larry: should have asked this before the vote, but who from the projects should be on the WG / participating, or will someone from the projects will show up and do some of the work. Wave: will show up initially, I’m interested. Jim: we have Foundry / OpenAssetIO, so we have some participation. Gordon: we also have Autodesk in here. Larry: I have people in SPE who may want to participate and will connect with the WG.
- Eric: would love it if something would work with 2030 Greenlight stuff. Jim: that’s a great idea, we are doing PoCs and working with partners, great place to prototype something. Eric: would love to be able to collaborate with 2030 Greenlight initiative.
- John: will follow up with onboarding
Chat:
- Spencer: MovieLabs has produced a video on zero trust and production security
- Ben: Is it more about authorization than authentication? Security metadata (ACLs) on artifacts being necessary but not sufficient for ZT?
- Spencer: Both. Whether ACLs are sufficient is a matter for risk assessment, using ACLs is one way ZT AuthZ can be implemented
- Ben: Sure— I suppose I was highlighting that it’s necessary to have ACLs on the data itself so that authorization is possible? Then the authentication can be useful in being the go/no go?
- Deke Kincaid: Seems relevant to openrv & xstudio
- Carol: To me, seems like a good use a of a working group for initial discovery. Even if, as Cary states, there might not be much initial application to projects directly, it might impact us eventually.
- Eric R: USD referencing could get interesting in this world, what if your references point to assets sitting at various sub-vendors working on a shot?
- Michael: It’s expected that a studio would implement their own Asset Resolver in USD, and many do, and those usually involve authentication…
- John: A working group could generate code ( for example, Working Group for RUST bindings does - though that WG is designed around upstreaming into other projects so it somewhat makes sense ).