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.
