diff --git a/ASWF/tsc-meetings/2019-09-17.md b/ASWF/tsc-meetings/2019-09-19.md similarity index 100% rename from ASWF/tsc-meetings/2019-09-17.md rename to ASWF/tsc-meetings/2019-09-19.md diff --git a/ASWF/tsc-meetings/2019-09-26.md b/ASWF/tsc-meetings/2019-09-26.md new file mode 100644 index 0000000000..a2f87bddc8 --- /dev/null +++ b/ASWF/tsc-meetings/2019-09-26.md @@ -0,0 +1,97 @@ +# 9/26/2019 + +### Agenda: + +* Dan Hutchinson (Foundry, security expert) + - What should we know? We don’t know what we don’t know. + - CVE’s on mitre.org + - Allocating huge memory: -x option? +* Tarball signing +* VFX reference platform says 2.3.x ?!? +* Distro packages +* SonarCloud has failed on last 2 PRS’s +* Mission Statement +* Reference images + +### Attending: + +* Cary Phillips +* Christina Tempelaar-Lietz +* Kimball Thurston +* Joseph Goldstone +* Peter Hillman +* Doug Walker +* Dan Hutchinson +* Carol Payne +* Daniel Heckenberg + +### Discussion: + +* Dan Hutchinson joined from Foundry to discuss security. + +* There’s a healthy security research community, likes to look at + popular libraries and does research to find vulnerabilities. They’re + quite enthusiastic. + +* Projects need a security policy, and should announce a solicitation + to the community to report vulnerabilities. Some projects post a PGP + key with which to encrypt vulnerability reports. + +* Projects should have a Responsible Disclosure Policy - given 60 days + to respond. + +* There’s a huge chasm between a bug and an exploit, a way of turning + the bug into an actionable way of gaining access to a system. It’s + legitimate for projects to ask, “Do you have an exploit available?” + +* Projects need static and dynamic analyzers. OpenEXR uses + Sonar. SonarCube is a report aggregator. It can subsume valgrind + reports. + +* How concerned should we be about security? Put yourself in the + shoes of a hacker: file formats are a common attack vector. + +* Dan: OpenEXR is being proactive already;IlmImfFuzzTest is “awesome”. + +* Dan: Fewer than 10 CVE’s in 10 years is a pretty good record for a + file format. + +* Dan: From what you’ve said, OpenEXR has ticked all the security + boxes. + +* There are issues with how the library is used: the API says pass in + a buffer of size X and application passes in buffer of size X-1, and + we overwrite. Is that our problem? Not really. + +* Some of the complaints were that the library could allocate all the + machine’s memory, then something else would crash, leading to a + DoS. DoS attacks are common, but not the worst vulnerability. + +* An image can be large but compress well, so a small file can lead to + large memory allocation. + +* Tiff has a comparable attribute structure: is there anything we can + learn from them? + +* Is there a plan to provide binary packages hosted in nexus? Not yet. + +* Should use common hardening C++ flags. + +* Is it worth providing GPG signatures? It prevents against someone + someone inserting something into the repo, and man-in-the-middle + attacks.. + +* Should enable 2-factor authentication on GitHub accounts. + +* Would hope that package maintainers would be proactive, but many of + them probably include OpenEXR only because it’s a dependency of + something else which might not have changed.. + +* Reference images: it would be helpful to have a set of images for + use with a performance test suite, and that exhibit a range of + features of the library and format, such as multiple AOV’s, + etc. https://github.com/openexr/openexr-images needs some curating. + +* TAC meeting yesterday - Michael Johnson mentioned that Apple is + sitting on some security-related issues, will work on getting them + approved.