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
Hello everyone,
there has been a report on incident-response at idpy.org about a security
issue in PySaml2.
Alexey Sintsov and Yuri Goltsev from HERE Technologies reached out and
reported a XML Signature Wrapping (XSW) vulnerability. The issue
affects responses with signed assertions. PySaml2 can be tricked to
think that an assertion had been signed and use the assertion
information, when in reality the Signature points to another part of
the xml document that is controlled by another party.
The issue was assigned CVE-2020-5390 and is now fixed in the latest
pysaml2 release.
The relevant code commit that fixes is the issue:
https://github.com/IdentityPython/pysaml2/commit/5e9d5acbcd8ae45c4e736ac521…
Release v5.0.0 contains more changes, including:
- Add freshness period feature for MetaDataMDX
- Fix ipv6 validation to accommodate for addresses with brackets
- Fix xmlsec temporary files deletions
- Add method to get supported algorithms from metadata
- Add mdstore method to extract assurance certifications
- Add mdstore method to extract contact_person data
- Start dropping python2 support
Pointers to the release with changelog and more information, below:
- the relevant release commit:
https://github.com/IdentityPython/pysaml2/commit/f27c7e7a7010f83380566a219f…
- the github release:
https://github.com/IdentityPython/pysaml2/releases/tag/v5.0.0
- the pypi package:
https://pypi.org/project/pysaml2/5.0.0/
+ + + + + + + +
In more detail, regarding the XSW vulnerability:
libxml2 follows the xmldsig-core specification. The xmldsig
specification is way too
general. saml-core reuses the xmldsig specification, but constrains it to use of
specific facilities. The implementation of the SAML specification is
responsible to
enforce those constraints. libxml2/xmlsec1 are not aware of those
constraints and thus
process the document based on the full/general xmldsig rules.
What is happening is the following:
- xmldsig-core allows the signature-information and the data that was
signed to be in
different places. This works by setting the URI attribute of the
Reference element.
The URI attribute contains an optional identifier of the object
being signed. (see
"4.4.3 The Reference Element" --
https://www.w3.org/TR/xmldsig-core1/#sec-Reference)
This identifier is actually a pointer that can be defined in many
different ways; from
XPath expressions that need to be executed(!), to a full URL that
should be fetched(!)
in order to recalculate the signature.
- saml-core section "5.4 XML Signature Profile" defines constrains on
the xmldsig-core
facilities. It explicitly dictates that enveloped signatures are the
only signatures
allowed. This mean that:
* Assertion/RequestType/ResponseType elements must have an ID attribute
* signatures must have a single Reference element
* the Reference element must have a URI attribute
* the URI attribute contains an anchor
* the anchor points to the enclosing element's ID attribute
xmlsec1 does the right thing - it follows the reference URI pointer
and validates the
assertion. But, the pointer points to an assertion in another part of
the document; not
the assertion in which the signature is embedded/enveloped. SAML
processing thinks that
the signature is fine (that's what xmlsec1 said), and gets the
assertion data from the
assertion that contains the signature - but that assertion was never
validated. The
issue is that pysaml2 does not enforce the constrains on the signature
validation
facilities of xmldsig-core, that the saml-core spec defines.
The solution is simple; all we need is to make sure that assertions
with signatures (1)
contain one reference element that (2) has a URI attribute (3) that is
an anchor that
(4) points to the assertion in which the signature is embedded. If
those conditions are
met then we're good, otherwise we should fail the verification.
--
Ivan c00kiemon5ter Kanakarakis >:3
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
Hello everyone,
I have a problem with a "idp hinting" feature. I set in SP a SAML
AuthnRequest url, e.g.:
https://proxy.example.com/Saml2/sso/redirect?idphint=https%3A%2F%2Fidp.exam…
I have SATOSA 8.1.0 with a Discovery Service:
https://service.seamlessaccess.org/ds/ and a configuration of idp
hinting:
https://github.com/IdentityPython/SATOSA/blob/master/example/plugins/micros…
In satosa saml backend are metadata from eduGAIN. (For this example I
changed domain to "example.com")
After authentication request in SATOSA log is:
[2022-07-26 14:09:40,711] [ERROR] [saml2.request._verify]
https://proxy.example.com/Saml2/sso/redirect?idphint=https%3A%2F%2Fidp.exam…
not in ['https://proxy.example.com/Saml2/sso/redirect']
[2022-07-26 14:09:40,711] [ERROR] [satosa.base.run]
[urn:uuid:1f970493-c436-4d86-83a5-88162a2ca2a1] Uncaught exception
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line
240, in run
resp = self._run_bound_endpoint(context, spec)
File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line
180, in _run_bound_endpoint
return spec(context)
File
"/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line
100, in handle_authn_request
return self._handle_authn_request(context, binding_in, self.idp)
File
"/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line
195, in _handle_authn_request
req_info = idp.parse_authn_request(context.request["SAMLRequest"],
binding_in)
File "/usr/local/lib/python3.6/site-packages/saml2/server.py", line
244, in parse_authn_request
signature=signature)
File "/usr/local/lib/python3.6/site-packages/saml2/entity.py", line
1080, in _parse_request
_request.verify()
File "/usr/local/lib/python3.6/site-packages/saml2/request.py", line
157, in verify
return self._verify()
File "/usr/local/lib/python3.6/site-packages/saml2/request.py", line
144, in _verify
raise OtherError("Not destined for me!")
saml2.s_utils.OtherError: Not destined for me!
[2022-07-26 14:09:40,712] [ERROR] [satosa.proxy_server.__call__] Unknown
error
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line
240, in run
resp = self._run_bound_endpoint(context, spec)
File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line
180, in _run_bound_endpoint
return spec(context)
File
"/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line
100, in handle_authn_request
return self._handle_authn_request(context, binding_in, self.idp)
File
"/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line
195, in _handle_authn_request
req_info = idp.parse_authn_request(context.request["SAMLRequest"],
binding_in)
File "/usr/local/lib/python3.6/site-packages/saml2/server.py", line
244, in parse_authn_request
signature=signature)
File "/usr/local/lib/python3.6/site-packages/saml2/entity.py", line
1080, in _parse_request
_request.verify()
File "/usr/local/lib/python3.6/site-packages/saml2/request.py", line
157, in verify
return self._verify()
File "/usr/local/lib/python3.6/site-packages/saml2/request.py", line
144, in _verify
raise OtherError("Not destined for me!")
saml2.s_utils.OtherError: Not destined for me!
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/satosa/proxy_server.py",
line 148, in __call__
resp = self.run(context)
File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line
258, in run
raise SATOSAUnknownError("Unknown error") from err
satosa.exception.SATOSAUnknownError: Unknown error
Do you know the solution of the problem?
Best Regards,
Marcin Miłek
Hi all,
Is anyone planning to attend TechEx in December? If so, would there be any interest in an idpy workshop?
Thanks! Heather
---------- Forwarded message ----------
Date: Jul 5, 2022, 11:29 AM -0700
To: request(a)internet2.edu
>
> Colleagues,
>
> Please consider this the ‘official call’ for pre- and post-2022 Technology Exchange Tutorials and Workshops, to be held in Denver, December 5-8, at the Sheraton Denver Downtown. Please take a few minutes to read the information below before submitting.
>
> Submission Deadline: Friday, July 15
>
> TERMS: For the purposes of Internet2 Anchor Events, we consider:
>
> • Tutorials: to be any gathering that is instructional in nature and often offers hands-on training (i.e., attendees take knowledge away vs. providing advice or expertise), often
> • Workshops: to be a gathering where the attendees engage in intensive discussion and activity on a particular subject or project to reach a goal (i.e., develop best-practices or recommendations, further knowledge around a grant-funded project, etc.).
>
>
> As such, fees are collected on all Tutorials that cover AV, and refreshments for attendees. Fees for Workshops are collected only at the direction of the Workshop submitter, who agrees to be cross-charged for any AV, and refreshments provided if they exceed the fees collected!
>
> Tutorials and Workshops are different from working meetings (the call for which will go out in mid-July). Registration for all tutorials and workshops will be integrated into the Technology Exchange registration process so please respond by the deadline to ensure we have all the necessary information to set this up prior to going live.
>
> Please submit your requests for:
>
> Tutorials at: meetings.internet2.edu/portal/meetings/2022-technology-exchange/proposals/n…
>
> Workshops at: app.smartsheet.com/b/form/07e229b6efbd49858882b95352e7bb68
>
>
> IMPORTANT NOTE: Before submitting your request(s), please consider the schedule detailed below.
>
>
> • Tutorials, workshops, and co-located meetings begin on MONDAY, December 5; core days for track content and working meetings run from Tuesday, December 6 through Thursday, December 8.
> • NOTE: Advance CAMP content continues until 12 Noon on FRIDAY, December 9
>
>
> Space is allocated on a ‘first come first serve’ basis and is not guaranteed. We have space available on Monday, December 5 and very limited space on Friday, December 9. In order to avoid scheduling on any of the core days for track content, we MAY be able to offer limited space on Sunday afternoon, December 7.
>
> If you aren't planning a workshop yourself but know that a colleague outside of Internet2 is interested, please notify meetings(a)internet2.edu so that we may contact that individual and determine their workshop requirements.
>
> Thanks,
> Kelly
>
>
> Kelly Faro - Manager, Community Events
> Internet2
> 100 Phoenix Drive, Suite 111
> Ann Arbor, MI 48108
> kelly(a)internet2.edu
> (734) 352-7080 Office
Attendees
Johan, Giuseppe, Ivan, Heather, Matthew
Regrets
Scott, Roland
0 - Agenda bash
1 - Administrivia
a. Summer call scheduling - next call 9 August 2022
b. mailing list/website
Ivan fixed the mailing list links, but it highlights that we should think about how the website is organized and consider making it look more like a documentation website along the lines of an FAQ; we can have each question and answer as a PR to the website. Some concern that the answers may be complicated, which won't translate well to a website, but we can try this out and see how it looks. Giuseppe has opened several issues that we can experiment with. Developers would prefer this kind of documentation in documentation files rather than elsewhere, but we don't have a documentation site suitable for this (yet).
2 - Frameworks and Storage
Re: storage - can either treat this as a key/value store--this gives the users the opportunity to choose their own backend storage--or we can require specific storage and then take advantage of their features, thus tying us into specific platforms.
Re: framework - Ivan is leaning towards FastAPI; it is gaining in popularity and is light/flexible. We will use its tutorials on how to connect to a database. There are choices in the ORM space. This would prevent us from using Reddis.
3 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
Need to consider having the develop branch as the default branch. Things are being merged to the wrong branch.
Roland is working on the refactoring of the RP code. Likely will see more work on this in September.
There are some PRs open around revocation and client credentials. For the client credentials, it's unusual because there is no user; the PR uses the client ID as the user ID.
b. Satosa - https://github.com/IdentityPython/SATOSA
Some new interest from people Giuseppe introduced at TNC22. Ivan has offered a list of where we need development assistance:
• Integration with some well known framework
• What I'm looking towards is FastAPI. Part of this work will be to redo how routing works.
• Being part of a wider community will automatically allow us to leverage existing tools, plugins and efforts but will also allow developers to work within a more familiar framework.
• improve observability
• Part of this work is to redo logging and introduce metrics. The idea to work on this through OpenTelemetry but parts of the python lib are still experimental.
• Schema for configuration and requests
• At the moment we rely on hand-written documentation which is not always updated. The idea is to introduce a schema for the configuration from which we can also generate documentation, tests, and additionally automatically load the files and derive the expected values with proper errors if something fails.
• Improve documentation
• Describe how the different modules work and how they all tie together.
• Add graphs and flow diagrams to convey the bigger picture but also certain aspects of the internals.
• Storage backend abstraction
• Introduce an API to hide communication with databases, the filesystem and the current storage we have, which is HTTP cookies. Along with that, the state handling should be revisited and maybe redesigned to properly cover the different usages.
AEGID (sp?) in Italy has started using Satosa to act as the proxy between Italian infrastructure and eIDAS.
Satosa image that Matthew created is going to be the default image.
Changes around the cookies have not proceeded yet.
c. pySAML2 - https://github.com/IdentityPython/pysaml2
Big changes coming up on formatting (not functionality). Important parts are the make file and config; will be using poetry. Expect to submit the MR in the next week or so.
pySAML2 includes XML templates via manifests. When we switch to poetry, we will need to make sure that these files are properly included.
re: the project to replace xmlsec1, Ivan is still working on that. Needs to write the tests for the new code.
pySAML2 is on the top 1% of packages downloaded from pypy.
d. Any other project (pyFF, djangosaml2, etc)
new djangosaml2 release earlier this month. Now compliant with latest releases of django; dropped some features that are no longer required. (https://github.com/IdentityPython/djangosaml2/releases/tag/v1.5.1)
4 - AOB
OIDF and idpy - is there an opportunity to share something wrt compliance testing around OIDC Federation?
https://github.com/oauthstuff/draft-selective-disclosure-jwt - Guiseppe has started contribute to this draft. Should we consider splitting the code in our documentation from the specification?
SSI work? Ivan still has the task to go through the requirements and consider how we can build a new library in idpy. Remember to review https://ted.europa.eu/udl?uri=TED:NOTICE:309685-2022:TEXT:EN:HTML&src=0 for the requirements of a reference implementation.
Thanks! Heather
