Hi Tim, Indeed I looked at the comments in the ticket and pull request. I don't feel like these changes provide a significant security improvement: - using JSONSerializer over PickleSerializer is only relevant if you are using any non-default configuration that allows session data to be tampered. Incidentally, the whole contrib.auth (project-default) mechanism is compromised in this case anyway, even if you use JSONSerializer. - using the raw JSONEncoder by default is not offering any significant security advantage over using an extended encoder. I feel like it's going to discourage coders to use JSONSerializer at all.
Pushing the community, as you say it, is a decision with a rather big impact and carries some responsibility. I understand this has been discussed and I respect that the core developers agreed on a decision. But I believe this decision didn't give a realistic weight to the impact on the community. Davide On Thursday, September 19, 2013 6:23:56 PM UTC+2, Tim Graham wrote: > > Hi Davide, > > Did you take a look at the design decisions as described in the ticket and > pull request? We made these decisions in order to push the community toward > developing more secure apps and the transition isn't expected to be > painless. We had several core developers review the patch and discuss the > decisions. It seems like you are asking us to reconsider, but you haven't > presented anything we haven't discussed. Would you like me to address > anything specific? > > Tim > > On Thursday, September 19, 2013 10:46:44 AM UTC-4, Davide Rizzo wrote: >> >> #20922 <https://code.djangoproject.com/ticket/20922> introduced the >> option to choose a custom session data serializer. The default option is to >> use the new JSONSerializer starting from 1.6, since using pickle would lead >> to a remote code execution vulnerability when session data is stored in >> cookies. >> >> While this can be considered a sensible security choice, it becomes >> inconvenient as the JSON encoder used by JSONSerializer is not the same >> used elsewhere in Django, as it only support basic data types: string, >> int/floats, booleans, nested dicts and lists, None. >> >> The inconvenience is breaking compatibility with all third party apps >> that rely on storing extended data types (such as those supported by >> DjangoJSONEncoder) with the default settings. Properly serializing datetime >> (possibly tz-aware) can be hard, and changing the default puts the burden >> on third party apps coders. >> >> They would have the option to either add two complexity layers (properly >> serializing/deserializing datetime objects, and not breaking compatibility >> with the previous versions of the same app), or to break compatibility with >> Django default settings. >> >> As an example of commonly used data types that can't be stored anymore >> with default settings: >> >> - datetime, timedelta objects (supported by DjangoJSONEncoder) >> - decimal objects (supported by DjangoJSONEncoder) >> - arbitrary binary strings >> - Geometry objects >> >> I think the option of reverting the default to pickle should be also >> considered. >> >> [[I originally posted this as >> #21124<https://code.djangoproject.com/ticket/21124>, >> where it was closed as not a bug. What follows is the response I got, for >> reference: >> >> by timo (core developer) >> >> Thanks for your thoughts. I think most of the points you've raised were >> discussed during the implementation of this, either on the ticket >> (#20922<https://code.djangoproject.com/ticket/20922>) >> or on the linked pull request<https://github.com/django/django/pull/1488> >> (or >> the documentation >> itself<https://docs.djangoproject.com/en/dev/topics/http/sessions/#session-serialization>). >> >> Could you please take a look at the discussion there if you haven't? If >> after reading that you still have disagreements, please raise the issue on >> django-developers rather than this ticket tracker. Thanks! >> >> Suggestions for documentations edits or additions would also be welcome. >> >> p.s. To address one of your points, one of the decisions was indeed to >> put the burden on third party app coders to serialize session data as >> simple data types like strings which would be compatible with JSON. We made >> this change to contrib.messages for example. >> ]] >> > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
