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)
https://github.com/IdentityPython/pyXMLSecurity/pull/49
This PR refactors how padders and hashers are created for the
cryptography backend and adds a test validating an ecdsa-sha512 signature
My plan after this is sorta like this:
1. remove the do_padding/do_hashing boolean and move the
outside-the-pkcs11-token hashing and padding into sign/verify of
XMLSecCryptoP11
2. refactor crypto to along the lines of what Steffen and others have
suggested.
3. add support for explicit parametrized padding mechanisms
Thoughts?
Cheers Leif
Hi,
I was discussing development of InAcademia with Niels and again had to mention
that the debug cycle of SATOSA involves: pip installing, editing the virtual-
env code, restarting satosa, check behaviour, port changes to the git tree,
commit and push, pip install --upgrade, check.
Especially the manual port of the virtualenv changes/hacks back into the git
tree are error prone.
Am I doing it wrong, or is this really the only way?
Best regards,
Martin