I want to give just a few info about this:<p>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.<p>2. Forking is a right that open source gives you. Have fun coding Josiah!<p>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.<p>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.<p>(1) my as mine and a number of other contribs.
Just a few days ago, AWS announced[1] that they will be contributing TLS to Redis, and judging by one of his comments[2], antirez doesn't seem to be completely against merging it.<p>According to a comment on Reddit[3], Josiah wasn't aware of this effort by AWS.<p>[1]: <a href="https://aws.amazon.com/cn/blogs/opensource/open-sourcing-encryption-in-transit-redis/" rel="nofollow">https://aws.amazon.com/cn/blogs/opensource/open-sourcing-enc...</a><p>[2]: <a href="https://github.com/antirez/redis/pull/4855#issuecomment-383171007" rel="nofollow">https://github.com/antirez/redis/pull/4855#issuecomment-3831...</a><p>[3]: <a href="https://www.reddit.com/r/redis/comments/8f373k/a_new_redis_fork_with_ssl_transactions/dy19br1/" rel="nofollow">https://www.reddit.com/r/redis/comments/8f373k/a_new_redis_f...</a>
But... why? SSL will eventually make it into the official Redis release.<p>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.
I forked Redis years ago providing threads and SQL support, though I can't remember if transactions were supported now. This was done mostly for fun and as an experiment, learned a lot about locking and database internals in the process:<p>Main concept: <a href="http://thredis.org/" rel="nofollow">http://thredis.org/</a><p>Implementation details: <a href="https://github.com/grisha/thredis/blob/master/README-THREDIS" rel="nofollow">https://github.com/grisha/thredis/blob/master/README-THREDIS</a>
i love redis and have been using in production for over five years. But i'm interested to read the story of this fork because the practicioner-focused redis book this guy wrote is one of the best software-related texts i've read in the past 7 - 8 years. ("Statistical Rethinking" by Richard McElreath, and "The Art of SQL" by Stephane Faroult are two others that had the same impact)
Did I miss something here around the rationale for forking vs. attempting to contribute this to the official project?<p>Edit: found some more details over on reddit[0]:<p><i>I didn't see the existing TLS PR, and I'm not finding it now. Do you have a link?<p>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: <a href="https://redis.io/topics/encryption" rel="nofollow">https://redis.io/topics/encryption</a> , read the implementation of spiped (it uses fixed 1k block sizes), then realized that SSL/TLS is the right answer in this situation.<p>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.<p>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.</i><p>[0] - <a href="https://www.reddit.com/r/redis/comments/8f373k/a_new_redis_fork_with_ssl_transactions/" rel="nofollow">https://www.reddit.com/r/redis/comments/8f373k/a_new_redis_f...</a>
Not expecting this to see much traction given there's already an open PR to add SSL to Redis (from an AWS employee):<p><a href="https://github.com/antirez/redis/pull/4855" rel="nofollow">https://github.com/antirez/redis/pull/4855</a>
From the article:<p>> 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?<p>> With 3rd party SSL/TLS termination, that can only get worse. How much worse?<p>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)
Meh. A short-lived fork addressing issues being addressed in mainstream redis in a way that is probably more consistent with the codebase.<p>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.
Anyone knows a redis cli client that supports rediss/TLS? Tunneling the server is one thing, but I do miss the convenience of redis-cli and tunneling the client is a bit of a nuisance.
Why does Redis need SSL/TLS? It's meant to be used as a backend service across trusted networks. And if you need to use it over untrusted networks, you're best off using an actual server like NGINX or HAProxy to mediate it. Not to mention the killer feature of Redis is not neccessarily throughput, but it's best-in-class latency, which could be severely affected by SSL termination (and if you are doing SSL termination on the same machine as your Redis instance, you're doing it wrong.). This seems like added bloat to a really great lightweight tool.