[Idpy-discuss] Agenda: idpy developers meeting, 4 September 2018

Hey all, Here are some quick notes from today's call. If I forgot anything, feel free to add it ;) The easiest way seems to be adding and maintaining an AUTHORS(.md, .rst, .txt, ..) file. Some projects name this file CONTRIBUTORS and then others MAINTAINERS. There doesn't seem to be any standard around this issue. The most relevant text discussing this seems to be this part[0] by opensource.guide. GNU[1][2][3] has some recommendations and google[4][5] too, while both get into the discussion regarding CLA and Copyrights. [0]: https://opensource.guide/how-to-contribute/#anatomy-of-an-open-source-proje… [1]: https://www.gnu.org/prep/maintain/maintain.html#Recording-Contributors [2]: https://www.gnu.org/prep/maintain/maintain.html#Copyright-Notices [3]: https://www.gnu.org/prep/maintain/maintain.html#Crediting-Authors [4]: https://opensource.google.com/docs/releasing/contributions/ [5]: https://opensource.google.com/docs/releasing/authors/ The discussion did not add new ideas than those posted on the list earlier[6][7][8][9]. Developing using `pip install -e .` and using gunicorn with the `--reload` option make for most of the tricks needed to have an efficient development environment. [6]: https://lists.sunet.se/pipermail/idpy-discuss/2018-August/000254.html [7]: https://lists.sunet.se/pipermail/idpy-discuss/2018-August/000255.html [8]: https://lists.sunet.se/pipermail/idpy-discuss/2018-August/000257.html [9]: https://lists.sunet.se/pipermail/idpy-discuss/2018-August/000258.html This was an issue raised by Scott[10]. Part of the SAMLMirrorFrontend was leaking logic to the saml backend. This has been address by PR#191 [11] and once Scott approves this will be merged. I also plan to merge #190, #176 and #137 (with the changes on my branch) and release a new version. [10]: https://lists.sunet.se/pipermail/idpy-discuss/2018-August/000250.html [11]: https://github.com/IdentityPython/SATOSA/pull/191 There was a new minor pysaml2 release[12] the previous week. Some changes described at the changelog; nothing very big or new but incremental fixes that should be readily available. One particular commit[13] is a fix for a test that started failing. The test depends on the real time to figure out if a response is valid by checking if it has been issued within a certain time period. Similar tests may start failing at some point in the future and we should keep an eye for those. The fix is to mock time and make the test-case believe the current time is the one we've chosen. That way we are in control on how the test behaves. [12]: https://github.com/IdentityPython/pysaml2/releases/tag/v4.6.1 [13]: https://github.com/IdentityPython/pysaml2/commit/5a844536d7074b1c2fe111515b… With @sklemer1's work[14], pyXMLSecurity is now updated to make use of the pyca/cryptography[15] library, removing all the custom cryptographic code that wasn't being updated. Among the nice security implications this has, it also enables an easier transition to support Python3. Thanks @sklemer ;) [14]: https://github.com/IdentityPython/pyXMLSecurity/pull/41 [15]: https://cryptography.io * Additional item #1 regarding SATOSA frontends: Scott is developing a new frontend similar to how SAMLMirrorFrontend works. (I will not describe here the concept as I haven't taken many notes, but it is not very important to the question asked) Scott asked whether there should be an abstraction where code between the SAMLMirrorFrontend and the new frontend could be shared. This has been raised before in another context. I'll paste here my (long) answer for anyone interested. === Question === There is a common pattern implement almost by all micro_services: - Read the configuration file - Check the entity id of the SP - Override default configuration if there is SP specific configuration This is 30-40 lines of code that is repeated in almost each micro_service. === Answer === There are two ways to share code: either the code is grouped in a library, or the code is part of a framework. 1. library code: Sharing code through a library means an additional package is created that contains common functionality (whether it is classes or functions). Any service that needs that functionality imports and uses the package. 2. framework code: The difference with the library code is that inside a framework, the functionality is already there; nothing needs to be imported. There are two possibilities that fill the role of a framework: a) SATOSA itself, b) a common ancestor. For (a): SATOSA itself could provide the required functionality and all the service would need is to reach out to the corresponding method to do its work. This sounds nice, but it introduces a number of problems that I'll discuss below. For (b): A common ancestor would be a new class that is the parent of the services that need the specified functionality. The services reach out to the parent class and methods to ask for a functionality or an already computed value. Any sharing means coupling. Part of the redesign I am doing around how microservices are handled, is how to reduce coupling. I would prefer microservices to be independent from SATOSA itself. SATOSA defines an interface for the entry point of microservices and invokes each microservice passing over the things that the service may find useful. Additionally, any new shared functionality would need SATOSA to be modified to incorporate that new functionality. This new functionality would not help SATOSA but some set of microservices. By this thinking 2.a. is no go. Since, this is shared functionality between the microservices you use, the choice is between (1) and (2.b.). If I were to make this choice it would depend on whether the services are type-compatible; that is if there have an actual hierarchal relation. Can I swap one service for the other? If they do a completely different thing then there is no such relation and they should not have a common parent. Inverting this, if the parent cannot abstract the children it is a bad design. Generally, I avoid sharing code through inheritance. A library that defines a set of common utilities is much more flexible. Using a library would still mean that some things need to be repeated (the calls to the library functions), but the logic does not. This is a good thing. What should be shared is the logic, not the process. Any choice, still means coupling. A change in the parent class or the library could break any microservice, and needs every microservice that uses that functionality to be tested. One needs to make sure that the intention is the same, not just the lines of the code but what they try to express. Going forward, I am preparing a proposal on how to handle micro-services, where each micro-service is on its own package, it defines its own dependencies and configuration. With this in mind, I think the best choice is (1). If (2.b.) is chosen, then as the relation implies, the micro-service will be a package that includes all children and cannot be split. That is another way to think about whether a common ancestor is what you want. === EOF === * Additional item #2 regarding pyff: Martin has filled issue #150 [16] regarding no logo being shown on the discovery service search. Scott, having talked to Leif about this before, said that this is intentional in order to cut down the load caused by requesting the images. This may be revisited in the future. Martin suggestion was to remove the empty space that seems to be reserved for the logo to make that decision apparent in the interface. [16]: https://github.com/IdentityPython/pyFF/issues/150 * Additional item #3 regarding pyff: Martin mentioned issue #128 [17] (related to issue #139 [18]) regarding a bad default value for the google-maps APi-key. If no API-key is configured the script should not be injected and invoked. This needs a minor fix in the templates as has been done by surfnet on this commit[19] [17]: https://github.com/IdentityPython/pyFF/issues/128 [18]: https://github.com/IdentityPython/pyFF/issues/139 [19]: https://github.com/SURFscz/pyFF/commit/03541571f6f50c67188297cc0c2d70f60845… Martin may not be with us in the calls to come; time will tell. Everyone is welcome anytime. There is no obligation to always be present on the calls. The calls are made to keep the (currently small) community close, getting to know each other and interact in real time while going through updates about the projects or discussing planned changes and new ideas. I encourage people to express themselves, whether it is about a technical subject or not. Feedback to the process is also welcomed and I consider it of great value to keep the project moving forward in the right direction. Cheers, -- Ivan c00kiemon5ter Kanakarakis >:3