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
Hi everyone,
I proposed to discuss this at the bi-weekly idpy call (Tue 18/9 at
13:00 UTC). This is a bit complex, so I thought I'd do a writeup for
anyone that would like to discuss this.
I will try to describe how SATOSA handles the NameID value, and by
this I mean how the text value of the NameID node is transformed,
after it is received by the saml-backend (from an IdP), and before it
is passed over to the appropriate (saml or openid) frontend.
Omitting some details the flow is as follows: Once an authn-response
is received, the backend parses the response and extracts the NameID
node as `name_id` and its text value as `user_id`[0]. Control flow is
returned to the `base` module where `used_id` is hashed[1] before it
is passed to the response-microservices. Once microservices are done
doing their job, control is back in `base` module and the `user_id` is
hashed again[2]. Finally, the appropriate frontend module (saml[3],
openid[4]) is invoked and `user_id` is used as the basis for the
attribute that is needed.
What stands out here is the hashing of `user_id` (that happens twice).
This is something that has come up multiple times in different forms
(pull-requests #137 #160 #193 work around it). I decided to figure out
what's going on: How is that decision formed? Why does that take
place? Does it provide any value?
Hashing of `user_id` was introduced by commit b54006f [5].
Unfortunately, the accompanying commit message does not offer an
explanation or any hints on why this was needed. Looking at the
evolution of the code, nothing shows me why that was needed or what
value it added. A hint is that it is closely coupled to the
`UserIdHashType` enumeration[6] from `internal_data` module.
Unfortunately, the evolution of that part of the code also doesn't
help to reveal the need for both the enumeration and the hash.
In the hope that maybe a test that I did not see at the time could
reveal a reason for this behaviour, I went ahead and removed the
relevant code. You can see the changeset on my personal fork on the
branch named 'refactor-remove-user-id-hash' [7]. And nothing really
broke! At this point I do not see any value keeping the UserIdHashType
enumeration and hashing of `user_id`.
If someone has an insight on why hashing `user_id` was introduced and
what its purpose was, I would be interested to know. If we do not come
up with a valid use case, I would propose to move forward by removing
that part of the code.
[0]: https://github.com/IdentityPython/SATOSA/blob/d861e87/src/satosa/backends/s…
[1]: https://github.com/IdentityPython/SATOSA/blob/d861e87/src/satosa/base.py#L1…
[2]: https://github.com/IdentityPython/SATOSA/blob/d861e87/src/satosa/base.py#L1…
[3]: https://github.com/IdentityPython/SATOSA/blob/d861e87/src/satosa/frontends/…
[4]: https://github.com/IdentityPython/SATOSA/blob/d861e87/src/satosa/frontends/…
[5]: https://github.com/IdentityPython/SATOSA/commit/b54006f
[6]: https://github.com/IdentityPython/SATOSA/blob/d861e87/src/satosa/internal_d…
[7]: https://github.com/c00kiemon5ter/SATOSA/compare/d861e87...refactor-remove-u…
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
Hola a todos!
We've been talking for a while about how to structure idpy into a
project that has clear IPR guidelines, security policies, and
governance. You've had a chance to see the proposed governance statutes
(https://github.com/IdentityPython/Governance) Having heard no changes,
I'd like to propose the following:
First, that the statues and incident response policies be considered
"good enough" to get us started.
Second, that we establish a Board of Directors as described in the
statues. I have a list of candidates that have agreed to be nominated as
the initial board seats. If you would like to be added to the list, or
have any comments on the proposed candidates, please drop me a direct
message. Nominations will be closed on 30 September 2018, and we will
either go to a vote of idpy participants if there is contention for one
or more seats, or we will have a board slate ready to go.
The initial list of nominees are:
* idpy chair for 12 months = Ivan
* at-large for 12 months = Roland
* at-large for 24 months = Heather
* regular board member for 12 months = Mike Jones (as a link to the
OpenID Foundation)
* regular board member for 24 months = Leif
Please let me know if you have any questions!
Heather
Hi all,
One of the individuals I contacted when I was reaching out about the
possibility of a [C]CLA pointed out the following from the GitHub Terms
of Service:
---
6. Contributions Under Repository License
Whenever you make a contribution to a repository containing notice of a
license, you license your contribution under the same terms, and you
agree that you have the right to license your contribution under those
terms. If you have a separate agreement to license your contributions
under different terms, such as a contributor license agreement, that
agreement will supersede.
Isn't this just how it works already? Yep. This is widely accepted as
the norm in the open-source community; it's commonly referred to by the
shorthand "inbound=outbound". We're just making it explicit.
(https://help.github.com/articles/github-terms-of-service/)
---
I've also reviewed the licenses listed under each of the Identity Python
projects:
* pySAML2 = Apache 2.0
* SaToSa = Apache 2.0
* pyXMLSecurity = NORDUnet (2 clause BSD)
* pyFF = SUNET (2 clause BSD)
* pyeleven = SUNET (2 clause BSD)
My reading of this suggests that a CLA doesn't actually offer us any
assurances we don't already have by a) using GitHub (and therefore
agreeing to the ToS) and b) posting the licenses in the repos (which
must be inherited by anyone posting in those repos, again thanks to the
GitHub ToS).
Thoughts or concerns?
Heather
Date: Tuesday, 18 September 2018
Time: 13:00 UTC
https://bluejeans.com/655841213
Agenda:
0. Agenda bash
1. Governance and nominations: what does that mean / how we move
forward (e.g., with CLA and other CommonsConservancy) / etc
- See email from 11 September 2018 (Subject: [idpy-discuss] idpy
governance and nominations for first Board of Directors) for initial set
of candidates
2. New bugfix/minor pysaml2 release v4.6.2
3. pyXMLSecurity refactor (see email from 14 September 2018 (Subject:
Re: [Idpy-discuss] getting beyond RSA and PKCS1 v1.5 for pyXMLSecurity)
4. SATOSA: Hashing the user-id - is this necessary?
5. AOB
---
For reference:
- Satosa (Satosa PRs - https://github.com/IdentityPython/SATOSA)
- pySAML (https://github.com/IdentityPython/pysaml2)
- pyFF (https://github.com/IdentityPython/pyFF)
- Governance docs (https://github.com/IdentityPython/Governance)
