Seems similar to Apple's 2015 acquisition of FoundationDB -- they sunset the commercial offering. But it's unclear if they acquired Styra or just hired the team?
This is a more defensible take than some on here, but still a wild comparison. FDB was closed source software that existing customers kept source access to the entire time it was closed, and then opened under a permissive license soon after. So yes, you couldn’t buy it, but if you had, you kept access to new development.
Yes, similar discussion across two separate articles:
(1) article from General Analysis on "Supabase MCP can leak your entire SQL database"
(2) article from Oso talking about why authorization in AI is hard, what to do about it, which references the General Analysis article
Out of an abundance of caution, we cast a wide net and contacted all current and past MongoDB users, including those that may have closed their MongoDB Atlas Projects. If you would like to have your contact information completely deleted from our systems, please file a GDPR deletion request: https://www.mongodb.com/legal/privacy-policy/request-for-del...
You can reach out to me directly for assistance with this, if needed. My email is my first name at mongodb dot com.
The login issues are unrelated to the security incident. We notified all of our customers and users concurrently resulting in a spike in login attempts. Please try again in a few minutes if you are still having trouble logging in.
Nice post. This covers how you'd model the permissions, etc. but do you have any articles/docs on how you'd actually integrate this into an application?
- It's an ideal language for writing security-focused software given that it eliminates memory safety bugs (a leading cause of security vulnerabilities in the wild).
- Authorization is generally on the critical path, so providing a decision quickly is very important. Rust is extremely fast, but more crucially it doesn't have runtime garbage collection so there's no possibility of an ill-timed GC run disrupting your application.
- Rust has a great language interoperability story. We designed oso as a library that you embed in your application. The upshot of that is that we've already built Java, Python, and Ruby libraries, with additional languages to follow. Using Rust allowed us to write the core logic and runtime once in a correct, extremely performant language and then write the language libraries as thin shells around the Rust core. That lowered the bar for expanding oso to new languages pretty dramatically.
Agree that eventual consistency is inappropriate for the majority of database workloads. This is why we has always defaulted to strong consistency, by reading from primary nodes in a cluster. (Because eventual consistency is sometimes useful, MongoDB offers eventual consistency, too.)
As I understand things based on the OP it seems however your documentation promotes the insecure way of setting up mongodb. It's even true that mongodb doesn't even ask to create db credentials during the installation,something it should do by default.
the real problem is lack of network protections. there are many things on the internet unprotected. this article is not news. dont put your database on the internet.
Security is a matter of layers, like an onion, it's not just an either-or. Any sensible database or database-like software does not come with authentication disabled by default. Yes, your DB should be behind a firewall, but if RedHat installed out of the box without a root password you wouldn't say "well your server should be behind a firewall anyway."
