You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This original issue #1004 describes the problem with returning a tuple from __setstate__, so #1009 removed it. But once new release was actually cut #1085 reported that this actually broke a lot of stuff, and support for unpickling from tuple was added back in.
The problem with this is that anyone who stores pickled representations of their objects with code using versions prior to 22.2 is till vulnerable to the issue described in #1004 ( potentially assigning a wrong value to a an attribute on unpickle).
Let's try to really remove the support for tuple on deserialisation in a newer version (best is 22.3) once more people have had a chance to re-process their data using newer code.
I don't think we can ever guarantee that no one in the world will be hit by the issue like #1085 again, but at leas at this point there will be an officially released version (the first one containing #1085) that can be used to re-process the data once the support is gone from trunk.
Storing data in long term storage remains a bad idea that maybe Python official docs could do more to warn people about alongside the security concerns (which are very prominent in the docs).
The text was updated successfully, but these errors were encountered:
This original issue #1004 describes the problem with returning a tuple from
__setstate__
, so #1009 removed it. But once new release was actually cut #1085 reported that this actually broke a lot of stuff, and support for unpickling from tuple was added back in.The problem with this is that anyone who stores pickled representations of their objects with code using versions prior to 22.2 is till vulnerable to the issue described in #1004 ( potentially assigning a wrong value to a an attribute on unpickle).
Let's try to really remove the support for tuple on deserialisation in a newer version (best is 22.3) once more people have had a chance to re-process their data using newer code.
I don't think we can ever guarantee that no one in the world will be hit by the issue like #1085 again, but at leas at this point there will be an officially released version (the first one containing #1085) that can be used to re-process the data once the support is gone from trunk.
Storing data in long term storage remains a bad idea that maybe Python official docs could do more to warn people about alongside the security concerns (which are very prominent in the docs).
The text was updated successfully, but these errors were encountered: