My application carried its SAML settings and certificates in code inside a ZIP. Python-SAML supported certificates in the settings dictionary, but enabling signatures made initialization fail.
The report followed this sequence:
load settings dictionary
→ validate signature requirements
→ inspect certificate through self.__sp
→ assign self.__spThe certificate was supplied. The validation path was trying to find it through an instance field before that field had been assigned.
I demonstrated the ordering problem with an intentionally awkward workaround: temporarily remove the security block, initialize the objects, restore the block, prime the private service-provider field, and rerun the settings loader. That was diagnostic surgery around a constructor, not an interface I wanted callers to maintain.
The maintainer initially thought I had missed the documented settings path, then read the trace and recognized a bug introduced when dictionary-based certificates were added. He supplied a correction; I confirmed it solved the problem. The discussion then records a 2.0.2 release containing the repair.
The report proposed either passing the provider settings into validation explicitly or assigning the field earlier. Both addressed the actual dependency. Adding another certificate file would have changed how the application supplied its data without correcting why the supported dictionary path failed.