More HTTP/3 focus, one backend less (#curl drops OpenSSL-QUIC support)
Say hello to the 29th URL scheme #curl supports MQTTS://
You are hereby banned from our program. We don't want your "help". Please never contact us again. (just sent off to another "helpful" security researcher)
some of these graphs are truly helpful to us, some of them I think show "interesting stuff" that we can extract from an old well maintained source code written in C even though that data might not really help us. Then there is a subset of graphs that are mostly silly and they are there simply because I'm obsessed with graphs. Just 6 graphs left to the big 100. Isn't that what all projects aim for? Updated daily here:
"taking an OpenSSL public API and attempting to trace the implementation to see how it is implemented has become an exercise in self-flagellation"
There, now you know.
It is our moral imperative to consider the "real world" and actual users when assessing the possible security impact of a reported #curl issue. If we deem that there is likely to be zero affected users, then we do more damage than good by insisting on doing the security dance for the issue. Then we end up with a severity level that is below LOW, and then we treat it as a bug instead. For the good of mankind.
When I find myself working in a big pile of metaphorical manure, I can always bring out this email I received on this day, nine years ago... image
$ git log --author="Daniel Stenberg" --oneline | wc -l 19988
On the morning of the 13th day of the year we have received *checks notes* 13 #curl vulnerability reports on Hackerone this year. None a confirmed vulnerability.