3 ms·
Brutal - Unicorn didn't use Rack.env in a thread safe way. It's tougher given that this was in a widely used app-server and not even in Rails code. Impressed w
by shay_ker 6y ago
Brutal - Unicorn didn't use Rack.env in a thread safe way. It's tougher given that this was in a widely used app-server and not even in Rails code.
Impressed with GH folks in finding this, though I wonder how many more of these types of bugs are out there in Ruby libs. It'd be nice to make this more difficult to do, a la FP languages, by making it really intentional to modify state. Maybe in Ruby 4??
- SilverRed 6y agoI feel like if you dig down deep enough, every single site on the web has a serious security bug in its app code or the layers it runs on top of. How many more bugs are there still in the CPU your server runs on?
- Thorrez 6y ago>Unicorn didn't use Rack.env in a thread safe way. Was Unicorn itself not thread safe? It sounds like Unicorn had the requirement that once you send back the request to the user you must stop accessing the request object. Maybe Unicorn didn't document that requirement clearly, but even if it's not documented it's not clear to me that Unicorn itself is not thread safe, but rather that it has undocumented pitfalls that can easily lead to thread unsafety.
- chucke 6y agounicorn is single-threaded by design, and is not expected to support any background threading workarounds that people build on top of it. That "feature" in github shouldn't be passing the env hash.