Hey list,
is there a specific reason that pyXMLSecurity maintains forked,
crippled down and slightly changed versions of pycrypto (abandoned) and
PyASN1 (with security changes in the upstream since forking)? From a
quick look it seems that it might be quiet easy to port it over to
PyCryptodome(x) which is maintained and itself a fork of pycrypto and
would bring back some speed optimized parts in c (that were cut
away when forking) as well as ECC that might get relevant in the coming
years. My main concern is about the long term security impact of a
self-maintained crypto module; speed is just a nice addition ;).
pkcs11 wouldn't be impacted by it and has to be kept separately.
Would patches/PR be welcome or just a waste of time?
Steffen
--
DFN-Verein Steffen Klemer
Alexanderplatz 1 +49 30 884299 307
10178 Berlin klemer at dfn.de
Fax: 030 88 42 99 370
http://www.dfn.de
Hey everyone,
At some earlier point we had a discussion about creating labels for
the github repositories so that we (and users) can put an order in the
issues and pull requests.
So, I went around some big and some small-but-trending repos on github
and using the github-api and a shell script I got two files: one has
the labels by repo, the other is a list of all labels sorted and
unique'd. The latter is the interesting one, and from a quick look,
the labels with a prefix (area, component, kind, needs, priority,
scope, topic, type) seem to be the interesting ones.
Do you think those are useful? Would someone like to pick some,
propose a list and then help labelling the existing open issues?
PS: On another note, the cpython labels include "CLA signed" and "CLA
not signed". Maybe we can use those if we go forward with that.
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
On Wed, 4 Apr 2018 at 11:42, Niels van Dijk <niels.vandijk at surfnet.nl> wrote:
>
> Hi all,
>
> I would like to find out what the licenses of *all* components and
> dependencies that make up SaToSa. Any suggestion to how to do that in an
> automated fashion?
>
> I could walk down the libraries manually in
> virtualenv/lib/python3.5/site-packages, but that is rather tedious and
> error prone. I also found some scripts to do this for me, however these
> seem to just report what is in use at the os/system level, not
> specifically for our virtualenv.
>
> Any suggestions, or a solution you may have used previously?
>
Also, related to:
[Idpy-discuss] SaToSa (and dependencies) licenses and copyright
https://lists.sunet.se/pipermail/idpy-discuss/2018-May/000161.html
I have been looking for ways to automate dependency tracking and
license compliance. Bellow is a list of tools that do that. If anyone
has tried any of the tools, feedback would be appreciated.
- FOSSA
https://fossa.io/
Managed dependency tracking and license compliance as a (paid)
service. From the FAQ:
> Do you offer discounts for non-commerical projects?
> If you are a non-profit, educational institution or based in open source, we offer special plans for your budget.
- Fossology
https://www.fossology.orghttps://github.com/fossology/fossology
Self-hosted; PHP/C; Free and Open Source; Supported by the Linux Foundation.
- scancode-toolkit
https://github.com/nexB/scancode-toolkit/wikihttps://github.com/nexB/scancode-toolkit/
Self-hosted; Python; Free and Open Source
- Licensee
http://ben.balter.com/licensee/https://github.com/benbalter/licensee
Self-hosted; Ruby; Free and Open Source
- Ninka
http://ninka.turingmachine.org/https://github.com/dmgerman/ninka
Self-hosted; Perl; Free and Open Source
( compares to a big list of predefined licenses:
https://github.com/dmgerman/ninka/tree/master/t/data/licenses )
- Speedy LIcense Checker
https://github.com/gerv/slic
Self-hosted; C; Free and Open Source
And on a side note, dependency vulnerability checkers:
- snyk
https://snyk.io/
Managed vulnerability checker as a (paid) service.
> Unlimited tests on open source projects
- Dependency Track
https://dependencytrack.org/https://github.com/DependencyTrack/dependency-trackhttps://www.owasp.org/index.php/OWASP_Dependency_Track_Project
Self-hosted; Java; Free and Open Source; Supported by OWASP
Hopefully, these will prove helpful to the community,
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
Hi,
On Wed, 11 Jul 2018 at 00:04, Schmidt, Michael <Michael.Schmidt at lrz.de> wrote:
> Even if the heavy stuff is done in the libs, could you tell some places of interest in the code? SATOSA has some content even without the libs. Maybe we could narrow the most important/critical down to some files and functions. It would be helpful to split the application into parts of "low" and "high" interest, if possible.
Some things on the top of my head (not in any specific priority):
- how external information is handled (configuration & data from the
network, replay attacks) [satosa_config, backends/, frontends/]
- how information is stored and transferred (cookie state and crypto:
key handling, IV, modes, algos) [state, backends/, frontends/]
- information leakage (logged data, stacktraces from exceptions,
unneeded data kept around) [logging_util, exception]
- can the internal attribute translation be tricked? [routing,
attribute_mapping]
> For the libs themselves, which are the most important ones? Is there some kind of documentation that states which dependencies are used for which purpose?
>
- pysaml2 implements the saml2 parts [fronends/saml, backends/saml,
metadata_creation]
https://github.com/IdentityPython/pysaml2
- pyop implements the oidc parts and in turn depends on other libs
https://github.com/IdentityPython/pyop
I hope these are useful pointers to start.
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
Attendees:
Ivan, Johan L., Heather, Christos, Rainer
0. Agenda bash
1. PR status and upcoming code releases
- Satosa (Satosa PRs - https://github.com/IdentityPython/SATOSA)
- Satosa microservices
- pySAML (https://github.com/IdentityPython/pysaml2)
- pyFF (https://github.com/IdentityPython/pyFF)
## satosa
- satosa configuration
https://github.com/IdentityPython/SATOSA/issues/184
A small fix, but had Ivan looking deeper into how to configure Satosa,
pySAML, etc. So, did a small rewrite (see
https://github.com/c00kiemon5ter/satosa/tree/refactor-parse-config (no
PR yet)). Part of the configuration is how we configure secrets and
microservices. See:
- where do configuration secrets go
https://github.com/IdentityPython/SATOSA/issues/167
See email about the environment variables. Note that the proposed fix
will result in having to restart Satosa when environment variables are
changed or set.
- satosa micro-services as plugins
planning to write about this to the list; for both front end and
back end modules. Doing this via “entry points”, part of setuptools.
Satosa will define group names, then each plug in can define its entry
point (which function will run when invoked). This will work for
backend (SP), frontend (IdP), request microservices, and response
microservices
- demo
- Ivan still needs to look into the ordering of micro services
(what order they need to run). Expect more info on the list
- pySAML will likely be handled the same way with the revised
configuration method
- an IE11 cookie issue that had been reported by Rainer
https://github.com/IdentityPython/SATOSA/issues/164https://github.com/IdentityPython/SATOSA/pull/166
These can be merged now. The idea behind the fix is that the state
module produces a satosa state error; it catches the new error and
exposes it so the state module can handle it.
After these changes, Satosa can have a new release. This will help the
security review team have a solid place to start.
## pysaml2
- new cryptography module for pysaml2
https://github.com/IdentityPython/pysaml2/pull/519https://github.com/IdentityPython/pysaml2/issues/417
A GitHub engineer indicated he was going to send a security warning to
everyone that had downloaded pySAML2. Ivan has come up with a fix, which
should fix the changes that the engineer asked for. Will be using
https://cryptography.io/en/latest/fernet/. Please review (especially if
you have any crypto experience).
- some deprecation warnings that surfaced
https://github.com/IdentityPython/pysaml2/pull/520
Changed in version python 3.7: DeprecationWarning is once again shown by
default when triggered directly by code in __main__.
One warning is still persisting if you use the defusedxml library; that
is not being maintained.
PR 498 - https://github.com/IdentityPython/pysaml2/pull/498 - Ivan is
also working on this one.
Ivan will be merging some of these by the end of this week or early next
week; there will be new releases for both pySAML and Satosa next week
(Wednesday or Thursday).
2. AOB
Security review update - Michael has asked a few questions about where
to start looking; Ivan will respond. Ivan will also be reviewing the
incident response guidelines before we make public.
Next call: 7 August 2018 (HF, Johan, Scott are unavailable) ; Ivan,
Christos are available. Ivan will make the call as to whether there are
enough items to hold a call.
Hi all,
No worries (yet), this is not about issues we have uncovered.
We have the opportunity however to have a team from the GEANT project
review the code of SaToSa. We already had them do a review of the
InAcademia service itself, now they can look at the code.
Their question is however, which areas would be of most interest to look
at, as just starting at line 1 is probably not a good idea ;)
Could you also express why these code areas are most sensitive?
* My initial guess would be the code that handles incoming OIDC and
SAML is most critical (so the backends). Including the bits that do
validation of these requests.
* Next the code that handles business logic of interpreting the
internal state and make the responses out of that
* Then the frontends
Does that make sense? Should we also include looking into the libraries
deeply?
In addition are you aware of additional reviews that were performed? If
so we would be really interested to learn about these.
Ofcause we will share the finding in a confidential way. By the way,
does idpy have some contingency rules about that already?
Thanks,
Niels
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nlwww.openconext.org
Date: Tuesday, 26 June 2018
Time: 06:00 PT | 09:00 ET | 15:00 GMT
https://bluejeans.com/655841213
Agenda:
0. Agenda bash
1. särimner and Satosa (managing Satosa as a service)
- how can SATOSA run behind a load balancer or with multiple gunicorn
workers, as unsolicited-requests need to be shared between the
processes
- if there is a way to gracefully restart/reload SATOSA to load a new
configuration
2. PR status
- Satosa (Satosa PRs - https://github.com/IdentityPython/SATOSA)
- Satosa microservices
- pySAML (https://github.com/IdentityPython/pysaml2)
- pyFF (https://github.com/IdentityPython/pyFF)
3. OIDC libraries
- pyOIDC
- fedOIDC*
4. Governance update and CLAs (or not)
5. AOB
Hey everyone,
TL:DR the world disagrees with the SAML2 spec regarding datetime representation.
I've been looking over issue #445
https://github.com/IdentityPython/pysaml2/issues/445
The user is using some software that generates a date like this:
2017-08-29T09:16:45.0631274-05:00
and this cannot be parsed by pysaml2.
Even if pysaml2 did parse this, internally it does not take into
account the timezone information. This means that comparing two dates
with different timezones will return incorrect results.
Dates can appear in a lot of attributes in SAML, but they are all
defined as of type `dateTime` datatype. This type is defined by XML
Schema Part 2: Datatypes Second Edition:
https://www.w3.org/TR/xmlschema-2/#dateTime
However, SAML2-core on section 1.3.3 specifies that:
> #### 1.3.3 Time Values
>
> All SAML time values have the type `xs:dateTime`, which is built in to the W3C XML Schema Datatypes specification [Schema2], and **MUST be expressed in UTC form, with no time zone component**.
>
> SAML system entities SHOULD NOT rely on time resolution finer than milliseconds. Implementations MUST NOT generate time instants that specify leap seconds.
>
Note that at this point there are three layers:
- SAML2-core, section 1.3.3
- XML Schema Part 2: section 3.2.7: dateTime datatype definition
- ISO-8601 spec
Each layer says it does exactly what the layer below does .. but with
some exceptions .. which usually make things *a lot* harder to manage.
This means that for SAML2 the `dateTime` datatype is assumed to be in
UTC and must not define a timezone. In the example case above, the
correct value would be:
2017-08-29T14:16:45.063
Notice that the fractional seconds have been stripped to 3 decimal
places to represent milliseconds (instead of 6 places which would mean
microseconds). The original representation had 7 decimal places which
means nanosecond precision which cannot be supported by the native
python types; numpy defines datetime64 which has greater precision
https://docs.scipy.org/doc/numpy-1.13.0/reference/arrays.datetime.html
So.. the question now becomes whether implementations actually hold
that promise, and if not, how do we handle it..
Looking around, all I can find is examples where dates are in the form:
2017-08-29T09:16:45Z
that is, they include 'Z' which means 'UTC', or '+00:00' or '-00:00'.
By including the timezone part they are invalid values.
The only place where I see correct values is the Wikipedia examples:
https://en.wikipedia.org/wiki/SAML_2.0
Looking at the history, these examples used to include 'Z', but have
been fixed by the following changeset:
https://en.wikipedia.org/w/index.php?title=SAML_2.0&type=revision&diff=5049…
which correctly summarises the change as "Removed time-zone component
from examples as this is prohibited (see section 1.3.3 of SAMLCore)".
How do we solve this?
## Plan A:
Follow the spec. Treat 'Z'-suffixed and other timezoned values as invalid.
This will probably break many running setups, as it seems other
implementations send dates including the 'Z'/UTC timezone suffix. (It
is still an open question whether implementations send other timezoned
values.)
## Plan B:
Ignore the spec, assume XML Schema dateTime datatype and accept
'Z'-suffixed values (along other timezoned values.)
This means things will continue as normal, but there is a case that we
now need to handle; comparing timezoned dates with untimezoned dates.
This is covered by the XML Schema spec in section 3.2.7.4 Order
relation on dateTime and defines the incomparable cases
https://www.w3.org/TR/xmlschema-2/#dateTime-order
## Plan C:
Do our own thing? Make things worse? Treat untimezoned dates as UTC?
I'm putting this here to see what everyone else has to say.
I'd love to go with Plan-A :) (What's the point of a specification
that none follows? I understand though, it is not a viable solution,
at least at the moment.)
In the meantime, I'll look into other implementations to figure out
what they do.
--
Ivan c00kiemon5ter Kanakarakis >:3
