Paste numbers are being re-used

[dexen.devries@…]

To reproduce:

• create two new pastes (for example, ID 9 & 10)
• remove the pastes ID 9 & 10
• create new paste quickly (before anybody other have chance to create one concurrently)
• compare old address with the new paste. The new paste will have ID equal 9. Subsequent one will have ID equal 10, and so on.

If you remove one or more last pastes, the new paste to be created will re-use IDs of former pastes. This will lead to people finding completly unrelated pastes under same ID, if the previous one has been deleted and was the highest numbered one.

I'm not entirely sure whether it's abut the most recent paste in sense of time, or the highest numbered one. I guess it's the later.

The problem is probably caused by default SQLite semantics.

[Michael Renzmann]

On a first glance I'd expect that assigning the autoincrement attribute to a row should prevent such things from happening, at least I vaguely remember that MySQL had this behaviour. But it's years ago since I last dealt with such questions, so I might be wrong. I will look at it.

However, I plan to use randomized 32bit values in hexadecimal representation as ticket ID and, in a next step, introduce a feature to declare a paste "private". Private pastes won't appear in the "recent pastes" list, and due to the randomized ticket IDs it will at least be hard (although not impossible) to find it by trial-and-error. As a side effect the issue you describe will virtually be fixed, since it's much less likely that a ticket ID will be reused.

[Ryan J Ollos]

Potential issue exists in combination with proposed TracLinks support, as described in ​ticket:5773#comment:9.

[ejucovy]

See also ​trac:#11378 -- I think this is actually an issue in Trac core.