<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 11/5/15 12:33 PM, Brent Putman
wrote:<br>
</div>
<blockquote cite="mid:563B92D9.6040704@georgetown.edu" type="cite">
<pre wrap="">
On 11/5/15 10:03 AM, Cantor, Scott wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 11/5/15, 2:55 AM, "dev on behalf of Brent Putman" <a class="moz-txt-link-rfc2396E" href="mailto:dev-bounces@shibboleth.netonbehalfofputmanb@georgetown.edu"><dev-bounces@shibboleth.net on behalf of putmanb@georgetown.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">As I mentioned, we already have similar issues with decryption+validation (e.g. decrypt an Assertion then validate its signature). That is documented extensively in the Decrypter Javadocs. This may just have to be a documentation thing.
</pre>
</blockquote>
<pre wrap="">It's fairly easy to trigger in a unit test. Do we want to do anything to cover this case? I guess maybe not, but it felt weird since it obviously changed behavior with 2.0.5 and our tests didn't notice. But a test here would just fail so it would be an inverse test to verify that the library contained to fail on this case I guess. Feels like we should have something.
</pre>
</blockquote>
<pre wrap="">
Yeah, I was going to look at that. I didn't now for sure whether tests
had failed yet or not. We should have something I guess.</pre>
</blockquote>
<br>
<br>
For the record for the decryption+validation, we have a whole unit
test class just testing that case.<br>
<br>
org.opensaml.xmlsec.encryption.support.DecryptionSignedContentTest<br>
<br>
<br>
IIRC, we encountered a similar failure as here, so I added that
rootInNewDocument option and the test.<br>
<br>
So the cloning issue is the same. It wasn't an issue, but
apparently now it, so we'll add some tests and/or fixes to account
for it.<br>
</body>
</html>