Agreed it is an orthogonal change that can be done separately. Timing wise though, it would be nice if we could introduce this breaking change (tightening up system channels) as part 7.0 release. I will file a bug to track the discussion independently.

Originally posted by @PingXie in https://github.com/redis/redis/pull/10358#discussion_r818888997

Comment From: PingXie

@zuiderkwast @madolson @yossigo pinging you to see if there is a chance to catch the 7.0 train - since this is a breaking change, i.e. blocking clients from publishing into __redis__:*. Happy to start a PR next if you agree in principle.

Copy/paste the proposal from other thread:

  1. Client can't publish to any channel whose name starts with __redis__:
  2. Client subscribing to a channel whose name starts with __redis__: won't result in the channel getting created silently. Instead, Redis would fail the subscription if such a "system" channel doesn't already exist. This contract helps with "system" channel discovery.

Comment From: zuiderkwast

That is channels with prefix __redis__: (@PingXie use backticks to preserve the underscores)

Comment From: madolson

We don't have to lock this down right? We don't lock down keyspace notifications either, we just let people broadcast stuff into them. I don't feel like we need to block usage of them to support keyspace notifications.

Comment From: PingXie

We don't have to lock this down right? We don't lock down keyspace notifications either, we just let people broadcast stuff into them. I don't feel like we need to block usage of them to support keyspace notifications.

I am looking at this from the reliability's perspective as the subscriber might have a dependency on the specific message format in the channel so if, for whatever reason, bugs or something else, a malformed message or an incorrect message was broadcast to the channel, it would confuse the subscriber or even crash the subscriber.

Comment From: madolson

Redis is well known for letting users be wild and free. We have ACLs so that you can lock down who has access to a given channel space, or we could be very basic and just have a list of blocked ACL channels and a recommended set. This allows us not be hard backwards incompatible but provide controls so a user can fix the issue themselves.

Comment From: zuiderkwast

I don't mind this, but I think it's low prio. @madolson Does your suggestion mean we make some channels ACL-blocked by default? In the config file?

Comment From: madolson

We could do that too. The only drawback is we don't have block selectors, only allow selectors today.

Comment From: PingXie

Redis is well known for letting users be wild and free.

This thinking works fine for self-managed single-use instances. For cloud-managed or shared instances, this kind of tightening is always welcomed. I feel that antirez's own words does a better job explaining the difference between the two use cases.

Comment From: madolson

I'm not sure the cloud provider is the right metaphor here? This is more for redis internals than anything else.

Comment From: madolson

@PingXie The consensus with the core group was that we are okay with letting users inject messages into Redis reserved namespaces, since that could be considered a feature.