# Links

* https://www.openwall.com/lists/oss-security/2024/03/29/4
* https://tukaani.org/xz-backdoor/
* https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024
* https://boehs.org/node/everything-i-know-about-the-xz-backdoor
* https://lists.fedoraproject.org/archives/list/[e-mail]/thread/YWMNOEJ34Q7QLBWQAB5TM6A2SVJFU4RV/
* https://research.swtch.com/xz-timeline
* ASWF thread: https://academysoftwarefdn.slack.com/archives/CKAH4EU4Q/p1711817642946339
* https://github.com/ossf/wg-vulnerability-disclosures/discussions/143 (Very nice thread from industry experts)
* https://openssf.org/blog/2024/04/15/open-source-security-openssf-and-openjs-foundations-issue-alert-for-social-engineering-takeovers-of-open-source-projects/

# Notes

* CLA would not have prevented the attack.
* First of all, the attack came from the inside.
* Knowing who was the threat actor doesn't really solve any issues. Energy is better spent elsewhere. Authorities (governments, etc) will take care of finding the person responsible for the backdoor).
* A CLA can't be used to know for sure who someone is because anyone can enter whatever information they want when they fill a CLA. They can even enter invalid data.
* ASWF projects are in a better position than xz when it comes to maintenance. TSCs can serve as a tool to keep control of a project (if TSC members are active and projects make sure that they remove and replace inative members).
* It's not a silver bullet, but it's a tool.
* It's a tool because there needs to be a vote to accept a new member. The decision to add a maintainer doesn't solely rely on a single person.
* If a project ever gets into a situation where there is only one TSC member left and that person burns out or leaves the project, what would happen?
* https://www.bestpractices.dev is important! Projects should try to reach the gold level, or at least they should try to satisfy most requirements of all levels.
* An ounce of prevention is worth a pound of cure? Better safe than sorry?
* Security is extremelly important and shouldn't be ignored for the more "shiny" things.
* Time spent on improving the security posture of your project is time spent to protect your users.
* Projects are starting to think about getting into web browsers and being used in web services, etc. We'll have a ticking bomb waiting to explode in our hands if we don't secure our projects before it becomes our present and new reality and studios/companies start to rely on our projects in these scenarios.
* (personal opinion): I think VFX studios would be happy to hear that ASWF projects are spending time on improving their security posture instead of working on new features, since they will directly benefit from these security improvements.
* Audit permissions and assets
* Which sites/services is used by the project?
* Where are things hosted??
* Who has access to what and what permissions do they have?
* Why? Because when things go wrong and you are attacked from the inside like in xz's case, knowing your assets and who has access to what will speed up the response time to remove the attacker from your systems.
* Do you have any binary blobs in your repo?
* If so, are you able to mechanically re-create them using a script?
* Are you SLSA level 3 compliant (this would have avoided the problem where the artifacts uploaded on the release differ from the source code). Or at least it would have been very easy to spot.
* Are you able to reproduce your release artifacts (yes, even tarballs, zips, etc).
* Are you able to prove that they are reproducible?
* Also related to SLSA
* Would an image cound as a binary blob?
* Could some of these images be created using scripts?
* Are they part of the build process or are they optional?
* Are they included in the distributed source or not?
* If you accept an image as a test case for your project, do you have a process in place to track where it's coming from, how it was generated, inspect its content, scan for viruses, etc?
* It's not always going to be easy or possible to answer these kind of questions, but it's probably worth considering the or keeping these things in mind.
* Release process:
* Is your release process fully automated and easily auditable? AGAIN SLSA.
* Is it documented and if so, is it publicly available (again for auditing purposes and also for transparency)
* Don't use autotools and use a more modern build system. I don't think any ASWF project use autotools, but it's worth saying anyway.
* Projects should simplify their build system (related to not using autotools)
* What about the case where the accound of Jia was under control of an attacker?
* What would be the impact if my account ([@JeanChristopheMorinPerso](https://github.com/JeanChristopheMorinPerso)) was taken over by a malicious actor?
* Personal note: improve my hygiene regarding what I have access to and better track what I have access to and maintain? In other words, reduce the blast radius of an account take over, or in yet other words, the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege).

# Meeting notes (2024-04-22)

* Larry: Would we have fallen to it?
* Stephen: How do you make sure that contributions you receive are safe?
* Larry: We have inherited a circle of trust. We all know each other right now. Projects are backed by companies.
* Cary: Claryfying how projects promote contributors to maintainers.
* JC: It's hard to protect against an insider threat. Or you could trust someone and their account could be hacked/taken over.
* JC: We could give guidance or a framework for our projects on who to know when it's safe to promote contributors to higher roles?
* Cary: Could we clarify roles?
* Larry: We shouldn't give keys to a project if that person has never showed up to a meeting.
* John: How do we avoid situations where it would be hard to everbecome a maintainer if you are not already poart of the cicle of trust we currently have?
* John: The XZ creator was put under pressure ot add a maintainer. Attackers were pushing really hard.
* We are protected by the TSCs, TAC, etc.
* JC: See my point above in the notes
* Cary: OpenEXR was in a similar situation than XZ before it joined the ASWF.
* Larry: What should project do when someone submits a huge patch that is for something that a project really want but nobody has the time to review in-depth? How they submit a patch for a platform that nobody know about or don't have access to? Would projects just merge it without looking into it too much?
* Cary: OpenEXR accepted a bazel build system. Nobody knows anything about it.
* John: If something is too esoteric, maybe we should reject it.
* Windows is a good example. Very little people know about WIndows, and so it's sometimes hard to know if WINdows changes are good or not and if they should be accepted.
* Ben: How about identity verification? Should we go through all maintainers of every ASWF projects and verify their identity?
* JC: I don't like the idea
* Larry: Yes
* John: It's a sensitive topic.
* Larry: Does the kernel have any identity verification in place?
* John: No
* Cary: All the stuff I did with OpenEXR
* JC: I agree. We can also improve it with how to prove how binaries, source artifacts were produces and where they were produced.
* JC: What about projects that accept binary blobs (like images)?
* Larry: It woul be hard to avoid in some projects.
* JC: Could we provide guidance for projects to be careful when accepting them.