GNOME Bugzilla – Bug 645680
Use random integer IDs for Kf.Personas
Last modified: 2011-03-29 22:22:30 UTC
(This bug was originally filed as number 645663, but then Bugzilla went and lost data, so I'm refiling.) As explained in the branch which is going to be attached momentarily, re-using IDs for new Kf.Personas can cause links referring to those IDs to end up pointing to the wrong persona (due to, e.g., a link being created pointing to persona #5, persona #5 being deleted, and a new persona' being assigned ID #5). This is bad. This can be (probabilistically) fixed by using random IDs for new personas, and continuing to ensure that IDs are fresh wrt the current set of assigned IDs. A perfect solution would be to hash the contents of the persona, but since they can change, that's not workable. This is necessary for the anti-linking work in bug #629537 (and, in fact, has been split off that branch and rebased to a recent master).
Created attachment 184239 [details] [review] Squashed diff of the 645680-key-file-ids branch http://git.collabora.co.uk/?p=user/pwith/folks;a=shortlog;h=refs/heads/645680-key-file-ids
I've done that thing again where I forget to add a NEWS entry. Oh well.
Review of attachment 184239 [details] [review]: Consequently, the use of a random integer evenly distributed over the space of unsigned 32-bit integers will do. What if I have a *lot* of friends? Looks good -- please apply.
Review of attachment 184239 [details] [review]: Also, add the NEWS entry and make sure you backport this to the 0.4.x branch.
(In reply to comment #3) > Review of attachment 184239 [details] [review]: > > Consequently, the use of a random integer evenly distributed over the space of > unsigned 32-bit integers will do. > > What if I have a *lot* of friends? If my maths is still working at this time of night, you'd need to have more than approximately sqrt(2^32) = 65536 friends for the probability of two of them to share a randomly-assigned uint ID to exceed 50% (birthday theorem). If that's the case, it sounds like you've been hoarding Facebook friends. > Looks good -- please apply. master: commit f87361964aa60361da59a3eb9e404fd37769c0b5 Author: Philip Withnall <philip.withnall@collabora.co.uk> Date: Mon Jan 17 15:42:24 2011 +0000 Bug 645680 — Use random integer IDs for Kf.Personas Using consecutive integer IDs meant that IDs often got re-used as Personas were deleted and added, meaning that the same ID could, over time, be applied to several different Personas which contained completely different IM addresses. Any external references to such IDs which weren't updated over time with the IDs themselves (such as the to-be-added anti-links) would end up pointing to effectively the wrong Persona. A perfect solution would be to hash the IM addresses in each Persona and use that as the Persona's ID, but that's not possible as the set of IM addresses in a Kf.Persona can change over time, while the ID has to remain constant. Consequently, the use of a random integer evenly distributed over the space of unsigned 32-bit integers will do. Closes: bgo#645680 NEWS | 1 + backends/key-file/kf-persona-store.vala | 14 ++++++-------- 2 files changed, 7 insertions(+), 8 deletions(-) commit c40b69f3b3c3dfb5890b964f2ec1e9daacc5a0aa Author: Philip Withnall <philip@tecnocode.co.uk> Date: Sun Nov 21 14:15:36 2010 +0000 Clarify immutability of Persona.uid folks/persona.vala | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) folks-0-4: commit 8203422ce88df80c1c3c40cf715d959359e1cfa8 Author: Philip Withnall <philip.withnall@collabora.co.uk> Date: Mon Jan 17 15:42:24 2011 +0000 Bug 645680 — Use random integer IDs for Kf.Personas Using consecutive integer IDs meant that IDs often got re-used as Personas were deleted and added, meaning that the same ID could, over time, be applied to several different Personas which contained completely different IM addresses. Any external references to such IDs which weren't updated over time with the IDs themselves (such as the to-be-added anti-links) would end up pointing to effectively the wrong Persona. A perfect solution would be to hash the IM addresses in each Persona and use that as the Persona's ID, but that's not possible as the set of IM addresses in a Kf.Persona can change over time, while the ID has to remain constant. Consequently, the use of a random integer evenly distributed over the space of unsigned 32-bit integers will do. Closes: bgo#645680 NEWS | 1 + backends/key-file/kf-persona-store.vala | 14 ++++++-------- 2 files changed, 7 insertions(+), 8 deletions(-) commit fa10cf2365ce8f06a95caac3f1ca1eb3f535e925 Author: Philip Withnall <philip@tecnocode.co.uk> Date: Sun Nov 21 14:15:36 2010 +0000 Clarify immutability of Persona.uid folks/persona.vala | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)