contrib.markup deprecation

[Luke Plant]

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/

[Paul McMillan]

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

> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>

[ptone]

On Saturday, October 13, 2012 10:35:10 AM UTC-7, Luke Plant 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.

That seems entirely reasonable, but if it is the convention, I wasn't aware of it - sorry.  The ticket got some relatively quick traction just in trac.

This goes to the heart of defining the purpose, current and future, of contrib.

I believe in shrinking in contrib - but I do think it has to be done mindfully.

There was some *brief* conversation at DjangoCon about phasing contrib.markup out in a fashion similar to localflavor - but it seemed to end unresolved in a discussion of submodules, namespace, and other imperfect solutions.

On this issue of markup I do think the answer should lie in a strong 3rd party option. 

 I agree we could provide better migration docs and maybe we shouldn't do an accelerated deprecation to give a better migration option the chance to be developed?

-Preston

[Waylan Limberg]

On Sat, Oct 13, 2012 at 1:34 PM, Luke Plant <L.Pla...@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 most recent discussion of this on the list was here (although I do remember it being mentioned previously):

https://groups.google.com/forum/#!msg/django-developers/tRpwMudkCfo/pVIPk8QvRusJ

Luke, perhaps you missed it as it was about markdown. I link to it now because it includes my take (as the maintainer of the markdown lib) of the current markdown implementation in contrib.markup.

Someone else in this discussion mentioned that the markdown implementation is not safe. I believe that it the case with all "true" markdown implementations.

--
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg