cubicweb: Changelog

DeprecationWarning: The default pickle serializer is deprecated as of Pyramid 1.9 and it will be changed to use pyramid.session.JSONSerializer in version 2.0. Explicitly set the serializer to avoid future incompatibilities . See "Upcoming Changes to ISession in Pyramid 2.0" for more information about this change. As describe here https://docs.pylonsproject.org/projects/pyramid/en/1.10-branch/narr/sessions.html#pickle-session-deprecation use a serializer that fallback on pickle if needed to avoid impacting users.

[pyramid/enh] generate pyramid.ini "create" and on "pyramid" command if needed

DeprecationWarning: The SafeConfigParser class has been renamed to ConfigParser in Python 3.2. This alias will be removed in future versions. Use ConfigParser directly instead.

Account for new psycopg2 exception classes mapping From psycopg2 >= 2.8, specific exceptions are raised corresponding to postgresql errors. E.g. a CheckViolation exception is raised instead of a generic IntegrityError previously when a constraint violation occurs. The way we intercept database errors, especially for constraint violation, is not compliant with that because we do not catch subclasses of IntegrityError in native source's doexec() method. We fix this by checking for the presence of IntegrityError error in exception class's mro. This is still overcomplicated and clumsy, because we still use string comparison, but this is the best we can do as far as I know. (A better fix would be 'isinstance(ex, IntegrityError)' but we have no engine-independent error classes, so this is not possible. Something like sqlalchemy's DBAPI Errors [1] might help: https://docs.sqlalchemy.org/en/latest/errors.html#dbapi-errors)

[cubicweb-ctl] remove "cubicweb-ctl wsgi" command following pyramid standardization

Use secure hash algorithm in WebConfiguration.sign_text Fix: PendingDeprecationWarning: HMAC() without an explicit digestmod argument is deprecated. The default hash algorithm used by hmac.new is md5. As of today, md5 is so weak that it's the equivalent of plaintext and can't be considered to be secured at all. Therefor, we switch to a secure hash algorithm. The rational for choosing sha3_512 is: * the recommended algorithm is at least sha_256 * the stronger, the more secured and sha3_512 is the stronger available * thinking about the future this should keep this part of the code safe long enough before people think about checking it again You can read more about choosing a secure hash algorithm in the NIST recommendations https://csrc.nist.gov/Projects/Hash-Functions/NIST-Policy-on-Hash-Functions This code modification should normally be transparent since check_text_sign is exactly this code 'self.sign_text(text) == signature' and that sign_text is only used in combination with it. The only impact is that the hash is going to move from 32 char to 128 which might make html page a bit bigger and that sha3_512 is slow to compute (which is a good thing for security)