1.0.0 Removed

[mitsuhiko]

I’m sorry for the inconvenience caused but I missed that there was a signature change that made it into 1.0. I yanked the release now because this change had some cery bad consequences and yanking the release is less risky in comparison.

If someone already uses 1.0 roll back to 0.24 and set the hash algoritm to sha 512 if needed. Note though that it will be unlikely we switch to that algorithm going forward.

I will figure out a way forward over the weekend.

For more information see #111

[alexbecker]

Please do not yank already-released packages. Lots of tooling assumes that PyPI releases will never vanish, and when they do it causes nasty problems. I agree the change in default hash algorithm was unfortunate, but 1.0 is a major release and some of your users (my company, for one) have already upgraded and handled the change.

[mitsuhiko]

@alexbecker i understand it's unfortunate but pypi does not provide with a way to just hide a release. The issue is that even though you already handled the change, the change will be rolled back in future releases as well so that does not help you much. For all intends and purposes 0.24 with changes is what 1.x will become.

[alexbecker]

A less disruptive way to handle this would have been to immediately re-release 0.24 as 1.0.1, with a changelog explaining why.

[prometheanfire]

Yep, broke openstack ci too. http://logs.openstack.org/52/612252/8/check/requirements-tox-py27-check-uc/138a9ea/job-output.txt.gz#_2018-10-26_18_58_15_139922

I do agree that the proper way of handling it would be to release it as 1.0.1. If the change is rolled back in a future release then you release that as 2.0.0 semantic versioning exists for a reason.

[bsanders]

In general, the changes to various pallets projects have been causing breakage in the Stacki CI, too.

A couple weeks ago we went from itsdangerous to ItsDangerous. Why change the case of the name of an established package? A month or so ago the same change in name (click -> Click) broke our pipeline, too. This is now the third time in as many months we've had to track down why our builds started failing and traced it back to a pointless change in setup.py change in one of these packages.

[mitsuhiko]

@bsanders I understand the frustration. I'm sorry :(

[davidism]

1.1.0 has been released. It reverts to SHA-1, and adds a fallback mechanism to safely upgrade signing parameters in the future. It also reverts the package name to all lowercase "itsdangerous".

You can read a longer explanation here: https://palletsprojects.com/blog/itsdangerous-1-1-0-released/

[cuonglm]

@mitsuhiko @davidism flask app using itsdangerous session interface stop working after upgrading to 1.1.0.

Revert to 0.24 works.

class ItsdangerousSessionInterface(SessionInterface):
    session_class = ItsdangerousSession

    def get_serializer(self, app):
        if not app.secret_key:
            return None
        return URLSafeTimedSerializer(app.secret_key,
                                      signer_kwargs={'key_derivation': 'hmac'})

Something must be done for URLSafeTimedSerializer?

[davidism]

@Gnouc that's not enough information to go on. ItsDangerousSessionInterface is not part of Flask, it must be from some other code. SessionInterface does not have a get_serializer method. All Flask's tests still pass with itsdangerous 1.1.0. Also, the built-in session interface already uses key_derivation = 'hmac', which appears to be the only change in your code. You'll need to open a new ticket with the appropriate ammount of information demonstrating the issue.

[davidism]

Locking this because the issue is resolved. If you have a new issue, please open a new ticket.