6 ms·

But... why? SSL will eventually make it into the official Redis release. Anyway, I don't think anyone would use a fork of Redis just because of SSL. I would ta

But... why? SSL will eventually make it into the official Redis release. 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.

jeremiep 9y ago
Same, no way we're using a fork while the main project is still actively maintained and putting out great features. The added value of built-in SSL doesn't even justify losing half the value of using the main project.
- DrJosiah 9y ago
  You're assuming that changes upstream can't be merged into 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?
originalsimba 9y ago
> But... why? SSL will eventually make it into the official Redis release. "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.
- decebalus1 9y ago
  Redis plaintext was a conscious decision, it wasn't due to laziness, lack of knowledge or lax security policies. And Redis is not a mission-critical enterprise tool. 'Redis enterprise'[1] is, and it does have security features. 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 https://github.com/antirez/redis/pull/4855 ? [1] https://redislabs.com/redis-enterprise/ https://redislabs.com/redis-enterprise/
  - DrJosiah 9y ago
    Redis is used as a mission critical tool by companies, whether it wants to be or not. The SSL/TLS changes I was making were going to be easy to merge in for those who were interested. And the fork wasn't just for SSL/TLS; it was for transactions, speedups, and other work that is in-process. 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.
    - decebalus1 8y ago
      I have to admit, I didn't look over your code and haven't noticed it incorporated multiple ideas aside from TLS. You're correct, if the main project doesn't accept the contributions then the beauty of open-source is that you can roll your own and fork it. 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.
DrJosiah 9y ago
I didn't know about it until after I'd posted. And the fork wasn't just for SSL, it was for additional features that I'd also been trying to get in for ... years.

jeremiep 9y ago

Same, no way we're using a fork while the main project is still actively maintained and putting out great features. The added value of built-in SSL doesn't even justify losing half the value of using the main project.

DrJosiah 9y ago
You're assuming that changes upstream can't be merged into 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?

originalsimba 9y ago

> But... why? SSL will eventually make it into the official Redis release. "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.

decebalus1 9y ago
Redis plaintext was a conscious decision, it wasn't due to laziness, lack of knowledge or lax security policies. And Redis is not a mission-critical enterprise tool. 'Redis enterprise'[1] is, and it does have security features. 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 https://github.com/antirez/redis/pull/4855 ? [1] https://redislabs.com/redis-enterprise/ https://redislabs.com/redis-enterprise/
- DrJosiah 9y ago
  Redis is used as a mission critical tool by companies, whether it wants to be or not. The SSL/TLS changes I was making were going to be easy to merge in for those who were interested. And the fork wasn't just for SSL/TLS; it was for transactions, speedups, and other work that is in-process. 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.
  - decebalus1 8y ago
    I have to admit, I didn't look over your code and haven't noticed it incorporated multiple ideas aside from TLS. You're correct, if the main project doesn't accept the contributions then the beauty of open-source is that you can roll your own and fork it. 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.

DrJosiah 9y ago

I didn't know about it until after I'd posted. And the fork wasn't just for SSL, it was for additional features that I'd also been trying to get in for ... years.