Skip to content

Adding latest DBPAInterface to dev-miniapp#65

Merged
argmarco-tkd merged 2 commits into
dev-miniappfrom
dev_dll_work
Aug 19, 2025
Merged

Adding latest DBPAInterface to dev-miniapp#65
argmarco-tkd merged 2 commits into
dev-miniappfrom
dev_dll_work

Conversation

@argmarco-tkd

@argmarco-tkd argmarco-tkd commented Aug 19, 2025

Copy link
Copy Markdown
Collaborator

Rationale for this change

In this change, we are merging-in the latest version of DataBatchProtectionAgentInterface into the mini-app code branch

What changes are included in this PR?

  • Copying the latest version of dbpa_interface.h (and some of the required dependencies, like enums.h)
  • Updating the code to use tcb::span (instead of std::span, which cannot be used given that Arrow is C++17 and std::span is C++20)
  • Modify the dbpa_library_wrapper to also decorate the init() method (this method was not considered in the earlier version of dbpa_interface). Modified the tests to include init()
  • Modify tests to account for the fact that EncryptionResult and DecryptionResult are now well defined.
  • In dbpa_library_wrapper, moved some of the decorated methods to the *.h file and inlined them.

Are these changes tested?

  • All existing tests pass, and the newly updated tests also pass.

@github-actions

Copy link
Copy Markdown

Thanks for opening a pull request!

If this is not a minor PR. Could you open an issue for this pull request on GitHub? https://github.com/apache/arrow/issues/new/choose

Opening GitHub issues ahead of time contributes to the Openness of the Apache Arrow project.

Then could you also rename the pull request title in the following format?

GH-${GITHUB_ISSUE_ID}: [${COMPONENT}] ${SUMMARY}

or

MINOR: [${COMPONENT}] ${SUMMARY}

See also:

@argmarco-tkd argmarco-tkd changed the title Dev dll work Adding latest DBPAInterface to dev-miniapp Aug 19, 2025
@argmarco-tkd argmarco-tkd marked this pull request as ready for review August 19, 2025 15:40

@avalerio-tkd avalerio-tkd left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Thanks for the change. Nothing blocking, just a few questions and comments.


class EncryptionResult {
};
using tcb::span;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

👍

std::unique_ptr<EncryptionResult> DBPATestAgent::Encrypt(
span<const uint8_t> plaintext,
span<uint8_t> ciphertext) {
span<const uint8_t> plaintext) {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

At what point will the tcb::span be converted into arrow::span? This is still tcb::span at this point, right?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Correct. At this point, this is still tcb::span. There is no "conversion" per-se between span types - there will be copying happening at the ExternalEncryptorImpl and ExternalDecryptorImpl level. (that will be coming in another PR a bit later)

create_encryptor_t create_instance_fn = reinterpret_cast<create_encryptor_t>(symbol_result.ValueOrDie());

//at this point, we have the create_instance function pointer (from the shared library)
// at this point, we have the create_instance function pointer (from the shared library)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

(Not specific to this line but using to ask)

Is there anything in particular we do so that we have class variables for the DBPA implementations? This is so that we can have the shared connections, auths, etc in the future? Not inmediately related to the PR, and this for my understanding. We can chat offline as well.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Happy to chat, but in summary - we don't need to do anything special to have class variables for DBPA implementations. As long as the classes are loaded from the same shared library (i.e. the same*.so file) - things should work as if the code was compiled/linked directly with the app. I added a note in this doc

@@ -0,0 +1,618 @@

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

About the file location of external resources, we may want to put them in a directory exclusively for truly external files, not mixed with other things. Not super sure if that's the case. I see cpp/src/parquet/encryption/external/loadable_encryptor_utils_test.cc for example in external and not sure if that is truly that.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Currently, within the Arrow codebase, we have three files that "should not be there": span.hpp, dbpa_utils.h and enums.h (the latter two being copies from the DataBatchProtectionService repo). I thought thought of doing that (having a special directory for "header files that should not be here"), but given the number of files I found it to be slightly overkill. Given the push, I will make the change - but if not a blocker, I'll send a separate PR.

Now, the external directory here exists for a different reason - to contain "external encryptor/decryptor-related stuff" (e.g. dbpa loaders, etc).

And yes - loadable_encryptor_utils_test.cc is there intentionally - the actual file (loadable_encryptor_utils.cc) belongs to the external dir, and the C++ common practice is to keep the test files right next to the files they test :).

@avalerio-tkd avalerio-tkd left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

LGTM in general. If concerns are addressed feel free to merge.

@argmarco-tkd argmarco-tkd merged commit 81c2682 into dev-miniapp Aug 19, 2025
33 of 72 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants