My primary concerns are that we: A) do not ship vulnerable code B) do not bundle new external libraries C) do not make misleading assertions about the security of the solutions we do provide
C was the primary motivator here - the python-markdown library does not seem to provide a mode where it is both useful and safe. If you're willing to do the work to make sure that all the template filters we ship are both useful and safe (or deprecated), I'd be in support of reversing the decision to deprecate the whole module. In the case of markdown, my personal preference would be to encourage the use of the sundown library. -Paul On Sat, Oct 13, 2012 at 1:34 PM, Luke Plant <l.plant...@cantab.net> wrote: > Hi all, > > https://code.djangoproject.com/ticket/18054 > > I just came across this, and it seems slightly hasty. Most deprecations > of entire contrib modules would require some discussion on django-devs, > I would have thought. > > The filters provided by this module are probably widely used, and I > think slightly better documentation of a migration route would be nice, > and some more explanation in the release notes. The nature of template > tags/filters like this is that they are necessarily glue code between > some functions and the Django template library, so it didn't seem that > inappropriate to me to have a contrib.markup module, any more than any > of the other contrib modules, even though they are relatively small > functions. > > Also, hundreds of developers implementing their own solutions doesn't > seem sensible. That's especially true as it is easy to get those > functions wrong. I think the current state leaves people more likely to > be vulnerable, because many people will botch together an insecure > solution - and encouraging people to use the markup libraries directly, > as the release notes do, will make that worse. > > For example, for restructured text, you need at least these settings to > be safe in a typical HTML/web app situation: > > { 'raw_enabled': False, > 'file_insertion_enabled': False > } > > (This is implied by the current Django docs, but it really ought to be > enforced by the code) > > To add further confusion, there are projects like django-rstify out > there, which has the same vulnerabilities, and also seems to be a bit > dead at the moment (github repo has disappeared). > > I'm happy to work on this to provide an external solution for > restructured text, but don't want to compete with django-rstify if I can > avoid it. > > I will invite Martin Mahner, the author of django-rstify to participate > in this thread. I think we should have recommendations for alternatives > for rendering markdown as well. > > Regards, > > Luke > > > -- > "Christ Jesus came in to the world to save sinners" (1 Timothy 1:15) > > Luke Plant || http://lukeplant.me.uk/ > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
