Attendees:
Christos, Johan L, Roland, Heather, Martin, Ivan, Rainer
Notes:
0. Agenda bash
1. Introductions (if needed)
2. Project review
- Satosa (Satosa PRs - https://github.com/IdentityPython/SATOSA)
Roland still waiting to hear from Ivan on creating a federation aware
front end to satosa; they will discuss at a f2f meeting next week.
Many things are on the list. Ivan has been working on the configuration
options, which have been intermixed with config options for pySAML. The
way we specify how we want to sign an assertion is also messes up with
the other options. Satosa should only dictate what values go to the
configurations and pySAML should handle the encryptions. Ivan will roll
out the small changes separately, then will later start deprecating the
current options in Satosa and only use the pySAML options. Ivan will
discuss this further with Johan.
After the options are sorted out, will work on logging (which will also
impact pySAML - want to use the same logger, using the same format,
throughout the whole stack).
Martin has an issue regarding creating a better, default/common template
for direct user interfacing. This starts again through pySAML and how it
handles exceptions; this needs to surface up to Satosa for
interpretation, otherwise Satosa doesn’t actually know anything about
this. Does Satosa actually need to handle the error, or can it just
present a static error page? Maybe. Rainer points out that SAML has an
error URL in metadata; it shouldn’t be the responsibility for a
transparent proxy to engage in user interactions. Ivan suggests that the
error should be in a JSON format that can be presented to something else
for handling (e.g., display or redirection, etc)
Instrumentation discussion: instrumentation is different than error
handling; it is more like log handling. Ivan will probably define
various stable things during execution (e.g., PID, statistics of system,
request ID) and then provide more context as things are processed. The
logging will (probably) be in JSON format. This is higher priority than
error handling. If we go forward with structured logging, we have more
options for monitoring the service.
- pySAML (https://github.com/IdentityPython/pysaml2)
PR 485 - may be able to do this in a more efficient way, but it works as
is. Ivan will likely refactor in a future release. In particular,
handling redirect binding request with Satosa.
Other small changes around general code quality, and updates on examples
to make them work with Python 3. It is a big question about moving from
Python 2 to Python 3 exclusively. Python 2 will no longer be updated
past 2020 (see https://pythonclock.org) Would like to reach out to
other projects using pySAML; there is something in GitHub
(https://github.com/IdentityPython/pysaml2/network/dependents) that
would help with this, but that list needs to be cleaned up. Can there be
a deprecation warning that appears during pySAML upgrades? Not sure;
Ivan will follow up. Alternatively, put a warning in the install log and
have the install fail, redirecting the user to another package.
PR 556 and PR 548 and Issue 549 - name handling. Ivan will be going
forward with this, but via a transition phase. Some changes will be made
to make warnings surface.
- pyFF (https://github.com/IdentityPython/pyFF)
Martin opened two PRs for pyFF last week. Reloading metadata, and fixing
the command line parser.
Leif is still working on splitting the pyFF code to separate the
discovery component from the metadata handling component.
Still hoping that Leif moves away from CherryPi to flask.
- Governance docs (https://github.com/IdentityPython/Governance)
Had the first governance meetings. No hard decisions yet, but hopefully
by the next meeting we will have decisions re: the CLA and the IPR home.
Notes are in the mailing list archive
(https://lists.sunet.se/pipermail/idpy-board/)
3. AOB
TIIME - Rainer has reserved a room for us.
Hi everyone,
PySAML2 v4.6.4 was just released and includes the long wanted
want_assertions_or_response_signed configuration option. See the
changelog[0] for details on the latest changes and try it out ;)
[0]: https://github.com/IdentityPython/pysaml2/releases/tag/v4.6.4
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
Hey all,
we were supposed to have the regular idpy-call today, but none showed
up. We didn't send out an agenda but the meeting should happen
nonetheless. So, I though I'd give everyone an update since the last
call.
## Governance
We finally have a governance board, consisting of 7 people. First task
is to determin whether we'll go the route of requiring a CLA or CCLA
for the code submitted to idpy.
https://lists.sunet.se/pipermail/idpy-discuss/2018-October/000292.html
Governance docs: https://github.com/IdentityPython/Governance
## pyXMLSecurity
- The p11_test suite needs to find the appropriate paths for some
components. The paths are not standard, but depend on where each
distribution places the needed files per its package-management
policy. As we cannot guarantee the location of the files on every
system, the paths are made configurable through env-vars.
https://github.com/IdentityPython/pyXMLSecurity/pull/52
- Travis skips p11_test suite because not all components are being
installed. Getting all components in place is not enough, as travis
runs an Ubuntu version (Trusty/14.04) that does not package
softhsm2/libsofthsm2. Until travis updates the test environment with a
newer ubuntu version, the tests will fail. This will be put aside
until there is an update from travis-ci.
https://github.com/IdentityPython/pyXMLSecurity/pull/53
## pysaml2
- Another issue showed up on pyXMLSecurity that is really a problem
with pysaml2. I've documented the problems on the issue. What it boils
down to is that C14N does not canonicalize namespace-prefixes and they
become an important part of the resulting signature. Any modification
of the namespaces will cast the signature invalid. On the other hand,
the xml-namspace spec says that prefixes are non-important and apps
should not depend on them. The builtin xml parser for python does not
preserve namespace prefixes. This results in cases where signatures
fail to be verified (when the document is exactly the same except for
the namespace-prefixes). Do read the issue, and the linked paper, if
you're interested in learning more.
https://github.com/IdentityPython/pyXMLSecurity/issues/55https://github.com/IdentityPython/pysaml2/issues/551
- The pull request by Martin has been merged (thanks!), and it's the
first in series of commits I'd like to do, that stops pysaml2 from
mapping attribute names to attribute friendly-names (or vice versa).
Attribute friendly names should be preserved when given, but only
attribute-names should be used to identify attributes. Friendly names
should not appear where not requested - they are optional and
inconsequential.
https://github.com/IdentityPython/pysaml2/pull/548
More info: https://github.com/IdentityPython/pysaml2/issues/549
- Branching from above, there was a discussion around how
configuration management and deployment works.
https://lists.sunet.se/pipermail/idpy-discuss/2018-October/000290.html
- Support for encrypting attribute values encoded in unicode landed by
Johan (thanks!). This PR reveals inconsistencies between the callers
of certain functions. I think the arguments types are one of the
greatest sources of pain in pysaml2. There way too many functions that
just accept args or kwargs and until you go deep in the stack you
cannot know whether there is something of value passed through those.
Then there are arguments that can be of two or more types which lead
to many checks and divergence in the code that handles them. I would
really like to get rid of all *args and **kwargs arguments and convert
them to named arguments. That would reveal whether there is a way to
improve the interfaces without breaking the existing code (I am not
very optimistic about that.)
https://github.com/IdentityPython/pysaml2/pull/550
- Finally there is a new request to allow '--id-attr' option that is
passed to xmlsec1 to have multiple values. This seems like a
reasonable request and should be easy to implement.
https://github.com/IdentityPython/pysaml2/issues/552
## Satosa
- Last time we talked about removing the hashing behaviour that satosa
enforces, unconditionally. Work has been done on the
refactor-internal-hashing branch:
https://github.com/c00kiemon5ter/SATOSA/tree/refactor-interal-hashing
This change touches many things that we did not consider initially,
like the internal data representation, and configuration options like
'hash'-attributes. I already have a micro-service to replace the
previous behaviour while making the process a lot more flexible. It
will be on that branch soon.
That's all for now. If you have feedback, or want to add more
information on any of those topics, I encourage you to do so. Either
here, or at the appropriate issue/conversation on github.
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
Hola a todos!
There were no objections to the initial board slate, nor to adding two
more seats to the board. As of today, the list of nominations are:
* idpy chair for 12 months = Ivan Kanakarakis
* at-large for 12 months = Roland Hedberg (independent)
* at-large for 24 months = Heather Flanagan (SCG)
* regular board member for 12 months = Mike Jones (as a link to the
OpenID Foundation)
* regular board member for 12 months = Chris Whalen (NIAID, as a
representative of the research community)
* regular board member for 24 months = Christos Kanellopoulos (GEANT)
* regular board member for 24 months = Leif Johansson (SUNET)
The draft statues (https://github.com/IdentityPython/Governance) have
been updated to include the additional seats, and a final copy will be
approved by the board when it is seated. Also on the early agenda for
the board: determining whether or not we'll go the route of requiring a
CLA or CCLA for the code submitted to idpy.
If anyone has any questions, comments, or concerns, please let me know
by the end of this week.
Thanks!
Heather
Hi,
I just redeployed our satosa setup after rebasing our fork to upstream, so
that setup.py pointed to pysaml2 without any version restriction and expected
my PR to be reflected in the virtualenv site-packages for saml2 egg. But the
attribute_converter.py file still tries to get the name from friendly_name?
pysaml2 seems to be 4.5.0, looking at the dist-info directory.
How long does it generaly take for merged PR's to be available for pip
install? Does this require a release and if so, when will this happen?
Best regards,
Martin
