There are some visual glitches around the catalog dropdown buttons.
For instance, the one on pools#show is positioned a bit below the other
buttons in the same row.
This is my attempt at fixing it, but my work with CSS is usually more struggle
I would appreciate a review from someone who actually understands CSS and
This adds some rake tasks I've cobbled together to automate things I do a lot. (Okay, some more often than others.)
I was on the fence about whether or not this needs an ACK, but I wouldn't mind a set of eyes just since I haven't done much with rake tasks so I could be doing something foolish and not realize it. Hopefully others will find it useful, and maybe contribute others.
I just discovered that we are not, by default, modifying the secret_token that Rails uses to sign its cookies. (For some reason, the Rails security guide makes no mention of this.) It is my understanding that, if an attacker knows the secret token a Rails installation is using, they can modify session cookies however they wish (e.g., becoming an administrator) and then use the token to sign the cookie so Rails accepts it.
This patch adds a rake task to generate a new token and replace the one in the config/initializers/secret_token.rb file. It also invokes this task in the %post section of the RPM spec file, so that it will be re-generated when installing. (I don't think invoking it from aeolus-configure (in puppet) would be adequate, as it would leave people vulnerable until they ran aeolus-configure the first time.)
I'm not super-experienced with RPM specs, so someone should review the RPM spec and make sure I'm not doing anything absurd. Since the rake task is part of the app, it has to run in %post, since it won't exist in %install. Note that the added "Requires: rubygem(rake)" isn't really a new dependency. Rails requires it, but it was suggested that, since we're using it in the spec, we should explicitly require it.
One small side-effect of this patch is that a user who updates to a new RPM will have their token regenerated. This would invalidate existing cookies, which will cause users to be logged out. I think this is perfectly-acceptable and possibly desirable, but if you disagree, we could change the rake task to look for the specific default token and only replace that.
We may want to backport this change as I believe this vulnerability has existed from the beginning.
Currently, the aeolus-configserver-proxy spec does not require mod_ssl.
Strangely, up until now mod_ssl was automagically getting installed when httpd
(or aeolus-configserver-proxy) was installed.
After testing on a sparkling new ec2 instance, it's clear that whatever black
magic was in play before is now gone.
Now, aeolus-configserver-proxy explicitly requires mod_ssl.
(pushing to the master branch)