Created pull request, changed the approach a bit: https://github.com/Pylons/pyramid/pull/695
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+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/pylons-devel?hl=en. > > -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
