Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

2022-11-28 Thread 'John Whitlock' via Django developers (Contributions to Django itself) 
I'd like to see database-level defaults supported in models and migrations:

https://code.djangoproject.com/ticket/470

There's currently a PR open, which replaces an earlier 2020 PR

https://github.com/django/django/pull/16092

It would be a large benefit to those of us practicing continuous
deployment. It is also tricky enough that it would benefit from a full-time
effort to implement and refactor.

- John

On Tue, Nov 15, 2022 at 3:11 AM Carlton Gibson 
wrote:

> Hi all.
>
> Google Summer of Code (GSoC) for 2023 has just been announced.
>
> https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html
>
> Django has participated many times, and it's been a real boon. Recent
> successes include:
>
> * The django-stubs mypy plugin.
> * The cross-db JSON field.
> * The Redis cache backend.
> * Per model-class (field instance) custom lookups
> * Setup of the django-asv benchmarking project.
> * ...
>
> Application deadline for Orgs is February 7. I'll begin working on it
> after the New Year.
>
> Main bit is an ideas list for projects. The GSoC guide has a Writing a
> Good Ideas List
> section.
>
> > Projects should take ~175 hours or ~350 hours for GSoC contributors to
> complete.
>
> i.e. "short" or "long" projects.
> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>
> I'm writing here *to solicit input on project ideas*.
>
> I put "Technical Board?" in the subject because we're short a list of
> project
> ideas for the technical direction of Django going forward, and maybe
> thinking
> in terms of GSoC could be a way of bootstrapping that. The "?" is because
> that's not
> meant to exclude other input.
>
> Here's last year's list for reference:
> https://code.djangoproject.com/wiki/SummerOfCode2022
>
> - Some of those were done: benchmarking (but that could be built on) and
> per-instance
>   field lookups.
>
> - Rate-limiting is a no-go I think: we couldn't come to any decent
> agreement on scope,
>   so it's better to live as a third-party package.
>
> - I've tried to include folks from the wider ecosystem in previous years.
> Two years ago
>   we had both Wagtail and django-stubs projects. Wagtail then (last year)
>   applied in their own right, to great success. I'd like to offer that help
>   again to e.g. Jazzband or other established projects, assuming
> maintainers
>   feel they have the capacity to mentor. (It's a minor increment to my
> effort
>   for a good return I think.)
>
>
> No urgency but, can I ask you to put your grey cells into action? 
>
>
> Thanks.
>
> Kind Regards,
>
> Carlton
>
> --
> 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/194b43ff-98cf-4736-8360-3d79e9b62402n%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/CAJ3y2QR7jg7cHWbTxEv-Pje9%3Dfxp7yiPBRuoxn1hAAX%3D8v0Vdg%40mail.gmail.com.

Re: Why using django.contrib.sessions as the salt to encode session data? why not secret key?

2022-10-05 Thread 'John Whitlock' via Django developers (Contributions to Django itself) 
Looking at the code, the hard-coded salt seems OK to me. The encoding is
done by SessionBase.encode()
,
which calls dumps() from django.core.signing
.
The docstring says:






*Return URL-safe, hmac signed base64 compressed JSON string. If key is
None, use settings.SECRET_KEY instead. The hmac algorithm is the default
Signer algorithm.If compress is True (not the default), check if
compressing using zlib can save some space. Prepend a '.' to signify
compression. This is included in the signature, to protect against zip
bombs.Salt can be used to namespace the hash, so that a signed string is
only valid for a given namespace. Leaving this at the default value or
re-using a salt value across different parts of your application without
good cause is a security risk.*

*The serializer is expected to return a bytestring.*

So, settings.SECRET_KEY is used to sign the session, and salt acts like a
namespace to distinguish sessions from other uses of the SECRET_KEY.

Trying it out in `./manage.py shell`:

>>> from django.contrib.sessions.backends.db import SessionStore
>>> from django.core.signing import b64_decode
>>> session = SessionStore().encode({"foo": "bar"})
>>> print(session)
eyJmb28iOiJiYXIifQ:1ogD1v:OIpRWKZdxbhox3d7XaS7A0bZouEXQV6jx03FlAaDGZo
>>> val, ts, sign = session.split(':')
SessionStore().encode({"foo": "bar"})
>>> b64_decode(val.encode())
b'{"foo":"bar"}'
>>> b64_decode(ts.encode())
b'\xd6\x88\x03\xd6'
>>> b64_decode(sign.encode())
b'8\x8aQX\xa6]\xc5\xb8h\xc7w{]\xa4\xbb\x03F\xd9\xa2\xe1\x17A^\xa3\xc7M\xc5\x94\x06\x83\x19\x9a'
>>> len(b64_decode(z.encode()))
32

The first section of the session value is the encoded value, base64
encoded, and potentially compressed.
The second section is the encoded timestamp, used to determine if it was
created too long ago on decode
The third section is the HMAC signature, base64 encoded.

- John

On Wed, Oct 5, 2022 at 4:45 PM 'Adam Johnson' via Django developers
(Contributions to Django itself)  wrote:

> Looking through blame, it looks like this hardcoded salt was added in
> 2010:
> https://github.com/django/django/commit/45c7f427ce830dd1b2f636fb9c244fda9201cadb#diff-3a6c11bbe36a0e6927f71ad8d669f0021897ba73768ee41073a318a12e11c3d1L85-L90
>
> This actually changed from using the secret key as the salt, to the fixed
> string, whilst also changing the algorithm from MAC to HMAC. But I cannot
> see any discussion on why in the ticket:
> https://code.djangoproject.com/ticket/14445 .
>
> 路‍♂️
>
> On Mon, Oct 3, 2022 at 8:43 AM Lokesh Sanapalli 
> wrote:
>
>> Hi,
>>
>> I was going through the code and got a question. I saw that we are using
>> hard-coded string `django.contrib.sessions` as the key salt to encode
>> session data
>> .
>> Why not using the secret key? as the secret key is specific to environment
>> and project it serves as a good candidate. Is it because the session data
>> does not contain any sensitive info (it only contains user id and other
>> info) so that's why this decision is made?
>>
>> Thanks & Regards,
>> Lokesh Sanpalli
>>
>> --
>> 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/6c6544b7-a190-4198-9108-6c66fac213ebn%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/CAMyDDM1C6HxOVYrVL2XuBOhjWUb0EnThvzSAzocdKXrr%2BjkNEg%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