Re: Pluggable secret key backend
Personally, I like the simplicity and elegance of a single SECRET_KEYS setting. It's also a good way to raise awareness that rotation is A Good Thing to be doing anyways. In any case, I second all of those who've already endorsed this idea. If I can help, let me know. Tobias On Sun, Nov 18, 2018, 6:25 PM Adam Johnson Very good point. I'd prefer a second setting though, named like > OLD_SECRET_KEYS or VERIFICATION_SECRET_KEYS. If we're going to add a new > setting, we might as well not force users who aren't rotating their keys to > the new one, especially if they are semantically different. > > On Sun, 11 Nov 2018 at 18:32, Aymeric Augustin < > aymeric.augus...@polytechnique.org> wrote: > >> Good point, I can think of at least two apps of mine that would break. >> Transitioning to a new setting makes more sense. >> >> -- >> Aymeric. >> >> >> >> > On 11 Nov 2018, at 18:58, Tom Forbes wrote: >> > >> > Is it going to be easy to adjust the semantics of SECRET_KEY to support >> sequences like that? I’d imagine a lot of third party packages that expect >> SECRET_KEY to be a string would break in weird ways (thanks to both strings >> and tuples of strings being iterables that yield strings). >> > >> > Here’s a quick search on GitHub: >> https://github.com/search?q=%22settings.SECRET_KEY%22&type=Code >> > >> > To ease the backward compatibility concerns we could use SECRET_KEYS, >> then make SECRET_KEY (if it is not explicitly defined) map to >> SECRET_KEYS[0]? Third party packages using would not necessarily work with >> the backwards verification but they would at least not break and continue >> to work as expected. >> > >> > Tom >> > >> > >> > >> > >> > >> > On 11 November 2018 at 07:38:15, Aymeric Augustin ( >> aymeric.augus...@polytechnique.org) wrote: >> > >> >> Hello, >> >> >> >> I think this is a great idea. >> >> >> >> As suggested by others, an even better default implementation would be: >> >> >> >> class SecretKeysBackend: >> >> >> >> def get_signing_key(self): >> >> if isinstance(settings.SECRET_KEY, (list, tuple)): >> >> return settings.SECRET_KEY[0] >> >> else: >> >> return settings.SECRET_KEY >> >> >> >> def get_verification_keys(self): >> >> if isinstance(settings.SECRET_KEY, (list, tuple)): >> >> return settings.SECRET_KEY >> >> else: >> >> return [settings.SECRET_KEY] >> >> >> >> Once Django is updated to take advantage of this feature, hat would >> make key rotation practical for every Django user! >> >> >> >> (And it seems easier to adjust the semantics of SECRET_KEY than to >> introduce a SECRET_KEYS settings.) >> >> >> >> Best regards, >> >> >> >> -- >> >> Aymeric. >> >> >> >> >> >> >> >>> On 10 Nov 2018, at 11:12, Andreas Pelme wrote: >> >>> >> >>> Hi, >> >>> >> >>> settings.SECRET_KEY can be used for sessions, password resets, form >> wizards and >> >>> other cryptographic signatures via the signing APIs. Changing >> SECRET_KEY means >> >>> that all of those will be invalidated and the users will be affected >> in weird >> >>> ways without really knowing what happened. (Why am I logged out? >> Where did my >> >>> form submission go? Why does not this password reset link work?). >> This is >> >>> desirable in case the key is compromised and swift action must be >> taken. >> >>> >> >>> There are other situations when it would be nice to change the >> SECRET_KEY when >> >>> this sudden invalidation is not desirable: >> >>> >> >>> - When someone leaves a project/company that had access to the >> production >> >>> system. After SSH keys/login credentials is revoked the developer >> could >> >>> potentially have a copy of the secret key. It is essentially a >> backdoor with >> >>> full remote access. It would be wise to rotate the key in those >> cases. >> >>> >> >>> - Periodic and automatic rotations of keys to make it less useful in >> the >> >>> future. >> >>> >> >>> The current situation of a single SECRET_KEY makes key rotation >> impractical. If >> >>> you run a busy site with active users 24/7, there is never a nice >> time to >> >>> change the SECRET_KEY. >> >>> >> >>> A solution for this problem would be sign new secrets with a new key >> while >> >>> still allow signatures made with the old key to be considered valid >> at the same >> >>> time. Changing keys and having a couple of hours of overlap where >> signatures >> >>> from both keys are accepted would mitigate most of the user facing >> problems >> >>> with invalidating sessions, password reset links and form wizard >> progress. >> >>> >> >>> You could do this today by implementing your own session backend, >> message >> >>> storage backend and password reset token generator but that is >> cumbersome and >> >>> does not work across reusable apps that directly use low level Django >> signing >> >>> APIs unless they too provide hooks to provide your own secret. >> >>> >> >>> I propose a pluggable project wide secret key backend >> >>>
Re: Pluggable secret key backend
Very good point. I'd prefer a second setting though, named like OLD_SECRET_KEYS or VERIFICATION_SECRET_KEYS. If we're going to add a new setting, we might as well not force users who aren't rotating their keys to the new one, especially if they are semantically different. On Sun, 11 Nov 2018 at 18:32, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Good point, I can think of at least two apps of mine that would break. > Transitioning to a new setting makes more sense. > > -- > Aymeric. > > > > > On 11 Nov 2018, at 18:58, Tom Forbes wrote: > > > > Is it going to be easy to adjust the semantics of SECRET_KEY to support > sequences like that? I’d imagine a lot of third party packages that expect > SECRET_KEY to be a string would break in weird ways (thanks to both strings > and tuples of strings being iterables that yield strings). > > > > Here’s a quick search on GitHub: > https://github.com/search?q=%22settings.SECRET_KEY%22&type=Code > > > > To ease the backward compatibility concerns we could use SECRET_KEYS, > then make SECRET_KEY (if it is not explicitly defined) map to > SECRET_KEYS[0]? Third party packages using would not necessarily work with > the backwards verification but they would at least not break and continue > to work as expected. > > > > Tom > > > > > > > > > > > > On 11 November 2018 at 07:38:15, Aymeric Augustin ( > aymeric.augus...@polytechnique.org) wrote: > > > >> Hello, > >> > >> I think this is a great idea. > >> > >> As suggested by others, an even better default implementation would be: > >> > >> class SecretKeysBackend: > >> > >> def get_signing_key(self): > >> if isinstance(settings.SECRET_KEY, (list, tuple)): > >> return settings.SECRET_KEY[0] > >> else: > >> return settings.SECRET_KEY > >> > >> def get_verification_keys(self): > >> if isinstance(settings.SECRET_KEY, (list, tuple)): > >> return settings.SECRET_KEY > >> else: > >> return [settings.SECRET_KEY] > >> > >> Once Django is updated to take advantage of this feature, hat would > make key rotation practical for every Django user! > >> > >> (And it seems easier to adjust the semantics of SECRET_KEY than to > introduce a SECRET_KEYS settings.) > >> > >> Best regards, > >> > >> -- > >> Aymeric. > >> > >> > >> > >>> On 10 Nov 2018, at 11:12, Andreas Pelme wrote: > >>> > >>> Hi, > >>> > >>> settings.SECRET_KEY can be used for sessions, password resets, form > wizards and > >>> other cryptographic signatures via the signing APIs. Changing > SECRET_KEY means > >>> that all of those will be invalidated and the users will be affected > in weird > >>> ways without really knowing what happened. (Why am I logged out? Where > did my > >>> form submission go? Why does not this password reset link work?). This > is > >>> desirable in case the key is compromised and swift action must be > taken. > >>> > >>> There are other situations when it would be nice to change the > SECRET_KEY when > >>> this sudden invalidation is not desirable: > >>> > >>> - When someone leaves a project/company that had access to the > production > >>> system. After SSH keys/login credentials is revoked the developer > could > >>> potentially have a copy of the secret key. It is essentially a > backdoor with > >>> full remote access. It would be wise to rotate the key in those cases. > >>> > >>> - Periodic and automatic rotations of keys to make it less useful in > the > >>> future. > >>> > >>> The current situation of a single SECRET_KEY makes key rotation > impractical. If > >>> you run a busy site with active users 24/7, there is never a nice time > to > >>> change the SECRET_KEY. > >>> > >>> A solution for this problem would be sign new secrets with a new key > while > >>> still allow signatures made with the old key to be considered valid at > the same > >>> time. Changing keys and having a couple of hours of overlap where > signatures > >>> from both keys are accepted would mitigate most of the user facing > problems > >>> with invalidating sessions, password reset links and form wizard > progress. > >>> > >>> You could do this today by implementing your own session backend, > message > >>> storage backend and password reset token generator but that is > cumbersome and > >>> does not work across reusable apps that directly use low level Django > signing > >>> APIs unless they too provide hooks to provide your own secret. > >>> > >>> I propose a pluggable project wide secret key backend > >>> (settings.SECRET_KEY_BACKEND maybe?) with an API something like: > >>> > >>> class SecretKeyBackend: > >>> def get_signing_key(self): … > >>> def get_verification_keys(self): ... > >>> > >>> The default (and backward compatible) backend would then be > implemented as > >>> something like: > >>> > >>> class SecretKeySettingsBackend: > >>> def get_signing_key(self): > >>>return settings.SECRET_KEY > >>> def get_verification_keys(self): > >>>return [s
Re: Add Python 3.7 support for Django 1.11?
On Sunday, November 18, 2018 at 5:21:14 AM UTC+1, Josh Smeaton wrote: > > Should this also be a policy change, or is it better to maintain a > position of "if it's relatively easy and unobtrusive"? > Imo absolutely the latter. Personally I am (sadly to late) not really happy with official support at all. I would have merged the patch without documentation changes -- the docs now imply that we will fix it in the future too… -- 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/f1eb2df8-0664-46cf-b137-89d7ac8fa935%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
