Re: I need a mentor on django

[Manas Paul]

You can visit https://wsvincent.com/, my personal blog 
https://manascode.com   or 
https://simpleisbetterthancomplex.com/

On Thursday, 11 June 2020 00:45:40 UTC+5:30, Onayemi Hakeem wrote:
>
> Okay if that is the case I agreed I've been in the wrong mailing list can 
> you please add or refer to a platform where I can be mentored, or assisted 
> whenever I ran into problems using django
>
> On Wed, Jun 10, 2020, 17:11 Adam Johnson > 
> wrote:
>
>> Hi!
>>
>> I think you've found the wrong mailing list for this post. This mailing 
>> list is for discussing the development of Django itself, not for support 
>> using Django. This means the discussions of bugs and features in Django 
>> itself, rather than in your code using it. People on this list are unlikely 
>> to answer your support query with their limited time and energy.
>>
>> For support, please follow the "Getting Help" page: 
>> https://docs.djangoproject.com/en/3.0/faq/help/ . This will help you 
>> find people who are willing to support you, and to ask your question in a 
>> way that makes it easy for them to answer.
>>
>> Thanks for your understanding and all the best,
>>
>> Adam
>>
>> On Wed, 10 Jun 2020 at 16:52, Onayemi Hakeem > > wrote:
>>
>>> I need a mentor who can guide me on my Django programming skill to 
>>> develop my dream app
>>>
>>> -- 
>>> 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-d...@googlegroups.com .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/8b4b8a83-aee6-4c84-acf5-3f0cdf3c03d2o%40googlegroups.com
>>> .
>>>
>>
>>
>> -- 
>> 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-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CAMyDDM2gOnUKGM%2BFcEwLRN_TKT20jkbjJjoXs1tQkgoh_gov%2Bw%40mail.gmail.com
>>  
>> 
>> .
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/15c841da-ad21-4088-b865-cdc114e941ddo%40googlegroups.com.

Re: I need a mentor on django

[Rodrigo Luciano]

Hi whats especif tou nerd?

Em dom, 2 de ago de 2020 14:33, SUNIL PATEL 
escreveu:

> Hi
> how are you doing at django.
> sunil patel
>
> On Wed, Jun 10, 2020 at 9:27 PM Onayemi Hakeem 
> wrote:
>
>> I need a mentor who can guide me on my Django programming skill to
>> develop my dream app
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/8b4b8a83-aee6-4c84-acf5-3f0cdf3c03d2o%40googlegroups.com
>> .
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CADarRE46vWdCiAfMUhXNHNXctTiDgsPNAMhGBeZZ1a0vzZu9yA%40mail.gmail.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAD-xn8LqqZAwBXP_R-k%2B5ZYJFdSdAj-xZ%2B%2BCoh24mNgj1DKwFA%40mail.gmail.com.

Ticket #31823 Fetch Metadata Request Headers

['Megan Huber' via Django developers (Contributions to Django itself)]

Hi Everyone,

TL;DR: This ticket was triaged to “Someday/Maybe” due to concerns over 
Fetch Metadata Request Headers being experimental and not supported by all 
browsers. I would like to address these concerns and hear them in more 
detail to see if we can add more protection for Django users now.

I wanted to get more feedback on this ticket regarding implementing Fetch 
Metadata Request Headers as an additional protection against cross-origin 
attacks. I also want to open a discussion about improving the CSRF 
middleware. 

The feedback on this ticket was concerned about the experimental nature of 
the headers. I would like to know more about the concerns regarding these 
headers as I think they would add value to Django and would not require 
additional maintenance once implemented given the current status of the 
specification.

Fetch Metadata Request Headers are a new security feature that protects 
against cross-origin attacks. They are to be used as a defense-in-depth 
feature and not as a replacement for the current CSRF protections. The spec 
can be found here.  These 
headers, if set by the browser, would be checked in place of the referer 
header to protect against CSRF. Because these headers are only set if they 
are supported by the browser, their presence in the request indicates that 
the browser supports this feature and that the headers are accurate. If the 
headers are not present, the browser does not support this feature and the 
referer header check can be used instead. Given this, it is possible to 
account for browsers adopting this feature without losing backwards 
compatibility. 

The experimental status of the feature should not affect the server-side 
implementation as only the client-side spec is subject to change. Of the 
four headers, the Sec-Fetch-Site header is the only one considered 
unstable. This header can be set to "cross-site", "same-origin", 
"same-site", or "none". “None” is used to distinguish “webby” requests from 
those that arise from user interaction with the user agent, like opening a 
bookmark. Each browser may have different interactions that fall into this 
category. As such, the client-side specification is open to some 
interpretation as the feature is adopted by more browsers. However, this 
shouldn’t have an impact on the server-side usage of the headers. More 
information can be found here. 


Currently, the CSRF middleware checks the referer header as an additional 
protection against MITM and other attacks that can circumvent the CSRF 
cookie and token checks. This is done by checking that the referer is a 
well formed URL and that connection is over https and not http. However, 
this header is not included in every request which leads to false positive 
cases where non malicious requests may be blocked. The new Fetch Metadata 
Request Headers provide more information than the referer header alone 
which allows for finer security controls based on the request origin and 
the adoption of a strict resource isolation policy in addition to verifying 
the URL.


Thank you for your thoughts!

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/315c3c13-12e2-45fc-97f7-cd39f760e916n%40googlegroups.com.

Re: Rethink (?) how we handle security headers.

['Megan Huber' via Django developers (Contributions to Django itself)]

Hi Y'all, 

I suggested the addition of the COOP header. I don't have enough experience 
contributing to Django to know if the process of adding new headers should 
be streamlined. I am curious though if CORS or CORP support has ever been 
considered as a part of the security middleware. COOP is usually 
implemented with a header called Cross-origin Embedder Policy but it relies 
on CORS or CORP being set to a specific value. I know that currently Django 
projects use a middleware to handle CORS but we can't have a safe default 
for COEP set unless we know they are using this middleware. The middleware 
is also not a Mozilla repository. 

Maybe now is a good time to add support for CORS/CORP while we are adding 
many other security headers? I would be interested in contributing to this 
and could submit a new issue for it or do it as a part of the COOP ticket.

Another +1 to Adam's Add_Headers idea. This would be an effective way of 
keeping up with new security standards for concerned developers but would 
offer no protection to the average Django user.

Thanks,

Megan


On Friday, July 31, 2020 at 1:25:08 PM UTC-4 Adam Johnson wrote:

> > I would suggest that the redirection part be moved to a different 
> middleware.
>
> I doubt this would have any noticeable performance impact on any 
> application. I’d like to see profiling data before imposing such a change 
> on users.
>
> Also I find myself using the Django redirect with several different 
> “serverlwss” deployment setups.
>
> On Thu, 30 Jul 2020 at 17:43, Claude Paroz  wrote:
>
>> By the way, while reviewing the SecurityMiddleware, I would suggest that 
>> the redirection part be moved to a different middleware.
>> http to https redirection should preferably be done at the Web server 
>> level, and for those doing that properly, they still pay for the unneeded 
>> (albeit small) overhead of the `SecurityMiddleware.process_request`.
>>
>> > 3. For new headers I think we could add a setting called e.g. 
>> ADD_HEADERS - a dict of keys to values that 
>> > CommonMiddleware (or similar) could add to outgoing responses' headers. 
>>
>> +1 to that proposal.
>>
>> Claude
>>
>> -- 
>>
> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/3da2e385-551e-4905-83e8-7f2b99896f18o%40googlegroups.com
>>  
>> 
>> .
>>
> -- 
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/138e2004-49e2-4d70-a410-a53f4d80aa6an%40googlegroups.com.

Re: Status of 3.1 release blockers.

[Mariusz Felisiak]

Hi Markus,

I don't see a clear path to do this, we cannot add a setting that 
accepts a string and immediately (in the next release) change it to a list, 
this will require a deprecation path etc. and will be really confusing to 
users. IMO we can reconsider this new feature in the next release with a 
different setting.

Best,
Mariusz

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/77dfa750-21c2-42ef-a69c-077217746098n%40googlegroups.com.

Re: Set up autolinks on Django's GitHub repositories

[laym...@gmail.com]

Hi Markus,

Thanks, I must've missed that . Then, I guess I'd suggest adding a 
briefer one *and using it in commit messages*. So yep, the contributing 
guide needs to be updated as well. However, this changes the convention 
which has been there for years. I'd like to hear what the Fellows or board 
think about this.

Sage

On Monday, 3 August 2020 at 14:52:31 UTC+7 in...@markusholtermann.eu wrote:

> Hi Sage, 
>
> thank you for the suggestion. There's already autolinking setup for 
> `ticket-123`. I'm happy to add another one which would be a bit briefer. 
> But if this is done, the contribution documentation needs to be updated as 
> well. 
>
> /Markus 
>
> On Mon, Aug 3, 2020, at 8:06 AM, laym...@gmail.com wrote: 
> > Hi folks, 
> > 
> > I came across this feature on GitHub today: 
> > 
> https://docs.github.com/en/github/administering-a-repository/configuring-autolinks-to-reference-external-resources
>  
> > 
> > In short, it adds autolinks to external resources (e.g. our issue 
> > tracker) by referencing them using a prefix in GitHub comments or 
> > commits. So, instead of using Markdown to manually link to a ticket, we 
> > can just use the prefix followed by the ticket number, e.g. *TR-123* 
> > and GitHub will automatically convert it to a link. 
> > 
> > Currently, we use the # character as a convention to refer to the 
> > tickets. However, this conflicts with the use of # on GitHub which 
> > automatically links to PRs (and issues if enabled). As a result, 
> > commits that refer to a ticket whose number is also a valid PR number, 
> > incorrectly link to the PR. Here's an example: 
> > 
> https://github.com/django/django/commit/5d4b9c1cab03f0d057f0c7751862df0302c65cf9
>  
> > 
> > As you can see, the commit message links to PR#12990 which actually 
> > isn't relevant. This also generates noise in the PR itself: 
> > https://github.com/django/django/pull/12990. I think that can be 
> > misleading to new contributors. 
> > 
> > By using the autolinks, we can properly link the reference to the 
> > tickets. Sadly, we can't replace GitHub's # autolinks. So, we need to 
> > create a new prefix. This has some downsides, though: 
> > * It breaks the current convention of using # to refer to tickets. 
> > * The prefix must only contain letters, numbers, or -:/# 
> > * The prefix is 3 characters minimum, so this means commit messages 
> > will be at least 2 characters longer than with the current convention. 
> > However, considering the benefits: 
> > * No more incorrect links to irrelevant PRs. 
> > * No more noise in PRs from irrelevant commits. 
> > * Clickable ticket numbers in commits that take you to the tickets. 
> > * Quick linking to tickets in GitHub comments (no need to use 
> > Markdown). 
> > * Less confusion to new contributors. 
> > I think it's worth it. 
> > 
> > What do y'all think? If we're to agree upon this, I guess we need to 
> > come up with the prefix. I don't have any preference; as long as it 
> > makes sense, I'm in. 
> > 
> > Oh, and one more thing: maybe we can also set up a prefix for PRs to 
> > easily differentiate between the two from now on. Here are some 
> > proposals: 
> > * *TR-1234* for TRac tickets, and *PR-5678* for PRs. 
> > * *TR#1234* for TRac tickets, and *PR#5678* for PRs. 
> > And maybe we can set up another for DEPs, but that may not be 
> > necessary... 
> > 
> > Regards, 
> > Sage 
> > 
> > -- 
> > 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 view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/django-developers/e070dd97-0d22-4566-a605-867141f7e0aan%40googlegroups.com
>  
> <
> https://groups.google.com/d/msgid/django-developers/e070dd97-0d22-4566-a605-867141f7e0aan%40googlegroups.com?utm_medium=email_source=footer>.
>  
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5f2fb712-a0eb-49c4-a368-2c01adeec8e1n%40googlegroups.com.

Re: Set up autolinks on Django's GitHub repositories

[Markus Holtermann]

Hi Sage,

thank you for the suggestion. There's already autolinking setup for 
`ticket-123`. I'm happy to add another one which would be a bit briefer. But if 
this is done, the contribution documentation needs to be updated as well.

/Markus

On Mon, Aug 3, 2020, at 8:06 AM, laym...@gmail.com wrote:
> Hi folks,
> 
> I came across this feature on GitHub today:
> https://docs.github.com/en/github/administering-a-repository/configuring-autolinks-to-reference-external-resources
> 
> In short, it adds autolinks to external resources (e.g. our issue 
> tracker) by referencing them using a prefix in GitHub comments or 
> commits. So, instead of using Markdown to manually link to a ticket, we 
> can just use the prefix followed by the ticket number, e.g. *TR-123* 
> and GitHub will automatically convert it to a link.
> 
> Currently, we use the # character as a convention to refer to the 
> tickets. However, this conflicts with the use of # on GitHub which 
> automatically links to PRs (and issues if enabled). As a result, 
> commits that refer to a ticket whose number is also a valid PR number, 
> incorrectly link to the PR. Here's an example: 
> https://github.com/django/django/commit/5d4b9c1cab03f0d057f0c7751862df0302c65cf9
> 
> As you can see, the commit message links to PR#12990 which actually 
> isn't relevant. This also generates noise in the PR itself: 
> https://github.com/django/django/pull/12990. I think that can be 
> misleading to new contributors.
> 
> By using the autolinks, we can properly link the reference to the 
> tickets. Sadly, we can't replace GitHub's # autolinks. So, we need to 
> create a new prefix. This has some downsides, though:
>  * It breaks the current convention of using # to refer to tickets.
>  * The prefix must only contain letters, numbers, or -:/#
>  * The prefix is 3 characters minimum, so this means commit messages 
> will be at least 2 characters longer than with the current convention.
> However, considering the benefits:
>  * No more incorrect links to irrelevant PRs.
>  * No more noise in PRs from irrelevant commits.
>  * Clickable ticket numbers in commits that take you to the tickets.
>  * Quick linking to tickets in GitHub comments (no need to use 
> Markdown).
>  * Less confusion to new contributors.
> I think it's worth it.
> 
> What do y'all think? If we're to agree upon this, I guess we need to 
> come up with the prefix. I don't have any preference; as long as it 
> makes sense, I'm in.
> 
> Oh, and one more thing: maybe we can also set up a prefix for PRs to 
> easily differentiate between the two from now on. Here are some 
> proposals:
>  * *TR-1234* for TRac tickets, and *PR-5678* for PRs.
>  * *TR#1234* for TRac tickets, and *PR#5678* for PRs.
> And maybe we can set up another for DEPs, but that may not be 
> necessary...
> 
> Regards,
> Sage
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/e070dd97-0d22-4566-a605-867141f7e0aan%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0f9ddf24-b903-4bf1-9b27-bc73353b1957%40www.fastmail.com.

Re: Status of 3.1 release blockers.

[Markus Holtermann]

Can we come up with a way that we have the settings variable around for now, 
only to allow transitioning, and then add it as a proper feature in 3.2.

As for the feature, I think we could choose a path like passlib does: A list of 
2 (n>=1) algorithms. The first one will be used for signing, and all of them 
for verification. We could then limit the set of options to sensible algorithms 
(or put some algorithms on a blocklist, such as md5). But I think that's 
nothing we should add the day before the final release.

Cheers,

Markus

On Mon, Aug 3, 2020, at 8:48 AM, Mariusz Felisiak wrote:
> It seems that adding DEFAULT_HASHING_ALGORITHM setting is an acceptable 
> solution, we have one remaining question: Do we keep the setting around?
>  1. we can treat DEFAULT_HASHING_ALGORITHM as a transitional setting, 
> limit its values to `sha1` and `sha256`, and deprecate it immediately. 
> Florian said: *"From a security perspective I wonder if we should limit 
> this that the existing sha1 and the new sha256 algos. We really don't 
> ever want anyone to put md5 there and it is really just a transitional 
> setting.", "...setting this to sha256, running with it and then 
> changing it to sha512 will be a hard cut. There will be no migration 
> path like there would be for sha1. Imo that limits the usefulness of 
> such a setting for long term usage and makes it questionable if we want 
> to support such usage."*
>  2. we can treat DEFAULT_HASHING_ALGORITHM as a new feature and allows 
> any secure hash algorithm supported by hashlib. Simon said: *"**It does 
> add one more setting but it feels like having this configurable project 
> wide will be a plus as it will allow the ecosystem to rely on it and 
> hopefully make audit of large Django application a bit easier when 
> having specific hashing requirements.".*
> Personally I think we should choose the first option because it's 
> safer. 
> 
> *We're delaying the 3.1 release until tomorrow.*
> 
> Best,
> Mariusz
> 
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/023a0518-a58c-48c6-8b36-9d5fb7a7c108n%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/17636c67-cdb5-4cf9-bb95-b10b8cc0885d%40www.fastmail.com.

Django bugfix releases issued: 3.0.9 and 2.2.15

[Mariusz Felisiak]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2020/aug/03/django-bugfix-releases-309-2215/

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5e7f0415-544a-5289-c537-f172985c90ec%40gmail.com.

Re: Username Validators 27807

[Shekhar Gyanwali]

I have submitted a PR with what I had before the discussion. Will work on
it based on feedback.

Please see PR here. 

On Thu, Jul 30, 2020 at 11:35 PM Shekhar Gyanwali <
saykharng.gyanw...@gmail.com> wrote:

> Hi Everyone!
>
> I am currently working on my first Django ticket 27807
> , which is to allow users to
> customize username validation. My experience with Django and development is
> very limited (junior developer level). I need some guidance on this.
>
> I am taking similar approach as password validation
> 
>  (Thanks
> to Jacob ) . In the current solution, I am following Django core validators
> pattern which is to have __call__ method for validator. However, I have
> noticed that password validator needs to have it's own validate method.
>
> Is it best to implement username validators similar to password validators
> for the consistency and better user experience?
>
> What is the best approach here and what are the benefits of the best
> approach?
>
> Your feedback is much appreciated.
>
> Cheers
> Shekhar
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/6102cf17-b9be-4987-863f-1939feed93f8o%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHAmSnptjSUERW5F%2BNEwZSxV_GTrLrJ02Qn%3DsXCRL1eY9c_vFg%40mail.gmail.com.

Re: Status of 3.1 release blockers.

[Mariusz Felisiak]

It seems that adding DEFAULT_HASHING_ALGORITHM setting is an acceptable 
solution, we have one remaining question: Do we keep the setting around?

   1. we can treat DEFAULT_HASHING_ALGORITHM as a transitional setting, 
   limit its values to `sha1` and `sha256`, and deprecate it immediately. 
   Florian said: *"From a security perspective I wonder if we should limit 
   this that the existing sha1 and the new sha256 algos. We really don't ever 
   want anyone to put md5 there and it is really just a transitional 
   setting.", "...setting this to sha256, running with it and then changing it 
   to sha512 will be a hard cut. There will be no migration path like there 
   would be for sha1. Imo that limits the usefulness of such a setting for 
   long term usage and makes it questionable if we want to support such 
   usage."*
   2. we can treat DEFAULT_HASHING_ALGORITHM as a new feature and allows 
   any secure hash algorithm supported by hashlib. Simon said: *"**It does 
   add one more setting but it feels like having this configurable project 
   wide will be a plus as it will allow the ecosystem to rely on it and 
   hopefully make audit of large Django application a bit easier when having 
   specific hashing requirements.".*

Personally I think we should choose the first option because it's safer. 

*We're delaying the 3.1 release until tomorrow.*

Best,
Mariusz

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/023a0518-a58c-48c6-8b36-9d5fb7a7c108n%40googlegroups.com.

Set up autolinks on Django's GitHub repositories

[laym...@gmail.com]

Hi folks,

I came across this feature on GitHub today:
https://docs.github.com/en/github/administering-a-repository/configuring-autolinks-to-reference-external-resources

In short, it adds autolinks to external resources (e.g. our issue tracker) 
by referencing them using a prefix in GitHub comments or commits. So, 
instead of using Markdown to manually link to a ticket, we can just use the 
prefix followed by the ticket number, e.g. *TR-123* and GitHub will 
automatically convert it to a link.

Currently, we use the # character as a convention to refer to the tickets. 
However, this conflicts with the use of # on GitHub which automatically 
links to PRs (and issues if enabled). As a result, commits that refer to a 
ticket whose number is also a valid PR number, incorrectly link to the PR. 
Here's an example: 
https://github.com/django/django/commit/5d4b9c1cab03f0d057f0c7751862df0302c65cf9

As you can see, the commit message links to PR#12990 which actually isn't 
relevant. This also generates noise in the PR 
itself: https://github.com/django/django/pull/12990. I think that can be 
misleading to new contributors.

By using the autolinks, we can properly link the reference to the tickets. 
Sadly, we can't replace GitHub's # autolinks. So, we need to create a new 
prefix. This has some downsides, though:

   - It breaks the current convention of using # to refer to tickets.
   - The prefix must only contain letters, numbers, or -:/#
   - The prefix is 3 characters minimum, so this means commit messages will 
   be at least 2 characters longer than with the current convention.
   
However, considering the benefits:

   - No more incorrect links to irrelevant PRs.
   - No more noise in PRs from irrelevant commits.
   - Clickable ticket numbers in commits that take you to the tickets.
   - Quick linking to tickets in GitHub comments (no need to use Markdown).
   - Less confusion to new contributors.

I think it's worth it.

What do y'all think? If we're to agree upon this, I guess we need to come 
up with the prefix. I don't have any preference; as long as it makes sense, 
I'm in.

Oh, and one more thing: maybe we can also set up a prefix for PRs to easily 
differentiate between the two from now on. Here are some proposals:

   - *TR-1234* for TRac tickets, and *PR-5678* for PRs.
   - *TR#1234* for TRac tickets, and *PR#5678* for PRs.

And maybe we can set up another for DEPs, but that may not be necessary...

Regards,
Sage

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e070dd97-0d22-4566-a605-867141f7e0aan%40googlegroups.com.