Hi Leif,
I added 2 pipes to buildin.py:
- publish_html creates static HTML views of IDPs and SPs, using XSLT based on Peter Schober’s alternative to MET;
- publish_split: similar to store, but added validUntil and creates signed XML-file per EntityDescriptor. This can be consumed dynamically by ADFS in an IDP role.
I put it directly into buildin.py because it shares some code with the sign pipe. Is this viable from your PoV - if yes, I would make an PR.
Cheers, Rainer
Hi all,
being part of Commons Conservancy brought up yet another subject,
which is whether we should add a header with license information in
every file in the projects under idpy. This is not something done in
an abstract way, there is a specific format modelling this information
(see https://spdx.org/ and https://reuse.software/ - more specifically
https://reuse.software/practices/2.0/) Still, I find it problematic.
We want to open up the question to the wider community and consider
their thoughts on this. The forwarded message below is discussing this
subject. You can see the question we posed, the answer we got and my
comments. Feel free to tell us what you think on this.
---------- Forwarded message ---------
Date: Thu, 16 May 2019 at 09:56
> ---------- Forwarded message ----------
> Date: May 8, 2019, 8:15 AM -0700
>
> > Why does CC think having a single license file per project is
> > insufficient? Our thought is that if we can avoid adding a header to
> > every single file, that would be nice, esp. given we already have this
> > info in the license file and we have the Note Well.
>
>
> this is not just our opinion, but something that is an industry and
> community standard for legal compliance these days. When companies like
> Siemens, Samsung or Honeywell use some code in one of the hundreds or
> thousands of devices and systems in their product line, they need to be
> able to provide the correct license and a download of the exact version.
> This means machine readability too.
>
I've actually observed the opposite of that. Communities abandon the
"license in every file" model, and just use a single LICENSE file in
the root of the project. The LICENSE file contains license
information, that is, it is not a single license but it has exception
sections and so on.
> To quote from https://reuse.software/practices/2.0/ :
>
> Scroll to the section "2. Include a copyright notice and license in each
> file"...
>
> "Source code files are often reused across multiple projects, taken from
> their origin and repurposed, or otherwise end up in repositories where
> they are separate from its origin. You should therefore ensure that all
> files in your project have a comment header that convey that file’s
> copyright and license information: Who are the copyright holders and
> under which license(s) do they release the file?
>
Continuing from above, the standardization of package-management
formats and tools has helped exactly with that: to avoid distribution
of single files, and instead provide packages and modules. It is bad
practice and considered a hack to copy files. Nobody liked that model
and everyone is moving away; it is unstructured, it becomes
unmanageable and it will cause problems.
> It is highly recommended that you keep the format of these headers
> consistent across your files. It is important, however, that you do not
> remove any information from headers in files of which you are not the
> sole author.
>
> You must convey the license information of your source code file in a
> standardised way, so that computers can interpret it. You can do this
> with an SPDX-License-Identifier tag followed by an SPDX expression
> defined by the SPDX specifications."
>
> (the text goes on for a while after this, to clarify the point but this
> is the basic gist of it)
>
> There is a nice Python tool to check:
>
> https://github.com/fsfe/reuse-tool
>
> I hope this makes sense
>
Well, it does not make complete sense. We're talking about licensing a
project. A project is not just code; there are data files (html, xml,
yaml, json files), binary files (archives/zip, images, audio, video,
etc), text files (configs, ini-files, etc) all "not-code". How do you
mark those files? Does the LICENSE file need a license-header? The
json format does not define comments, how do you add a header there?
If a binary file does not get a license header, why should a file with
code get one?
I would expect there to be a way to have the needed information
unified. If the files themselves cannot provide this information it
has to be external; thus the LICENSE file. If someone is worried about
somebody else re-using single files that do not have license
information (a python file, a png image, etc) there is really nothing
you can do (the DRM industry has been trying to solve for a long time;
and still your best bet is "social DRM").
Since, we're developing on open source with a permissive license, even
if someone does that, should we be happy that someone is actually
using what we built or sad that the files they copied did not have a
license header? And if they include the license information of that
copied file in their project's LICENSE file, is this solved?
Having pointed these contradictions, I am thinking that the "license
in every file" model seems to be a step backwards. It is introducing
overhead and does not really solve the problem, while at the same time
it enables a culture of bad practice (copying files around).
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
Attendees
Heather, Ivan, JohnP, Hannah Sebuliba, Johan
Regrets:
Scott, Roland
0 - Agenda bash
New Incubator - GEANT has a program where they sponsor a team to do a project that will serve as the basis to do something bigger. Niels suggested that we use the incubator program to set up a matrix of idpy projects to determine if the communication is working properly between all the different services. Ivan will send the suggestion about this to the list. The trick will be that it's often the configuration, not the software itself, that causes the problems. The matrix would need to be more about common configurations rather than just a default deployment, but it's an open question as to how what configurations we would choose. Ivan will follow up with initial meetings to see if this can be applied to us, but this won't be a high priority and someone else may want to eventually take point.
What if we started limiting support to specific profiles of configuration? The challenge with that is we don't really know all the ways that idpy apps and libraries are used. If we do go down this path, we'll need to document carefully because it will impact what we test for, what issues are valid, etc.
1 - Governance policy updates
Board has approved the updated policies, with a few minor changes (specifying ideal test coverage at 80%, requesting that the common incident handling policy is followed)
https://github.com/IdentityPython/Governance
2 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
No update
b. Satosa - https://github.com/IdentityPython/SATOSA
New release expected soon. We have a new contributor to the code base.
• https://github.com/IdentityPython/SATOSA/pull/354 - will be a breaking change for OIDC plugins; see documentation
• will be some other updates to various microservices
c. pySAML2 - https://github.com/IdentityPython/pysaml2
Has just about finished the code that will let us update to new algorithms. Ivan will merge the PR (https://github.com/IdentityPython/pysaml2/pull/778) soon, set up some new GitHub actions (first time we'll be using these) and cut a new release.
Several people are working in the same part of the code, so we need to come to some conclusion on the crypto pieces. Ivan will be reviewing the different PRs and figuring out what and how to merge the ideas if not the exact code.
• https://github.com/IdentityPython/pysaml2/pull/781
• https://github.com/IdentityPython/pysaml2/pull/660
• https://github.com/IdentityPython/pysaml2/pull/787
Test Suite under development by Giuseppe: https://github.com/peppelinux/spid-sp-test. This could serve as a way to start doing integration tests. The tests make certain assumptions, which feeds the conversation about having specific support profiles (see Agenda Bash - New Incubator discussion).
Next up for pySAML2:
1. More work around signing and encryption to add lists of allowed/disallowed algorithms
2. Creating a python-based signing/encryption library (replacing xmlsec1)
3. Changing the base of pySAML2 using a proper parser and possibly using types (idea introduced by Davide Brunato)
d. pyFF - https://github.com/IdentityPython/pyFF
No update
Thanks! Heather
Attendees:
Ivan, Giuseppe, Heather, Hannah Sebuliba, John P, Roland
Regrets:
Scott
0 - Agenda bash
1 - Governance policy updates
• Joseph has transferred the djangosaml2 to the GitHub repository page
• idpy Board meeting next Thursday
2 - GitHub review
b. Satosa - https://github.com/IdentityPython/SATOSA
Merged a few things, but nothing major. We have a new person contributing to the code based, contributing new microservices and working with the OIDC backend.
• https://github.com/IdentityPython/SATOSA/pull/355 - feat: add support for the Scoping element and RequesterID in SAML2 backend
Question re: does SATOSA have support for SLO on the roadmap? Not right now, though Ivan recognizes we need to look at this. See also https://github.com/IdentityPython/SATOSA/issues/211. There are different types and methods to initiate logout, but it all comes down to a best-effort activity for the user.
c. pySAML2 - https://github.com/IdentityPython/pysaml2
Ivan has been looking at the PRs for both pySAML2 and Satosa and have merged some.
• https://github.com/IdentityPython/pysaml2/pull/757 - Handle all types of ACS endpoint specifications
• https://github.com/IdentityPython/pysaml2/pull/779 - Raise SAMLError on failure to parse a metadata file
• https://github.com/IdentityPython/pysaml2/pull/763 - Invalid Destination URL Exception Handling
• https://github.com/IdentityPython/pysaml2/pull/766 - InvalidAssertion Exception
• https://github.com/IdentityPython/pysaml2/pull/772 - Response with unvalued AudienceRestriction (Condition) Handling
• https://github.com/IdentityPython/pysaml2/pull/762 - Minor bug fix to metadata function in example IdP
Changes still under discussion:
• https://github.com/IdentityPython/pysaml2/pull/778 - [Strengthen Encryption] PySAML2 Encrypted Assertions now works with Shibboleth SP 3 - note that we will not be using RSA, but instead using RSA OAEP as generally recommended. Switching to RSA OAEP is a breaking change.
The main thing we need to work on more are the encryption pieces. More work needs to be done around signing, and how we configure metadata and internal processing about which algorithms we accept. This is close to being wrapped up, and then Ivan will focus on how to encrypt the payloads. Right now we depend on xmlsec1, writing files, etc. Given our recent security issues were a result of how xmlsec1 behaves, this whole set of functionality must change. We have all the pieces we need to do this ourselves, without relying on a library like xmlsec1. We can focus purely on something that meets the need and requirements of SAML.
eIDAS requires specific algorithms be supported, and those algorithms are not supported by xmlsec1. This is another issue for us. This will be a new security backend for pySAML2, and xmlsec1 will be kept as an option.
What about pyXMLsecurity (https://github.com/IdentityPython/pyXMLSecurity)? This is a side project. It was initially planned to be used by pySAML2 but it was never extended to include all the operations expected. It support signing and verification, but there is no encryption/decryption support, and even the signing needs more work. The code is messy. Some of Ivan's new ideas, though, will be taken from here (e.g., low level processes). We don't know if this code is being used by anyone in production.
d. pyFF - https://github.com/IdentityPython/pyFF
No update
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
Roland is waiting for Nikos to sign off on the OIDC endpoint. When Nikos signs off, the project will start using that new code and Roland will need to update the documentation.
The OIDF has raised the fee for doing certification. They continue to discuss whether open source implementations should be able to go through certification, the challenge being how to define "open source". OIDF is willing to waive the fee for Identity Python. Roland will not try to certify for FAPI (Finance) unless we hear of a financial institution that uses our code that would require it.
The OIDC Federation spec is an implementer's draft right now. Roland is working with Mike Jones to edit some pieces, but it is largely stable. Hoping to get the vote kicked off to bring it up to a standard level soon (next month or so).
3 - AOB
Reminder: Daylight Saving Time clock skew about to start. Our next call will be March 23 @ 13:00 UTC.
Thanks! Heather
