All the revision IDs of a page should be stored in log_search when that page is deleted. That way, if the page is undeleted, there is still a way to find out what page ID its revisions had at the time of deletion. This is useful for countering the merge page histories attack; see bug 69047.
Version: 1.24rc
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=69871
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T71047 Develop countermeasures to the merge page histories attack | |||
| Open | Feature | None | T71049 All the revision IDs of a page should be stored in log_params when that page is deleted |
Change 151309 had a related patch set uploaded by leucosticte:
Store revision IDs of a page in log_search when that page is deleted
Hey MZM, do you think there might be a more efficient way to accomplish what this patch does? As written, the patch does a select on the revision table on the master to get the revision IDs right before an insertSelect is done on archive, page, and revision on the master to shunt the revision data into the archive table. Is there a way to add this functionality without adding another query, or is there a way to do it using a less expensive query? Thanks.
So is this a WONTFIX? The log_search option was opposed by Brian Wolff and the log_params option was described on IRC by legoktm as infeasible.
Another possible implementation would be to have page_original_id and ar_original_page_id fields that contain the value of what the page_id was when the page was created. Revisions could then be merged or unmerged based on the value of that field.