Uploaded image for project: 'Drivers'
  1. Drivers
  2. DRIVERS-2586

Create and drop collection helpers should ignore custom names for Queryable Encryption metadata collections

    • Type: Icon: Task Task
    • Resolution: Duplicate
    • Priority: Icon: Unknown Unknown
    • None
    • Component/s: Client Side Encryption
    • None
    • Needed
    • $i18n.getText("admin.common.words.hide")
      Key Status/Resolution FixVersion
      CDRIVER-4606 Blocked
      CXX-2667 Blocked
      CSHARP-4602 Blocked
      GODRIVER-2799 Blocked
      JAVA-4924 Blocked
      NODE-5175 Blocked
      MOTOR-1111 Blocked
      PYTHON-3655 Blocked
      PHPLIB-1102 Duplicate
      RUBY-3234 Blocked
      RUST-1624 Blocked
      $i18n.getText("admin.common.words.show")
      #scriptField, #scriptField *{ border: 1px solid black; } #scriptField{ border-collapse: collapse; } #scriptField td { text-align: center; /* Center-align text in table cells */ } #scriptField td.key { text-align: left; /* Left-align text in the Key column */ } #scriptField a { text-decoration: none; /* Remove underlines from links */ border: none; /* Remove border from links */ } /* Add green background color to cells with FixVersion */ #scriptField td.hasFixVersion { background-color: #00FF00; /* Green color code */ } /* Center-align the first row headers */ #scriptField th { text-align: center; } Key Status/Resolution FixVersion CDRIVER-4606 Blocked CXX-2667 Blocked CSHARP-4602 Blocked GODRIVER-2799 Blocked JAVA-4924 Blocked NODE-5175 Blocked MOTOR-1111 Blocked PYTHON-3655 Blocked PHPLIB-1102 Duplicate RUBY-3234 Blocked RUST-1624 Blocked

      Summary

      DRIVERS-2284 originally instructed for drivers to allow custom names for Queryable Encryption Metadata Collections via the eccCollection, ecocCollection, and escCollection fields within the encryptedFields option for the createCollection() helper.

      SERVER-74069 has since added server-side validation for those fields and no longer allows names to deviate from the following:

      • enxcol_.<collectionName>.esc
      • enxcol_.<collectionName>.ecc
      • enxcol_.<collectionName>.ecoc

      These custom options within "encryptedFields" were never documented (see: create). The Queryable Encryption API is also documented as unstable so there should be no concern with changing this behavior.

      Drivers should remove any modeling of these options for "encryptedFields". The createCollection() and dropCollection() helpers should ignore any user-supplied values within the encryptedFields option and use generated names with the proper format. Any values within encryptedFields can be left as-is and passed on to the server (if that leads to an error, so be it).

      Additional Context

      Quoting discussion from an internal Slack thread in #drivers-fle:

      Looking at the create command docs, there's no mention of escCollection, eccCollection, or ecocCollection in the encryptedFields option docs. Were those fields always option and the server would just default to the generated names that are now enforced (as of DRIVERS-2565)?

      Yes. Manually creating a collection with the following "encryptedFields" option will apply the default names for escCollection, eccCollection, ecocCollection:

      db.runCommand({create: "foo", encryptedFields: {fields: []}})
      

      Presumably there is no reason for a user to ever define these in encryptedFields. Does it make sense to still display these fields in the encryptedFields example within the spec (they were left in place in 8f6f4a3 for DRIVERS-2565)? If they do remain, should there be language talking about how the format is enforced? Perhaps a suggestion that if drivers haven't already modeled these options, they shouldn't even give users the choice to set them?

      I am in favor of removing driver API and documentation of options for escCollection, eccCollection, and ecocCollection. I see no use case for a user to pass these options. Also, eccCollection is being removed with the new perf and on-disk format changes (DRIVERS-2524).

      Motivation

      Is this issue urgent?

      No, but should be done while the Queryable Encryption API is still unstable.

      Is this ticket required by a downstream team?

      No.

      Is this ticket only for tests?

      No.

            Assignee:
            Unassigned Unassigned
            Reporter:
            jmikola@mongodb.com Jeremy Mikola
            Kevin Albertson Kevin Albertson
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: