[NOTES 01/07] Security mailing list and security process

[Taylor Blau <ttaylorr@openai.com>]

Topic: Security mailing list and security process
Leader: Toon Claes
Notetaker: Peff

* Toon: We have a high influx of reports on the security list from
  outside the community, probably from people using AI. There are many
  unaddressed reports. We need a better process for addressing them, and
  to figure out who will do the work.

* Emily: How are we cutting security releases now? Are we waiting for
  the reports to stop before cutting a release?

* Taylor: There are many reports we still need to triage and determine
  which are important.

* Toon: I have been organizing the reports, and some patches have been
  sitting around for months.

* Patrick: Eventually we have to cut a release, because the influx will
  not stop.

* Peff: We should act on what we have triaged once we have enough for a
  release.

* Patrick: We get many duplicate reports from AI findings. We should be
  more willing to cut releases, with a well-defined timeline. We should
  document the process, perhaps in terms of a number of weeks after a
  report.

* Peff: I am hesitant to promise a response to reports within a fixed
  number of weeks.

* Patrick: We should try to rely on companies investing in fixes,
  without forcing volunteers to work on them.

* brian: We should document our security model. Many reports are not
  vulnerabilities, but explaining why takes work.

* Patrick: Documenting the model might also help AI tools respect it.

* Emily: Are we interested in following the Linux kernel's approach of
  not embargoing AI-found vulnerabilities?

* Patrick: I am worried about that because of vulnerabilities affecting
  forges.

* Taylor: It depends on the models; some are better than others.

* Patrick: We should fix non-security issues on the public mailing list,
  and be more proactive about moving reports there when nobody else
  replies.

* brian: Sometimes there is pushback about whether something is a
  vulnerability.

* Patrick: There should probably be a period after which it is assumed
  that a report can go public.

* Patrick: GitLab has put some resources into this, but I would like to
  see more from other companies.

* Emily: It has been difficult to get resources from companies. The
  response is often that AI could help with triage, but putting
  non-public knowledge into public AI systems feels risky.

* Taylor: We could consider using AI to help with triage and writing
  patches. It might be easier to get companies to sponsor the work if it
  is less arduous.

* brian: There are DCO questions, which I would like to leave for the AI
  discussion. At GitHub, Elijah is our only person in git-contrib. There
  is more work than we have staff for, and corporate email requirements
  make list work difficult.

* Peff: We can coordinate in the cabal repository.

* Patrick: Could we put money into a fund to pay somebody to work on
  security, perhaps using AI, and get ahead of the findings?

* Martin: The project has a bucket of money.

* Taylor: I do not have the exact figure, but probably around $100k.
  Would we hire a third party, or somebody from one of the companies?

* Patrick: We probably need somebody from the project.

* Emily: Why is there resistance to hiring a third party?

* Peff: I am skeptical because the onboarding cost and time might be
  substantial.

* Emily: There are contracting firms suited to open source. We have been
  happy with Collabora, and I am happy to explore similar options,
  though it costs a bit more.

* Adrian: Such projects are hard to pitch internally. We do address
  security issues in other projects, but at a normal rate of $200/hour,
  a $100k project is difficult to pitch.

* Peff: Toon has already made a list, and we have fixes. Can we make a
  release with what we have? The list may not be as long as we think.

* Patrick: Can we write down the process, and perhaps automate it?

* Taylor: It is not primarily a scripting issue. We need to assemble the
  required tags and have the confidence to say we have enough to cut a
  release. We should discuss it on the list. The list of reports is long
  enough that we may never get through all of it.

* Patrick: We should get more comfortable with faster releases.

* brian: Anyone should be able to propose a new release.

* Patrick: We can try to accommodate different release schedules, but
  eventually we should put our foot down.

* Taylor: Microsoft needs around seven weeks for a release.

* brian: Microsoft needs to provide staffing if it wants a particular
  schedule.

* Taylor: Does anybody object to telling Microsoft that we will not
  follow its schedule?

* [No objections recorded.]

* Patrick: Agreed. Who wants to tell them?

* Taylor: I do not want to make an ultimatum about adding resources.
  They might add a third party that does not work well with us and still
  stick with Patch Tuesday.

* Peff: I had hoped to goad Toon into handling a release.

* Toon: OK, but I mostly do not know how.

* Patrick: That is a general problem: the process is not documented, and
  we need to figure it out.

* Peff: I will see if I can dig up the resources I remember. Is it OK to
  discuss the process on the public list?

* [General agreement that discussion on the public list is OK.]

* Peff: I will write an email to the public list to start the process
  discussion.

* Taylor: Johannes, Junio, and I should contribute our experience.

* Patrick: Would scripting make it easier?

* Taylor: No, it is the work of merging fixes up through the versions.

* Junio: Fixes do not always apply to both old and new code.

* Peff: There is also the work of writing security advisories and
  obtaining CVEs.