[CDRIVER-3534] Vendor kms-message Created: 11/Feb/20  Updated: 28/Oct/23  Resolved: 24/Feb/20

Status: Closed
Project: C Driver
Component/s: libmongoc
Affects Version/s: None
Fix Version/s: 1.17.0-beta, 1.17.0

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

Issue Links:
Depends
is depended on by CDRIVER-3423 MONGODB-AWS Support Closed

 Description   

To support the MONGODB-AWS authentication mechanism, the driver will need to make signed AWS requests. The kms-message library does exactly that.

Here is a rough sketch of what I had in mind. Feel free to amend as needed.

  • Put kms-message into src/libmongoc/kms-message (as a sibling directory of zlib-1.2.11)
  • Do not use or alter the CMakeLists.txt (or any files) within kms-message, so we can copy over kms-message again in future. Instead, have src/libmongoc/CMakeLists.txt responsible for adding kms-message files to dist.
  • Similar to zlib, add the sources for kms-message in src/libmongoc/CMakeLists.txt. Do not define KMS_MSG_EXPORT, as we should not be exporting kms-message symbols.

Also to consider. If it seems a lot cleaner, we could move both zlib-1.2.11 and kms-message into a subdirectory named "vendor".

We don't need rigorous testing (if anything, maybe just check calling a kms function from libmongoc as a one-off test). The implementation of CDRIVER-3424 will test by virtue of using kms-message.



 Comments   
Comment by Githook User [ 21/Feb/20 ]

Author:

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

Message: CDRIVER-3534 tweak kms-message vendoring

Comment by Githook User [ 19/Feb/20 ]

Author:

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

Message: CDRIVER-3534 build kms-message with -fPIC
Branch: master
https://github.com/mongodb/mongo-c-driver/commit/98728780788c288ef643534e016ceb137998eefa

Comment by Githook User [ 19/Feb/20 ]

Author:

{'username': 'rcsanchez97', 'name': 'Roberto C. Sánchez', 'email': 'roberto@connexer.com'}

Message: CDRIVER-3534 vendor kms-message library
Branch: master
https://github.com/mongodb/mongo-c-driver/commit/489cdf4283ae4040f3cf87adc4350714e951595f

Comment by Kevin Albertson [ 12/Feb/20 ]

In deciding on vendoring kms-message, roberto.sanchez and I discussed these options.

1. vendor kms-message
2. require C driver consumers to first obtain and at least partially build libmongocrypt, and have libmongoc link against libkms_message.
3. reference kms-message as a Git submodule
4. split kms-message into a separate library

(2) seems like it may be an unreasonable ask of users. It would require users to first obtain libbson, build libmongocrypt (which is only required for Client Side Field Level Encryption not authenticating with MONGODB-AWS), then link against libkms_message built from that project.
(3) seemed viable, and that it might produce less churn when updating kms-message. But we've historically decided against using a git submodule to utilize libbson (see CDRIVER-2416). Though the relationship between libmongoc and kms-message would be simpler than the relationship between libmongoc and libbson, there's still the issue that kms-message is nested inside libmongocrypt. The submodule approach would not allow for KMS support in Debian builds and probably not in Fedora builds either.
(4) could pave the way for offering kms-message as its own package. But this would increase maintenance burden. Though kms-message seems like a generically useful library, aside from libmongoc and libmongocrypt there's no reason to expose it further currently.

Generated at Wed Feb 07 21:18:20 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.