TSC meeting notes from 9/26/2019

Signed-off-by: Cary Phillips <cary@ilm.com>

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.