Re: CommandTemplate Behavior Is Inconsistent

[Adam Johnson]

Hi John!

Thanks for taking the time to compile a detailed bug report. Unfortunately,
emailing django-developers isn't the right approach here - the mailing list
is normally for higher level discussion. The normal process is to write a
ticket on Trac, our ticket tracker:
https://docs.djangoproject.com/en/dev/internals/contributing/bugs-and-features/

I'd do it for you right now, but then you won't be subscribed to the ticket
and able to answer replies. If you could take the time to submit it as per
the guide, then we can have a proper conversation on Trac.

For what it's worth, at first glance I think you may have a bug here, and
it might be worth adding some more logic for where new apps can be placed
by startapp.

Thanks,

Adam

On Fri, 5 Jul 2019 at 20:51, John Gooding  wrote:

> To be clear, I am not saying there is a bug. It does what it is programmed
> to do. I am saying the expected behavior of the API / CLI / whatever you
> want to call it is inconsistent.
>
> I am not going to get into an argument of what a "proper" django structure
> is, etc. I want to focus purely on the behavior of the command.
>
> A more "normal" setup might look like this:
>
> /repository
>   manage.py
>   /project
> settings.py
> urls.py
> etc..
>   /polls
> models.py
> etc...
>
> When you run `python manage.py startapp polls` from the same directory as
> manage.py, it will create the polls directory for you, normal expected
> behavior.
>
> Another, equally as valid setup looks like this:
>
> repository/
>   manage.py
>   /project
> settings.py
> urls.py
> etc...
> /polls
>   models.py
>   etc...
> /my_app_2
>   models.py
>   etc...
>
> Where all of the apps live in the project directory, or perhaps some other
> directory. Now if you try to execute `python manage.py startapp polls
> project`, it will complain that the directory doesn't exist and that you
> need to create it first. However if you `cd` into /project, and run `python
> ../manage.py startapp polls`, it will create the directory for you, even
> though it doesn't exist.
>
> My ultimate point is this, the behavior of the command should not depend
> on where it is ran. It should only care if the directory already exists or
> not, which it does check, but the applied behavior of that check is
> different depending on if you're in the line 68 if block
> 
>  or
> the line 76 else block
> .
> The applied behavior ought to be the same, regardless of where the command
> is ran from.
>
> --
> 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/dfe324ce-3718-4379-b20e-a2703973869c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

-- 
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/CAMyDDM1EKO%2B6ZAYzoduC0tan1iy8Fbug1aKDUHKvzHxG6TsO5w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Fuzzing Django at Google OSS-Fuzz

[Guido Vranken]

Dear group,

I've built a Django fuzzer that can be used with Google OSS-Fuzz [1].

The current fuzzer harness calls a host of django.util.* and related 
functions with pseudo-random inputs. Fuzzing these functions can be useful 
to see if any untrusted input can cause slowdowns, hangs, excessive memory 
consumption, or unexpected exceptions. There have been several of such 
issues in recent years (CVE-2018-7537, CVE-2018-7536, CVE-2019-6975 [2]), 
and it is quite likely that my fuzzer would detect these vulnerabilities 
automatically. In addition to these general vulnerability classes, the 
harness can be easily extended to raise a warning on any custom condition.

Are the Django developers interested in OSS-Fuzz integration? If so, I will 
need one or more email addresses linked to a Google account that will 
receive the automated bug reports generated by OSS-Fuzz. Because these 
reports may contain security-sensitive information, it is recommended that 
only developers who ordinarily deal with security reports are included in 
this list.

Guido

[1] https://github.com/google/oss-fuzz
[2] https://docs.djangoproject.com/en/dev/releases/security/

-- 
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/08c201eb-e43d-4535-88b5-625ed3dfc89b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.