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)