> if there is such a bug, I'm sure someone will figure out how to get in touch with Daniel and co

No, that is the point, they are not going to accept your vuln report. They are taking a holiday.

There's a pretty big difference between a random report submitted via email, and, say, a close friend of the maintainers letting them know a serious vuln was found and they should login.

Curl maintainers are clearly going to still be using computers to provide support for paid customers.

But the message is pretty clear: if you’re not a paid customer, you are not getting patches or support from upstream during this month.

Plan accordingly.

Not if it's a real vacation. If it was me then there would be no way I'd log in. Maybe this will increase the sales of support contracts.

Except if you pay them for a support contract. So there is a way, and it's actually a pretty obvious way.

I wonder if the likes of Red Hat, SuSE and Canonical have a support contract as they are commercial redistributors.

Probably not. Why pay someone who's willing to work for free? When he stops working for free, then you pay him. Open source is not exempt from economic principles.

> curl is mature enough that the chance of an impactful bug is basically zero

Curl is also something that should be thoroughly sandboxed to begin with, because even if there are no vulnerabilities in curl itself, its a tool for downloading arbitrary data over the internet, and you may well accidentally trigger vulnerabilities in every other part of your environment just by downloading arbitrary data to your shell...

curl is the sandbox. It exchanges packets with the internet and then outputs a safely sanitized byte stream.

curl is only the sandbox if you don't then do anything with the byte stream.

Pipe it to bash? game over

Pipe it to less/more? Better hope your distro keeps those patched

Open the file in a browser or PDF reader? Hey, look at all this shiny new attack surface!

Well yeah, that's true for any sandbox. If you pipe stuff outside of the sandbox, outside of any sandbox, and run it there, then you're not running it in a sandbox.

Right, but nobody actually uses curl as the end destination, right? You use it to download something so that you can run another tool on it.

And as such, you need to already be sandboxing the tool (since it processes untrusted data you received over the internet).

How would sandboxing curl help with vulnerabilities in your pdf reader?

Obviously, you need to sandbox all tools in the chain that handles untrusted data. This is security 101 stuff

Do you sandbox the sandbox? When do you stop?

How do you set up the sandbox without having downloaded anything from the internet? I guess there’s still places where you can buy Linux CDs.

curl is not anti-virus.