MINIFICPP-2749 Add EncryptContentPGP and DecryptContentPGP by martinzink · Pull Request #2225 · apache/nifi-minifi-cpp

martinzink · 2026-08-04T15:52:12Z

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

In order to streamline the review of the contribution we ask you to ensure the following steps have been taken:

For all changes:

Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?
Does your PR title start with MINIFICPP-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
Has your PR been rebased against the latest commit within the target branch (typically main)?
Is your initial contribution a single, squashed commit?

For code changes:

If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
If applicable, have you updated the LICENSE file?
If applicable, have you updated the NOTICE file?

For documentation related changes:

Have you ensured that format looks appropriate for the output in which it is rendered?

Note:

Please ensure that once the PR is submitted, you check GitHub Actions CI results for build issues and submit an update to your PR as soon as possible.

szaszm

It's great to see the new Rust API working beautifully in practice, I really like the API design. A few minor comments below. I'm about halfway through, and will finish with a more thorough review next week.

szaszm · 2026-09-03T14:52:26Z

+| Name               | Default Value | Allowable Values | Description                                                                                                                                                                          |
+|--------------------|---------------|------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| **File Encoding**  | BINARY        | ASCII<br/>BINARY | File Encoding for encryption                                                                                                                                                         |
+| Symmetric Password |               |                  | Password used for encrypting data with Password-Based Encryption<br/>**Sensitive Property: true**                                                                                    |


Can we rename this to Passphrase to match NiFi?

passphrase for me signals its used to decrypt the private key, but i can change it if we want to be more in line with nifi

I'd rather be matching NiFi even if it's at a slight cost to clarity. Password and passphrase are used similarly, passphrase just signals that it can (and should) be longer than a word.

szaszm · 2026-09-03T15:02:42Z

+
+| Name                | Default Value | Allowable Values | Description                                                                                                 |
+|---------------------|---------------|------------------|-------------------------------------------------------------------------------------------------------------|
+| Symmetric Password  |               |                  | Password used for decrypting data encrypted with Password-Based Encryption<br/>**Sensitive Property: true** |


Can we rename this to Passphrase to match NiFi?

changed the properties to match nifi in review changes and review changes 2

szaszm · 2026-09-03T15:06:10Z

I'd keep all of the processor-related metadata in the same file as the processor implementation

still unsure which looks better
move defs into super files

If you prefer them separate, then it's ultimately your call as the author. I prefer them in a single file.

szaszm · 2026-09-16T13:59:07Z

If there is an easy way to reduce the code duplication without unifying public and private key types, and without exploding code complexity, it might be worth exploring.

Since they are completely different types, its either this or macros or add our own trait which we would have to implement twice so not much better. I've tried it originally but didnt like it, feel free to play with it, maybe you can come up with something better.

szaszm · 2026-09-16T14:20:53Z

+        if let Some(sym_passwd) = &self.symmetric_password {
+            ring.message_password.push(sym_passwd);
+        }


What if both a private key and a symmetric passphrase are used? How does that work? Does it work at all? Does it double encrypt and decrypt the message, once with asymmetric and once with symmetric encryption? Does roundtrip with EncryptContent work in that case? If not, should we disable that and exforce an exclusive-OR relationship between the different key types, in schedule?

it can be decrypted with either, its quite smart, pgp generates a single session token it uses that to encrypt the message/file symmetrically and then it encrypts the session token twice, once with public key, once with the configured symmetric key, then saves both results, during decrypiption if it can decrypt the sesion key with either private or symmetric key it can decrypt the file.

szaszm · 2026-09-16T14:24:20Z

+    pub(super) const LITERAL_DATA_FILENAME: OutputAttribute = OutputAttribute {
+        name: "pgp.literal.data.filename",
+        relationships: &["success"],
+        description: "Filename from decrypted Literal Data (Note that OpenPGP signatures do not include the formatting octet, the file name, and the date field of the Literal Data packet in a signature hash; therefore, those fields are not protected against tampering in a signed document. Therefore a lot of implementations omit these inherently malleable metadata)",


Should we ignore the unprotected metadata instead of using them when they're present? As a defense-in-depth measure, I think we should protect flowfile attributes from untrusted values, as some of our processors treat them as trusted data, opening attack vectors.

dd9c84f#diff-04a53c5b836714443ecb6da3dd630ee5c5ca30adff3012af7a13f5f71dcd7f19L174-L175

szaszm · 2026-09-16T14:25:36Z

+    pub(super) const LITERAL_DATA_MODIFIED: OutputAttribute = OutputAttribute {
+        name: "pgp.literal.data.modified",
+        relationships: &["success"],
+        description: "Modified Date from decrypted Literal Data (Note that OpenPGP signatures do not include the formatting octet, the file name, and the date field of the Literal Data packet in a signature hash; therefore, those fields are not protected against tampering in a signed document. Therefore a lot of implementations omit these inherently malleable metadata)",


dd9c84f#diff-04a53c5b836714443ecb6da3dd630ee5c5ca30adff3012af7a13f5f71dcd7f19L174-L175

martinzink assigned martinzink and unassigned martinzink Aug 4, 2026

martinzink added stacked-PR rust labels Aug 4, 2026

martinzink force-pushed the minifi_rust_pgp branch from d8d95a6 to 3c78d17 Compare August 5, 2026 13:19

martinzink force-pushed the minifi_rust_pgp branch from 3c78d17 to ec38f7e Compare August 6, 2026 13:50

martinzink force-pushed the minifi_rust_pgp branch 3 times, most recently from 0727d82 to 2ba9029 Compare August 13, 2026 16:22

martinzink changed the base branch from minifi_rust_impr to minifi_rust_impr_2 August 13, 2026 16:23

martinzink force-pushed the minifi_rust_pgp branch 2 times, most recently from 75e1bf9 to beb4e74 Compare August 17, 2026 12:43

martinzink force-pushed the minifi_rust_pgp branch from beb4e74 to 6bb2ae0 Compare August 18, 2026 07:50

martinzink force-pushed the minifi_rust_pgp branch from 6bb2ae0 to d3260c4 Compare August 19, 2026 13:03

martinzink force-pushed the minifi_rust_pgp branch 2 times, most recently from b913bef to b632b71 Compare August 26, 2026 11:39

martinzink force-pushed the minifi_rust_pgp branch from 71ba3f0 to b81b278 Compare August 28, 2026 14:59

martinzink force-pushed the minifi_rust_pgp branch from b81b278 to 39c2916 Compare September 1, 2026 10:34

martinzink added the priority Review these first label Sep 3, 2026

szaszm reviewed Sep 3, 2026

View reviewed changes

Base automatically changed from minifi_rust_impr_2 to main September 14, 2026 11:50

martinzink and others added 10 commits September 14, 2026 15:49

MINIFICPP-2749 Add EncryptContentPGP and DecryptContentPGP

aab7593

update manifest

bcc884c

minifi_pgp set version to 1.0.0

98d1e28

refactor

aaa9b16

no public key should route to failure instead of rollback

e5b2f33

ruff format, ruff check --fix

8afc68d

rebase

ef49474

review changes

92636d3

refresh manifest

1a65ca7

review changes

47e48ce

martinzink force-pushed the minifi_rust_pgp branch from 56651b5 to 47e48ce Compare September 14, 2026 13:51

martinzink removed the stacked-PR label Sep 14, 2026

martinzink added 2 commits September 16, 2026 10:52

renames

02a4049

move defs into super files

b83eae8

martinzink force-pushed the minifi_rust_pgp branch from dcac03e to b83eae8 Compare September 16, 2026 09:01

lordgamez reviewed Sep 16, 2026

View reviewed changes

martinzink added 4 commits September 16, 2026 14:36

python changes

1be37bd

add_minifi_dependent_option MINIFI_EXTENSION_PGP

3e2ea35

add pgp documentation to root docs

bd38590

python fixes

5611b89

szaszm reviewed Sep 16, 2026

View reviewed changes

lordgamez approved these changes Sep 17, 2026

View reviewed changes

martinzink added 4 commits September 18, 2026 12:49

review changes

dd9c84f

review changes 2

d3982f4

cargo fmt

9975fe7

refresh manifest

59bbc21

Conversation

martinzink commented Aug 4, 2026

For all changes:

For code changes:

For documentation related changes:

Note:

Uh oh!

szaszm left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants