Django security releases issued: 4.0.2, 3.2.12, and 2.2.27

[Mariusz Felisiak]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2022/feb/01/security-releases/

--
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/4f6f73a3-1066-8081-3950-fe0aa7634d11%40gmail.com.

Re: DATABASES setting for async usage

[Andrew Wang]

I'm thinking that for our purposes:

   1. Because several Django projects need a migration from sync to async 
   which requires time and resources, sync engines can specify a new key 
   called ASYNC_DATABASE_ALIAS whose value is a string that is a database 
   alias in the DATABASES dict. The purpose of this is two-fold: A) ease 
   Django project migrations to async and B) allow for testing on Django 
   internal test suite and third-party packages. This also helps with 
   backwards compatibility for the templating system such that when we 
   call Model.objects.acreate, because of that a prefix, we can implicitly use 
   the async engine.
   2. Projects that start off as async or have their default engine as 
   async need an option called SYNC_DATABASE_ALIAS that is exactly like 
   the ASYNC_DATABASE_ALIAS option. The purpose for this is to fill in the gap 
   of DEP 9 by having a migration and schema engine changer since async 
   engines aren't supposed to. In the database wrapper, we would grab the sync 
   database's database wrapper's Schema class.

It'll look like this:
DATABASES = { 'default': { 'ENGINE': 'django.db.backends.aiosqlite', 
'SYNC_DATABASE_ALIAS': 'sync' }, 'sync': { 'ENGINE': 
'django.db.backends.sqlite3', }, } 

or
DATABASES = { 'default': { 'ENGINE': 'django.db.backends.sqlite3', 
'ASYNC_DATABASE_ALIAS': 'async' }, 'async': { 'ENGINE': 
'django.db.backends.aiosqlite', }, } 

I'm not sure if either of these options are possible due to sqlite being 
tested in memory though.

On Monday, January 31, 2022 at 6:48:13 PM UTC-5 Adam Johnson wrote:

> Hi Andrew,
>
> I'm afraid I don't know much about async, but I can point you at some 
> recent changes. Andrew Godwin created a PR with the draft of the async ORM 
> API. Carlton recently asked for tests: 
> https://twitter.com/carltongibson/status/1486281689265545221 . Perhaps 
> check out those PR's and see if you can contribute further?
>
> Adam
>
> On Sat, Jan 29, 2022 at 1:42 AM Andrew Wang  wrote:
>
>> Hi, I'm intrigued in helping develop the async ORM engines (link to 
>> random PR  with aiosqlite 
>> and base async engine). The biggest road block is having test cases for 
>> async engines only; for instance, introspection/test_async.py can't run 
>> because the test suite needs to first migrate using a sync engine as the 
>> default database connection then switch the default alias to using an async 
>> engine; additionally, for most of the test suite, it uses the sync engine. 
>> The current methods I'm thinking of:
>>
>> 1. Each async engine would get its own CI worker. I think it's a waste of 
>> resources and because it wouldn't help Django users who also need to write 
>> test cases with both an async and sync (for migrations) engine.
>> 2. Async and sync engines for the same database are run at the same time. 
>> Every async engine requires a parallel sync engine, an alias to be 
>> specified in the engine's DATABASES options. This way, while testing, 
>> migrations can be performed with a designated sync engine. This is great 
>> for the end user who may be async-centric; this doesn't really resolve the 
>> current problem. Most of the Django test suite is designed for synchronous 
>> db engines, so the default alias database engine will switch around a bunch 
>> of times.
>> 3. Implement a test decorator that switches the default alias connection.
>>
>> Lemme know if that's confusing.
>>
>> Thanks,
>> Andrew
>>
>> -- 
>> 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/4ca69f37-cc9e-40c3-a73b-cc9a125ebaecn%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/70cf36e9-2c67-4bb8-ace9-a06d2ef6ee38n%40googlegroups.com.

Re: DATABASES setting for async usage

['Adam Johnson' via Django developers (Contributions to Django itself)]

Hi Andrew,

I'm afraid I don't know much about async, but I can point you at some
recent changes. Andrew Godwin created a PR with the draft of the async ORM
API. Carlton recently asked for tests:
https://twitter.com/carltongibson/status/1486281689265545221 . Perhaps
check out those PR's and see if you can contribute further?

Adam

On Sat, Jan 29, 2022 at 1:42 AM Andrew Wang  wrote:

> Hi, I'm intrigued in helping develop the async ORM engines (link to
> random PR  with aiosqlite
> and base async engine). The biggest road block is having test cases for
> async engines only; for instance, introspection/test_async.py can't run
> because the test suite needs to first migrate using a sync engine as the
> default database connection then switch the default alias to using an async
> engine; additionally, for most of the test suite, it uses the sync engine.
> The current methods I'm thinking of:
>
> 1. Each async engine would get its own CI worker. I think it's a waste of
> resources and because it wouldn't help Django users who also need to write
> test cases with both an async and sync (for migrations) engine.
> 2. Async and sync engines for the same database are run at the same time.
> Every async engine requires a parallel sync engine, an alias to be
> specified in the engine's DATABASES options. This way, while testing,
> migrations can be performed with a designated sync engine. This is great
> for the end user who may be async-centric; this doesn't really resolve the
> current problem. Most of the Django test suite is designed for synchronous
> db engines, so the default alias database engine will switch around a bunch
> of times.
> 3. Implement a test decorator that switches the default alias connection.
>
> Lemme know if that's confusing.
>
> Thanks,
> Andrew
>
> --
> 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/4ca69f37-cc9e-40c3-a73b-cc9a125ebaecn%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/CAMyDDM1hLH0GWjGne%2Bq%2BoM_nDhh4F8%3DC%3DoJ82i%3DF_%3D%3D_kzN%2BwQ%40mail.gmail.com.

Re: AWS RDS Proxy and session pinning

['Adam Johnson' via Django developers (Contributions to Django itself)]

Hi!

Good to hear about the use of RDS Proxy. I have considered looking at it to
help scaling.

You should be able to bypass the timezone check yourself with a little
subclassing. You can implement this yourself with a subclassed database
backend like so:
https://docs.djangoproject.com/en/4.0/ref/databases/#subclassing-the-built-in-database-backends
. Use it to replace the ensure_timezone() method with appropriate logic.

That may be all that's required. It would be good to know if that works
before considering changing Django.

Thanks,

Adam

On Mon, Jan 31, 2022 at 10:30 PM dans...@gmail.com 
wrote:

> Sorry - lest I miscommunicate - the DBAs make the default equivalent to
> EST5EDT, rather than UTC.   Django team leads (me and David), want USE_TZ =
> True to be on for all the applications, and because of this the postgresql
> backend will issue SET TIMEZONE UTC in
> django/db/backends/postgreql/base.py:209 (ensure_timezone).  At the same
> time, different applications and frameworks have different opinions and the
> DBAs try to satisfy us all, but can forget.  This issue of session pinning
> with connection pooling servers (such as RDS Proxy)  may be more general,
> and it may be good to not always set the timezone, but I want to discuss
> before filing an issue.
>
> On Monday, January 31, 2022 at 5:24:46 PM UTC-5 dans...@gmail.com wrote:
>
>> Hi Django developers,
>>
>> At the National Library of Medicine we are doing a lot of Django and
>> AWS.  For some of the applications with heavier traffic, we are using RDS
>> Proxy within AWS.  RDS Proxy is sort of like a managed version of pgbouncer
>> or pg-pool-II - it must be rather AWS customized because of the way it
>> manages authentication.
>>
>> Anyway, we found some problems for two reasons:
>>
>>- Our DBAs make the default timezone of the database UTF-8 is AWS
>>CloudFormation to create the databases.
>>- When "ensure_timezone" runs and sets the timezone, that database
>>session is "pinned", so that it will not be shared.
>>
>> Since we already have our own PostgreSQL backend for a couple of other
>> reasons, I just wrote a version of ensure_timezone which fails loudly if
>> the timezone is not UTF-8 rather than set the timezone.  I probably should
>> have discussed the issue on this list, and I am remedying this.
>>
>> The failure to manage database connections with RDS Proxy is a pretty
>> severe error, and I am wondering what the community thinks about a
>> connection specific setting about how the timezone should be handled?   For
>> lower traffic applications, SET TIMEZONE is fine.  For higher traffic
>> applications, raising ImproperlyConfigured is better.
>>
>> Does the group think that a Postgreql specific setting/option should be
>> implemented to prevent session pinning?
>>
> --
> 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/ecc0c527-465a-45c7-b6ff-3c35c56824bfn%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/CAMyDDM1Xj_JYKDLBHwPc%3D7Lz8NMqNVQz2vOLQ-cz9cjEuvDd7Q%40mail.gmail.com.

Re: AWS RDS Proxy and session pinning

[dans...@gmail.com]

Sorry - lest I miscommunicate - the DBAs make the default equivalent to 
EST5EDT, rather than UTC.   Django team leads (me and David), want USE_TZ = 
True to be on for all the applications, and because of this the postgresql 
backend will issue SET TIMEZONE UTC in 
django/db/backends/postgreql/base.py:209 (ensure_timezone).  At the same 
time, different applications and frameworks have different opinions and the 
DBAs try to satisfy us all, but can forget.  This issue of session pinning 
with connection pooling servers (such as RDS Proxy)  may be more general, 
and it may be good to not always set the timezone, but I want to discuss 
before filing an issue.

On Monday, January 31, 2022 at 5:24:46 PM UTC-5 dans...@gmail.com wrote:

> Hi Django developers,
>
> At the National Library of Medicine we are doing a lot of Django and AWS.  
> For some of the applications with heavier traffic, we are using RDS Proxy 
> within AWS.  RDS Proxy is sort of like a managed version of pgbouncer or 
> pg-pool-II - it must be rather AWS customized because of the way it manages 
> authentication.
>
> Anyway, we found some problems for two reasons:
>
>- Our DBAs make the default timezone of the database UTF-8 is AWS 
>CloudFormation to create the databases.
>- When "ensure_timezone" runs and sets the timezone, that database 
>session is "pinned", so that it will not be shared.
>
> Since we already have our own PostgreSQL backend for a couple of other 
> reasons, I just wrote a version of ensure_timezone which fails loudly if 
> the timezone is not UTF-8 rather than set the timezone.  I probably should 
> have discussed the issue on this list, and I am remedying this.
>
> The failure to manage database connections with RDS Proxy is a pretty 
> severe error, and I am wondering what the community thinks about a 
> connection specific setting about how the timezone should be handled?   For 
> lower traffic applications, SET TIMEZONE is fine.  For higher traffic 
> applications, raising ImproperlyConfigured is better.   
>
> Does the group think that a Postgreql specific setting/option should be 
> implemented to prevent session pinning?
>

-- 
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/ecc0c527-465a-45c7-b6ff-3c35c56824bfn%40googlegroups.com.

AWS RDS Proxy and session pinning

[dans...@gmail.com]

Hi Django developers,

At the National Library of Medicine we are doing a lot of Django and AWS.  
For some of the applications with heavier traffic, we are using RDS Proxy 
within AWS.  RDS Proxy is sort of like a managed version of pgbouncer or 
pg-pool-II - it must be rather AWS customized because of the way it manages 
authentication.

Anyway, we found some problems for two reasons:

   - Our DBAs make the default timezone of the database UTF-8 is AWS 
   CloudFormation to create the databases.
   - When "ensure_timezone" runs and sets the timezone, that database 
   session is "pinned", so that it will not be shared.

Since we already have our own PostgreSQL backend for a couple of other 
reasons, I just wrote a version of ensure_timezone which fails loudly if 
the timezone is not UTF-8 rather than set the timezone.  I probably should 
have discussed the issue on this list, and I am remedying this.

The failure to manage database connections with RDS Proxy is a pretty 
severe error, and I am wondering what the community thinks about a 
connection specific setting about how the timezone should be handled?   For 
lower traffic applications, SET TIMEZONE is fine.  For higher traffic 
applications, raising ImproperlyConfigured is better.   

Does the group think that a Postgreql specific setting/option should be 
implemented to prevent session pinning?

-- 
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/bf7ac5e1-05e1-4d5b-a2a5-8d1dda04b66bn%40googlegroups.com.

Re: Proposal on how add configuration options to Email Backends

[Jacob Rief]

On Monday, January 31, 2022 at 7:55:47 AM UTC+1 f.apo...@gmail.com wrote:

> Okay then,
>
> some of the things like sender reputation and different bounce hooks came 
> to my mind as well, but it is good to hear confirmation from others. I 
> think the next steps would be to create a new ticket to add support for 
> *multiple* email backends and then work from that (I would only link the 
> old ticket since it's scope was mainly putting the config into a dict as 
> opposed to multiple backends). Given that there are plenty of +1 here 
> already I think we already have our implementors? :)
>
> Some items that I like to see addressed in a PR:
>  * Backwards compat
>  * Similarity to Caches & Databases (ie so we don't invent yet another 
> syntax)
>  * Support for connection aliases (default/…) in send_email % friends 
> (basically everything taking a connection now should probably take aliases 
> as well)
>

OK. Since I made the proposal, it then is probably up to me to create the 
ticket.  

-- 
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/9f15a814-5424-46f7-8d91-fd4303d58579n%40googlegroups.com.