Attending
Martin, Heather, Scott, Rainer, Ivan
Regrets
Leif, Roland, Jonas, John, Benn
Agenda:
0. Agenda bash
1. XML bug (Ivan)
It is primarily an XML issue. We are not effected because we are using
element three which by default strips comments (though that is
problematic in a different way). This means one of the standards for
signing is not included in the code base. This is still a theoretical
limitation (no one has complained (yet)).
Ivan has found some interesting tools that might be used to help
validate XML. There is a tool in pySAML2 to do this; it works, but it is
not maintained. Ivan is still investigating. Note that this might also
be of interest to pyFF.
2. pySAML2 PRs - https://github.com/IdentityPython/pysaml2/pulls
Scott’s PRs are waiting on him to write tests. No other blockers.
PR 471 is straightforward to merge.
Ivan is still reviewing the other PRs.
PR493 is failing tests but the fix might not be the right solution.
There are many places where pySAML is encoding things, so need to
understand where and how we can generalize this. Need a test.
PR495 is also assigned to Ivan. It seems fine; will probably just accept.
PR499 is new. Not sure what the use case is here. It ties back to Issue
412 from May of last year. It could still use a test; Ivan will write a
comment asking for that.
Action item: update the PR template to be more explicit in asking for
the use case
3. Governance update
Many thanks to the interested parties that filled this out, but alas, I
will need to extend the doodle poll as some of the key people are unable
to be in the same place at the same time. Look for an updated poll in
the next few days.
4. AOB
* Consent manager service (Martin) -
https://github.com/its-dirg/CMservice/blob/master/src/cmservice -
discovered code injection bugs while investigating the SAML bug. Roland
says the code has been abandoned. SURFnet is actively using the
CMservice, so the question is what else is being used in the consent
space in idpy? For the other deployments described on the call, consent
is not part of the workflow (e.g., platform participants are employees
or otherwise have already consented to using the service)
* Should it be included? Consent will become more of a thing in the
future for additional deployments. Scott is supportive. Request for
Martin to ask if SURFnet is willing to provide some resources for
ongoing maintenance. Martin to send a formal request to the list as per
our inclusion guidelines.
(https://github.com/IdentityPython/IdentityPython.github.io/wiki/Adding-and-…)
* SURF fork of the software:
https://github.com/its-dirg/CMservice/compare/master...SURFscz:master
* The its-dirg is a department that has since been disbanded as Umea
University. Need to reach out to Leif and Roland to see if they can
reach out to someone who still has access
* New functionality request that would require a new SAML front end -
The Satosa mirror front end exposes multiple IdPs by mirroring the IdPs
that are available from the back end. If you’re federating with eduGAIN,
it would take those IdPs and expose them at the front end as multiple,
logical IdPs. This bypasses the WAYF. Satosa still looks like a single
SP. For Scott’s use case, rather than having mirrored IdPs that are
based on the downstream authenticating IdPs, the goal is to have
multiple virtual IdPs on the front end of Satosa that correspond to VOs.
The idea is that using a CMP, you would have a VO and would be able to
provision into Satosa a logical IdP that represents that organization.
Example: A set of SPs want to federate with the IdP for the MWA
collaboration. So, when the user looks to the service, they pick their
VO and from their VO, they get a smaller list of associated IdPs. The SP
will still think the user has come from the MWA virtual IdP, not
whatever the actual downstream IdP authenticated was. This is intended
to be something dynamic.
* This seems to be a new use case, and new tool(s) will likely be
required.
* Where should the information be stored? How does it consume the
information over time? Should this be functionality for Satosa as a
whole, or be a separate front end? Scott will pull together an initial
proposal and more specific questions for the group.
Next call:
March 20 - Note that Heather is unavailable, but group will still have a
discussion if needed
Hi !
I’ve been asked what’s happening with CMService (https://github.com/its-dirg/CMservice <https://github.com/its-dirg/CMservice>)
and if there is any interest from this group to included it among our work items.
This was a project Rebecka/Samuel worked on back in 2016 and nothing has been
done with it since then.
Myself, I have no interest in the project.
— Roland
I've been looking at how/if
https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-impl…
affects pyFF or pyXMLSecurity.
First some basic facts/observations:
- pyFF deals with SAML metadata and not SAML messages so
the vuln described by the DUO team doesn't apply to pyFF.
- its easy to imagine SAML-metadata based attacks that
would be similar to this (if perhaps more difficult in
practice).
- pyXMLSecurity is is the default choice in pyFF but
not the default choice in pySAML2 for xml signature and
verification.
Ever since the wrapping attacks that came out a few years
ago pyXMLSecurity has taken the position that the library
should only return a /processed/ reference from validation.
The xmlsec.verfied function does precisely this and I
have done some initial unit-tests that seem to indicate
that it does so correctly - i.e the references returned
by xmlsec.verified do not contain in-text comments unless
#WithComment c14 method is used. However these are early
results and I'll need to do more poking around to be sure.
There are of course ways to shoot yourself in the foot
anyway. For instance if your code does
xml = parse_xml(some_text)
if xmlsec.verify(xml):
use_bits_from(xml)
Then you're up the creek without a paddle. Instead you
need to do
xml = parse_xml(some_text)
verified_xml = xmlsec.verified(xml)
if verified_xml:
use_bits_from(verified_xml)
Thats it for now... more later.
Cheers Leif
Cheers Leif
Hi all,
During the developers meeting, we'd talked in general terms about
potential IPR homes. One of the actions out of that was the request to
generate a list of requirements so we could figure out what we really
wanted from an IPR home and make our decisions from there.
Fortunately, some of that work has already been done by others as they
went through the same comparison process for the same reasons (and were
willing to share that info with me to get this conversation moving along).
I have the comparison in a Google drive page. You can view it here:
https://docs.google.com/spreadsheets/d/1dNR8clA_wKouhwonD8bIiyA5N2wMsorS8Uz…
I will set up a separate meeting to discuss this; I'd like to keep our
biweekly meetings focused on getting through the backlog of pull
requests for now. Expect a doodle poll on Monday!
-Heather
Hi everyone,
The problem we are trying to address is «the process to decide whether
to add or remove a project on idpy.org.» The following is a draft I
put together based on the discussion we had on the call at 09 Jan
2017. Feel free to change it and enchant it in any way that you think
will make the process smoother.
# Project addition
Accepting the project means accepting the responsibility to maintain
it, and push to fulfil its short and long term goals. How do we make
sure it can do this, and we can help? This is what I'll try to outline
bellow.
So, a project is proposed to be added:
## Proposal format
The first thing we need to define is the format of the proposal.
Ideally, I would like to see:
+ Introduction of the maintainer(s):
Introduction could be just a hello from the person in charge. and a
minimal message on that person's availability in relation to the
project development. We do not collect projects, we want the people
that develop those to keep doing that and have them become part of the
organisation and their project part of the ecosystem.
+ Project goals & future:
Project goals are in direct relation to the project's future. Their
relation with idpy.org goals are the first thing to make sure is
aligned.
+ How it relates to idpy.org:
Is there another project that is using the new one as a dependency or
enhancement? Is there a relation to a more generic AAI concept? We
want to know!
+ Current project state:
- How far is the project from its goals?
- What are the problems it is facing (technical / community / dedication-time)?
+ Project metadata:
- URL to project website
- URL to project source code
- URL to project ticketing-system (issue tracker)
- URL to project license
- Communication channels (mailing-list, slack, irc, etc)
While all these might seem like too much bureaucracy, each of these
sections could be a couple of lines or even mangled together in a
couple of paragraphs.
Once we have such a proposal we should evaluate the project and come
to a conclusion. Bellow are some of the aspects I propose we must take
into account.
## Technical quality
Is there an architecture document?
How much work is needed to be incorporated with our coding standards
and practices?
Does it have (updated) documentation?
Does it have tests?
Does it have a CI setup?
What other projects does it depend on?
What is going on in the ticketing system (number of bugs and general activity)?
## People quality
This is a lot harder to judge, but very important. The community is
vital to the organisation's lifecycle. Growing the organisation means
growing the community and accepting more people in its core. While we
cannot prevent people from fighting over (many times even
non-)technical aspects, we can make a priority to make the community
feel safe. Thus we must take notice of how communicative the new
project's maintainers are, what the project's culture is, and whether
this fits to the form of the environment we want to create - an
environment where people are polite and try to understand rather than
dominate.
This is of course twofold - it is the same thing the other way around.
We are dealing with work done by other people. We must respect that
and be grateful that they put time in this.
In simpler terms, it is better to not reply to an
issue/question/email, if one is irritated, in hurry or stressed. None
should feel forced to answer or pressured to keep with others' pace.
## Organisation stability
While a project may fit perfectly, we should always keep in mind what
the organisation's pace is, and how many things it can process at the
same time. Growing should come in a steady fashion to avoid people
getting overwhelmed. Enthusiasm is great and needed but should be kept
in reason with pragmatism.
There is always a right time to do more. We should not be afraid to
reject even good looking matches, as doing so does not mean that there
is no way of even having that chance again.
The same way we require a project to be in a certain form to be
accepted, the same requirement is on us to be in a state to accept
that project.
To put it in another way, the organisation should help its project
move forward, and give tools and services to the community. If it is
in a state that is struggling, then accepting a new project does not
help neither party.
## Discussion and consensus
Everyone should do their homework, go through this list and then
decide whether they think it is a good idea and timing to accept the
project. While a message outlining their basic reasoning is wanted, a
simple +1 or -1 should suffice.
Keep in mind that a "-1" is *important to express*. It is very common
to only see +1 replies, accept the new thing, and then being into a
situation where many people do not like the new state but never
expressed it. In the long run, this will lead to problems within the
organisation.
My view on this is that it is many times harder to express rejection
as it seems to place people in a position where they have to explain
themselves. I reject this as a belief, and consider both +1 and -1
equally important and available with no justification. I cannot
understand how a +1 should be self explanatory, while -1 should not.
So I urge people to freely chose what they think is best for the
organisation at the time of the proposal and do express themselves.
## Process duration
We should put a limit on the overall process duration and at some
point come to a final conclusion. I do not have a good estimate, I'd
guess 4 weeks should be enough, even for people who may want to have a
say but are away on vacation etc.
Needless to say, that the community members must trust the decisions
of other members, and as such should not demand that they are present
in every process. As pragmatists (are we?), rough consensus is what we
are striving for - unanimity is pretty hard to achieve.
## Aftermath
- Set a member responsible for the overall supervision of the project
(the existing maintainer(s) most probably).
- Announce the conclusion to our communication channels
(announce-mailing-list, slack, website, blog, twitter, etc) whatever
the conclusion is. Transparency is important for the community as it
builds trust and portrays a certain level of maturity.
- Incorporate the code: Add project under the github organisation
- Incorporate the people: Add members to the appropriate lists and
other tools (github policies, travis, slack channels etc)
- Open appropriate issues to integrate the new project with existing projects.
- Add to the projects roadmap anything related to the organisation or
things that come up in the proposal discussion.
# Project removal
Removing an existing project should follow the same process. The
difference is that if decided, the actual process needs planning. The
project might be a dependency or part of another project, and as such
it should either be replaced (no functionality lost) or removed in way
that users and services are not affected.
The same way we want a steady removal of that project, the same thing
will be wanted by other people that could be using this. We should
reach out to project we know that they are using that component and
ask them to either adopt it, or replace it.
A good experiment for this will be the replacement of pyoidc/oic from
satosa (if we decide this) and the integration with the new libs by
Roland and Google.
That's all for now. Do tell me what you think and as said before, feel
free to alter and enhance this.
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
Hi all,
At this point, we have a general discussion list for the umbrella
project that is Identity Python (idpy-discuss at lists.sunet.se). We also
have a specific dev list for Satosa (satosa-dev at lists.sunet.se). Given
we have formally accepted pyff, pysaml, and pyXMLSecurity into the idpy
project, can we create targeted dev lists for them as well? Or do those
lists already exist?
Thanks!
Heather
Attendees:
Ivan, Heather, Scott, John
Action item:
* Heather to work with Ivan to create a shared admin account to manage
mailing list, slack, other tools as needed
* Heather to create templates for PRs and Issues
* Heather to add notes as needed to the PRs from today’s call
* Scott will re-run the tests for pyFF PR 118; if the test is actually
broken, Scott will write up an issue that there is a bad test.
0. Agenda bash
Set up an admin account to manage mailing list and slack.
1. Establishing a PR template -
https://github.com/blog/2111-issue-and-pull-request-templates
* Do we want to have a similar template for issues?
Yes, we want templates for both.
Two sections for a PR template: what problem are you trying to solve,
and what the solution is and why that solution and not something else
For issues: Include a pointer to documentation, what version is being
used, what branch are you using
2. Satosa pull requests (no more than 10 minutes each) -
https://github.com/IdentityPython/SATOSA
- #172 - fairly self contained. Ivan has’t tested the code yet. He
will do that, and assuming the code passes tests, will merge it. Scott
notes that the code is being used in production on a particular project
off a different branch.
- #137 - from Ivan’s email "needs to be refactored - part of it is
already there, part of it is useful, part of it belongs to pysaml2”.
Some of this needs to move to pySAML, and other changes are already made
by other commits. What’s missing is what the title says: adding the
nameID format. That’s easy to do, and something Ivan can do fairly
easily. There is a checkbox when you create a pull request that would
allow the project developer to change the commit. That was set for this,
so Ivan will directly edit the pull request.
- #166 - Ivan would like to reproduce this to figure out what
exactly is the problem. What is being done in the PR is capture every
exception and presenting an error, which might not be the best path
forward. This is not a fix, just a presentation of errors. Ask Rainer to
create a test for this issue so we can understand the full failure mode.
John adding that as a comment to the PR, Scott will add a request for
clarification to the Issue.
- #171 - Ivan has to review this one in more detail. This one could
very much use the template to explain what and why this PR exists. There
is no description around how this works or why it’s built this way.
3. pySAML2 - still needs to move to the IdentityPython repository
- #483 Enable signature verification for MDQ - This seems to be
fine. It does what it needs to do. It is related to Issue 448. Scott
will be writing some tests. When that is done, this and 485 can be merged.
- #485 Add want_assertions_or_response_signed functionality - Ivan
still needs to review this one. Scott reports this one is problematic -
this is the only way Scott can see to make this happen given how the
code is currently structured. It is ugly, but no obvious other way to do
it without a heavy refactor or the the pySAML code base. Scott will be
writing tests on this one (priority over 483)
4. AOB
pyFF: Failure of Travis CI build - what do we need to do about this
error? Someone needs to go back and review/fix the test that is causing
this to fail. Fixing the test should be a separate pull request. Scott
will re-run the tests for pyFF PR 118; if the test is actually broken,
Scott will write up an issue that there is a bad test.
