— > I know, but this worked with 2.6. There seems to be a hash algorith — > mismatch here, SHA1 vs SHA256. Maybe some default differs? Here's the — > trace output: — Oh, right, that would be the default signing change, some of that's down in the stack. I didn't get around to fixing that
Environment
None
Activity
Show:
Rod Widdowson August 11, 2018 at 3:18 PM
confirms this to be fixed on Unix too. Stopping now - we are testing our defaults.
Rod Widdowson August 10, 2018 at 1:34 PM
Thats the sha256 benchmarks pushed. I'm going to eyeball the metadata failures (i.e. do the usual pre-setup stages) before I resolve this
Rod Widdowson August 10, 2018 at 1:19 PM
I can do that. I'll do it quick and dirty for now and maybe ask to have a look then.
Scott Cantor August 10, 2018 at 1:05 PM
The tests should just be updated to compare against SHA-256 signatures, I just neglected to do it.
Rod Widdowson August 9, 2018 at 4:42 PM
So the required magicke appears to be the last four lines of this
Taken in this case from SAML1AssertionTest. I'll systematically make this change, but I am wondering whether it is worthwhile adding the SHA256 template in as well?
As per note by in the user-list.
— > I know, but this worked with 2.6. There seems to be a hash algorith
— > mismatch here, SHA1 vs SHA256. Maybe some default differs? Here's the
— > trace output:
— Oh, right, that would be the default signing change, some of that's down in the stack. I didn't get around to fixing that