Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-23 Thread Kamil
The name "mark_safe" unnecessarily exposes an implementation detail. People 
who misunderstand this API probably have no idea how this "marking" 
happens, it would make sense to name this after the *effect* it achieves: 
"don't process / escape me, I've been sanitized somewhere else".
Any of these would work: "no_escape", "dontescape", "sanitized_elsewhere", 
etc.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/268807b1-cfdf-4bf8-9c02-6e954bfa30e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-22 Thread Josh Smeaton
We could use the same name or just |trusted.

I'm not so concerned with the `safe` tag as it's already an adjective, but 
I would be ok with an alias for trusted also.

On Friday, 23 February 2018 08:24:50 UTC+11, Florian Apolloner wrote:
>
>
>
> On Thursday, February 22, 2018 at 9:52:04 PM UTC+1, Josh Smeaton wrote:
>>
>> Or, since this isn't a template tag (facepalm) 
>>
>
> Which raises a perfectly valid point: If we were to change this, we will 
> also need to come up with a new name for the "|safe"-filter. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f2a90aa8-87b8-476f-b72e-1b1c2e6fe4e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-22 Thread Florian Apolloner


On Thursday, February 22, 2018 at 9:52:04 PM UTC+1, Josh Smeaton wrote:
>
> Or, since this isn't a template tag (facepalm) 
>

Which raises a perfectly valid point: If we were to change this, we will 
also need to come up with a new name for the "|safe"-filter. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1aa8a64d-1bea-44d0-bfc0-3139e08ed039%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-22 Thread Josh Smeaton
Or, since this isn't a template tag (facepalm) 

trusted_html(m.content)
trust_html(m.content) 

On Friday, 23 February 2018 07:46:45 UTC+11, Josh Smeaton wrote:
>
> Yes I'm not a fan of the *dangerously...* names either. I'm still 
> somewhat wary of *trust_html* which is a *verb* and could still confuse 
> users in a similar way (does the api make it trustworthy?). I think I'd 
> prefer something more descriptive like *trusted_html*.
>
> {{ content|trusted_html }}
> vs
> {{ content|trust_html }}
>
> On Friday, 23 February 2018 01:07:12 UTC+11, Adam Johnson wrote:
>>
>> I am also in favour of a rename without deprecating the old name.
>>
>> I like 'trust_html' - it's still similarly short but as Tom says it 
>> implies more than 'mark_safe' does.
>>
>> On 22 February 2018 at 08:30, Tom Forbes  wrote:
>>
>>> What about just 'trust_html'? The dangerous part is quite context 
>>> dependent (and a bit of mouth-full), but at the core you are trusting the 
>>> HTML. Hopefully it follows that you should not trust html with user input 
>>> that hasn't been escaped.
>>>
>>>
>>> On 22 Feb 2018 13:10, "Anthony King"  wrote:
>>>
>>> I entirely agree with renaming `mark_safe`. Though it's name is correct, 
>>> it doesn't convey the gravity of what this actually does.
>>> However I'm unsure on the `dangerously_trust_html` name. It wouldn't be 
>>> dangerous to trust the literal "Some Content", for example.
>>>
>>> Perhaps it could be something a bit more explicit. `no_escape(string)`?
>>> This assumes that most have at least heard of escaping.
>>>
>>>
>>> On 22 February 2018 at 12:16, Josh Smeaton  wrote:
>>>
 The concern isn't overusing an API. It's not understanding the proper 
 use case for it.

 "mark safe" can sound like the API is doing sanitation so it can 
 encourage developers to use it incorrectly. I'm fairly sure I've done this 
 myself.

 The intended meaning is "this output is **already** safe" but the name 
 doesn't convey that meaning clearly enough.

 What the proposal is designed to do is convey the "I trust this output" 
 meaning of the API. I'm just wary of enforcing users to change code when 
 they already use the API correctly.

 On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:
>
> Yeah, I am also worried about the churn for no gain in my eyes. If 
> users overuse mark_safe, they will overuse dangerously_trust_html too…
>
> On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton 
> wrote:
>>
>> I agree that the names are misleading and we should probably provide 
>> better names. I'm wary of deprecating the old names because it'll create 
>> a 
>> lot of churn (some of which would be the right thing to do). Maybe we 
>> could 
>> just alias and warn when using the old name, leaving a decision on 
>> deprecation until some time in the future.
>>
>> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:
>>>
>>> In my experience, misuse of mark_safe() — i.e. marking stuff safe 
>>> which *isn’t* actually safe (e.g. HTML from a rich text input) — is 
>>> one of the biggest causes of XSS vulnerabilities in Django projects.
>>>
>>> The docs warn to be careful, but unfortunately I think Django devs 
>>> have just got too used to mark_safe() being *the way* to insert 
>>> HTML in a template. And it’s easy for something that was safe when it 
>>> was 
>>> authored (e.g. calling mark_safe() on a hard-coded string) to be 
>>> copied / repurposed / adapted into a case which is no longer be safe 
>>> (e.g. 
>>> that string replaced with a user-provided value).
>>>
>>> Some other frameworks use scary sounding names to help reinforce 
>>> that there are dangers around similar features, and that this isn’t 
>>> something you should use in everyday work — e.g. React’s 
>>> dangerouslySetInnerHTML.
>>>
>>> Relatedly, this topic 
>>> 
>>>  suggested 
>>> making it more explicit that mark_safe() refers to being safe for 
>>> use in *HTML* contexts (rather than JS, CSS, SQL, etc).
>>>
>>> Combining the two, it would be great if Django could rename 
>>> mark_safe() to dangerously_trust_html(), |safe to 
>>> |dangerously_trust_html, @csrf_exempt to @dangerously_csrf_exempt, 
>>> etc.
>>>
>>> Developers who know what they’re doing with these could then be 
>>> encouraged to create suitable wrappers which handle their use case 
>>> safely 
>>> internally — e.g.:
>>>
>>> @register.filter
>>> def sanitize_and_trust_html(value):
>>> # Safe because we sanitize before trusting
>>> return dangerously_trust_html(bleach.clean(value))
>>>
>>>
>>> -- 
 You 

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-22 Thread Tom Forbes
You're right, trusted_html is a better name than trust_html. I think either
is superior to mark_safe however.

Regarding deprecations, deprecating mark_safe will cause a lot of churn
even if the migration path is as simple as a rename. We should keep the old
alias around for a long time, but promote the new name wherever possible.

On 22 Feb 2018 20:46, "Josh Smeaton"  wrote:

Yes I'm not a fan of the *dangerously...* names either. I'm still somewhat
wary of *trust_html* which is a *verb* and could still confuse users in a
similar way (does the api make it trustworthy?). I think I'd prefer
something more descriptive like *trusted_html*.

{{ content|trusted_html }}
vs
{{ content|trust_html }}


On Friday, 23 February 2018 01:07:12 UTC+11, Adam Johnson wrote:

> I am also in favour of a rename without deprecating the old name.
>
> I like 'trust_html' - it's still similarly short but as Tom says it
> implies more than 'mark_safe' does.
>
> On 22 February 2018 at 08:30, Tom Forbes  wrote:
>
>> What about just 'trust_html'? The dangerous part is quite context
>> dependent (and a bit of mouth-full), but at the core you are trusting the
>> HTML. Hopefully it follows that you should not trust html with user input
>> that hasn't been escaped.
>>
>>
>> On 22 Feb 2018 13:10, "Anthony King"  wrote:
>>
>> I entirely agree with renaming `mark_safe`. Though it's name is correct,
>> it doesn't convey the gravity of what this actually does.
>> However I'm unsure on the `dangerously_trust_html` name. It wouldn't be
>> dangerous to trust the literal "Some Content", for example.
>>
>> Perhaps it could be something a bit more explicit. `no_escape(string)`?
>> This assumes that most have at least heard of escaping.
>>
>>
>> On 22 February 2018 at 12:16, Josh Smeaton  wrote:
>>
>>> The concern isn't overusing an API. It's not understanding the proper
>>> use case for it.
>>>
>>> "mark safe" can sound like the API is doing sanitation so it can
>>> encourage developers to use it incorrectly. I'm fairly sure I've done this
>>> myself.
>>>
>>> The intended meaning is "this output is **already** safe" but the name
>>> doesn't convey that meaning clearly enough.
>>>
>>> What the proposal is designed to do is convey the "I trust this output"
>>> meaning of the API. I'm just wary of enforcing users to change code when
>>> they already use the API correctly.
>>>
>>> On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:

 Yeah, I am also worried about the churn for no gain in my eyes. If
 users overuse mark_safe, they will overuse dangerously_trust_html too…

 On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton
 wrote:
>
> I agree that the names are misleading and we should probably provide
> better names. I'm wary of deprecating the old names because it'll create a
> lot of churn (some of which would be the right thing to do). Maybe we 
> could
> just alias and warn when using the old name, leaving a decision on
> deprecation until some time in the future.
>
> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:
>>
>> In my experience, misuse of mark_safe() — i.e. marking stuff safe
>> which *isn’t* actually safe (e.g. HTML from a rich text input) — is
>> one of the biggest causes of XSS vulnerabilities in Django projects.
>>
>> The docs warn to be careful, but unfortunately I think Django devs
>> have just got too used to mark_safe() being *the way* to insert HTML
>> in a template. And it’s easy for something that was safe when it was
>> authored (e.g. calling mark_safe() on a hard-coded string) to be
>> copied / repurposed / adapted into a case which is no longer be safe 
>> (e.g.
>> that string replaced with a user-provided value).
>>
>> Some other frameworks use scary sounding names to help reinforce that
>> there are dangers around similar features, and that this isn’t something
>> you should use in everyday work — e.g. React’s dangerouslySetInnerHTM
>> L.
>>
>> Relatedly, this topic
>> 
>>  suggested
>> making it more explicit that mark_safe() refers to being safe for
>> use in *HTML* contexts (rather than JS, CSS, SQL, etc).
>>
>> Combining the two, it would be great if Django could rename
>> mark_safe() to dangerously_trust_html(), |safe to
>> |dangerously_trust_html, @csrf_exempt to @dangerously_csrf_exempt,
>> etc.
>>
>> Developers who know what they’re doing with these could then be
>> encouraged to create suitable wrappers which handle their use case safely
>> internally — e.g.:
>>
>> @register.filter
>> def sanitize_and_trust_html(value):
>> # Safe because we sanitize before trusting
>> return 

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-22 Thread Josh Smeaton
Yes I'm not a fan of the *dangerously...* names either. I'm still somewhat 
wary of *trust_html* which is a *verb* and could still confuse users in a 
similar way (does the api make it trustworthy?). I think I'd prefer 
something more descriptive like *trusted_html*.

{{ content|trusted_html }}
vs
{{ content|trust_html }}

On Friday, 23 February 2018 01:07:12 UTC+11, Adam Johnson wrote:
>
> I am also in favour of a rename without deprecating the old name.
>
> I like 'trust_html' - it's still similarly short but as Tom says it 
> implies more than 'mark_safe' does.
>
> On 22 February 2018 at 08:30, Tom Forbes  
> wrote:
>
>> What about just 'trust_html'? The dangerous part is quite context 
>> dependent (and a bit of mouth-full), but at the core you are trusting the 
>> HTML. Hopefully it follows that you should not trust html with user input 
>> that hasn't been escaped.
>>
>>
>> On 22 Feb 2018 13:10, "Anthony King"  
>> wrote:
>>
>> I entirely agree with renaming `mark_safe`. Though it's name is correct, 
>> it doesn't convey the gravity of what this actually does.
>> However I'm unsure on the `dangerously_trust_html` name. It wouldn't be 
>> dangerous to trust the literal "Some Content", for example.
>>
>> Perhaps it could be something a bit more explicit. `no_escape(string)`?
>> This assumes that most have at least heard of escaping.
>>
>>
>> On 22 February 2018 at 12:16, Josh Smeaton > > wrote:
>>
>>> The concern isn't overusing an API. It's not understanding the proper 
>>> use case for it.
>>>
>>> "mark safe" can sound like the API is doing sanitation so it can 
>>> encourage developers to use it incorrectly. I'm fairly sure I've done this 
>>> myself.
>>>
>>> The intended meaning is "this output is **already** safe" but the name 
>>> doesn't convey that meaning clearly enough.
>>>
>>> What the proposal is designed to do is convey the "I trust this output" 
>>> meaning of the API. I'm just wary of enforcing users to change code when 
>>> they already use the API correctly.
>>>
>>> On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:

 Yeah, I am also worried about the churn for no gain in my eyes. If 
 users overuse mark_safe, they will overuse dangerously_trust_html too…

 On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton 
 wrote:
>
> I agree that the names are misleading and we should probably provide 
> better names. I'm wary of deprecating the old names because it'll create 
> a 
> lot of churn (some of which would be the right thing to do). Maybe we 
> could 
> just alias and warn when using the old name, leaving a decision on 
> deprecation until some time in the future.
>
> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:
>>
>> In my experience, misuse of mark_safe() — i.e. marking stuff safe 
>> which *isn’t* actually safe (e.g. HTML from a rich text input) — is 
>> one of the biggest causes of XSS vulnerabilities in Django projects.
>>
>> The docs warn to be careful, but unfortunately I think Django devs 
>> have just got too used to mark_safe() being *the way* to insert HTML 
>> in a template. And it’s easy for something that was safe when it was 
>> authored (e.g. calling mark_safe() on a hard-coded string) to be 
>> copied / repurposed / adapted into a case which is no longer be safe 
>> (e.g. 
>> that string replaced with a user-provided value).
>>
>> Some other frameworks use scary sounding names to help reinforce that 
>> there are dangers around similar features, and that this isn’t something 
>> you should use in everyday work — e.g. React’s 
>> dangerouslySetInnerHTML.
>>
>> Relatedly, this topic 
>> 
>>  suggested 
>> making it more explicit that mark_safe() refers to being safe for 
>> use in *HTML* contexts (rather than JS, CSS, SQL, etc).
>>
>> Combining the two, it would be great if Django could rename 
>> mark_safe() to dangerously_trust_html(), |safe to 
>> |dangerously_trust_html, @csrf_exempt to @dangerously_csrf_exempt, 
>> etc.
>>
>> Developers who know what they’re doing with these could then be 
>> encouraged to create suitable wrappers which handle their use case 
>> safely 
>> internally — e.g.:
>>
>> @register.filter
>> def sanitize_and_trust_html(value):
>> # Safe because we sanitize before trusting
>> return dangerously_trust_html(bleach.clean(value))
>>
>>
>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django-develop...@googlegroups.com .
>>> To post to 

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-22 Thread Дилян Палаузов

Hello,

is everybody fine with the documentation of mark_safe?

I think by default people don't come to the idea to use mark_safe  
except on occasions, where they notice their output is not the desired  
one.  Then investigations on rendering to achieve the right output  
lead to mark_safe() and by that time the developers have enough  
knowledge how the whole stuff works internally.


With this flow there is no danger of misusing mark_safe.

Greetings
  Дилян

- Message from Douglas Miranda <douglasmirandasi...@gmail.com> -
Date: Thu, 22 Feb 2018 09:40:08 -0800 (PST)
From: Douglas Miranda <douglasmirandasi...@gmail.com>
Reply-To: django-developers@googlegroups.com
 Subject: Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)
  To: "Django developers  (Contributions to Django itself)"  
<django-developers@googlegroups.com>




Yes, people read *mark_safe* as *MAKE_safe*, I'm not sure yet, but I'm
liking the idea of *trust_html*, I feel like more developers will
understand what they're doing.

Maybe the docs could have more detailed notes about HTML inputs that you
want to mark them safe, one thing is trust "" another is trust "{{
post.content }}". Rich text editors play a big part of beginner devs, a lot
of people start with Django and don't quite understand Python or Web
Security yet, that's just reality.

Django it is not to blame, but I think that's a small change with big
impact.


On Thursday, February 22, 2018 at 10:07:12 AM UTC-4, Adam Johnson wrote:


I am also in favour of a rename without deprecating the old name.

I like 'trust_html' - it's still similarly short but as Tom says it
implies more than 'mark_safe' does.

On 22 February 2018 at 08:30, Tom Forbes <t...@tomforb.es >
wrote:


What about just 'trust_html'? The dangerous part is quite context
dependent (and a bit of mouth-full), but at the core you are trusting the
HTML. Hopefully it follows that you should not trust html with user input
that hasn't been escaped.


On 22 Feb 2018 13:10, "Anthony King" <anthon...@gmail.com >
wrote:

I entirely agree with renaming `mark_safe`. Though it's name is correct,
it doesn't convey the gravity of what this actually does.
However I'm unsure on the `dangerously_trust_html` name. It wouldn't be
dangerous to trust the literal "Some Content", for example.

Perhaps it could be something a bit more explicit. `no_escape(string)`?
This assumes that most have at least heard of escaping.


On 22 February 2018 at 12:16, Josh Smeaton <josh.s...@gmail.com
> wrote:


The concern isn't overusing an API. It's not understanding the proper
use case for it.

"mark safe" can sound like the API is doing sanitation so it can
encourage developers to use it incorrectly. I'm fairly sure I've done this
myself.

The intended meaning is "this output is **already** safe" but the name
doesn't convey that meaning clearly enough.

What the proposal is designed to do is convey the "I trust this output"
meaning of the API. I'm just wary of enforcing users to change code when
they already use the API correctly.

On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:


Yeah, I am also worried about the churn for no gain in my eyes. If
users overuse mark_safe, they will overuse dangerously_trust_html too…

On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton
wrote:


I agree that the names are misleading and we should probably provide
better names. I'm wary of deprecating the old names because  
it'll create a
lot of churn (some of which would be the right thing to do).  
Maybe we could

just alias and warn when using the old name, leaving a decision on
deprecation until some time in the future.

On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:


In my experience, misuse of mark_safe() — i.e. marking stuff safe
which *isn’t* actually safe (e.g. HTML from a rich text input) — is
one of the biggest causes of XSS vulnerabilities in Django projects.

The docs warn to be careful, but unfortunately I think Django devs
have just got too used to mark_safe() being *the way* to insert HTML
in a template. And it’s easy for something that was safe when it was
authored (e.g. calling mark_safe() on a hard-coded string) to be
copied / repurposed / adapted into a case which is no longer  
be safe (e.g.

that string replaced with a user-provided value).

Some other frameworks use scary sounding names to help reinforce that
there are dangers around similar features, and that this isn’t  
something

you should use in everyday work — e.g. React’s
dangerouslySetInnerHTML.

Relatedly, this topic
<https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ>  
suggested

making it more explicit that mark_safe() refers to being safe for
use in *HTML* contexts (rather than JS, CSS, SQL, etc).

Combining the two, it wou

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-22 Thread Douglas Miranda
Yes, people read *mark_safe* as *MAKE_safe*, I'm not sure yet, but I'm 
liking the idea of *trust_html*, I feel like more developers will 
understand what they're doing.

Maybe the docs could have more detailed notes about HTML inputs that you 
want to mark them safe, one thing is trust "" another is trust "{{ 
post.content }}". Rich text editors play a big part of beginner devs, a lot 
of people start with Django and don't quite understand Python or Web 
Security yet, that's just reality.

Django it is not to blame, but I think that's a small change with big 
impact.


On Thursday, February 22, 2018 at 10:07:12 AM UTC-4, Adam Johnson wrote:
>
> I am also in favour of a rename without deprecating the old name.
>
> I like 'trust_html' - it's still similarly short but as Tom says it 
> implies more than 'mark_safe' does.
>
> On 22 February 2018 at 08:30, Tom Forbes  
> wrote:
>
>> What about just 'trust_html'? The dangerous part is quite context 
>> dependent (and a bit of mouth-full), but at the core you are trusting the 
>> HTML. Hopefully it follows that you should not trust html with user input 
>> that hasn't been escaped.
>>
>>
>> On 22 Feb 2018 13:10, "Anthony King"  
>> wrote:
>>
>> I entirely agree with renaming `mark_safe`. Though it's name is correct, 
>> it doesn't convey the gravity of what this actually does.
>> However I'm unsure on the `dangerously_trust_html` name. It wouldn't be 
>> dangerous to trust the literal "Some Content", for example.
>>
>> Perhaps it could be something a bit more explicit. `no_escape(string)`?
>> This assumes that most have at least heard of escaping.
>>
>>
>> On 22 February 2018 at 12:16, Josh Smeaton > > wrote:
>>
>>> The concern isn't overusing an API. It's not understanding the proper 
>>> use case for it.
>>>
>>> "mark safe" can sound like the API is doing sanitation so it can 
>>> encourage developers to use it incorrectly. I'm fairly sure I've done this 
>>> myself.
>>>
>>> The intended meaning is "this output is **already** safe" but the name 
>>> doesn't convey that meaning clearly enough.
>>>
>>> What the proposal is designed to do is convey the "I trust this output" 
>>> meaning of the API. I'm just wary of enforcing users to change code when 
>>> they already use the API correctly.
>>>
>>> On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:

 Yeah, I am also worried about the churn for no gain in my eyes. If 
 users overuse mark_safe, they will overuse dangerously_trust_html too…

 On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton 
 wrote:
>
> I agree that the names are misleading and we should probably provide 
> better names. I'm wary of deprecating the old names because it'll create 
> a 
> lot of churn (some of which would be the right thing to do). Maybe we 
> could 
> just alias and warn when using the old name, leaving a decision on 
> deprecation until some time in the future.
>
> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:
>>
>> In my experience, misuse of mark_safe() — i.e. marking stuff safe 
>> which *isn’t* actually safe (e.g. HTML from a rich text input) — is 
>> one of the biggest causes of XSS vulnerabilities in Django projects.
>>
>> The docs warn to be careful, but unfortunately I think Django devs 
>> have just got too used to mark_safe() being *the way* to insert HTML 
>> in a template. And it’s easy for something that was safe when it was 
>> authored (e.g. calling mark_safe() on a hard-coded string) to be 
>> copied / repurposed / adapted into a case which is no longer be safe 
>> (e.g. 
>> that string replaced with a user-provided value).
>>
>> Some other frameworks use scary sounding names to help reinforce that 
>> there are dangers around similar features, and that this isn’t something 
>> you should use in everyday work — e.g. React’s 
>> dangerouslySetInnerHTML.
>>
>> Relatedly, this topic 
>> 
>>  suggested 
>> making it more explicit that mark_safe() refers to being safe for 
>> use in *HTML* contexts (rather than JS, CSS, SQL, etc).
>>
>> Combining the two, it would be great if Django could rename 
>> mark_safe() to dangerously_trust_html(), |safe to 
>> |dangerously_trust_html, @csrf_exempt to @dangerously_csrf_exempt, 
>> etc.
>>
>> Developers who know what they’re doing with these could then be 
>> encouraged to create suitable wrappers which handle their use case 
>> safely 
>> internally — e.g.:
>>
>> @register.filter
>> def sanitize_and_trust_html(value):
>> # Safe because we sanitize before trusting
>> return dangerously_trust_html(bleach.clean(value))
>>
>>
>> -- 
>>> You received this message 

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-22 Thread Adam Johnson
I am also in favour of a rename without deprecating the old name.

I like 'trust_html' - it's still similarly short but as Tom says it implies
more than 'mark_safe' does.

On 22 February 2018 at 08:30, Tom Forbes  wrote:

> What about just 'trust_html'? The dangerous part is quite context
> dependent (and a bit of mouth-full), but at the core you are trusting the
> HTML. Hopefully it follows that you should not trust html with user input
> that hasn't been escaped.
>
>
> On 22 Feb 2018 13:10, "Anthony King"  wrote:
>
> I entirely agree with renaming `mark_safe`. Though it's name is correct,
> it doesn't convey the gravity of what this actually does.
> However I'm unsure on the `dangerously_trust_html` name. It wouldn't be
> dangerous to trust the literal "Some Content", for example.
>
> Perhaps it could be something a bit more explicit. `no_escape(string)`?
> This assumes that most have at least heard of escaping.
>
>
> On 22 February 2018 at 12:16, Josh Smeaton  wrote:
>
>> The concern isn't overusing an API. It's not understanding the proper use
>> case for it.
>>
>> "mark safe" can sound like the API is doing sanitation so it can
>> encourage developers to use it incorrectly. I'm fairly sure I've done this
>> myself.
>>
>> The intended meaning is "this output is **already** safe" but the name
>> doesn't convey that meaning clearly enough.
>>
>> What the proposal is designed to do is convey the "I trust this output"
>> meaning of the API. I'm just wary of enforcing users to change code when
>> they already use the API correctly.
>>
>> On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:
>>>
>>> Yeah, I am also worried about the churn for no gain in my eyes. If users
>>> overuse mark_safe, they will overuse dangerously_trust_html too…
>>>
>>> On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton wrote:

 I agree that the names are misleading and we should probably provide
 better names. I'm wary of deprecating the old names because it'll create a
 lot of churn (some of which would be the right thing to do). Maybe we could
 just alias and warn when using the old name, leaving a decision on
 deprecation until some time in the future.

 On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:
>
> In my experience, misuse of mark_safe() — i.e. marking stuff safe
> which *isn’t* actually safe (e.g. HTML from a rich text input) — is
> one of the biggest causes of XSS vulnerabilities in Django projects.
>
> The docs warn to be careful, but unfortunately I think Django devs
> have just got too used to mark_safe() being *the way* to insert HTML
> in a template. And it’s easy for something that was safe when it was
> authored (e.g. calling mark_safe() on a hard-coded string) to be
> copied / repurposed / adapted into a case which is no longer be safe (e.g.
> that string replaced with a user-provided value).
>
> Some other frameworks use scary sounding names to help reinforce that
> there are dangers around similar features, and that this isn’t something
> you should use in everyday work — e.g. React’s dangerouslySetInnerHTML
> .
>
> Relatedly, this topic
> 
>  suggested
> making it more explicit that mark_safe() refers to being safe for use
> in *HTML* contexts (rather than JS, CSS, SQL, etc).
>
> Combining the two, it would be great if Django could rename
> mark_safe() to dangerously_trust_html(), |safe to
> |dangerously_trust_html, @csrf_exempt to @dangerously_csrf_exempt,
> etc.
>
> Developers who know what they’re doing with these could then be
> encouraged to create suitable wrappers which handle their use case safely
> internally — e.g.:
>
> @register.filter
> def sanitize_and_trust_html(value):
> # Safe because we sanitize before trusting
> return dangerously_trust_html(bleach.clean(value))
>
>
> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/django-developers/db4ac958-89e1-4286-a616-99e9854c9bbb%4
>> 0googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are 

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-22 Thread Tom Forbes
What about just 'trust_html'? The dangerous part is quite context dependent
(and a bit of mouth-full), but at the core you are trusting the HTML.
Hopefully it follows that you should not trust html with user input that
hasn't been escaped.

On 22 Feb 2018 13:10, "Anthony King"  wrote:

I entirely agree with renaming `mark_safe`. Though it's name is correct, it
doesn't convey the gravity of what this actually does.
However I'm unsure on the `dangerously_trust_html` name. It wouldn't be
dangerous to trust the literal "Some Content", for example.

Perhaps it could be something a bit more explicit. `no_escape(string)`?
This assumes that most have at least heard of escaping.


On 22 February 2018 at 12:16, Josh Smeaton  wrote:

> The concern isn't overusing an API. It's not understanding the proper use
> case for it.
>
> "mark safe" can sound like the API is doing sanitation so it can encourage
> developers to use it incorrectly. I'm fairly sure I've done this myself.
>
> The intended meaning is "this output is **already** safe" but the name
> doesn't convey that meaning clearly enough.
>
> What the proposal is designed to do is convey the "I trust this output"
> meaning of the API. I'm just wary of enforcing users to change code when
> they already use the API correctly.
>
> On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:
>>
>> Yeah, I am also worried about the churn for no gain in my eyes. If users
>> overuse mark_safe, they will overuse dangerously_trust_html too…
>>
>> On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton wrote:
>>>
>>> I agree that the names are misleading and we should probably provide
>>> better names. I'm wary of deprecating the old names because it'll create a
>>> lot of churn (some of which would be the right thing to do). Maybe we could
>>> just alias and warn when using the old name, leaving a decision on
>>> deprecation until some time in the future.
>>>
>>> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:

 In my experience, misuse of mark_safe() — i.e. marking stuff safe
 which *isn’t* actually safe (e.g. HTML from a rich text input) — is
 one of the biggest causes of XSS vulnerabilities in Django projects.

 The docs warn to be careful, but unfortunately I think Django devs have
 just got too used to mark_safe() being *the way* to insert HTML in a
 template. And it’s easy for something that was safe when it was authored
 (e.g. calling mark_safe() on a hard-coded string) to be copied /
 repurposed / adapted into a case which is no longer be safe (e.g. that
 string replaced with a user-provided value).

 Some other frameworks use scary sounding names to help reinforce that
 there are dangers around similar features, and that this isn’t something
 you should use in everyday work — e.g. React’s dangerouslySetInnerHTML.

 Relatedly, this topic
 
  suggested
 making it more explicit that mark_safe() refers to being safe for use
 in *HTML* contexts (rather than JS, CSS, SQL, etc).

 Combining the two, it would be great if Django could rename mark_safe() to
 dangerously_trust_html(), |safe to |dangerously_trust_html,
 @csrf_exempt to @dangerously_csrf_exempt, etc.

 Developers who know what they’re doing with these could then be
 encouraged to create suitable wrappers which handle their use case safely
 internally — e.g.:

 @register.filter
 def sanitize_and_trust_html(value):
 # Safe because we sanitize before trusting
 return dangerously_trust_html(bleach.clean(value))


 --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/django-developers/db4ac958-89e1-4286-a616-99e9854c9bbb%
> 40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To 

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-22 Thread Anthony King
I entirely agree with renaming `mark_safe`. Though it's name is correct, it
doesn't convey the gravity of what this actually does.
However I'm unsure on the `dangerously_trust_html` name. It wouldn't be
dangerous to trust the literal "Some Content", for example.

Perhaps it could be something a bit more explicit. `no_escape(string)`?
This assumes that most have at least heard of escaping.


On 22 February 2018 at 12:16, Josh Smeaton  wrote:

> The concern isn't overusing an API. It's not understanding the proper use
> case for it.
>
> "mark safe" can sound like the API is doing sanitation so it can encourage
> developers to use it incorrectly. I'm fairly sure I've done this myself.
>
> The intended meaning is "this output is **already** safe" but the name
> doesn't convey that meaning clearly enough.
>
> What the proposal is designed to do is convey the "I trust this output"
> meaning of the API. I'm just wary of enforcing users to change code when
> they already use the API correctly.
>
> On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:
>>
>> Yeah, I am also worried about the churn for no gain in my eyes. If users
>> overuse mark_safe, they will overuse dangerously_trust_html too…
>>
>> On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton wrote:
>>>
>>> I agree that the names are misleading and we should probably provide
>>> better names. I'm wary of deprecating the old names because it'll create a
>>> lot of churn (some of which would be the right thing to do). Maybe we could
>>> just alias and warn when using the old name, leaving a decision on
>>> deprecation until some time in the future.
>>>
>>> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:

 In my experience, misuse of mark_safe() — i.e. marking stuff safe
 which *isn’t* actually safe (e.g. HTML from a rich text input) — is
 one of the biggest causes of XSS vulnerabilities in Django projects.

 The docs warn to be careful, but unfortunately I think Django devs have
 just got too used to mark_safe() being *the way* to insert HTML in a
 template. And it’s easy for something that was safe when it was authored
 (e.g. calling mark_safe() on a hard-coded string) to be copied /
 repurposed / adapted into a case which is no longer be safe (e.g. that
 string replaced with a user-provided value).

 Some other frameworks use scary sounding names to help reinforce that
 there are dangers around similar features, and that this isn’t something
 you should use in everyday work — e.g. React’s dangerouslySetInnerHTML.

 Relatedly, this topic
 
  suggested
 making it more explicit that mark_safe() refers to being safe for use
 in *HTML* contexts (rather than JS, CSS, SQL, etc).

 Combining the two, it would be great if Django could rename mark_safe() to
 dangerously_trust_html(), |safe to |dangerously_trust_html,
 @csrf_exempt to @dangerously_csrf_exempt, etc.

 Developers who know what they’re doing with these could then be
 encouraged to create suitable wrappers which handle their use case safely
 internally — e.g.:

 @register.filter
 def sanitize_and_trust_html(value):
 # Safe because we sanitize before trusting
 return dangerously_trust_html(bleach.clean(value))


 --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/db4ac958-89e1-4286-a616-
> 99e9854c9bbb%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALs0z1YuC63d6aJ1VEhcnezpCg1NPJYpadcR4-fRRwGDrR4-qw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-22 Thread Tim Graham
I don't know that "dangerously_trust_html" is a better name. The argument 
is supposed to be a string that you know is trusted so there shouldn't be 
any danger involved. Naming something based on how it could be misused 
seems odd.

For me, mark_safe() is a fine name, but maybe that preference is from a 
knowledge of django.utils.safestring internals that most users don't have.

On Thursday, February 22, 2018 at 7:16:29 AM UTC-5, Josh Smeaton wrote:
>
> The concern isn't overusing an API. It's not understanding the proper use 
> case for it.
>
> "mark safe" can sound like the API is doing sanitation so it can encourage 
> developers to use it incorrectly. I'm fairly sure I've done this myself.
>
> The intended meaning is "this output is **already** safe" but the name 
> doesn't convey that meaning clearly enough.
>
> What the proposal is designed to do is convey the "I trust this output" 
> meaning of the API. I'm just wary of enforcing users to change code when 
> they already use the API correctly.
>
> On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:
>>
>> Yeah, I am also worried about the churn for no gain in my eyes. If users 
>> overuse mark_safe, they will overuse dangerously_trust_html too…
>>
>> On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton wrote:
>>>
>>> I agree that the names are misleading and we should probably provide 
>>> better names. I'm wary of deprecating the old names because it'll create a 
>>> lot of churn (some of which would be the right thing to do). Maybe we could 
>>> just alias and warn when using the old name, leaving a decision on 
>>> deprecation until some time in the future.
>>>
>>> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:

 In my experience, misuse of mark_safe() — i.e. marking stuff safe 
 which *isn’t* actually safe (e.g. HTML from a rich text input) — is 
 one of the biggest causes of XSS vulnerabilities in Django projects.

 The docs warn to be careful, but unfortunately I think Django devs have 
 just got too used to mark_safe() being *the way* to insert HTML in a 
 template. And it’s easy for something that was safe when it was authored 
 (e.g. calling mark_safe() on a hard-coded string) to be copied / 
 repurposed / adapted into a case which is no longer be safe (e.g. that 
 string replaced with a user-provided value).

 Some other frameworks use scary sounding names to help reinforce that 
 there are dangers around similar features, and that this isn’t something 
 you should use in everyday work — e.g. React’s dangerouslySetInnerHTML.

 Relatedly, this topic 
 
  suggested 
 making it more explicit that mark_safe() refers to being safe for use 
 in *HTML* contexts (rather than JS, CSS, SQL, etc).

 Combining the two, it would be great if Django could rename mark_safe() to 
 dangerously_trust_html(), |safe to |dangerously_trust_html, 
 @csrf_exempt to @dangerously_csrf_exempt, etc.

 Developers who know what they’re doing with these could then be 
 encouraged to create suitable wrappers which handle their use case safely 
 internally — e.g.:

 @register.filter
 def sanitize_and_trust_html(value):
 # Safe because we sanitize before trusting
 return dangerously_trust_html(bleach.clean(value))




-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/370611c1-2031-4c0b-9f56-4b2c482e1113%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-22 Thread Josh Smeaton
The concern isn't overusing an API. It's not understanding the proper use 
case for it.

"mark safe" can sound like the API is doing sanitation so it can encourage 
developers to use it incorrectly. I'm fairly sure I've done this myself.

The intended meaning is "this output is **already** safe" but the name 
doesn't convey that meaning clearly enough.

What the proposal is designed to do is convey the "I trust this output" 
meaning of the API. I'm just wary of enforcing users to change code when 
they already use the API correctly.

On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:
>
> Yeah, I am also worried about the churn for no gain in my eyes. If users 
> overuse mark_safe, they will overuse dangerously_trust_html too…
>
> On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton wrote:
>>
>> I agree that the names are misleading and we should probably provide 
>> better names. I'm wary of deprecating the old names because it'll create a 
>> lot of churn (some of which would be the right thing to do). Maybe we could 
>> just alias and warn when using the old name, leaving a decision on 
>> deprecation until some time in the future.
>>
>> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:
>>>
>>> In my experience, misuse of mark_safe() — i.e. marking stuff safe which 
>>> *isn’t* actually safe (e.g. HTML from a rich text input) — is one of 
>>> the biggest causes of XSS vulnerabilities in Django projects.
>>>
>>> The docs warn to be careful, but unfortunately I think Django devs have 
>>> just got too used to mark_safe() being *the way* to insert HTML in a 
>>> template. And it’s easy for something that was safe when it was authored 
>>> (e.g. calling mark_safe() on a hard-coded string) to be copied / 
>>> repurposed / adapted into a case which is no longer be safe (e.g. that 
>>> string replaced with a user-provided value).
>>>
>>> Some other frameworks use scary sounding names to help reinforce that 
>>> there are dangers around similar features, and that this isn’t something 
>>> you should use in everyday work — e.g. React’s dangerouslySetInnerHTML.
>>>
>>> Relatedly, this topic 
>>> 
>>>  suggested 
>>> making it more explicit that mark_safe() refers to being safe for use 
>>> in *HTML* contexts (rather than JS, CSS, SQL, etc).
>>>
>>> Combining the two, it would be great if Django could rename mark_safe() to 
>>> dangerously_trust_html(), |safe to |dangerously_trust_html, @csrf_exempt to 
>>> @dangerously_csrf_exempt, etc.
>>>
>>> Developers who know what they’re doing with these could then be 
>>> encouraged to create suitable wrappers which handle their use case safely 
>>> internally — e.g.:
>>>
>>> @register.filter
>>> def sanitize_and_trust_html(value):
>>> # Safe because we sanitize before trusting
>>> return dangerously_trust_html(bleach.clean(value))
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/db4ac958-89e1-4286-a616-99e9854c9bbb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-22 Thread Florian Apolloner
Yeah, I am also worried about the churn for no gain in my eyes. If users 
overuse mark_safe, they will overuse dangerously_trust_html too…

On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton wrote:
>
> I agree that the names are misleading and we should probably provide 
> better names. I'm wary of deprecating the old names because it'll create a 
> lot of churn (some of which would be the right thing to do). Maybe we could 
> just alias and warn when using the old name, leaving a decision on 
> deprecation until some time in the future.
>
> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:
>>
>> In my experience, misuse of mark_safe() — i.e. marking stuff safe which 
>> *isn’t* actually safe (e.g. HTML from a rich text input) — is one of the 
>> biggest causes of XSS vulnerabilities in Django projects.
>>
>> The docs warn to be careful, but unfortunately I think Django devs have 
>> just got too used to mark_safe() being *the way* to insert HTML in a 
>> template. And it’s easy for something that was safe when it was authored 
>> (e.g. calling mark_safe() on a hard-coded string) to be copied / 
>> repurposed / adapted into a case which is no longer be safe (e.g. that 
>> string replaced with a user-provided value).
>>
>> Some other frameworks use scary sounding names to help reinforce that 
>> there are dangers around similar features, and that this isn’t something 
>> you should use in everyday work — e.g. React’s dangerouslySetInnerHTML.
>>
>> Relatedly, this topic 
>>  
>> suggested 
>> making it more explicit that mark_safe() refers to being safe for use in 
>> *HTML* contexts (rather than JS, CSS, SQL, etc).
>>
>> Combining the two, it would be great if Django could rename mark_safe() to 
>> dangerously_trust_html(), |safe to |dangerously_trust_html, @csrf_exempt to 
>> @dangerously_csrf_exempt, etc.
>>
>> Developers who know what they’re doing with these could then be 
>> encouraged to create suitable wrappers which handle their use case safely 
>> internally — e.g.:
>>
>> @register.filter
>> def sanitize_and_trust_html(value):
>> # Safe because we sanitize before trusting
>> return dangerously_trust_html(bleach.clean(value))
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3d683e14-a2dd-4f17-8774-9ddd88558254%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-21 Thread Collin Anderson
> Maybe we could just alias and warn when using the old name, leaving a
decision on deprecation until some time in the future.

I'm a fan of delaying deprecation/removal if we do change it. :)

On Wed, Feb 21, 2018 at 4:41 PM, Josh Smeaton 
wrote:

> I agree that the names are misleading and we should probably provide
> better names. I'm wary of deprecating the old names because it'll create a
> lot of churn (some of which would be the right thing to do). Maybe we could
> just alias and warn when using the old name, leaving a decision on
> deprecation until some time in the future.
>
> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:
>>
>> In my experience, misuse of mark_safe() — i.e. marking stuff safe which
>> *isn’t* actually safe (e.g. HTML from a rich text input) — is one of the
>> biggest causes of XSS vulnerabilities in Django projects.
>>
>> The docs warn to be careful, but unfortunately I think Django devs have
>> just got too used to mark_safe() being *the way* to insert HTML in a
>> template. And it’s easy for something that was safe when it was authored
>> (e.g. calling mark_safe() on a hard-coded string) to be copied /
>> repurposed / adapted into a case which is no longer be safe (e.g. that
>> string replaced with a user-provided value).
>>
>> Some other frameworks use scary sounding names to help reinforce that
>> there are dangers around similar features, and that this isn’t something
>> you should use in everyday work — e.g. React’s dangerouslySetInnerHTML.
>>
>> Relatedly, this topic
>>  
>> suggested
>> making it more explicit that mark_safe() refers to being safe for use in
>> *HTML* contexts (rather than JS, CSS, SQL, etc).
>>
>> Combining the two, it would be great if Django could rename mark_safe() to
>> dangerously_trust_html(), |safe to |dangerously_trust_html, @csrf_exempt to
>> @dangerously_csrf_exempt, etc.
>>
>> Developers who know what they’re doing with these could then be
>> encouraged to create suitable wrappers which handle their use case safely
>> internally — e.g.:
>>
>> @register.filter
>> def sanitize_and_trust_html(value):
>> # Safe because we sanitize before trusting
>> return dangerously_trust_html(bleach.clean(value))
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/05de4602-5c44-41bf-b675-
> ab15d69fb46d%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFO84S7x0y07eY4uYO2cKCe4%2B8jo9x%3DrO0QA3EAbJvU1pmbJ5Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-21 Thread Josh Smeaton
I agree that the names are misleading and we should probably provide better 
names. I'm wary of deprecating the old names because it'll create a lot of 
churn (some of which would be the right thing to do). Maybe we could just 
alias and warn when using the old name, leaving a decision on deprecation 
until some time in the future.

On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:
>
> In my experience, misuse of mark_safe() — i.e. marking stuff safe which 
> *isn’t* actually safe (e.g. HTML from a rich text input) — is one of the 
> biggest causes of XSS vulnerabilities in Django projects.
>
> The docs warn to be careful, but unfortunately I think Django devs have 
> just got too used to mark_safe() being *the way* to insert HTML in a 
> template. And it’s easy for something that was safe when it was authored 
> (e.g. calling mark_safe() on a hard-coded string) to be copied / 
> repurposed / adapted into a case which is no longer be safe (e.g. that 
> string replaced with a user-provided value).
>
> Some other frameworks use scary sounding names to help reinforce that 
> there are dangers around similar features, and that this isn’t something 
> you should use in everyday work — e.g. React’s dangerouslySetInnerHTML.
>
> Relatedly, this topic 
>  
> suggested 
> making it more explicit that mark_safe() refers to being safe for use in 
> *HTML* contexts (rather than JS, CSS, SQL, etc).
>
> Combining the two, it would be great if Django could rename mark_safe() to 
> dangerously_trust_html(), |safe to |dangerously_trust_html, @csrf_exempt to 
> @dangerously_csrf_exempt, etc.
>
> Developers who know what they’re doing with these could then be encouraged 
> to create suitable wrappers which handle their use case safely internally — 
> e.g.:
>
> @register.filter
> def sanitize_and_trust_html(value):
> # Safe because we sanitize before trusting
> return dangerously_trust_html(bleach.clean(value))
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/05de4602-5c44-41bf-b675-ab15d69fb46d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-15 Thread Douglas Miranda
I think this can mislead the developers to think mark_safe solves it all.

The forums are full of answers with *Use mark_safe;* *Use htmlfield|safe;* 
 
Maybe Django should start warning about mark_safe on the logs, then change 
the behavior. (Or even deprecate and remove)

Things like this we tend to blame the users, but it's there for using and 
it says *"SAFE"*.


On Sunday, January 28, 2018 at 1:14:27 PM UTC-3, Stuart Cox wrote:
>
> In my experience, misuse of mark_safe() — i.e. marking stuff safe which 
> *isn’t* actually safe (e.g. HTML from a rich text input) — is one of the 
> biggest causes of XSS vulnerabilities in Django projects.
>
> The docs warn to be careful, but unfortunately I think Django devs have 
> just got too used to mark_safe() being *the way* to insert HTML in a 
> template. And it’s easy for something that was safe when it was authored 
> (e.g. calling mark_safe() on a hard-coded string) to be copied / 
> repurposed / adapted into a case which is no longer be safe (e.g. that 
> string replaced with a user-provided value).
>
> Some other frameworks use scary sounding names to help reinforce that 
> there are dangers around similar features, and that this isn’t something 
> you should use in everyday work — e.g. React’s dangerouslySetInnerHTML.
>
> Relatedly, this topic 
>  
> suggested 
> making it more explicit that mark_safe() refers to being safe for use in 
> *HTML* contexts (rather than JS, CSS, SQL, etc).
>
> Combining the two, it would be great if Django could rename mark_safe() to 
> dangerously_trust_html(), |safe to |dangerously_trust_html, @csrf_exempt to 
> @dangerously_csrf_exempt, etc.
>
> Developers who know what they’re doing with these could then be encouraged 
> to create suitable wrappers which handle their use case safely internally — 
> e.g.:
>
> @register.filter
> def sanitize_and_trust_html(value):
> # Safe because we sanitize before trusting
> return dangerously_trust_html(bleach.clean(value))
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c4da4fc8-6565-42d8-bb4a-d9a8601ae355%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.