Skip to content

test(NODE-4227): add explicit encryption prose tests #3297

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
Jun 29, 2022
Merged

Conversation

durran
Copy link
Member

@durran durran commented Jun 23, 2022

Description

Adds explicit encryption prose tests

What is changing?

Adds 5 new prose tests for #12 in the client side encryption spec. https://github.com/mongodb/specifications/blob/7f37c9325b423223edf54d795afed444e6989b98/source/client-side-encryption/tests/README.rst#explicit-encryption

I've also included the spec prose test language in code comments in the test here for easier following.

Is there new documentation needed for these changes?

No

What is the motivation for this change?

NODE-4227

Double check the following

  • Ran npm run check:lint script
  • Self-review completed using the steps outlined here
  • PR title follows the correct format: <type>(NODE-xxxx)<!>: <description>
  • Changes are covered by tests
  • New TODOs have a related JIRA ticket

@durran durran force-pushed the NODE-4227 branch 2 times, most recently from a9e1a3f to afd2724 Compare June 23, 2022 19:16
@durran durran force-pushed the NODE-4227 branch 2 times, most recently from 00a9c16 to 29e3f35 Compare June 23, 2022 20:43
@durran durran marked this pull request as ready for review June 23, 2022 20:43
@@ -40,6 +40,14 @@ const metadata = {
}
};

const eeMetadata = {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#12 prose test section for explicit encryption requires server 6.0 and higher and not standalone.

beforeEach(async function () {
const mongodbClientEncryption = this.configuration.mongodbClientEncryption;
// Load the file encryptedFields.json as encryptedFields.
encryptedFields = EJSON.parse(
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Data for the encryptedFields option and key document are now provided in 2 new files in the etc/ directory in the csfle spec directory.

// Assert 10 documents are returned. Assert each returned document contains the
// field { "encryptedIndexed": "encrypted indexed value" }.
const collection = encryptedClient.db('db').collection('explicit_encryption');
const result = await collection.find({ encryptedIndexed: findPayload2 }).toArray();
Copy link
Member Author

@durran durran Jun 23, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just pointing out I find this absolutely crazy. A value is directly encrypted on line 1603 with a contention factor equal to the amount of documents in the collection that would match the original value of the field. But each field's encrypted value would not match the encrypted value passed to the find in theory as all the bin data would be different for each document on insert. But it still matches all of them. Mind blown.

});
});

context('Case 4: can roundtrip encrypted indexed', eeMetadata, function () {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These last 2 are just encrypt/decrypt roundtrips. So pretty straightforward.

function dropCollection(dbObj, collectionName) {
return dbObj.dropCollection(collectionName).catch(ignoreNsNotFound);
function dropCollection(dbObj, collectionName, options = {}) {
return dbObj.dropCollection(collectionName, options).catch(ignoreNsNotFound);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just adding the ability to pass options to the dropCollection helper. If we pass encryptedFields here an extra 3 collections will get dropped. (The esc/ecc/ecoc collections)

Copy link
Contributor

@addaleax addaleax left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you want to drop these tests from the libmongocrypt repo? https://github.com/mongodb/libmongocrypt/blob/93b82421dfe9ad472ef12b26a47aa94e631f9be1/bindings/node/test/clientEncryption.test.js#L584-L797

Fwiw, I really like that the Node.js driver deviates from other drivers and instead maintains a lot more functionality in the libmongocrypt repo (i.e. the full AutoEncrypter and ClientEncryption classes, rather than just raw bindings).

@durran
Copy link
Member Author

durran commented Jun 24, 2022

Do you want to drop these tests from the libmongocrypt repo? https://github.com/mongodb/libmongocrypt/blob/93b82421dfe9ad472ef12b26a47aa94e631f9be1/bindings/node/test/clientEncryption.test.js#L584-L797

Fwiw, I really like that the Node.js driver deviates from other drivers and instead maintains a lot more functionality in the libmongocrypt repo (i.e. the full AutoEncrypter and ClientEncryption classes, rather than just raw bindings).

I think it's fine to keep them there - can't have too many tests. :)

@dariakp dariakp self-assigned this Jun 24, 2022
@dariakp dariakp added the Primary Review In Review with primary reviewer, not yet ready for team's eyes label Jun 24, 2022
requires: {
clientSideEncryption: true,
mongodb: '>=6.0.0',
topology: ['replicaset', 'sharded']
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what about load balanced? is that considered more like a standalone?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't run the other fle tests against load balanced clusters so I was keeping in line with that. The spec in general pre-dates the load balancer spec and does not mention that topology at all, and enabling it got some strange setup errors that I felt were outside the scope of the ticket. I can create a ticket to look into running all the fle tests with load balancers as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should check with the spec owners regarding this, and maybe file a drivers ticket to add lb to the testing matrix if it makes sense to do so, then the node ticket will automatically come down to us

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for context, the reason for requiring these topologies is that QE requires transactions, which in turn requires a replset topology. I guess technically one could run a load balancer in front of a single standalone node, but I assume that won’t happen in practice or in tests?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just as a follow up, other drivers are not running prose tests against a load balancer. However, the LB spec says it should run all tests in unified format so we'll need to make sure the new FLE unified tests are running against a load balanced topology.

@durran durran requested a review from dariakp June 27, 2022 13:20
@dariakp dariakp added Team Review Needs review from team and removed Primary Review In Review with primary reviewer, not yet ready for team's eyes labels Jun 27, 2022
@dariakp dariakp merged commit fb2b4a5 into main Jun 29, 2022
@dariakp dariakp deleted the NODE-4227 branch June 29, 2022 15:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Team Review Needs review from team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants