From 9c80db1df2d3cdf2c0ac10014fede91d0c5405d0 Mon Sep 17 00:00:00 2001
From: Hugo Trentesaux <hugo@trentesaux.fr>
Date: Thu, 21 Nov 2024 13:00:16 +0100
Subject: [PATCH] note about profile deletion
---
src/indexer/database.ts | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/indexer/database.ts b/src/indexer/database.ts
index 517a78c..d0825cf 100644
--- a/src/indexer/database.ts
+++ b/src/indexer/database.ts
@@ -218,8 +218,14 @@ export async function handleInsertRequest(irCID: CID, ir: IndexRequest): Promise
// delete cesium plus profile
case CESIUM_PLUS_PROFILE_DELETE:
- // FIXME if delete instruction is received from past, this should be ignored
- // i.e.: database should keep track of deleted profiles with a timestamp to allow items to be inserted in any order
+ // NOTE: if delete instruction is received from past, an existing profile can be deleted
+ // Cases when it can occur:
+ // - a profile is deleted, then re-created, then an attacker submits again the deletion message within the MAX_IR_TIME_DIFF delay
+ // - a node is synchronizing, gets profile creation from pubsub, and then gets old deletion request from peer
+ // NOTE: the same can happen if create instruction if received from the past
+ // We could prevent it by:
+ // - keeping track of deleted profiles with a timestamp
+ // Not implemented yet because these cases have low probability, but this should be implemented in the future.
await client.query(`DELETE FROM profiles WHERE pubkey = $1;`, [ir.pubkey])
return
--
GitLab