so that lasso.py, lasso/types.c and liblasso.so.3.13.0
build reproducibly
in spite of indeterministic filesystem readdir order.
For some reason, lasso/extract_sections.py lasso/extract_symbols.py
do not need such patches to get a reproducible openSUSE package.
See https://reproducible-builds.org/ for why this is good.
This patch was done while working on reproducible builds for openSUSE.
License: MIT
Signed-off-by: Bernhard M. Wiedemann <bwiedemann@suse.de>
As implemented lasso_server_add_provider2 could not be used as a publik
API as it dit not increase the reference count of the LassoProvider
object before adding it to the providers hashtable.
lasso_server_add_provider_helper had to be modified to decrement the
reference count of the new LassoProvider object after using
lasso_server_add_provider2.
debian/rules supposed that lasso Makefile would always prefer python2 to
python3, it's not the case anymore. Also recent python3 improvements to
bindings scripts did not work with python 3.5 on jessie (on jessie/3.5
default open() encoding is still ASCII not UTF-8 as with the default
UTF-8 of later python3 versions).
When ECP profile (saml-ecp-v2.0-cs01) is used with PAOS binding Lasso
populates an AuthnRequest with the "Destination" attribute set to
AssertionConsumerURL of an SP - this leads to IdP-side errors because
the destination attribute in the request does not match the IdP URL.
The "Destination" attribute is mandatory only for HTTP Redirect and HTTP
Post bindings when AuthRequests are signed per saml-bindings-2.0-os
(sections 3.4.5.2 and 3.5.5.2). Specifically for PAOS it makes sense to
avoid setting that optional attribute because an ECP decides which IdP
to use, not the SP.
Fixes Bug: 34409
License: MIT
Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
saml2:AuthnContext XML schema indicate that AuthenticatingAuthority is
an optional unbounded list of nodes, but the current Lasso schema only
handle an unique element. To prevent Lasso from refusing perfectly legal
messages, we add a rule to the Lasso ignoring other nodes after the
first one.
With a SAML Authn Response either the message or the assertion
contained in the response message or both can be signed. Most IdP's
sign the message. This fixes a bug when processing an ECP authn
response when only the assertion is signed.
lasso_saml20_profile_process_soap_response_with_headers() performs a
signature check on the SAML message. A signature can also appear on
the assertion which is checked by
lasso_saml20_login_process_response_status_and_assertion() The problem
occurred when the message was not signed and
lasso_saml20_profile_process_soap_response_with_headers() returned
LASSO_DS_ERROR_SIGNATURE_NOT_FOUND as an error code which is not
actually an error because we haven't checked the signature on the
assertion yet. We were returning the first
LASSO_DS_ERROR_SIGNATURE_NOT_FOUND error when in fact the subsequent
signature check in
lasso_saml20_login_process_response_status_and_assertion() succeeded.
The ECP unit tests were enhanced to cover these cases.
The enhanced unit test revealed a problem in two switch statements
operating on the return value of
lasso_profile_get_signature_verify_hint() which were missing a case
statement for LASSO_PROFILE_SIGNATURE_VERIFY_HINT_FORCE which caused
an abort due to an unknown enumeration value.
Fixes Bug: 26828
License: MIT
Signed-off-by: John Dennis <jdennis@redhat.com>
Benjamin Dauvergne
Bernhard M. Wiedemann
Tomohiro "Tomo-p" KATO
Thomas NOËL
Dmitrii Shcherbakov
John Dennis