Is it just discord webhooks?

In T7213#143129, @RhinosF1 wrote:

Is it just discord webhooks?

Right now, Discord and SlackNotifications only.

Ack they're near forks of each other.

Oh I see what you mean now

You should be able to do a private patch via https://github.com/miraheze/ManageWiki/security/advisories/GHSA-jmc9-rv2f-g8vv

@Universal_Omega: Should that not match the private config flag? It seems like duplication to me.

In T7213#143136, @RhinosF1 wrote:

@Universal_Omega: Should that not match the private config flag? It seems like duplication to me.

You mean the commits I did and PR paladox opened? If so then no because the private config is set as an option key from within MWS.php, and therefore the api can't really read it the same so I introduced a whole new config variable for the API to read.

But SpecialManageWiki can access it so why can't API do the same and just not emit it. That's a mistake waiting to happen.

In T7213#143138, @RhinosF1 wrote:

But SpecialManageWiki can access it so why can't API do the same and just not emit it. That's a mistake waiting to happen.

Technically it probably could but it'd have to read the entire ManageWikiSettings config and check for the right keys, this seemed better.

In T7213#143139, @Universal_Omega wrote:

In T7213#143138, @RhinosF1 wrote:

But SpecialManageWiki can access it so why can't API do the same and just not emit it. That's a mistake waiting to happen.

Technically it probably could but it'd have to read the entire ManageWikiSettings config and check for the right keys, this seemed better.

I disagree. It's an extra step to think about and introduces a risk.

If this can’t be done as a single source of truth, my personal opinion would be to get rid of public/private settings until they can be done safely and securely.

In T7213#143140, @RhinosF1 wrote:

In T7213#143139, @Universal_Omega wrote:

In T7213#143138, @RhinosF1 wrote:

But SpecialManageWiki can access it so why can't API do the same and just not emit it. That's a mistake waiting to happen.

Technically it probably could but it'd have to read the entire ManageWikiSettings config and check for the right keys, this seemed better.

I disagree. It's an extra step to think about and introduces a risk.

Well what about other scenarios also, there can be multiple reasons configs shouldn't be shown in API rather then that one key, this allows multiple reasons without adding hard coded checks for them all.

In T7213#143142, @John wrote:

If this can’t be done as a single source of truth, my personal opinion would be to get rid of public/private settings until they can be done safely and securely.

Thats fair and overall its up to the tech team. I'm only trying to fix a mistake but removing the private/public configs I really disagree with as it is hard to revert back to PrivateSettings.php (which of course if wanted it can be done) but also allowing users to manage it themselves is essential, but I guess its just opinion. Ots your choice.

Well what about other scenarios also, there can be multiple reasons configs shouldn't be shown in API rather then that one key, this allows multiple reasons without adding hard coded checks for them all.

Can you think of any?

I'm 1000% with John, we need a single source of truth whatever that might be.

You can create private patches too on GitHub so that's a doc to right after.

Well I guess you make a point ill redo commits to use ManageWikiSettings config.

https://github.com/miraheze/ManageWiki/pull/272

https://github.com/miraheze/ManageWiki/security/advisories/GHSA-jmc9-rv2f-g8vv

It seems that the visibility check is awkwardly implemented if each interface that exposes a setting needs to independently check the visibility.

Also (somewhat related): The PSA for the Discord/Slack hook security issue is probably of no interest for vast majority of the users: only Bureaucrats can act on the stuff, and the readers from external links don't even care if there's discord or slack stuff. It is probably a wise idea to implement some hacks (i.e. Wikimedia Stewards Election Call for Candidates CN banner which is only displayed if you have sysop on the wiki) so those who are simply not affected can skip it even further. (Or think of a better way to alert crats without relying on sitenotice/CN)

In T7213#143208, @revi wrote:

Also (somewhat related): The PSA for the Discord/Slack hook security issue is probably of no interest for vast majority of the users: only Bureaucrats can act on the stuff, and the readers from external links don't even care if there's discord or slack stuff. It is probably a wise idea to implement some hacks (i.e. Wikimedia Stewards Election Call for Candidates CN banner which is only displayed if you have sysop on the wiki) so those who are simply not affected can skip it even further. (Or think of a better way to alert crats without relying on sitenotice/CN)

Yeah I was actually thinking about that also. But I think it is OK if the site notice is up for only a day or 2, anything beyond that I think what you suggested should be done.

In T7213#143182, @Void wrote:

It seems that the visibility check is awkwardly implemented if each interface that exposes a setting needs to independently check the visibility.

True, ManageWikiSettings really should have this and by default be configured to display only non private settings. This would be one of numerous improvement to the security and reliability of this feature set.

In T7213#143208, @revi wrote:

Also (somewhat related): The PSA for the Discord/Slack hook security issue is probably of no interest for vast majority of the users: only Bureaucrats can act on the stuff, and the readers from external links don't even care if there's discord or slack stuff. It is probably a wise idea to implement some hacks (i.e. Wikimedia Stewards Election Call for Candidates CN banner which is only displayed if you have sysop on the wiki) so those who are simply not affected can skip it even further. (Or think of a better way to alert crats without relying on sitenotice/CN)

👍 to this idea, to allowing us to set the visibility to only local bureaucrats. There could be several ways to do this, I think.