you know its a special day when the curl signal group is busier than the mastodon feed

Please upgrade certifi in all Python applications to the latest version (2026.10.19) following emSign CA certificate security incident:

https://github.com/certifi/python-certifi/security/advisories/GHSA-6q48-6c7w-9gw2

#security #python

Dear Diary,

we stemmed the HackerOne flood some more today.

Then we got notifications via all available communication channels to several people in the project that we need to do something because Mozilla did not.

Also, the Google cloud melted in Europe and no one had access to banking.

On the upside, github was only normally unreliable, not more than every day.

*chews on his pen*

The day is not over yet, I just thought I'd write this down before I forget. k, thx, byeee!

the alarm: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/0XofdebrAAAJ?pli=1

The CA cert bundle on curl.se is updated accordingly after the latest alarms. If you use one of these: update.

https://curl.se/docs/caextract.html

RE: https://infosec.exchange/@harrysintonen/117473095311666143

Someone just a little mean spirited would perhaps think that Mozilla doesn't really care since Firefox itself is not harmed by this since they have other means. It's only the rest of the internet world who might burn...

We started the #curl hackerone program in April 2019. We have received 1,030 vulnerability reports over these 7.5 years.

More than a third of the reports were submitted in 2026.

RE: https://hachyderm.io/@golang/117470816794707999

Update everything that verifies certificates against public roots.

The next one just below in my queue: its initial paragraph has 392 words in 2265 characters.

The first line in the submission form says:

"Initial reports should be six or fewer sentences describing the issue and optionally a short proof-of-concept script."

Original AI word salad describing a flaw: 241 words and 1322 characters.

My human summary of the same problem: 27 words,. 142 characters.

"Ignoring the slop" cannot be done and it doesn't help. These reports created with the help of AIs point out actual problems, and sometimes vulnerabilities. Ignoring real vulnerabilities because they were found by AI does not make users safe and secure. It makes them vulnerable. We don't want that. (I don't call this "slop" because it's typically accurate and correct, even if too wordy)

We're slowly realizing this is the new reality. This is the background noise we must live with, so we need to adapt our processes to this. A 5 submissions a day life.

Do minor #curl vulnerabilities in the open

(Starting Monday October 26)

https://daniel.haxx.se/blog/2026/10/20/do-minor-curl-vulnerabilities-in-the-open/

#curl hackerone stats as of yday

This policy change is entirely triggered by the current avalanche of vulnerability reports that keep pouring in. We see no end to them and we do not anticipate this flood to decrease within the next several months.

We are struggling as a project as all key maintainers feel strained, overloaded and brought to the brink of what we can muster. We must act to survive. This is our next step in a survival strategy. It might not be our last. We aim to not drown.

At our #curl maintainer meeting tonight we decided to move forward with the "handle LOW/MED vuln reports openly on GitHub".

Now we just need to get the documentation and processes adjusted, then push the button to do this. Maybe write a blog post too. So, ideally within this week.

Stay tuned

@bittcrak I'm disclosing several curl vuln reports per day, there are perhaps hundreds of examples: https://hackerone.com/hacktivity/overview?queryString=team%3A%28%22curl%22%29+AND+disclosed%3Atrue&sortField=latest_disclosable_activity_at&sortDirection=DESC&pageIndex=0

@icing a thing I'm still grieving is the world where when someone reported a bug/vuln it was typically because either A) they were a user of the software, and bumped into the issue B) they thought harder about the code than I had when I wrote it, and found something overlooked. Some combination of those factors helped alleviate the feeling of "damn, I fucked up".

I'm all for improving things but the wave of input from drive-by "people" that are both divorced from the purpose/use of the software, and have also spent no time doing any real analysis of their own sucks... It wears you down in a uniquely new way and there's nothing compensating for the negative feelings.

And all I do now is cleaning toilets

working with vulnerability reports really is the toilet cleaning of open source