computerfan494

By "patch" I am talking about the public commit. Updated binaries were made available when the CVE was published.

That's a good question. I suppose that posting the commit makes it incredibly obvious how to exploit the issue, so maybe they wanted to wait a little bit longer for their on-prem users who were slow to patch?

The author of this post is incorrect about the timeline. Our Atlas clusters were upgraded days before the CVE was announced.

If this is a result of that vulnerability, Ubisoft only have themselves to blame. Our support contacts ensured that we knew about the vulnerability as early as possible and gave us a clear guide to remediation for our self-hosted clusters. Our Atlas clusters were automatically patched before this was announced publicly. You'd have to be running your database open to the internet (already a mistake), ignore the advice to simply turn off zlib, and ignore the fixed versions that have been available for over a week.

If you're going to be in the business of running your own critical infrastructure, you better have spent a lot of effort planning for these situations, because they are inevitable. Otherwise, it's easier to just pay a vendor to do it for you.

We received communication that all Atlas clusters were upgraded with the fix before the vulnerability was announced.

Yes, and my point is that this customer switching to running their own MongoDB instances on EC2 like Atlas does would reduce the bill by less than 50% because the rates that they are charging mean that their cut is less than what AWS is getting from this customer.

You can look at this particular bill and observe that more than 50% of the cost was going to AWS.

There's definitely MongoDB markup, but a full 33% of their bill was AWS networking costs that have nothing to do with Atlas.

Most of the cost in their bill wasn't from MongoDB, it was cost passed on from AWS

I can assure you that Stripe does not regret the decision.

Maybe it's only me, but I just don't write that much code. I try to change less than 100ish lines per day. I try to keep codebases small. I don't want to run a codebase with hundreds of thousands of lines of code in a production environment.

I'm not planning to because there is no documented protocol. If there were, I might! As a result, I can't use FoundationDB.

The hard part is that there is no client spec you can follow as a third-party. Everything is implementation-defined. If you're out-of-tree, your code can break at any time. If the FoundationDB project committed to a protocol, client authors could write libraries outside of the main project.

FoundationDB is very cool, but I wish it didn't require linking in their C library to talk to it. The client story is not good.