Hello,
When setting up the new labs infra, we realised that the following tables are on the labs hosts (both, old labs servers and new labs servers)
`metawiki.oauth_accepted_consumer`
`metawiki.oauth_registered_consumer`
They do contain sensitive data. These are the column names, easy to figure what they have :-)
```
mysql:root@localhost [metawiki]> show create table oauth_accepted_consumer\G show create table oauth_registered_consumer\G
*************************** 1. row ***************************
Table: oauth_accepted_consumer
Create Table: CREATE TABLE `oauth_accepted_consumer` (
`oaac_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`oaac_wiki` varbinary(255) NOT NULL,
`oaac_user_id` int(10) unsigned NOT NULL,
`oaac_consumer_id` int(10) unsigned NOT NULL,
`oaac_access_token` varbinary(32) NOT NULL,
`oaac_access_secret` varbinary(32) NOT NULL,
`oaac_grants` blob NOT NULL,
`oaac_accepted` varbinary(14) NOT NULL,
PRIMARY KEY (`oaac_id`),
UNIQUE KEY `oaac_access_token` (`oaac_access_token`),
UNIQUE KEY `oaac_user_consumer_wiki` (`oaac_user_id`,`oaac_consumer_id`,`oaac_wiki`),
KEY `oaac_consumer_user` (`oaac_consumer_id`,`oaac_user_id`),
KEY `oaac_user_id` (`oaac_user_id`,`oaac_id`)
) ENGINE=InnoDB AUTO_INCREMENT=96155 DEFAULT CHARSET=binary
1 row in set (0.00 sec)
*************************** 1. row ***************************
Table: oauth_registered_consumer
Create Table: CREATE TABLE `oauth_registered_consumer` (
`oarc_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`oarc_consumer_key` varbinary(32) NOT NULL,
`oarc_name` varbinary(128) NOT NULL,
`oarc_user_id` int(10) unsigned NOT NULL,
`oarc_version` varbinary(32) NOT NULL,
`oarc_callback_url` blob NOT NULL,
`oarc_callback_is_prefix` tinyblob,
`oarc_description` blob NOT NULL,
`oarc_email` varbinary(255) NOT NULL,
`oarc_email_authenticated` varbinary(14) DEFAULT NULL,
`oarc_developer_agreement` tinyint(4) NOT NULL DEFAULT '0',
`oarc_owner_only` tinyint(4) NOT NULL DEFAULT '0',
`oarc_wiki` varbinary(32) NOT NULL,
`oarc_grants` blob NOT NULL,
`oarc_registration` varbinary(14) NOT NULL,
`oarc_secret_key` varbinary(32) DEFAULT NULL,
`oarc_rsa_key` blob,
`oarc_restrictions` blob NOT NULL,
`oarc_stage` tinyint(3) unsigned NOT NULL DEFAULT '0',
`oarc_stage_timestamp` varbinary(14) NOT NULL,
`oarc_deleted` tinyint(3) unsigned NOT NULL DEFAULT '0',
PRIMARY KEY (`oarc_id`),
UNIQUE KEY `oarc_consumer_key` (`oarc_consumer_key`),
UNIQUE KEY `oarc_name_version_user` (`oarc_name`,`oarc_user_id`,`oarc_version`),
KEY `oarc_user_id` (`oarc_user_id`),
KEY `oarc_stage_timestamp` (`oarc_stage`,`oarc_stage_timestamp`)
) ENGINE=InnoDB AUTO_INCREMENT=926 DEFAULT CHARSET=binary
1 row in set (0.01 sec)
```
Those two tables are not accessible as they do not have a view to access them on labs databases, but yet they are present, if they are not being used, we should probably filter them on the sanitarium hosts and delete them from the labs servers to avoid any leak vector there.
Any objection to filter them out and truncate them?
CC: @jcrespo @chasemp @bd808