Repository navigation
Fix rnp_op_verify_get_used_recipient to support hidden recipient - #2391
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2391 +/- ##
=======================================
Coverage ? 85.35%
=======================================
Files ? 126
Lines ? 22852
Branches ? 0
=======================================
Hits ? 19506
Misses ? 3346
Partials ? 0 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
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, overwriteop->used_recipient->keyidwith 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.
| /* 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(); | ||
| } |
367a2e0 to
1206c79
Compare
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.
|
Thank you @kaie for the contribution! |
Fix rnp_op_verify_get_used_recipient to support hidden recipient
Related to Issue #1275