On Sunday, September 23, 2012 3:11:51 PM UTC+2, Chris McDonough wrote:
> On Sun, 2012-09-23 at 05:54 -0700, Florian Rüchel wrote:
> > How about a script that's part of the framework itself? We > > have pserve, > > pcreate... how about
> > pkeygen [-w <filename>]
> > or
> > pyramid-keygen [-w <filename>]
> > I like this idea very much. I would like to either get this usage > > approved or I would just build a simple function inside pyramid. > > However, such a function belongs more into an installation than into > > application code. Can you tell me how to build such a script that runs > > on both Windows and Linux? I would like to see it implemented in this > > way if Chris approves.
> Who will use it and when would they use it?
Well it will be used by the user deploying the application. This can be the developer or even multiple end-users (if the application itself is distributed). In both cases there would be a simple deployment instruction:
"Upon installation you need to execute 'pyramid-keygen -w cookie_secret -b 256'" or similar. Then you have a secret file and can use it in your application. Otherwise each developer has to develop their own method of generating such a secret during the deployment process. Furthermore, we could then add a hint to the documentation to use this if they want a strong secret (see below).
> > On a seperate note: I have started on improving the documentation. As > > a first step, I have edited the `narr/authentication.rst` to include a > > note and have documented the API for > > `pyramid.authentication.AuthTktAuthenticationPolicy` (better > > documentation for secret, add documentation for hashalg). My question > > is now how would you handle this in regards to the documentation. I > > thought about adding this (or a similar) note everywhere this policy > > is used. This should raise the awareness everywhere the docs are read > > (e.g. tutorials). Furthermore, since we would clearly recommend to use > > something like SHA256 if MD5 is not explicitly needed, should we > > change the code examples to include a better hashalg (instead of just > > documenting it)? I would vote for a yes, since I don't see any > > disadvantage: If you build a new application, you should always use > > another algorithm and as shown above mod_auth_tkt can also easily > > handle other algorithms if configured correctly.
> I didn't know we already had a mergeable patch for the hashalg stuff. > The last patch I saw seemed maybe a little overwrought. Until we figure > that out, I'd hold off on changing docs.
Yeah, I took a step back, changed it to be only a callable and made it very simple again. Take look at the corresponding commit and tell me if it is still too much.
If you approve, I would really recommend changing the docs at least in regards to a notice that the default behavior is at least not *that* secure.
> > I would like to hear some opinions on this matter before I start to > > make big changes and only end up reverting them because you don't like > > it. My first version can be found here:
> > I have also created a small `gensecret` function based on the ideas of > > Daniel and Domen (but with added Python3 compatibility):
> https://github.com/Javex/pyramid/commit/d4f2943fa50e34f682f8097dccee2... > > This function is not what I expect in the final version but it shows > > where I would like to go with this: Provide a function that makes it > > easier for a user to obtain a strong secret. Either we use it this way > > or the above mentioned seperate script, that really doesn't matter.
On Sun, 2012-09-23 at 06:54 -0700, Florian Rüchel wrote:
> On Sunday, September 23, 2012 3:11:51 PM UTC+2, Chris McDonough wrote:
> On Sun, 2012-09-23 at 05:54 -0700, Florian Rüchel wrote:
> > How about a script that's part of the framework
> itself? We > > have pserve, > > pcreate... how about
> > pkeygen [-w <filename>]
> > or
> > pyramid-keygen [-w <filename>]
> > I like this idea very much. I would like to either get this
> usage > > approved or I would just build a simple function inside
> pyramid. > > However, such a function belongs more into an installation
> than into > > application code. Can you tell me how to build such a script
> that runs > > on both Windows and Linux? I would like to see it
> implemented in this > > way if Chris approves.
> Who will use it and when would they use it?
> Well it will be used by the user deploying the application. This can
> be the developer or even multiple end-users (if the application itself
> is distributed). In both cases there would be a simple deployment
> instruction:
> "Upon installation you need to execute 'pyramid-keygen -w
> cookie_secret -b 256'" or similar. Then you have a secret file and can
> use it in your application. Otherwise each developer has to develop
> their own method of generating such a secret during the deployment
> process. Furthermore, we could then add a hint to the documentation to
> use this if they want a strong secret (see below).
There's currently no machinery in Pyramid that can use a "secret file".
Instead, developers are expected to add a secret value to their .ini
file and use it as input to the AuthTktAuthenticationPolicy constructor.
So I'd be -1 on something that created a file, unless there's some other
use case that this sweater-thread of a topic has convinced us must be
implemented along the lines of "the secret must be in another file".
If the purpose is only to output a "sufficiently random" string, then I
personally don't think we need to get into the business of supplying
software that does that, although we might supply documentation for UNIX
and for Windows that helps people do that using third-party tools. If
that turns out to be untenable for some reason, then I might reconsider
writing software that helps.
> > On a seperate note: I have started on improving the
> documentation. As > > a first step, I have edited the `narr/authentication.rst` to
> include a > > note and have documented the API for > > `pyramid.authentication.AuthTktAuthenticationPolicy`
> (better > > documentation for secret, add documentation for hashalg). My
> question > > is now how would you handle this in regards to the
> documentation. I > > thought about adding this (or a similar) note everywhere
> this policy > > is used. This should raise the awareness everywhere the docs
> are read > > (e.g. tutorials). Furthermore, since we would clearly
> recommend to use > > something like SHA256 if MD5 is not explicitly needed,
> should we > > change the code examples to include a better hashalg
> (instead of just > > documenting it)? I would vote for a yes, since I don't see
> any > > disadvantage: If you build a new application, you should
> always use > > another algorithm and as shown above mod_auth_tkt can also
> easily > > handle other algorithms if configured correctly.
> I didn't know we already had a mergeable patch for the hashalg
> stuff. > The last patch I saw seemed maybe a little overwrought. Until
> we figure > that out, I'd hold off on changing docs.
> Yeah, I took a step back, changed it to be only a callable and made it
> very simple again. Take look at the corresponding commit and tell me
> if it is still too much.
I'll defer to Domen on this.
> If you approve, I would really recommend changing the docs at least in
> regards to a notice that the default behavior is at least not *that*
> secure.
On Sun, Sep 23, 2012 at 4:05 PM, Chris McDonough <chr...@plope.com> wrote:
> On Sun, 2012-09-23 at 06:54 -0700, Florian Rüchel wrote:
> > On Sunday, September 23, 2012 3:11:51 PM UTC+2, Chris McDonough wrote:
> > On Sun, 2012-09-23 at 05:54 -0700, Florian Rüchel wrote:
> > > How about a script that's part of the framework
> > itself? We
> > > have pserve,
> > > pcreate... how about
> > > pkeygen [-w <filename>]
> > > or
> > > pyramid-keygen [-w <filename>]
> > > I like this idea very much. I would like to either get this
> > usage
> > > approved or I would just build a simple function inside
> > pyramid.
> > > However, such a function belongs more into an installation
> > than into
> > > application code. Can you tell me how to build such a script
> > that runs
> > > on both Windows and Linux? I would like to see it
> > implemented in this
> > > way if Chris approves.
> > Who will use it and when would they use it?
> > Well it will be used by the user deploying the application. This can
> > be the developer or even multiple end-users (if the application itself
> > is distributed). In both cases there would be a simple deployment
> > instruction:
> > "Upon installation you need to execute 'pyramid-keygen -w
> > cookie_secret -b 256'" or similar. Then you have a secret file and can
> > use it in your application. Otherwise each developer has to develop
> > their own method of generating such a secret during the deployment
> > process. Furthermore, we could then add a hint to the documentation to
> > use this if they want a strong secret (see below).
> There's currently no machinery in Pyramid that can use a "secret file".
> Instead, developers are expected to add a secret value to their .ini
> file and use it as input to the AuthTktAuthenticationPolicy constructor.
> So I'd be -1 on something that created a file, unless there's some other
> use case that this sweater-thread of a topic has convinced us must be
> implemented along the lines of "the secret must be in another file".
> If the purpose is only to output a "sufficiently random" string, then I
> personally don't think we need to get into the business of supplying
> software that does that, although we might supply documentation for UNIX
> and for Windows that helps people do that using third-party tools. If
> that turns out to be untenable for some reason, then I might reconsider
> writing software that helps.
> > > On a seperate note: I have started on improving the
> > documentation. As
> > > a first step, I have edited the `narr/authentication.rst` to
> > include a
> > > note and have documented the API for
> > > `pyramid.authentication.AuthTktAuthenticationPolicy`
> > (better
> > > documentation for secret, add documentation for hashalg). My
> > question
> > > is now how would you handle this in regards to the
> > documentation. I
> > > thought about adding this (or a similar) note everywhere
> > this policy
> > > is used. This should raise the awareness everywhere the docs
> > are read
> > > (e.g. tutorials). Furthermore, since we would clearly
> > recommend to use
> > > something like SHA256 if MD5 is not explicitly needed,
> > should we
> > > change the code examples to include a better hashalg
> > (instead of just
> > > documenting it)? I would vote for a yes, since I don't see
> > any
> > > disadvantage: If you build a new application, you should
> > always use
> > > another algorithm and as shown above mod_auth_tkt can also
> > easily
> > > handle other algorithms if configured correctly.
> > I didn't know we already had a mergeable patch for the hashalg
> > stuff.
> > The last patch I saw seemed maybe a little overwrought. Until
> > we figure
> > that out, I'd hold off on changing docs.
> > Yeah, I took a step back, changed it to be only a callable and made it
> > very simple again. Take look at the corresponding commit and tell me
> > if it is still too much.
> I'll defer to Domen on this.
> > If you approve, I would really recommend changing the docs at least in
> > regards to a notice that the default behavior is at least not *that*
> > secure.
> Proceeding one step at a time.
> - C
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-devel" group.
> To post to this group, send email to pylons-devel@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-devel+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-devel?hl=en.
> On Sun, Sep 23, 2012 at 4:05 PM, Chris McDonough <chr...@plope.com<javascript:>
> > wrote:
>> On Sun, 2012-09-23 at 06:54 -0700, Florian Rüchel wrote:
>> > On Sunday, September 23, 2012 3:11:51 PM UTC+2, Chris McDonough wrote:
>> > On Sun, 2012-09-23 at 05:54 -0700, Florian Rüchel wrote:
>> > > How about a script that's part of the framework
>> > itself? We
>> > > have pserve,
>> > > pcreate... how about
>> > > pkeygen [-w <filename>]
>> > > or
>> > > pyramid-keygen [-w <filename>]
>> > > I like this idea very much. I would like to either get this
>> > usage
>> > > approved or I would just build a simple function inside
>> > pyramid.
>> > > However, such a function belongs more into an installation
>> > than into
>> > > application code. Can you tell me how to build such a script
>> > that runs
>> > > on both Windows and Linux? I would like to see it
>> > implemented in this
>> > > way if Chris approves.
>> > Who will use it and when would they use it?
>> > Well it will be used by the user deploying the application. This can
>> > be the developer or even multiple end-users (if the application itself
>> > is distributed). In both cases there would be a simple deployment
>> > instruction:
>> > "Upon installation you need to execute 'pyramid-keygen -w
>> > cookie_secret -b 256'" or similar. Then you have a secret file and can
>> > use it in your application. Otherwise each developer has to develop
>> > their own method of generating such a secret during the deployment
>> > process. Furthermore, we could then add a hint to the documentation to
>> > use this if they want a strong secret (see below).
>> There's currently no machinery in Pyramid that can use a "secret file".
>> Instead, developers are expected to add a secret value to their .ini
>> file and use it as input to the AuthTktAuthenticationPolicy constructor.
>> So I'd be -1 on something that created a file, unless there's some other
>> use case that this sweater-thread of a topic has convinced us must be
>> implemented along the lines of "the secret must be in another file".
>> If the purpose is only to output a "sufficiently random" string, then I
>> personally don't think we need to get into the business of supplying
>> software that does that, although we might supply documentation for UNIX
>> and for Windows that helps people do that using third-party tools. If
>> that turns out to be untenable for some reason, then I might reconsider
>> writing software that helps.
>> > > On a seperate note: I have started on improving the
>> > documentation. As
>> > > a first step, I have edited the `narr/authentication.rst` to
>> > include a
>> > > note and have documented the API for
>> > > `pyramid.authentication.AuthTktAuthenticationPolicy`
>> > (better
>> > > documentation for secret, add documentation for hashalg). My
>> > question
>> > > is now how would you handle this in regards to the
>> > documentation. I
>> > > thought about adding this (or a similar) note everywhere
>> > this policy
>> > > is used. This should raise the awareness everywhere the docs
>> > are read
>> > > (e.g. tutorials). Furthermore, since we would clearly
>> > recommend to use
>> > > something like SHA256 if MD5 is not explicitly needed,
>> > should we
>> > > change the code examples to include a better hashalg
>> > (instead of just
>> > > documenting it)? I would vote for a yes, since I don't see
>> > any
>> > > disadvantage: If you build a new application, you should
>> > always use
>> > > another algorithm and as shown above mod_auth_tkt can also
>> > easily
>> > > handle other algorithms if configured correctly.
>> > I didn't know we already had a mergeable patch for the hashalg
>> > stuff.
>> > The last patch I saw seemed maybe a little overwrought. Until
>> > we figure
>> > that out, I'd hold off on changing docs.
>> > Yeah, I took a step back, changed it to be only a callable and made it
>> > very simple again. Take look at the corresponding commit and tell me
>> > if it is still too much.
>> I'll defer to Domen on this.
>> > If you approve, I would really recommend changing the docs at least in
>> > regards to a notice that the default behavior is at least not *that*
>> > secure.
>> Proceeding one step at a time.
>> - C
>> --
>> You received this message because you are subscribed to the Google Groups >> "pylons-devel" group.
>> To post to this group, send email to pylons...@googlegroups.com<javascript:>
>> .
>> To unsubscribe from this group, send email to >> pylons-devel...@googlegroups.com <javascript:>.
>> For more options, visit this group at >> http://groups.google.com/group/pylons-devel?hl=en.
>> On Sun, Sep 23, 2012 at 4:05 PM, Chris McDonough <chr...@plope.com>wrote:
>>> On Sun, 2012-09-23 at 06:54 -0700, Florian Rüchel wrote:
>>> > On Sunday, September 23, 2012 3:11:51 PM UTC+2, Chris McDonough wrote:
>>> > On Sun, 2012-09-23 at 05:54 -0700, Florian Rüchel wrote:
>>> > > How about a script that's part of the framework
>>> > itself? We
>>> > > have pserve,
>>> > > pcreate... how about
>>> > > pkeygen [-w <filename>]
>>> > > or
>>> > > pyramid-keygen [-w <filename>]
>>> > > I like this idea very much. I would like to either get this
>>> > usage
>>> > > approved or I would just build a simple function inside
>>> > pyramid.
>>> > > However, such a function belongs more into an installation
>>> > than into
>>> > > application code. Can you tell me how to build such a script
>>> > that runs
>>> > > on both Windows and Linux? I would like to see it
>>> > implemented in this
>>> > > way if Chris approves.
>>> > Who will use it and when would they use it?
>>> > Well it will be used by the user deploying the application. This can
>>> > be the developer or even multiple end-users (if the application itself
>>> > is distributed). In both cases there would be a simple deployment
>>> > instruction:
>>> > "Upon installation you need to execute 'pyramid-keygen -w
>>> > cookie_secret -b 256'" or similar. Then you have a secret file and can
>>> > use it in your application. Otherwise each developer has to develop
>>> > their own method of generating such a secret during the deployment
>>> > process. Furthermore, we could then add a hint to the documentation to
>>> > use this if they want a strong secret (see below).
>>> There's currently no machinery in Pyramid that can use a "secret file".
>>> Instead, developers are expected to add a secret value to their .ini
>>> file and use it as input to the AuthTktAuthenticationPolicy constructor.
>>> So I'd be -1 on something that created a file, unless there's some other
>>> use case that this sweater-thread of a topic has convinced us must be
>>> implemented along the lines of "the secret must be in another file".
>>> If the purpose is only to output a "sufficiently random" string, then I
>>> personally don't think we need to get into the business of supplying
>>> software that does that, although we might supply documentation for UNIX
>>> and for Windows that helps people do that using third-party tools. If
>>> that turns out to be untenable for some reason, then I might reconsider
>>> writing software that helps.
>>> > > On a seperate note: I have started on improving the
>>> > documentation. As
>>> > > a first step, I have edited the `narr/authentication.rst` to
>>> > include a
>>> > > note and have documented the API for
>>> > > `pyramid.authentication.**AuthTktAuthenticationPolicy`
>>> > (better
>>> > > documentation for secret, add documentation for hashalg). My
>>> > question
>>> > > is now how would you handle this in regards to the
>>> > documentation. I
>>> > > thought about adding this (or a similar) note everywhere
>>> > this policy
>>> > > is used. This should raise the awareness everywhere the docs
>>> > are read
>>> > > (e.g. tutorials). Furthermore, since we would clearly
>>> > recommend to use
>>> > > something like SHA256 if MD5 is not explicitly needed,
>>> > should we
>>> > > change the code examples to include a better hashalg
>>> > (instead of just
>>> > > documenting it)? I would vote for a yes, since I don't see
>>> > any
>>> > > disadvantage: If you build a new application, you should
>>> > always use
>>> > > another algorithm and as shown above mod_auth_tkt can also
>>> > easily
>>> > > handle other algorithms if configured correctly.
>>> > I didn't know we already had a mergeable patch for the hashalg
>>> > stuff.
>>> > The last patch I saw seemed maybe a little overwrought. Until
>>> > we figure
>>> > that out, I'd hold off on changing docs.
>>> > Yeah, I took a step back, changed it to be only a callable and made it
>>> > very simple again. Take look at the corresponding commit and tell me
>>> > if it is still too much.
>>> I'll defer to Domen on this.
>>> > If you approve, I would really recommend changing the docs at least in
>>> > regards to a notice that the default behavior is at least not *that*
>>> > secure.
>>> Proceeding one step at a time.
>>> - C
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "pylons-devel" group.
>>> To post to this group, send email to pylons...@googlegroups.com.
>>> To unsubscribe from this group, send email to pylons-devel...@**
>>> googlegroups.com.
> To post to this group, send email to pylons-devel@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-devel+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-devel?hl=en.
