Dear users of IdentityPython,
this is a heads-up about two vulnerabilities affecting pySAML2.
Software that uses pySAML2 is indirectly affected, too (ie, SATOSA).
The issues were reported to the IdentityPython incident-response
mailing list and we have been working on a mitigation. A new version
of pySAML2 that includes the fixes will be released on Wednesday
20th of January between 13:00 CET and 17:00 CET. We urge
everyone to be prepared to update their setup to the latest version.
Kind regards,
Ivan Kanakarakis on behalf of the incident-response team
Attendees
John, Scott, Giuseppe, Ivan, Hannah, Ori, Johan, Chris
0 - Agenda bash
1 - Administrivia
Suggestion made that announcements of security issues should include some indication of severity and whether there is indication these have been found 'in the wild'. Also some additional guidance on what to expect with regards to remediation (what are deployers expected to do, what level of effort can people expect to encounter) would be helpful. The team will put together an FAQ on how security vulnerabilities are handled and include a log of known vulnerabilities (once those vulnerabilities and their remediations are public).
2 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
No update
b. Satosa - https://github.com/IdentityPython/SATOSA
c. pySAML2 - https://github.com/IdentityPython/pysaml2
Nothing major through the holiday, only some minor fixes for the tests. Ivan wants to reorganize the code a bit to clearly separate the operations that work on the XML document representation from those that work on an object representation of the XML data.
d. pyFF - https://github.com/IdentityPython/pyFF
No update
3 - Normalizing idpy projects (see email from Ivan, "Subject: [idpy-discuss] Normalizing across all projects”, 10 November 2020)
a. Extending the invitation to djangosaml2 - status?
Will add to the agenda for our next call
4 - AOB
Thanks! Heather
Tuesday, 12 January 2021, 14:00 UTC
BlueJeans: https://bluejeans.com/444837426?src=join_info
Agenda:
0 - Agenda bash
1 - Administrivia
2 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
b. Satosa - https://github.com/IdentityPython/SATOSA
c. pySAML2 - https://github.com/IdentityPython/pysaml2
d. pyFF - https://github.com/IdentityPython/pyFF
3 - Normalizing idpy projects (see email from Ivan, "Subject: [idpy-discuss] Normalizing across all projects”, 10 November 2020)
a. Extending the invitation to djangosaml2 - status?
4 - AOB
Thanks! Heather
Hello all,
Thank you for filling out the doodle poll to determine when we should have our calls! We’ll be using the same time slot (14:00 UTC for now, subject to change during those pesky Daylight Saving Time changes).
If the Google Gods are being cooperative today, you should be able to add this calendar invitation via the following link:
https://calendar.google.com/event?action=TEMPLATE&tmeid=NXJmNXZ0dG9kbWNkcTd…
Our first call for 2021 will be next week on Tuesday, 12 January 2021.
Thanks! Heather
Hola a todos!
As discussed on the last call, we’re going ahead and canceling the call for 22 December. THAT SAID! Please fill out the doodle poll so I can get the 2021 series of calls on the calendar. Right now, only four people have responded. I you have an opinion about when the calls should happen, please fill out the poll:
https://doodle.com/poll/vtdidxvpstvzb8vc?utm_source=poll&utm_medium=link
Thanks! Heather
Hi!
I had a question from Torsten Lodderstedt, who some of you know, on whether our OIDC/OAuth2 implementation
supported all the features that the FAPI 2 baseline stipulates.
Turns out we do support most of them (PKCE, PAR and the new iss authorisation response parameter).
What we don’t have support for is RAR (https://tools.ietf.org/html/draft-ietf-oauth-rar-03 <https://tools.ietf.org/html/draft-ietf-oauth-rar-03>).
The new session/grant subsystem has hooks for it but we’re lacking the part that actually can use it.
I don’t think that GEANT has any use for RAR but I may be wrong. If so I’d like someone to tell me.
The larger question is of course: should we care what FAPI/FAPI 2 demands ?
Or ultimately, our customer what do they want ?
Anyone knows who are customers are ?
Anyone with an idea as to who we would like to be our customers ? Except for the HigherEd and Research ?
— Roland
Can anything be sadder than work left unfinished? Yes, work never begun. -Christina Rossetti, poet (5 Dec 1830-1894)
Hello idpy developers!
ON the last call, the group suggested sending out a poll oto see if our current call time slot works for 2021, or if there might be a better one for the participants. I’ve put together a poll to see if we can answer that question. When you fill out the poll, please consider whether you can make that time slot every other week, and not just that one day.
https://doodle.com/poll/vtdidxvpstvzb8vc?utm_source=poll&utm_medium=link
If you could fill that out before you head off for any vacations you might be taking this year, I would greatly appreciate it!
Thanks! Heather
Attendees:
Ivan, Giuseppe, Heather, Hannah, Roland, Scott, John P, Johan, Nikos
1 - Status of architecture documentation & Normalizing idpy projects (see email from Ivan, "Subject: [idpy-discuss] Normalizing across all projects”, 10 November 2020)
Before we make djangosaml2 part of idpy, we should have a stronger set of guidelines on what we expect in terms of managing a project (using semver, readthedocs, change logs, etc). Could also use something called “cookie cutter” which does several of the set up of these kinds of things for projects in GitHub. While we would not create new project spaces for projects that come in with their own repository, it would allow for a type of model and technical documentation on how we think projects should look like. Note that this would let us to also normalize on how we handle issues, what labels we use, PR templates, a common FAQ, tooling to build and test packaging, boilerplate (README, LICENSE, etc)
• Example: https://github.com/SUNET/eduid-webapp/tree/master/cookiecutter-app
Ivan will continue to write up his thoughts in email.While Ivan can make these decisions for Satosa and pySAML2, need input from other maintainers.
Discussion:
• We can agree to semver and pep8, but some of the other things we’ve been talking about are very heavy for some of the smaller projects.
• Do we know who our customers are, and what they need? Will they be taking our libraries and using them to build their own use cases? Or are they looking for a packaged service they can just run? We can’t cater to both. Can we have two categories of rules? One size won’t fit all projects.
• What about change logs? They send a good signal to deployers about what to watch for when they upgrade (or help them decide if an upgrade is required).
Consensus:
• semver
• pep8
• readthedocs
• README and LICENSE files
• PR and issue templates (already exist)
• Change logs
3 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
New project for the documentation on session management (code is still in oidcendpoint). Since readthedocs can’t handle documentation for forks, this allows the publication of material before the code is even final. Has not pushed to readthedocs yet; will aim to have that done before the next call.
b. Satosa - https://github.com/IdentityPython/SATOSA
No changes.
c. pySAML2 - https://github.com/IdentityPython/pysaml2
There was a bug in the redirect binding, where the request was also going to be signed. The problem is that by default, if the signing algorithm was not specified, the right parameters were not produced. This has been fixed. In the same PR will be Giuseppe’s work on configurable signing and digest algorithm (see https://github.com/IdentityPython/pysaml2/pull/744) Ivan will be pushing a commit with partial notes (in the form of bullet points) and other people involved will help turn that into proper documentation. We will need to refactor the whole process of signing, encryption, and decryption.
d. pyFF - https://github.com/IdentityPython/pyFF
4 - AOB
Thanks! Heather
Hello everyone,
at the last idpy meeting, we started a discussion around normalizing
how idpy projects operate. The goal is to agree on a baseline on how
we treat different project aspects and how we can harmonize those in
order to give users uniform expectations. A user that is familiar with
how project-x works, should automatically be familiar with how
project-y works when they decide to use that too. The first step is to
agree on guidelines, and then have each project steadily work its way
to that. In the process, we should effectively be cultivating a
culture on how we manage projects, and not blindly follow policies.
The initial discussion started around documentation, versioning and
changelogs. Many more things can and should be discussed. Those
include topics such as tooling, CI/CD, testing, packaging, release
schedules, issues management, git-workflow, etc. I will expand on some
of those topics and we can further discuss in this or separate threads
or in the following calls about each one.
## Documentation
I think we can all agree that documentation is important and needed. I
make a distinction between documentation whose audience is a user and
documentation whose audience is a developer. The user-documentation
consists mainly of the project API, how it is used, and use-case
scenarios. The developer-documentation consists of architectural
diagrams, design choices, separation of entities, and general guidance
on how modules are separated and code is organized.
Being part of the python community, the natural tool around
documentation is https://readthedocs.org/. Readthedocs works in tandem
with Git(Hub) projects, and can automatically be kept in sync with a
repo.
- Do we agree to use https://readthedocs.org/ to publish documentation?
- Should we request PRs to include documentation? or, should we
fill-in the documentation when creating a new release?
## Managing change
### Versioning
What we actually want to do with versioning is _signal_ the type of
changes that are part of a new release. The most common versioning
scheme is semantic versioning (https://semver.org/) - other things out
there include CalVer (https://calver.org/) Apache versioning
(https://apr.apache.org/versioning.html) and more. However, I think
semver is quite common and probably everyone will agree that it's
fine. Most importantly it achieves the goal of signaling in a simple
way:
> Given a version number MAJOR.MINOR.PATCH, increment the:
>
> - MAJOR version when you make incompatible API changes,
> - MINOR version when you add functionality in a backwards
> compatible manner, and
> - PATCH version when you make backwards compatible bug fixes.
>
> Additional labels for pre-release and build metadata are available
> as extensions to the MAJOR.MINOR.PATCH format.
- Do you think we should use semver?
### Changelog
Same as with documentation, the Changelog comes in two flavours - the
changelog that is intended for developers, and the changelog that is
intended for users (aka release notes). The technical-changelog is the
VCS-log itself and contains purely technical entries on how the code
was modified to achieve a certain effect. We have the technical
changelog for free.
On the other hand, the user-changelog has the form of a set of release
notes. The release notes should be enough to explain what’s going on
to someone deploying the package, or to a user that wants to use new
functionality - it is a summary of the new release value. This type of
changelog cannot be autogenerated, and we must write and curate by
hand. As with versioning, there are some formats out there, but I
think something like keepachangelog (https://keepachangelog.com/) is
easy to use and very close to what most of us would end up with while
trying to specify a consistent format.
When should the user-changelog be updated? Usually this is done either
at release-time.
- Should we maintain a changelog/release-notes?
I will continue this subject with more topics, soon. I'm looking
forward to your thoughts!
Cheers,
--
Ivan Kanakarakis
