Note, that the user field is not compared. This is because the User is behind an RwLock, and therefore the lock would have to be acquired to do an equality comparison on the User object. This is fine in our current context, and PartialEq documents that this is a possibility.
However; the id field of Relationship is the ID of the target user, i.e. the User the Relationship is described to.
On Discord, Snowflake IDs are unique. In a federated context, this does not hold true, and an attacker could, if no change is made, craft a user object with the same Snowflake ID as another user, and possibly force a relationship with someone through that.
This needs to be considered when implementing polyproto into Chorus.
There might be a future security vulnerability in Chorus, if we implement polyproto into Chorus without the correct considerations.
For example:
Lets say we have a
Relationship
object.PartialEq
onRelationship
is defined as such:Note, that the
user
field is not compared. This is because the User is behind anRwLock
, and therefore the lock would have to be acquired to do an equality comparison on the User object. This is fine in our current context, andPartialEq
documents that this is a possibility.However; the
id
field ofRelationship
is the ID of the target user, i.e. the User the Relationship is described to. On Discord, Snowflake IDs are unique. In a federated context, this does not hold true, and an attacker could, if no change is made, craft a user object with the same Snowflake ID as another user, and possibly force a relationship with someone through that.This needs to be considered when implementing polyproto into Chorus.