ASWF TAC Meeting - November 04, 2020

Video Conference Link

Voting member attendance

Other Attendees

John Mertic, Linux Foundation
Emily Olin, Linux Foundation
Andrew Grimberg, Linux Foundation Release Engineering Group
JT Nelson, Pasadena Open Source consortium / SoCal Blender group
Nick Porcino, Pixar
Alex Meddick, Rising Sun Pictures
Rachel Rose, ILM, Diversity+Inclusion WG
Mathieu Mazerolle, Foundry
Deke Kincaid, DIgital Domain
Greg Denton, Microsoft Azure
Karthik Lyer
Owen Taylor
Scott Wilson

Apologies

Michael Min, Netflix

Agenda

Goals for TAC: Year 2
- Documentation
Discussion on channels
- Daniel: Slack seems to have been quite successful, do we agree on that? Are we OK with the risk of ‘spreading the discussion too thin’?
- Larry: still see substantive discussions happening that may not be captured elsewhere, not just ephemeral discussions. For example what’s happening in the rust channel.
- Nick: trying to aggregate conversation into GitHub repo issues
- Daniel: exactly the conversation we want to have, we can come back specifically for the rust discussion later in the meeting. Also good discussion on the documentation front. Opportunity for cross-project cooperation. We want to put in place best practices.
- Also issues with calendars
Security Guidance (Cary)
- https://github.com/AcademySoftwareFoundation/aswf-sample-project/pull/17
- Most recent discussions on security requirements came up in context of OTIO and OpenCue
- Cary: two main categories in CII requirements:
  - Cryptographic requirements: most ASWF projects don’t have those, except perhaps OpenCue
  - Security vulnerabilities: a vulnerability is really just a “bug”, with some caveats. What to do when your project coredumps, or more to the point, what to do when someone finds out your project coredumps, with the additional context of public disclosure. Especially important for projects that implement a file format, ability of attackers to craft a malicious file. Projects that read file, especially projects that are widely used, not just in a studio behind a firewall. But OpenEXR is part of macOS, any software that is used in that context needs to take vulnerabilities very seriously. The mechanism of public disclosure serves the purpose of allowing users of software to track which versions of a software project have the vulnerability. CVEs are a global system to reference vulnerabilities. A CVE ID can be given out by an organization that is registered as a “CVE Numbering Authority”, several companies act as such: Google, Autodesk, The MITRE Corporation is the overall manager of this project, and the “CVE Numbering Authority of last resort”. Getting a CVE ID is simple: you fill a form on the MITRE web site, not completely automatic, since there is a manual review process before the CVE is actually created. Primary context where this is relevant when someone in the public announces to a project they have discovered a vulnerability, having a CVE ID allows tracking that a specific version reported is fixed in which version(s). OpenEXR had a variety of experiences, CVE was filed, no one paid attention (part of the origin story of ASWF). As soon as OpenEXR was transferred to ASWF, the issue was fixed, updated the project documentation, and the CVE documentation on the MITRE web site.
  - Also got a couple of reports from “security researchers”, who seem to be people who spend full time looking for bugs. Someone presented a file that crashed OpenEXR and required we filed a CVE on their behalf. CVEs aren’t a “bad checkmark” against a library, it shows a diligence about security issues. Bug was fixed, requested CVE ID, new version was released, mentioned CVE in release notes, and notified researcher of CVE ID.
  - Fuzz testing: process of identifying corrupted / potentially malicious input data that causes crash / misbehavior on load. OpenEXR has had a fuzz testing in its test suite a long time ago. Was approached by Goggle’s ossfuzz project, thought about it for a while, then decided to do it. Google servers generated “random” EXR files and try to load them, and reports bugs when something is detected. Compiles code with -fsanitize command line option. A lot of these reports are “hard to believe” could ever be an exploitable vulnerability, so a certain amount of busy work to be expected, but several actual bugs were found. So the recommendation would be to adopt ossfuzz. Tests the software “along the edges”: test bizarrely sized images for instance. Reports from ossfuzz has slowed down to a trickle, Peter Hillman did a lot of the work to address these.
  - Tarball signing: back in the days OpenEXR was hosted on GNU savannah, tarball can be signed using GPG on upload, users can download tarball and signature and confirm that the tarball matches the project signature. Somewhat of an archaic process, most projects currently rely on the GitHub release page / process. OpenEXR still does this manually based on request from one of the Linux distros that requested it. So don’t necessarily see this as still very important, but it’s also not a lot of overhead.
  - There are many other security issues that OpenEXR hasn’t encountered, and may be encountered by OpenCue due to the network centric nature of the project.
- Daniel: do projects still in incubation have any specific questions on this topic?
- Joshua: a great step forward, very clear, OTIO can learn from this. Thank you!
Rust Bindings (Nick)
- Share the process happening around the Rust discussion, and how it should go forward, points of contact with existing projects, and welcome to new people.
- Nick: initiative being taken, something new that generates a lot of enthusiasm. A lot of movement recently in language bindings. C bindings created for OCIO and OTIO (Java as well). Scott saw opportunity to have a consistent look and organization of Rust bindings for VFX projects. Registered a number of Rust “Crates” (packages) names. Conversations started in Slack. At first was unclear what was the best way to host these conversations, created #rust channels, and created a GitHub repo, for now an independent GitHub organization to bootstrap the project, if it pans out, can bring back to TAC. Scott has done a lot of work looking for CLAs, Code of Conduct… Seems to be evolving into what could be a process for nascent community projects. Would be great to have templates that could be used for these projects. Work being done on the GitHub repo could lead to such templates.
- Larry: it’s amazing how quickly this exploded from 2 people on OCIO to 40 people on a Slack channel, ambitions are to make comprehensive bindings for a large section of the core VFX projects, all the way up to USD Rust bindings.
- Nick: Anders took automatic binding framework, what if ASWF projects had a standard adornment for exported APIs that would make automatic generation of bindings robust.
- Scott: motivation came out of a discussion on 3d-pro, decided to start wrapping OIIO, want to see more Rust in the industry, Rust is potentially a better language than C++ in the future for the industry.
- Daniel: was the aswf-sample-project useful to this process at all?
- Nick: they should be correlated and cross referenced, might need to take more initiative on some topics, such as “is it appropriate to create your own slack channel”, “what are Wiki resources available (not a lot of statements as to the purpose of the Wiki)”. Should Rust activity belong in the ASWF Wiki, or in a repo-specific Wiki?
- Daniel: should bindings live outside the project repos, or in the projects themselves? In the context of OpenEXR, it could be messy to have bindings “out in the wild”, should C bindings be pulled in to projects as core part of the project?
- Joshua: there’s a tension between “should the bindings be included in our project or a separate thing”. Worry about adding more burdens on the release process. For now the thought is that the bindings should at least be a separate repo, and use the submodule mechanism. In fact would like to factor out existing bindings in the project and move them out.
- Nick: interesting point about Java, the core team doesn’t spend a lot of time on Java, could get stuck fixing a core problem, reaching out to Java expertise
- Larry: counter point is that if the bindings are separated out, user doesn’t know if a problem is in the bindings, in the core, or version mismatch between bindings and core. Core developers are likely still going to be burdened by problem reports. If someone does the original work, test suite tests the bindings, and additional work is mostly “cut and paste”, could still be tractable without deep expertise. Also bindings could be covered in the core documentation.
- Nick: since there aren’t existing Rust bindings (as opposed to Python bindings that have grown in ad-hoc ways), there’s an opportunity to set standards for Rust bindings for all ASWF projects, would relieve a lot of maintenance burden if all the projects do it the same way.
- Wave: would love to see Swift bindings (from an Apple perspective), would be very straightforward to automatically generate from C bindings.
- Gordon: seems that this is heading towards a discussion of language adoption in the industry, are we seeing specific trends, studios heading in certain directions. Is this a good discussion topic for this group, opportunity for another survey? Would be very useful for vendors. Could be address in community survey.
- Kimball: for OpenEXR, would be convenient to have C bindings, and a chance to make structure changes to the performance of OpenEXR, so was the trigger to start working on C bindings. Makes other language bindings simpler / trivial. WETA compiles most of its own software internally, often have customized copies, use namespace to create custom namespaces. Doing that for C, which could be considered “weird”, if this is useful, we should have an agreement about these approaches, to allow users to override symbols when they need to.
- Daniel: as a complement to the VFX Reference Platform, tackling namespace would help components to cooperate.
Documentation efforts across projects (Daniel)
- Daniel: a lot of effort in OCIO, also effort in OSL, any other projects?
- Kimball: OpenEXR as well, OTIO as well
- How much integration / cooperation / best practices can we establish across these efforst
- Larry: can’t go wrong with what OCIO did, they spent a lot of time debating the right approach and tools, but the result is very clear, IMHO would have to have a strong reason to not just adopt their methodology.
- Michael: reached out to the community, got a lot of contribution, large group of different contributors. System seems fairly effective.
- Larry: lesson from OCIO is that it’s not a single person effort, had a separate committee for documentation, with new / different contributors, brought writing skills, graphic design skills. It was a big production, it takes effort to make documentation that nice.
- Cary: working on documentation for IMath, found a “hello world” project for Doxygen / Sphinx / …which was very helpful. Did struggle with Sphinx and Breathe, they are complex in the way they deal with templates.
- Daniel: is there “hidden knowledge” from OCIO that could be shared?
- Michael: one of the bigger challenges was the workflow of how to have documentation live in one place of your source tree, for instance info from C++ headers end up in documentation for Python bindings. Establishing this pipeline was complicated. Some contributors found / developed some graphs demonstrating the workflow. At first it was somewhat overwhelming, but focussed on developing a Table of Contents that everyone agreed to in a Google Doc, once we established the scope of the work, it was possible to dole out the work. Also had a deadline (SIGGRAPH), helped to get most of the work done in a month, now there’s mostly cleanup left to be done.
- Daniel: would be good to highlight key discoveries and processes.
- Larry: any documentation on the tooling that was used would be helpful, a single Markdown file that highlights it all would help.
- Michael: also developed some custom Python tools that helped, not specific to OCIO, for instance a library to parse Doxygen XML that can be imported into PyBind11, matches a subproject of PyBind11 but doesn’t require clang.
- Larry: these tools could also be used internally at studios, useful and good looking documentation is always a challenge
Survey (Daniel)
- Still hoping to follow through with survey, goal is still “early November”. Aim for next TAC meeting.
Technical Project updates
Working Groups
- CI
- Diversity & Inclusion
  - Rachel: Working on first blog posts
  - Meeting with Governing Board
- Python 3
  - RV 2021.0.0 released with Python 3 support
  - (Ashlie from Slack): The Python 3 working group has been looking at a Python 3 guide from WDAS and whether we can extract parts of it to include in our own deliverables and documentation about Python 3. We’ve also found issues with Qt related segfaults which we thought were caused by Python 3, but may actually be due to Qt 5.12 and it being more strict about memory management. So many bad behaviors we were getting with away before now seem to be causing segfaults in Qt 5.12.
- USD
  - No meeting since last TAC meeting
- Assets
- Review & Approval
GSoC Mentor Summit
- Cary: 2 sections, lightning talks (3 min per organization), our 3 minute was a “plug” for ASWF, mentioning projects and students.
- Second session was breakout sessions on topics on how to be a better mentor, how to introduce your student to the organization, but didn’t have time to attend. Seemed to be more oriented towards organizations with little experience with mentoring process.
- Very international event, a lot of the participation was from India, if it had been in person, would have been possible to talk to people directly, but didn’t get much out of it outside of giving ASWF presentation
- Next year the structure of GSoC is changing (shorter scope projects), hopefully by that stage we have some of our own mentoring programs in place.
Next meeting
18 November 2020

Action Items (AIs)

Send calendar reset instructions to TAC mailing list to help flush zoom links without password (Daniel, John)

ASWF TAC Meeting - November 04, 2020

Voting member attendance

Other Attendees

Apologies

Agenda

Action Items (AIs)

Notes

Chat