also, some more background http://blog.phusion.nl/2013/01/04/securing-the-rails-session-secret/

Ohad Levy wrote:

also, some more background http://blog.phusion.nl/2013/01/04/securing-the-rails-session-secret/

I don't think that this: hash("#{machine_uuid}-#{hostname}-#{app_name}")
is good enough. If there are users with an operator role which have ssh access to look into logs or do some cleanup tasks that are not administrators in foreman webapp, then we have privilege escalation here. Hostname and app_name are known and uuid can be read with ssh access from a machine....
Anyway nice read, Ohad.

Greets Sandor

I like the rake task idea. To make it usable without running the task, we could comment out or delete secret_token.rb, then add an initializer after that generates + stores a key in tmp/ if the token's unset. People are then able to generate a static one with the rake task if they need it, which overrides the temporary secret.

Dominic Cleal wrote:

Implemented the above, kept the rake task: https://github.com/theforeman/foreman/pull/353

Katello generates a secret during RPM installation too, we could do the same in our package post installs by running the rake task.

It's not a good idea to use activesupport's SecureRandom, because they removed it: https://github.com/rails/rails/commit/1170cceaaec8c0c8aef173913405be1456e4b2be#activesupport/lib/active_support