-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge for release 2.3 #77
Conversation
…xplicit The regexp attribute of a Scope used to default to null when not set explicitly. According to the spec, when omitted this should be interpreted as it being false. Therefore, I think the null default is not correct to have. Also, we should always output an explicit regexp attribute, as recommended by the spec for document signing reasons: https://wiki.shibboleth.net/confluence/display/SC/ShibMetaExt+V1.0
Especially relevant now that a HHVM bug causes long hangs while HHVM is an allowed failure.
shibmd:scope regexp attribute should default to false and be always explicit
This reverts commit aed2223.
Also update tests to use expected key format. Fixes #62
Fix KeyLoader::loadKeys
… "true". This resolves #64. Related to simplesamlphp/simplesamlphp#346 and simplesamlphp/simplesamlphp#347.
SimpleSAML_Logger has been refactored to use namespaces. Replace all calls to the old class with the new.
…e fingerprints. See #68
…nsformer. This resolves #72.
…rsing Handle EPTI attribute parsing correctly
@thijskh @jaimeperez seeing you two did the work here 😉 are there any commits that should not be merged for release 2.3? |
I'm wondering if we should merge #69 also. |
The only commit of those I perpetrated that could be a bit more problematic is this one, since it bumps the minimum version of SimpleSAMLphp required by the compat layer. |
Otherwise I'm 👍 |
Add deprecation tags to classes and methods that work with certificate fingerprints.
#69 can and should be merged i.m.o. - a deprecation notice is still fully bc and just informative to users about what functionality will be removed at some point. The SSP logger is indeed technically a BC break, but only if you use the provided container with SSP which in and of itself is not even a requirement - seems that can and should be fixed with documentation and perhaps an additional interface (for dependecy inversion). Not sure whether or not breaking something that doesn't work out of the box and won't work without knowledge about SSP itself is considered a BC break... I'm actually in favor of keeping both in as neither should be an issue. Thoughts? |
Yes, agreed to add/keep both in. |
I'm assuming both you and us are the main users of this library. So if you don't see a problem with keeping both, and I don't see it either... go ahead! 😉 |
Awesome, thanks! |
No description provided.