[MONGOCRYPT-121] Properly handle duplicate key conflicts Created: 11/May/19  Updated: 28/Oct/23  Resolved: 24/Aug/19

Status: Closed
Project: Libmongocrypt
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0.0-beta5

Type: Task Priority: Major - P3
Reporter: Kevin Albertson Assignee: Kevin Albertson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Problem/Incident
Related
related to MONGOCRYPT-158 Error if we get keys with intersectin... Closed
Case:

 Description   

Came out of CDRIVER-3057. We should think carefully about handling conflicts of multiple keys with duplicate key alt names or keys sharing a UUID with different sets of key alt names.

Copied from the code review:

In cases where two keys conflict (different sets of keyAltName), perhaps the
right thing to do is always favor the key document has the more recent
"updateDate".

Conflicts might not be that uncommon, if we're getting some keys from the cache.
Consider a user moving a key alt name from one document to another.

Server first starts with:

Unknown macro: { _id}
Unknown macro: { _id}

The key cache contains

Unknown macro: { _id}

Then the user "renames" the entries:

Unknown macro: { _id}
Unknown macro: { _id}

The key broker gets two entries:
keyAltName="a"
keyAltName="b"

The first entry is satisfied with a cached value:

Unknown macro: { _id}

And the second is satisfied with the conflicting:

Unknown macro: { _id}

So in that case we could deduplicate based on "updateDate". That's not perfect,
as it's not guaranteed to be monotonically increasing, but it would probably
handle many common cases.

I think we should leave this as follow-up work, under a ticket like "Gracefully
handle all key inconsistencies"

This could involve:

  • handle conflicting duplicate entries by favoring "updateDate"
  • failing that, invalidate any matching cache entries (i.e. mark as expired),
    and try fetching again (maybe just once)

If that sounds good to you, I can create a ticket.

Edit: I think there's even more to consider. Requests for keys in the key broker
should stay satisfied after deduplication.

Consider:
Key broker has two entries:
keyAltName="a"
keyAltName="b"

First entry is satisfied with:

Unknown macro: { _id}

Then, second entry is satisfied with
{_id: 2, keyAltNames: ["b", "c"], lastUpdated: 2 }

When we deduplicate after the second entry, we'd remove the first entry since
it's older and has a conflicting shared keyAltName. But the marking requested a
key using keyAltName="a". So removing that key broker entry would leave that
marking unsatisfied.

Sooo... it might be a little more subtle. If one of the key broker entries would
be left unsatisfied after deduplication, perhaps refetch it, or don't
deduplicate?



 Comments   
Comment by Githook User [ 26/Aug/19 ]

Author:

{'username': 'kevinAlbs', 'email': 'kevin.albertson@mongodb.com', 'name': 'Kevin Albertson'}

Message: CDRIVER-3125 fix for local keys
Branch: master
https://github.com/mongodb/libmongocrypt/commit/7618e53eea8c82710ab519dd3118356de4925ca6

Comment by Githook User [ 24/Aug/19 ]

Author:

{'username': 'kevinAlbs', 'email': 'kevin.albertson@mongodb.com', 'name': 'Kevin Albertson'}

Message: CDRIVER-3125 handle duplicate keys

Comment by Kevin Albertson [ 03/Jun/19 ]

Some additional ideas that came out of this review for CDRIVER-2951.

In an event that we have two keys with intersecting key alt names but different key ids, the simplest approach may be to flush the cache.

Generated at Thu Feb 08 09:08:01 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.