Harden `django.utils.archive` against decompression bombs

[Natalia Bidart]

The django.utils.archive module is an internal utility used by startapp and startproject when the --template option is provided. The current implementation does not impose limits on extracted file size, file count, or decompression time. This makes it possible for a crafted archive to consume excessive resources.

Thanks to "junfuchong (chongfujun)" for the report.

This is not considered a security issue under Django's policy because:

• The module is undocumented and only used in local development commands.
• Our policy excludes issues that affect only local dev, and these commands are not intended to run on untrusted archives in production.

Still, adding safeguards (such as maximum size or file count limits) would make the code more robust and user-friendly. This ticket tracks such hardening work after a conversation held within the Security Team.

[Natalia Bidart]

Jake Howard said:

• This also highlights that we should probably document this explicitly. If it's come up before, it's going to come up again. Getting some agreement for how local development only vulnerabilities are classed will help avoid a lot of future confusion. I'd suggest we put a warning on the --template argument about using untrusted templates, not only for extraction issues, but also because if they contain bad practices or backdoors, the new project would contain them too.

• Python's built-ins have come a long way since this module was created, and we could defer a lot of this work upstream. zipfile is probably safe as-is at least for our use case, and tarfile has extraction filters since 3.12 to mitigate much of the weirdness. We might even be able to use shutil.unpack_archive entirely (more investigation needed).