1. SSL is going to be merged in the next days, I'm in this moment here in SF in the same room with the patch author, she made a wonderful work and the patch is "opt in", simple, and good, so this is going to happen.
2. Forking is a right that open source gives you. Have fun coding Josiah!
3. I really will push for any fork not being called Redis. I care a lot about the details, the stability, the quality and the ideas in my project, and I really want that when people say "Redis", it's Redis, and not a Redis fork.
4. I'll be a bit disappointed if the license of the fork is so that it will be possible to merge my(1) BSD code but I will not be able to merge back potential change. It's legal, it's possible to do for this approach, but it IMHO ethically speaking sucks.
(1) my as mine and a number of other contribs.
For example, you can get Firefox under the MPL, which says nothing about having to rename, but you still can't use the name "Firefox" if you distribute a modified version, due to Mozilla's trademark policy.
According to a comment on Reddit, Josiah wasn't aware of this effort by AWS.
I look forward to everyone having SSL :)
First-hand report from the impromptu Friday post-conf devmeet: he's gonna merge it! ;)
Anyway, I don't think anyone would use a fork of Redis just because of SSL. I would take the perf hit and go with socket tunneling just so that I don't have to deal with the maintenance burden of depending on a fork.
But SSL isn't the only thing. Transactions with rollbacks too. Being able to kill a Lua script that has already written. Transactions involving keys spread across multiple Redis Cluster nodes. 3-5x faster startup. I mean, I can go on.
At what point would it make sense for your organization to switch Redis binaries?
"Eventually" it's 2018. It's too late.
I'm especially cynical and jaded about the insanity of running any plaintext protocols in 2018, why wasn't SSL/TLS implemented by now? It should have been at the top of the priority list.
People who think unencrypted traffic is okay should have their competency challenged. Sure, in very limited specific deployment models you can maybe get away with it without compromising security, but actually even in the most restrictive networks it is still an open door for exploitation.
It's the same kind of stupidity as Docker running as root by default... this stuff is amateur hour and these apps are mission critical enterprise tools. That's a bad recipe. In the 90s it was forgiveable, today it is not.
Kudos to the guy. Maybe it'll light a fire under the official project. Or maybe the fork will pick up steam. It'll be interesting to see what happens.
I'm not saying Redis TLS is a bad thing (honestly: I'd prioritize "not having Redis in a design" over "making sure Redis runs over TLS"), but I think in a lot of very mainstream designs, it's mostly a cosmetic security control.
For the examples I was running, it's like going from 2 hours of total CPU time to 50 minutes, versus 40 minutes for no SSL/TLS. Or going from 1 hour to run the test to 45 minutes, versus 35 minutes with no SSL/TLS.
Redis is a tool and does what you make of it. You shouldn't have such demands for an open source project. It explicitly states that it doesn't support that and even gives you a workaround and warns you about your deployment model.
The problem here is that this change is not a fork-worthy feature. This is PR-level stuff. This discussion is not about Redis being 'amateur hour'. It may be for some people who have no idea what they're doing, but the industry managed to go around that.
Also, https://github.com/antirez/redis/pull/4855 ?
Some of that very well may make it back upstream. I can't say; a lot of what I've already done and am planning has been rejected before. Which is why there is the fork. I need those things, Salvatore already rejected them, maybe someone else would need them too, I'll fork.
About the mission critical stuff I was mentioning is a pet peeve of mine. Often people don't realize that most of this stuff is 'buyer beware' and comes with no guarantees. So if a tool has a certain set of features and becomes mission critical then you can't 'demand' extra features just because it became so important. The right approach is to either support the business side of the project and upgrade or as I mentioned above, roll your own.
We'll see if the other stuff I'm working on causes the fork to take off; SSL/TLS won't :P
Main concept: http://thredis.org/
Implementation details: https://github.com/grisha/thredis/blob/master/README-THREDIS
As for the story; the clues are there in public if you dig a bit, but aren't all that interesting to anyone.
Edit: found some more details over on reddit:
I didn't see the existing TLS PR, and I'm not finding it now. Do you have a link?
As for why fork and not PR, Salvatore already closed the Transactions PR and said he didn't want Redis to go in that direction. And when searching about SSL/TLS in Redis itself, I found this: https://redis.io/topics/encryption , read the implementation of spiped (it uses fixed 1k block sizes), then realized that SSL/TLS is the right answer in this situation.
Could transactions be a module? I was about halfway through the cluster transaction bits as a module when I hit a collection of "oh wait, I can't even call this entire class of things unless I create new module wrappers for both directions" problems. Then I just added a new .c file, new .h, did the right includes, a make clean && make, and my life was 10x better.
Also, this just includes redis-benchmark, redis with SSL/TLS, etc., is still a couple weeks out. I need to get redis-cli > and redis-sentinel speaking SSL/TLS.
 - https://www.reddit.com/r/redis/comments/8f373k/a_new_redis_f...
This fork announcement was a, "Hey, you can probably use this stuff, but it might not be usable for everyone now. In the future, it might be a materially better solution for some of your problems (transactions). I'd appreciate some sort of vote of confidence if you all think it's cool, or even an 'eff off' if I've somehow pissed in your coffee."
With the SSL work in PR #4855, some of the announcement has no real use now, and I've redirected my own efforts in its wake.
It's probably more complicated than that given that the Redis security page begins with:
> Redis is designed to be accessed by trusted clients inside trusted environments.
I think the current recommended approach for this use case is to wrap it with stunnel.
But #4855 is going to be merged, and my tests show that #4855 is actually faster than my changes, so ... :)
I like not having to be responsible for writing SSL/TLS code, even if I just spent 9 weeks doing it. :P
Good code is good code.
> And as a basic need, relying on third party tools for SSL/TLS termination or a transparent VPN solution is a great first step from running without encryption, but it can leave speed on the table. And part of the reason why we use Redis is for speed, right?
> With 3rd party SSL/TLS termination, that can only get worse. How much worse?
I'm curious to see what the results could be with HAProxy as a SSL termination frontend. (via a Unix socket or a TCP connection)
I think it's an interesting piece of work, no doubt. But I'd never adopt something like this in Real Life. Given the gorgeous state of the codebase, I trust the current stewardship of the project to make the right calls. This sounds more personal than technical.
Feel free to keep using Salvatore's Redis, it'll be around as long as he is, I'm sure.
And feel free to take a look (or not) at my fork in a few weeks. Maybe I'll disappoint you again. :)
And this was the start to several other changes I am in the process of adding, which Salvatore had historically not been interested in. The patches I'd been working on for SSL/TLS were small enough to be easily cherry-picked, at any point in the future, if Salvatore had wanted them.
It was easier to release some SSL/TLS bits to start, than to do everything else I need to do before adding SSL/TLS.
As well, if my understanding is correct, the OP’s goal is to create globally-distributed Redis clusters, where lower-level solutions like VPN network peering have relatively bad performance compared to plain userland TLS.
Sure, but they are almost certainly not just directly exposing Redis on port 6379. How would they handle auth, rate limiting, etc.?
You don't need anything more sophisticated than that for the use-case where you're just making Redis on one cloud available to trusted clients on another.