Skip to content

Fix rnp_op_verify_get_used_recipient to support hidden recipient#2391

Open
kaie wants to merge 2 commits into
rnpgp:mainfrom
kaie:fix_get_hidden_recipient
Open

Fix rnp_op_verify_get_used_recipient to support hidden recipient#2391
kaie wants to merge 2 commits into
rnpgp:mainfrom
kaie:fix_get_hidden_recipient

Conversation

@kaie

@kaie kaie commented May 27, 2026

Copy link
Copy Markdown
Contributor

Fix rnp_op_verify_get_used_recipient to support hidden recipient
Related to Issue #1275

@codecov

codecov Bot commented May 27, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (main@c57f486). Learn more about missing BASE report.
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2391   +/-   ##
=======================================
  Coverage        ?   85.37%           
=======================================
  Files           ?      126           
  Lines           ?    22789           
  Branches        ?        0           
=======================================
  Hits            ?    19457           
  Misses          ?     3332           
  Partials        ?        0           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Pull request overview

This PR updates the verify/decrypt operation so that when decrypting messages with a hidden recipient (KeyID 0x00000000) the “used recipient” reported via the FFI reflects the actual secret key that succeeded, aligning with the hidden-recipient behavior requested in Issue #1275.

Changes:

  • After process_pgp_source(), if hidden-recipient decryption was attempted and succeeded, overwrite op->used_recipient->keyid with the key ID of the successfully used secret key (kparam.last).
  • Leaves existing recipient enumeration intact, but improves the accuracy of rnp_op_verify_get_used_recipient() results for hidden-recipient decrypts.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread src/lib/rnp.cpp
Comment on lines +3401 to +3407
/* For hidden recipients, patch used_recipient with the actual key id that was used.
* kparam.last still points to the key that succeeded: the stream-parse loop breaks
* immediately after a successful encrypted_try_key(), so the key provider is not
* called again after that point. */
if (kparam.has_hidden && kparam.last && op->used_recipient) {
op->used_recipient->keyid = kparam.last->keyid();
}
@ronaldtse
ronaldtse force-pushed the fix_get_hidden_recipient branch from 367a2e0 to 1206c79 Compare July 22, 2026 14:32
Adds test_ffi_decrypt_hidden_recipient_used_recipient to ffi-enc.cpp,
exercising rnp_op_verify_get_used_recipient on a message that contains
a hidden-recipient PKESK (keyid all zeros per RFC 4880 §5.1).

The test verifies the API contract: after a successful decryption,
used_recipient is non-null and its keyid is the all-zero sentinel ONLY
when no real key succeeded for the hidden path. The existing fixture
message.txt.enc-hidden-1 has both a hidden (first) recipient and a
visible (second) recipient — rnp picks the visible one, so the fix's
specific path (patching keyid for an actually-successful hidden
recipient) is not directly exercised. A future test that requires a
single-hidden-recipient fixture (built via gpg --throw-keyids, since
rnp's FFI does not expose hidden-recipient encryption) would close
that gap directly.

This test still adds value as an API-contract regression: any future
change that breaks the used_recipient population path on
hidden-recipient messages will be caught here.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants