Notes: idpy developers call, 10 July 2018
by hlflanagan＠sphericalcowgroup.com
Attendees:
Ivan, Scott, Christos, Heather, Rainer, Johan L.
Notes
0. Agenda bash
* CLA status (see AOB)
1. Satosa Security review
Team in GEANT is offering to do a security review of Satosa and is looking for guidance on where to start. Ivan’s suggestion: “SATOSA only connects frontends to backend (and vice versa), with some intermediate logic that defines the internal representation of the
information it has collected, plus the metadata and configuration. The "heavy lifting" is left to the libraries that actually implement the standards. IMHO, the tricky bits are there; in the libs. So, my vote would be yes, but lets start with the shell (SATOSA) and see if we can move towards the core (libs) later.”
Note that SATOSA will evolve over time, so some of what gets reviewed will change. Should we hold off on doing this until the code settles a bit? It could help prioritize, and the GN4 project does have extra budget now. Could do a lightweight evaluation now, and more in-depth next year. Ask Niels if this is a one-off thing; if it can be repeated, then go ahead and do it now.
There is a rough draft of a security response process (in case they find something); is that ready for more public feedback? Ivan to do another quick review and then we can send it to the list.
2. PR status
- Satosa (Satosa PRs - https://github.com/IdentityPython/SATOSA)
Going through some documents from Christos regarding the step-up service. Somewhat related to PR 182. Will be working on that, probably making this a new microservice.
Evaluating flake8 (combines a linter, pyflakes, and a style guide, PEP8). This will also be part of the testing procedures.
PR186 - about adding contribution from GEANT (discussed on the mailing list)
- Satosa microservices
How flake8 handles plugins will impact how we manage microservices.
Each microservice will be split into its own package and its own repository; each microservices will be responsible for its own configuration and dependencies. It will be like a plug in system.
- pySAML (https://github.com/IdentityPython/pysaml2)
Ivan has gone through several issues and PRs, and sent the PR for the day/time module (a big one) out for review. Johan has done a review on that, and a few things will change. Additional reviews always welcome (518). The code is now using aniso8601, but that can easily be swapped out for something else if needed.
Ivan has merged some smaller PRs, including one to fix the CI stuff, and planning to add more Python versions to the testing. Also added more coverage reports. This will help us see what is/is not tested.
Working on figuring out how to properly package a Python project for release (see ‘flit’ https://flit.readthedocs.io/en/latest/ as a possible packaging source.) For current packages, the license was not included in the package, and other items needed to be fixed/renamed, version identified, etc.
Concern that many deployers are using things like salt, puppet, etc, and those tools have modules for the existing packaging tools. If we move too quickly, then we’ll have packages that deployers can’t easily install using existing infrastructure. Scott can help facilitate a discussion around these kinds of requirements.
note that something like flit is about creating the package, but it still creates a standard python package for deployers.
Another issue where someone removed a dependency from a library, but something else still depended on that - cryptodome replaced with cryptography.
Closed some issues that were invalid or outdated (fixed by merges already done).
Introduced a documentation file (editorconfig) - a generic description on how an editor should work.
See GitHub for full details.
- pyFF (https://github.com/IdentityPython/pyFF)
3. AOB
CLA status? The group has not come to consensus on what level of risk is acceptable (and who can accept that risk). This needs to be resolved so we can move forward, either by relying on the existing licenses and GitHub TOS, or trying to create a new CLA and get people and/or companies to sign it. Who can make this decision?
AARC project is going to start a pilot project for an OIDC federation. Satosa will be part of the software piloted. Is work towards this (working towards OIDC) on Ivan’s roadmap? It was not, but Ivan has started talking to Roland about this and collecting material to read. There is a branch on Satosa that might be of interest that assumes an OIDC front end. Ivan points out that some of this will need to tie into the OIDC libraries Roland has been writing for Google; Ivan will be looking at those libraries first.
Roland is the only one that can upload new releases to pypy. Hoping someone (Johan) can upload a new version of Satosa and give Ivan access to that repository? yes, this should be possible. Ivan wants to make more frequent releases, and start a change log.
Sent from my iPad
