Purging should not remove the whole history of a page

[dartar]

(reported by IanAndolina - original heading, "Alzheimers for Wikka")

This is not a bug specifically - it is really a potential implentation weakness, but if a user specifies a page purge time in wikka.config: "pages_purge_time" => "100" and if that page is not edited for a while, then when that page is edited, the last copy will be deleted, leaving no archived copies at all. I think purge pages should delete old pages, but there should always be a minimum number of old copies preserved, otherwise the wiki becomes highly vulnerable to a content deletion attack. Would it be better to remove this feature, or modify it? --IanAndolina

Instead of removing or modifying it (the configuration parameter, rather) we could refine it by introducing an extra parameter name something like "pages_keep" to set a maximum number of pages to be kept regardless (maximum, since it could be less if there are not that many versions in the first place). Setting one or the other to 0 could disable purging altogether. --JavaWoman

Sounds good to me - can you think of an elegant way to modify the SQL query to only delete pages older than X that are also more than Xth on a list of revisions. I'm sure I can come up with something ugly ;) --IanAndolina

I'm good enough at SQL that I need the manual for that. ;-) As far as I can determine, you need two statements (semi pseudo code):

1. a select count(*) from pages where ... to determine the current number of records;
2. a delete from pages where ... order by [timestamp] limit [$count - $pages_keep] .

You can't do a subquery in delete (yet) so the count must be a separate step (but it should be very fast). --JavaWoman

Even with a number of records kept, an attack could always be done by submitting n versions of the page. Two propositions:

1) Do purge regularly, for example every month, and When purging, create a gzipped archive of the versions about to be deleted.

2) Purge a version ONLY IF there is another more recent version that is 1 month old or more (1 month is configurable of course) => Admins have 1 month to detect attacks.

Related tickets

#100