From: Taylor Blau Date: Tue, 06 Oct 2026 18:06:12 GMT Subject: [NOTES 01/07] Security mailing list and security process Message-ID: In-Reply-To: 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.