You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@santuario.apache.org by "Peter De Maeyer (Jira)" <ji...@apache.org> on 2020/04/11 20:08:00 UTC
[jira] [Created] (SANTUARIO-536) OutboundXMLSec.processOutMessage
incorrectly uses SecurePart.getIdToSign for encryption
Peter De Maeyer created SANTUARIO-536:
-----------------------------------------
Summary: OutboundXMLSec.processOutMessage incorrectly uses SecurePart.getIdToSign for encryption
Key: SANTUARIO-536
URL: https://issues.apache.org/jira/browse/SANTUARIO-536
Project: Santuario
Issue Type: Bug
Components: Java
Affects Versions: Java 2.1.5
Reporter: Peter De Maeyer
Assignee: Colm O hEigeartaigh
{{OutboundXMLSec.processOutMessage}} incorrectly uses {{SecurePart.getIdToSign}} for encryption.
There are two "if/else if" branches, one for signature and one for encryption.
Both branches however use {{SecurePart.getIdToSign}}, which is correct for the signature branch, but not for the encryption branch.
I believe that the encryption branch must use {{getIdToReference}} instead.
"I believe" because the lack of Javadoc and unit tests makes it impossible to "know" the intent, so I have to make an educated guess based on the following observations:
* {{SecurePart.getIdToReference}} is called nowhere, which smells - I suppose it's intended for _something_.
* Neither {{setIdToSign}} nor {{setIdToReference}} are called anywhere, indicating that there are no tests for it, which explains why this feature is broken.
The impact is that encryption based on matching XML attribute ID does not work as intended.
The workaround is to use the equivalent for signing, but that means you can't choose a different ID for elements that need both signing and encryption.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)