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