February 2018 - Idpy-discuss

by leifj＠sunet.se

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

6 years, 1 month

1
0
0 0

Doodle poll: idpy governance

by hlflanagan＠sphericalcowgroup.com

Hello all, As mentioned on an email last week, we need to have a discussion re: governance for idpy. The document we will use as the basis of our discussion is here: https://docs.google.com/spreadsheets/d/1dNR8clA_wKouhwonD8bIiyA5N2wMsorS8Uz… And the doodle poll to help us find a time is here: https://doodle.com/poll/pgnqhgys2wxgm3z5 Please fill out the poll by this Thursday (as calendars tend to fill up). Thanks!

6 years, 1 month

1
0
0 0

governance stuff

by hlflanagan＠sphericalcowgroup.com

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

6 years, 1 month

1
0
0 0

Proposal policy to add/remove projects on idpy.org

by ivan.kanak＠gmail.com

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

6 years, 1 month

6
6
0 0

Mailing lists for idpy

by hlflanagan＠sphericalcowgroup.com

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

6 years, 1 month

3
4
0 0

Coding style. Was: Re: Notes: idpy dev meeting, 16 January 2018

by ivan.kanak＠gmail.com

Hi all, > Alternatives to PEP 8 > > the Google Python Style Guide > (https://google.github.io/styleguide/pyguide.html) > flake8 > https://en.wikipedia.org/wiki/SOLID_(object-oriented_design) flake8[0] is a wrapper that is enforcing a coding style using PEP8, and additionally does code analysis using pyflakes to catch bugs (eg undeclared variables) or leftovers (eg unused variables). It integrates well with different IDEs and also with the Syntastic vim plugin[1]. This article[2] goes into some details about flake8, PEP8 and pyflakes. I would strongly recommend to start using flake8 and progressively make style-changes to the code. SOLID is not related to coding style directly, but more to the principles which form a program structure - how interfaces are built, how components are separated, etc PS: I haven't looked into google's styleguide yet. [0]: http://flake8.pycqa.org/en/latest/manpage.html [1]: https://github.com/vim-syntastic/syntastic [2]: https://blog.sideci.com/about-style-guide-of-python-and-linter-tool-pep8-py… Cheers, -- Ivan c00kiemon5ter Kanakarakis >:3

6 years, 1 month

3
9
0 0

Notes: idpy Dev call, 20 February 2018

by hlflanagan＠sphericalcowgroup.com

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.

6 years, 1 month

2
2
0 0

Invitation: Biweekly idpy Developers call @ Every 2 weeks from 6am to 7am on Tuesday except Tue Mar 6 6am (PST) (discuss@idpy.org)

by hlflanagan＠sphericalcowgroup.com

You have been invited to the following event. Title: Biweekly idpy Developers call When: Every 2 weeks from 6am to 7am on Tuesday except Tue Mar 6 6am Pacific Time Video call: https://plus.google.com/hangouts/_/sphericalcowgroup.com/discuss-hlflana <https://plus.google.com/hangouts/_/sphericalcowgroup.com/discuss-hlflana?hc…> Calendar: discuss at idpy.org Who: * hlflanagan at sphericalcowgroup.com - organizer * discuss at idpy.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=Xzg4cTQ0ZDIyNzEwa2FiO… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account discuss at idpy.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding

6 years, 1 month

1
0
0 0

Agenda and call logistics for today

by hlflanagan＠sphericalcowgroup.com

Hi all, Apologies for the lateness in getting this out. The mailing list software ate the original meeting invitation, which I hadn't realized until late last night. I've sent a revised invitation with the BlueJeans link to the list from my own account; that should make its way through. BlueJeans: https://bluejeans.com/655841213 Agenda 0. Agenda bash 1. Establishing a PR template - https://github.com/blog/2111-issue-and-pull-request-templates 2. Satosa pull requests (no more than 10 minutes each) - https://github.com/IdentityPython/SATOSA - #172 - #137 - #166 - #171 3. pySAML2 - still needs to move to the IdentityPython repository - #483 Enable signature verification for MDQ - #485 Add want_assertions_or_response_signed functionality 4. AOB

6 years, 1 month

2
1
0 0

Invitation: idpy developers call (biweekly) @ Every 2 weeks from 6am to 7am on Tuesday 24 times (PST) (discuss@idpy.org)

by hlflanagan＠sphericalcowgroup.com

You have been invited to the following event. Title: idpy developers call (biweekly) When: Every 2 weeks from 6am to 7am on Tuesday 24 times Pacific Time Where: https://bluejeans.com/655841213 Calendar: discuss at idpy.org Who: * hlflanagan at sphericalcowgroup.com - organizer * discuss at idpy.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=NWtrOGRldGlsamQxbW5ld… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account discuss at idpy.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding

6 years, 1 month

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Idpy-discuss February 2018