Re: [Django] #27929: Add ManifestStaticFilesStorage option to remove original (non-hashed) files after processing

[Django]

#27929: Add ManifestStaticFilesStorage option to remove original (non-hashed) 
files
after processing
-+-
 Reporter:  Jesse|Owner:  Umang
 |  Patel
 Type:  New feature  |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  nobody => Umang Patel
 * needs_better_patch:  0 => 1
 * status:  new => assigned
 * needs_docs:  0 => 1


Comment:

 [https://github.com/django/django/pull/17328 PR]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018aee6cd169-b88e219c-0ec4-4809-892f-010d34dc040a-00%40eu-central-1.amazonses.com.

Re: [Django] #34885: Not removing original (non-hashed) files after processing

[Django]

#34885: Not removing original (non-hashed) files after processing
-+-
 Reporter:  Umang Patel  |Owner:  Umang
 |  Patel
 Type:  New feature  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  4.2
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  assigned => closed
 * resolution:   => duplicate
 * component:  Uncategorized => contrib.staticfiles
 * needs_tests:  1 => 0
 * type:  Cleanup/optimization => New feature


Comment:

 Duplicate of #27929.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018aee625aa2-f3922c42-caf9-46d5-b2c5-d2c20127236e-00%40eu-central-1.amazonses.com.

Re: [Django] #34865: DatabaseWrapper are not GC and connections are not closed

[Django]

#34865: DatabaseWrapper are not GC and connections are not closed
-+-
 Reporter:  Fábio Domingues  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by David Wobrock):

 * cc: David Wobrock (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018aec4b39da-4358b82a-65b0-4d26-a787-2ecb8ffd93ee-00%40eu-central-1.amazonses.com.

Re: [Django] #34830: csrf_failure view missing context processors

[Django]

#34830: csrf_failure view missing context processors
-+
 Reporter:  Alex Henman  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by David Wobrock):

 * cc: David Wobrock (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018aec499d96-409e4588-c566-4993-8388-0feb274eb056-00%40eu-central-1.amazonses.com.

Re: [Django] #34881: migrate crashes when renaming model referenced twice by ManyToManyField.through model on SQLite.

[Django]

#34881: migrate crashes when renaming model referenced twice by
ManyToManyField.through model on SQLite.
+
 Reporter:  dennisvang  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  dev
 Severity:  Normal  |   Resolution:
 Keywords:  sqlite  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by David Wobrock):

 * cc: David Wobrock (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018aec498beb-82028cfc-78ac-44f6-8292-c70104c81e5f-00%40eu-central-1.amazonses.com.

Re: [Django] #33277: SimpleTestCase does not block database connections in threads

[Django]

#33277: SimpleTestCase does not block database connections in threads
-+-
 Reporter:  Daniel Hahler|Owner:  Sulabh
 |  Katila
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by David Wobrock):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1


Comment:

 Hey Sulabh,

 I took a few more minutes to dig into the issue and I think we are close
 to a fix :)
 djangoci.com is down at the time of writing, so I'm missing the complete
 test suite, but it looks quite promising for now! We just need to fix a
 few tests.

 => [https://github.com/django/django/pull/17075 PR]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018aec3d5314-2a4a6a4c-8dc0-49f8-8b8d-a0a15f564b19-00%40eu-central-1.amazonses.com.

Re: [Django] #33277: SimpleTestCase does not block database connections in threads

[Django]

#33277: SimpleTestCase does not block database connections in threads
-+-
 Reporter:  Daniel Hahler|Owner:  Sulabh
 |  Katila
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by David Wobrock):

 I do not think I have that much experience.

 How did you implement the "pre-signal" solution? Do you have an open
 PR/branch to check out the code :)

 And did you have a look on the
 [https://github.com/django/django/pull/17075 patching method] approach,
 and play around with it?
 I feel like it could be a working path - it mainly requires some test
 fixing.

 Replying to [comment:6 Sulabh Katila]:
 > Hi David,
 >
 > I've been grappling with this issue for a while now, and I haven't made
 much progress. Given your expertise in this area, I'm reaching out for
 some much-needed guidance.
 >
 > To address this, I've been contemplating the idea of implementing a
 "pre-signal" solution. However, I must admit that I'm currently stuck, and
 I'm unsure about how to move forward.
 >
 > I had initially considered intervening at the
 BaseDataBaseWrapper.connect() level, but I haven't been able to find a
 clear and effective path for implementation.
 >
 > Since you have experience in related areas of this issue, I was hoping
 you could provide some insights. What should I be looking for, or are
 there alternative approaches that might be more suitable?
 >
 > Thank you!
 >
 > Replying to [comment:4 David Wobrock]:
 > > Hey Sulabh,
 > >
 > > I see you assigned yourself the ticket, that's great!
 > > I've started a [https://github.com/django/django/pull/17075 PR] some
 months ago, feel free to check it out if it can give you some inspiration
 :)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018aebf59157-0f22c1cc-bb6a-44c4-999d-e85bb1ae72fe-00%40eu-central-1.amazonses.com.

Re: [Django] #28900: QuerySet.values() and values_list() for compound queries fails with annotation.

[Django]

#28900: QuerySet.values() and values_list() for compound queries fails with
annotation.
-+-
 Reporter:  elliott-omosheye |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  union, values| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by David Wobrock):

 * owner:  David Wobrock => (none)
 * status:  assigned => new


Comment:

 I didn't find the time to push on this. Removing myself from the ticket.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018aebf19b06-4a14b83d-f476-4ffc-b7d1-36289abe01b4-00%40eu-central-1.amazonses.com.

Re: [Django] #34581: Filters should not implicitly mark unsafe strings as safe without escaping

[Django]

#34581: Filters should not implicitly mark unsafe strings as safe without 
escaping
-+-
 Reporter:  Shai Berger  |Owner:
 Type:   |  omerimzali
  Cleanup/optimization   |   Status:  assigned
Component:  Template system  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by omerimzali):

 Thank you for all clarifications.

 For Join filter:
 First case: Totally safe inputs the list members and the joiner are safe,
 it will be produce safe output. (There's no unsafe input and there no need
 to escape in anyway so it doesn't contain any of our conditions)
 Second case: When it has any of its inputs (the list members and the
 joiner) are safe but also some of the inputs are unsafe, it still needs to
 produce safe output.
 Third case: All of the inputs are unsafe, it can produce unsafe output.

 For Second case, we have 3 conditions to check:
 - it needs to produce safe output: For this case yes it needs to produce
 safe output because some of the inputs are safe.
 - some of its input is unsafe: Yes some of the inputs are not safe,
 - the context is such that it should not escape the input: How can we be
 sure it should not escape the input? is  {% autoescape off %} line enough
 to assume this? Could be any other configurations or common behaviours for
 some of the filters to not escape the input?

 If we check this 3 conditions it should error out.

 And for the 3rd case, if all of the inputs are unsafe, it doesn't need to
 produce a safe ouput so source doesn't need to error out. Is it correct?


 Replying to [comment:7 Shai Berger]:
 > Replying to [comment:5 omerimzali]:
 > >
 > > {{{
 > > "I suggest a general rule: A filter which gets unsafe input, should
 not escape it, and yet needs to produce safe output, should error out.
 This is a hardening, not a security fix, so it should follow a normal
 deprecation cycle: The actual change should only happen after the next LTS
 release."
 > > }}}
 > >
 > > A filter which gets unsafe input should not escape it. I totally agree
 but do we mean it only when autoescape off? {% autoescape off %}
 > >
 >
 > I guess this phrasing was unclear, and I changed it in hope it is
 clearer now: The "should not change it" part is not part of "how a filter
 should generally behave", but a further condition. A filter for which all
 three conditions are true, should error out. "autoescape off" means that
 filters, generally, should not escape the input.
 >
 > > How should I check "All filters which can get unsafe input".  I know
 Django at least has 4 of them below. What's the right way to find others?
 Should this patch contains all of them.
 > >
 > > {{{
 > > join
 > > linenumbers,
 > > linebreaks,
 > > linebreaksbr,
 > > }}}
 > >
 >
 > All filters can get unsafe input.  Whether the filter actually got safe
 or unsafe input is only decided at runtime, and cannot be known in
 advance. The interesting question is, "does the filter need to produce
 safe output", and this changes from filter to filter: The last three you
 listed always need to produce safe output, because they need to include
 HTML to break lines; but for some filters, like {{{join}}}, this too is
 only decided at runtime -- {{{join}}} needs to produce safe output if (and
 only if) any of its inputs (the list members and the joiner) are safe. I
 can't think of any way to find which filters are relevant (and when),
 except to go over them one by one.
 >
 > I hope this clarifies the issue.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018aebf0ce1d-69e0a5dd-0cdf-4a73-b57f-764f5005f1bb-00%40eu-central-1.amazonses.com.

Re: [Django] #32263: squashmigrations produces incorrect result with a RenameModel on a ForeignKey target.

[Django]

#32263: squashmigrations produces incorrect result with a RenameModel on a
ForeignKey target.
--+
 Reporter:  InvalidInterrupt  |Owner:  Bhuvnesh
 Type:  Bug   |   Status:  assigned
Component:  Migrations|  Version:  3.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by David Wobrock):

 * cc: David Wobrock (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018aebe2d944-f817860e-b7a4-4358-8a82-eb5f75169314-00%40eu-central-1.amazonses.com.

Re: [Django] #34581: Filters should not implicitly mark unsafe strings as safe without escaping

[Django]

#34581: Filters should not implicitly mark unsafe strings as safe without 
escaping
-+-
 Reporter:  Shai Berger  |Owner:
 Type:   |  omerimzali
  Cleanup/optimization   |   Status:  assigned
Component:  Template system  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Old description:

> Consider the following template code snippet:
> {{{
> {% autoescape off %}
> {{ some_list|join:some_var }}
> {% endautoescape %}
> }}}
> As noted in #34574, the current implementation joins the members of
> {{{some_list}}} without escaping them, but marks the end result as safe
> (since #34578, the joiner {{{some_var}}} is not escaped either -- but in
> most common use, it is a literal in the template, so it is safe to begin
> with).
>
> Given that we already have a {{{safeseq}}} filter, and #34577 is
> introducing {{{escapeseq}}} as well, I think we should change the
> behavior of {{{join}}} and other related filters (an initial list that
> was given in the related discussion in the security team includes
> {{{linenumbers}}}, {{{linebreaks}}}, and {{{linebreaksbr}}}, but there
> are probably others) so they don't mark unsafe strings as safe without
> escaping them.
>
> The details change by the specific filter: The {{{join}}} filter may
> output an unsafe string when all of its inputs are unsafe. The
> {{{linebreaks}}} filter cannot -- it introduces HTML tags into its
> output, so this output must be marked safe. The {{{join}}} filter, too,
> should preserve safety -- so if some input (in the sequence or the
> joiner) is safe, again, the output must be safe.
>
> When a filter gets an unsafe input, must produce a safe output, and
> autoescape is on, there's no real problem -- the input can be escaped.
> This is current behavior, mostly ({{{join}}} escapes input and marks the
> output safe, even if it isn't forced to).
>
> But when autoescaping is off, inputs are not escaped -- however, the
> output, which usually includes their content verbatim, is still marked
> safe.
>
> I suggest a general rule: A filter which gets unsafe input, should not
> escape it, and yet needs to produce safe output, should error out. This
> is a hardening, not a security fix, so it should follow a normal
> deprecation cycle: The actual change should only happen after the next
> LTS release.
>
> This would affect many filters, and is backwards-incompatible, but I
> think it would make the escaping more consistent and predictable, and it
> would make Django more safe-by-default for some less-common use-cases.

New description:

 Consider the following template code snippet:
 {{{
 {% autoescape off %}
 {{ some_list|join:some_var }}
 {% endautoescape %}
 }}}
 As noted in #34574, the current implementation joins the members of
 {{{some_list}}} without escaping them, but marks the end result as safe
 (since #34578, the joiner {{{some_var}}} is not escaped either -- but in
 most common use, it is a literal in the template, so it is safe to begin
 with).

 Given that we already have a {{{safeseq}}} filter, and #34577 is
 introducing {{{escapeseq}}} as well, I think we should change the behavior
 of {{{join}}} and other related filters (an initial list that was given in
 the related discussion in the security team includes {{{linenumbers}}},
 {{{linebreaks}}}, and {{{linebreaksbr}}}, but there are probably others)
 so they don't mark unsafe strings as safe without escaping them.

 The details change by the specific filter: The {{{join}}} filter may
 output an unsafe string when all of its inputs are unsafe. The
 {{{linebreaks}}} filter cannot -- it introduces HTML tags into its output,
 so this output must be marked safe. The {{{join}}} filter, too, should
 preserve safety -- so if some input (in the sequence or the joiner) is
 safe, again, the output must be safe.

 When a filter gets an unsafe input, must produce a safe output, and
 autoescape is on, there's no real problem -- the input can be escaped.
 This is current behavior, mostly ({{{join}}} escapes input and marks the
 output safe, even if it isn't forced to).

 But when autoescaping is off, inputs are not escaped -- however, the
 output, which usually includes their content verbatim, is still marked
 safe.

 I suggest a general rule: A filter which fulfills these three conditions,
 should error out:
 - it needs to produce safe output
 - some of its input is unsafe,
 - the context is such that it should not escape the input

 This is