Artificial truth

The more you see, the less you believe.

[archives] [latest] | [homepage] | [atom/rss/twitter]

What about something like letsencrypt and ACME, but for bugs?
Wed 13 May 2020 — download

Before Let's encrypt, around 30% of the web requests done by firefox were encrypted, now it's around 80-90%. The main reason behind this change is of course that Let's encrypt issues certificates for free. But there is an other important related change: not only is the web now encrypted, but certificates are automatically rotated, thanks to the ACME protocol. So it's both openly specified, with an API, and it's free.

And now, on a completely unrelated topic: semi-public/public bug producing machineries:

If you've fuzzed at scale, you know that it's usually way easier to find crashes than to get them fixed, and if you're an user, you know that it's easier to get the latest version than to find to what crashes your current installed one is vulnerable.

Wouldn't it be neat to have a standardized protocol to ask various "fuzzing authorities" if a given CPE is prone to (known) crashes, what is the mean time between the discovery of crashing input and a fix, how many crashes were found this month by how many CPU, what is the usual severity/type of crash, … and if the fateful 90-days deadline is passed, being able to get the reproducers?

I know that some people are already crawling bugtrackers and grepping VCS, either to find juicy 1-days, or to shove into some pricey intelligence feed. But as a user, I think it would be fantastic if I could with a simple query have all those information, before deciding to deploy a particular software.

Maybe something a bit like - the Core Infrastructure Best practise program, but useful. - CVE, but for every single crash - debsecan but not only for Debian packages