-
Notifications
You must be signed in to change notification settings - Fork 79
feat: detect CSFLE library path and pass it to driver MONGOSH-1118 #1246
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
Conversation
- Add `--csfleLibrarySearchPath` and `csfleLibraryPath` command line flags to control CSFLE library search path behavior - This is necessary for us for testing, but also likely for users, because simply adding an entry to the `PATH` environment variable will not be enough to locate the library if it is in a non-standard location (unlike mongocryptd). - Use these options in our e2e/smoke tests - Download the shared library when required for testing - Add CSFLE path detection logic, which replaces our mongocryptd path detection logic - Pass the resulting AutoEncryptionExtraOptions down to the driver.
// from a user we can consider trusted (current user or the one who owns | ||
// the mongosh binary to begin with) and they are not writable by other | ||
// users. On Windows, no such check is feasible. | ||
if (process.platform !== 'win32' && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT: just a silly thing, I got a bit puzzled by the fact that the function "returns" null
, in a good case and an object otherwise. Basically, I understood that we were reporting permission issues Infos only when I got to the usage.
Probably a comment that explains that we return details useful for debugging in case of a mismatch would have helped me.
Also, maybe you could early return here for win32
, but that's even more NIT that the previous one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, all of that makes sense, done! 👍
* feat: add packaging for CSFLE shared library MONGOSH-1116 (#1230) * feat: detect CSFLE library path and pass it to driver MONGOSH-1118 (#1246) - Add `--csfleLibrarySearchPath` and `csfleLibraryPath` command line flags to control CSFLE library search path behavior - This is necessary for us for testing, but also likely for users, because simply adding an entry to the `PATH` environment variable will not be enough to locate the library if it is in a non-standard location (unlike mongocryptd). - Use these options in our e2e/smoke tests - Download the shared library when required for testing - Add CSFLE path detection logic, which replaces our mongocryptd path detection logic - Pass the resulting AutoEncryptionExtraOptions down to the driver. * chore: bump mongodb-client-encryption, add ts-expect-error MONGOSH-1196 (#1266) This should be sufficient for bringing the CSFLE shared library work into a mergeable state. The ts-expect-error comments can likely be removed pretty soon as well, with the next driver bump. * fix(ci): rpm uses /usr/lib64 rather than /usr/lib * fixup: rc5 is minimum workingcsfle library version * fixup: drop ts-expect-error where unnecessary * fixup: update csfle distro lookup table, adjust new fle2 integration tests * fixup: monkey-patch mongodb-client-encryption for bypassQueryAnalysis * fixup: use minimum-glibc shared library in linux e2e tests, skip s390x fle testing * fixup: regen evergreen config, fix e2e fle test skipping * fixup: align new debian 11 dockerfile with docker changes
--csfleLibrarySearchPath
andcsfleLibraryPath
command lineflags to control CSFLE library search path behavior
because simply adding an entry to the
PATH
environment variablewill not be enough to locate the library if it is in a non-standard
location (unlike mongocryptd).
path detection logic
This fully working depends on upstream work in libmongocrypt and the Node.js driver. I’ve locally verified that this does work when those changes are in, up to the point of running into SERVER-64859 which is not something that we can easily work around.
No evergreen patch because it’s pointless, compiling TS fails without the Node.js driver typings for this.