According to this comparaison, non-intended missing permissions are:

• createaccount (well, it's on '*' already so I don't worry that much)
• nuke
• override-antispoof
• tboverride
• massmessage
• spamblacklistlog
• titleblacklistlog

editinterface-like permissions are rightly excluded but these others I mention do not seem like they're explicitly excluded from config files so I wonder why they do not appear. Is it possible that because I cannot edit MediaWiki:Spam-blacklist I do not have spamblacklistlog permissions? On the other hand, massmessage does not seem to depend on MediaWiki restricted pages so it's not clear for me why it does not appear.

User rights explicitely removed from 'contentadmin' in CommonSettings.php:

• Edit other users' CSS files (editusercss)
• Edit other users' JavaScript files (edituserjs)
• editrestrictedfield (this is apparently part of PageForms, which does not seem to be deployed to wikitech and hence should be removed)
• Edit the user interface (editinterface)
• Override the title or username blacklist (tboverride)
• View title blacklist log (titleblacklistlog)
• Override the spoofing checks (override-antispoof)
• Create new user accounts (createaccount)

@Krenair set these explicit removals back in c9f3ef6526c4 - maybe he knows what the reason was to keep some of these rights away from contentadmins (e.g. createaccount, override-antispoof, titleblacklistlog, tboverride).
Also, is "editusercss" and "edituserjs" actually dangerous? Of course "editinterface" is, as the MediaWiki: namespace has it's special role on wikitech, but these other rights are just for editing other users css/js, which doesn't share that special role (or does it?).

User shown for sysop (but not contentadmin) on Special:Version, but not explicitely removed in CommonSettings.php:

• Mass delete pages (nuke)
• Send a message to multiple users at once (massmessage)
• View the spam blacklist log (spamblacklistlog)

These are all from extensions that use the new extension registration and grant the respective right to 'sysop' from extension.json by default:

• https://github.com/wikimedia/mediawiki-extensions-Nuke/blob/master/extension.json#L41
• https://github.com/wikimedia/mediawiki-extensions-MassMessage/blob/master/extension.json#L179
• https://github.com/wikimedia/mediawiki-extensions-SpamBlacklist/blob/master/extension.json#L18

Iirc the default permissions (as set in extension.json) and $wgGroupPermissions (as set in LocalSettings.php) are merged after LocalSettings.php is evaluated, which means those rights are added to sysop after $wgGroupPermissions['contentadmin'] = $wgGroupPermissions['sysop'] is set, which is why they don't appear on contentadmin. @Legoktm might know whether this is really the issue and, if so, whether we should just add those rights to $wgGroupPermissions['contentadmin'] (workaround in config with three assignments) or look for a way to make extension registration work with $wgGroupPermissions['foo'] = $wgGroupPermissions['bar'];.

In T171208#3649622, @EddieGP wrote:

@Krenair set these explicit removals back in c9f3ef6526c4 - maybe he knows what the reason was to keep some of these rights away from contentadmins (e.g. createaccount, override-antispoof, titleblacklistlog, tboverride).

I know why at least one of those is considered a security-sensitive right.

In T171208#3649622, @EddieGP wrote:

Also, is "editusercss" and "edituserjs" actually dangerous? Of course "editinterface" is, as the MediaWiki: namespace has it's special role on wikitech, but these other rights are just for editing other users css/js, which doesn't share that special role (or does it?).

Yes, these rights are hugely dangerous, for the same reason as editinterface.

In T171208#3649629, @Krenair wrote:

I know why at least one of those is considered a security-sensitive right.

Would you dare to enlighten us, or is that knowledge somehow security-sensitive itself? :) I've searched for documentation on this on-wiki, but unfortunately I couldn't find anything specific.

In T171208#3649641, @EddieGP wrote:

In T171208#3649629, @Krenair wrote:

I know why at least one of those is considered a security-sensitive right.

Would you dare to enlighten us, or is that knowledge somehow security-sensitive itself? :)

Hmm. I think I can safely say we wouldn't want a contentadmin using tboverride

Change 382024 had a related patch set uploaded (by EddieGP; owner: EddieGP):
[operations/mediawiki-config@master] wikitech: Align 'contentadmin' and 'sysop' permissions

https://gerrit.wikimedia.org/r/382024

In T171208#3649644, @Krenair wrote:

Hmm. I think I can safely say we wouldn't want a contentadmin using tboverride

Looking at the blacklist, I can easily guess why. I assume override-antispoof is for the same reason, though I haven't figured out how titleblacklistlog would do any harm (as it just allows viewing the log).

I've uploaded a patch to add the permissions missing due to them being added in extension registration (nuke, massmessage, spamblacklistlog) and cleaning up the editrestrictedfield line as PageForms (formerly SemanticForms) has been undeployed from Wikitech. All other permissions are left as they are.

Change 382024 merged by jenkins-bot:
[operations/mediawiki-config@master] wikitech: Align 'contentadmin' and 'sysop' permissions

https://gerrit.wikimedia.org/r/382024

Mentioned in SAL (#wikimedia-operations) [2017-10-10T23:12:40Z] <thcipriani@tin> Synchronized wmf-config/CommonSettings.php: SWAT: [[gerrit:382024|wikitech: Align "contentadmin" and "sysop" permissions]] T171208 (duration: 00m 48s)