Redis: Security Fixes and New Rate Limiting Powers

Transcript

Hey there, developers! Welcome back to another episode of the Redis podcast. I'm so glad you're joining me today because we've got some really interesting changes to talk about. It's March 19th, and the Redis team has been busy with both critical fixes and some pretty cool new features.

Let's jump right into our merged pull requests, starting with something that's super important but might not get the flashy headlines it deserves. Zijie Zhao tackled a really nasty security issue with PR 14847. This was all about fixing ACL out-of-bounds access for commands with wrong arity. Now, I know that sounds technical, but here's the story - when you had commands like EVAL with the wrong number of arguments, Redis was trying to extract keys before properly checking if those arguments even existed. It's like reaching for a book on a shelf without checking if the shelf actually has that many books. Zijie fixed this by making sure we check command arity first, just like the main command processing does. It's one of those changes that makes Redis more robust and secure, and I love seeing this kind of defensive programming.

Speaking of improvements, we got a fantastic infrastructure update from gentcys with PR 14891. They added ARM64 jobs to the daily CI workflow, which is huge for anyone running Redis on Raspberry Pi, AWS Graviton, or Apple Silicon machines. The motivation here is simple but so important - Redis runs everywhere, so we need to test everywhere. This addition means we're catching ARM64-specific issues before they reach you, which is exactly the kind of proactive testing that makes open source projects reliable.

Our third merged PR comes from judeng, and this one's all about clean architecture. They refactored the async slot migration code to remove tight coupling between the ASM module and the core cluster implementation. It's like untangling Christmas lights - not glamorous work, but it makes everything so much easier to work with later. This kind of refactoring is what keeps codebases healthy and maintainable as they grow.

Now, let me tell you about something that got me genuinely excited - we have a brand new GCRA rate limiting feature! This is essentially bringing the popular redis-cell module functionality directly into Redis core. If you've ever needed to implement rate limiting - and honestly, who hasn't these days - you know how valuable this is. The new GCRA command lets you set up sophisticated rate limiting with burst capacity, sustained rates, and flexible time periods. What's really cool is they made the period parameter accept floating-point numbers instead of just integers, giving you much more flexibility in your rate limiting strategies.

We also saw a nice fix for redis-benchmark and redis-cli that prevents divide-by-zero errors when dealing with empty histograms. It's one of those edge cases that might not happen often, but when it does, you'll be grateful someone thought to handle it properly.

Here's what I love about today's changes - we're seeing Redis evolve in multiple dimensions at once. Security is getting tighter, platform support is expanding, architecture is getting cleaner, and new features are being added thoughtfully. Each of these changes makes Redis a better tool for all of us.

For today's focus, if you're using Redis in production, definitely keep an eye on that ACL fix when you update. And if you've been implementing rate limiting with external tools or Lua scripts, you might want to explore that new GCRA command - it could simplify your stack quite a bit.

The Redis community continues to impress me with the quality and thoughtfulness of these contributions. Whether it's security fixes, infrastructure improvements, or exciting new features, every change feels purposeful and well-considered.

That's a wrap for today! Keep building amazing things, and I'll catch you next time with more Redis updates. Until then, happy coding!