#curl security report number **eight** within the last seven days was just received. And as 8 out of 8 it will be closed as not applicable.
This is roughly 4x our normal average frequency. No clue as to why this peaks now.
We clearly need to raise the bar somehow to stop sand from getting into the machine.
excds
in reply to daniel:// stenberg:// • • •Billy O'Neal
in reply to daniel:// stenberg:// • • •New AI acid test just dropped: finding legitimate curl CVE.
At least, that seems to be what grifters are thinking.
the vessel of morganna
in reply to daniel:// stenberg:// • • •This one is really amusing.. "use after free" when the example code *literally* calls SSL_free then reuses the pointer. my brother in christ your "proof of concept" is literally just faulty code that has nothing to do with openssl
hackerone.com/reports/3242005
curl disclosed on HackerOne: Use-After-Free in OpenSSL Keylog...
HackerOnedaniel:// stenberg://
in reply to the vessel of morganna • • •daniel:// stenberg:// reshared this.
the vessel of morganna
in reply to daniel:// stenberg:// • • •Gregory
in reply to the vessel of morganna • • •daniel:// stenberg://
in reply to Gregory • • •mijenix
in reply to daniel:// stenberg:// • • •Stephen Rosen
in reply to daniel:// stenberg:// • • •while everyone is sharing their outrage -- and it is outrageous -- your ending note here is spot on. How do we stop this?
This is going to burn maintainers out.
We're going to need to come up with something. Maybe it will look something like CLA-signing bots, but what could submitters sign? A statement that they've read the project policy on slop?
I can't say I'm confident that would help.