[SERVER-39370] [FLE] Reject equality to regex for an encrypted field Created: 04/Feb/19  Updated: 06/Dec/22  Resolved: 06/Feb/19

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Nicholas Zolnierz Assignee: Backlog - Query Team (Inactive)
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-39223 Implement extracting encrypted paths ... Closed
Duplicate
duplicates SERVER-39233 [FLE] Implement method for replacing ... Closed
Assigned Teams:
Query
Participants:

 Comments   
Comment by Nicholas Zolnierz [ 06/Feb/19 ]

Ah I forgot about that, thought that the regex was a special case within EqualityMatchExpression. Agreed there's nothing extra needed and closing this ticket.

Comment by David Storch [ 05/Feb/19 ]

That will be parsed as a RegexMatchExpression not as an EqualityMatchExpression. I agree that we cannot support this predicate if ssn is encrypted, but I don't think we will have to special-case an EqualityMatchExpression which is checking equality against a regex. Does that make sense?

Comment by Nicholas Zolnierz [ 05/Feb/19 ]

david.storch How could we answer a regex equality on an encrypted field? I was thinking something like

db.coll.find({ssn: /^1234/})

where 'ssn' is an encrypted string. Or are you referring to a different query?

Comment by David Storch [ 05/Feb/19 ]

nicholas.zolnierz, on what basis will this be disallowed? We have to ban $in with a regex, but I don't think we need to ban $eq with a regex, right?

Generated at Thu Feb 08 04:51:50 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.