7 ms·

The only issues I have with this release is that they could of waited until after the holidays. I have a feeling we'll see a security patch right before xmas.

The only issues I have with this release is that they could of waited until after the holidays. I have a feeling we'll see a security patch right before xmas. The second issue I have is `secrets` should be entirely removed from the framework. These settings should NOT be stored at the file level, it should be handled by environment flags. I feel this is a fundamentally broken feature. Spring is neat, was it just a port of Zeus into Rails?

steveklabnik 13y ago
> Spring is neat, was it just a port of Zeus into Rails? Conceptually, they're the same thing, but since Zeus is written in Go, it's totally different code. > These settings should NOT be stored at the file level, it should be handled by environment flags. I feel this is a fundamentally broken feature. I personally use environment variables to handle this case, but basically, every single approach has pros and cons, not to mention that there's legacy codebases... small steps.
- 1qaz2wsx3edc 13y ago
  > Conceptually, they're the same thing, but since Zeus is written in Go, it's totally different code. Thank you, this is what I wanted to hear. :) > I personally use environment variables to handle this case, but basically, every single approach has pros and cons, not to mention that there's legacy codebases... small steps. I just think it's a bloated feature when `Rails.application.config` already exists.
danso 13y ago
No...Zeus is its own thing, AFAIK, though I guess it's described (by the Zeus maintainer) as "like Zeus but in pure Ruby, totally automatic, alpha and limited compatibility" https://github.com/burke/zeus#related-gems https://github.com/burke/zeus#related-gems I started using Zeus a couple of weeks ago and then switched over to Spring last week...I never figured out how to get the custom Zeus files to let me run regular rails/rake commands with certain flags and parameters, but Spring pretty much worked right out of the box. It works so well that I've been wary that it might cause issues in edge cases of test configuration, but haven't run into any yet...and now that it's a part of Rails, guess I'll be even less wary. It's definitely changed how I do TDD for Rails, in that I will actually do TDD for Rails, because the tests run so quickly. Yes, being hindered by Rails bootup just to run tests might be indicative of unneeded coupling, but sometimes a project doesn't require great abstraction, but still needs decent integration coverage. Spring is pretty handy for that.
- bratsche 13y ago
  Wow, that's an interesting description (the "alpha and limited compatibility" part). I've used both Zeus and Spring and I've found Spring to be more reliable. I've run into a number of issues with Zeus where it crapped out on me. I've never hit any such issues with Spring, it's felt very stable. I see the Zeus issue (#254) that plagued me the most has been fixed now though: it can now accept arbitrary-length commands. So maybe it's more usable now.
mscarborough 13y ago
If a project owner updates prod to a new beta of a point release right during the holiday season, that's entirely their fault, not the rails team who delivered something fun for people to mess around with.
- 1qaz2wsx3edc 13y ago
  This is a fair criticism, I totally missed the beta flag. Cheers.
tomphoolery 13y ago
> These settings should NOT be stored at the file level, it > should be handled by environment flags. I feel this is a > fundamentally broken feature. According to https://github.com/rails/rails/blob/master/railties/lib/rails/application.rb#L304 https://github.com/rails/rails/blob/master/railties/lib/rail..., this YAML file is handled like every other YAML by Rails...it's parsed through ERB first. That means, you can do something like development: secret_key_base: <%= ENV['RAILS_SECRET'] %> And reference it with that `Rails.configuration` business. With this, you basically get a nice little API for recalling env variables. Pretty neat!
- 1qaz2wsx3edc 13y ago
  Yes, I'm aware, but what was the problem with storing configurations under `Rails.application.config.thing` as ENV['vars']? It just seems like bloated featured.
  - xs_kid 13y ago
    No everyone likes that approach, some people prefers to save tokens in yaml files (see on github, you will find a dozen o plugins that do same thing)
    - 1qaz2wsx3edc 13y ago
      Just because you can, and others do, doesn't necessarily make it a good idea. By writing & encouraging developers to use the new `secrets` API, we expose them to a bad practise. Not only that, but other solutions exist (like using `Rails.application.config`). I'm not against configuration files per-say, I'm against secrets as persisted values in a codebase. Doing this is bad: https://github.com/search?l=ruby&q=cookie_secret&ref=cmdform&type=Code https://github.com/search?l=ruby&q=cookie_secret&ref=cmdform...
      - ds_ 13y ago
        Wouldn't the secrets file be added to gitignore?
jrochkind1 13y ago
If you don't store secrets in a file... how do you share them? When a new developer comes on board; when a new deploy machine is provisioned; etc. Honest question, I've been trying to figure out the best way to do this. Even without considering deploying secrets to a new machine, doesn't 'keep them in environment variables' usually mean store in a .bashrc or something, which is of course still a file?
- bri3d 13y ago
  Chef encrypted databags or a similar approach where the environment variable is encrypted on disk and decrypted at runtime. Obviously your deployment nodes eventually need the secret in plaintext and all end up with the key, but at least the information is encrypted at rest (for example in your source control, a common source of breaches). It doesn't seem wise to share secrets amongst developers (especially new ones) to me - that sounds like a recipe for disaster. GitHub accidentally deleted their production database by giving developers access to production secrets on their local machines a few years ago - regardless of how much you trust your people it's not a particularly solid plan.
- benesch 13y ago
  The idea is to keep them out of version control. At least ~/.bashrc won't end up in a repository under normal circumstances. You have no idea what pieces of your code base may eventually be open-sourced. For small teams, a good solution is to keep a GPG-encrypted file in Dropbox or another team file share. When you onboard a new developer, someone reencrypts the file with the new recipient. If you use Chef, the knife-briefcase plugin will handle this for you. For large teams, there shouldn't be any secrets that need to be disributed. In an ideal world, at least. Each user should get his/her own account on each server, his/her own AWS credentials, etc. At some point you'll run into sharing a secret among production servers (SSL certs, for example), but you should never need to share secrets among developers in a well-designed system. Individual accounts allows useful audit trails and limits the damage if a credential is leaked.

steveklabnik 13y ago

> Spring is neat, was it just a port of Zeus into Rails? Conceptually, they're the same thing, but since Zeus is written in Go, it's totally different code. > These settings should NOT be stored at the file level, it should be handled by environment flags. I feel this is a fundamentally broken feature. I personally use environment variables to handle this case, but basically, every single approach has pros and cons, not to mention that there's legacy codebases... small steps.

1qaz2wsx3edc 13y ago
> Conceptually, they're the same thing, but since Zeus is written in Go, it's totally different code. Thank you, this is what I wanted to hear. :) > I personally use environment variables to handle this case, but basically, every single approach has pros and cons, not to mention that there's legacy codebases... small steps. I just think it's a bloated feature when `Rails.application.config` already exists.

danso 13y ago

No...Zeus is its own thing, AFAIK, though I guess it's described (by the Zeus maintainer) as "like Zeus but in pure Ruby, totally automatic, alpha and limited compatibility" https://github.com/burke/zeus#related-gems https://github.com/burke/zeus#related-gems I started using Zeus a couple of weeks ago and then switched over to Spring last week...I never figured out how to get the custom Zeus files to let me run regular rails/rake commands with certain flags and parameters, but Spring pretty much worked right out of the box. It works so well that I've been wary that it might cause issues in edge cases of test configuration, but haven't run into any yet...and now that it's a part of Rails, guess I'll be even less wary. It's definitely changed how I do TDD for Rails, in that I will actually do TDD for Rails, because the tests run so quickly. Yes, being hindered by Rails bootup just to run tests might be indicative of unneeded coupling, but sometimes a project doesn't require great abstraction, but still needs decent integration coverage. Spring is pretty handy for that.

bratsche 13y ago
Wow, that's an interesting description (the "alpha and limited compatibility" part). I've used both Zeus and Spring and I've found Spring to be more reliable. I've run into a number of issues with Zeus where it crapped out on me. I've never hit any such issues with Spring, it's felt very stable. I see the Zeus issue (#254) that plagued me the most has been fixed now though: it can now accept arbitrary-length commands. So maybe it's more usable now.

mscarborough 13y ago

If a project owner updates prod to a new beta of a point release right during the holiday season, that's entirely their fault, not the rails team who delivered something fun for people to mess around with.

1qaz2wsx3edc 13y ago
This is a fair criticism, I totally missed the beta flag. Cheers.

tomphoolery 13y ago

> These settings should NOT be stored at the file level, it > should be handled by environment flags. I feel this is a > fundamentally broken feature. According to https://github.com/rails/rails/blob/master/railties/lib/rails/application.rb#L304 https://github.com/rails/rails/blob/master/railties/lib/rail..., this YAML file is handled like every other YAML by Rails...it's parsed through ERB first. That means, you can do something like development: secret_key_base: <%= ENV['RAILS_SECRET'] %> And reference it with that `Rails.configuration` business. With this, you basically get a nice little API for recalling env variables. Pretty neat!

1qaz2wsx3edc 13y ago
Yes, I'm aware, but what was the problem with storing configurations under `Rails.application.config.thing` as ENV['vars']? It just seems like bloated featured.
- xs_kid 13y ago
  No everyone likes that approach, some people prefers to save tokens in yaml files (see on github, you will find a dozen o plugins that do same thing)
  - 1qaz2wsx3edc 13y ago
    Just because you can, and others do, doesn't necessarily make it a good idea. By writing & encouraging developers to use the new `secrets` API, we expose them to a bad practise. Not only that, but other solutions exist (like using `Rails.application.config`). I'm not against configuration files per-say, I'm against secrets as persisted values in a codebase. Doing this is bad: https://github.com/search?l=ruby&q=cookie_secret&ref=cmdform&type=Code https://github.com/search?l=ruby&q=cookie_secret&ref=cmdform...
    - ds_ 13y ago
      Wouldn't the secrets file be added to gitignore?

jrochkind1 13y ago

If you don't store secrets in a file... how do you share them? When a new developer comes on board; when a new deploy machine is provisioned; etc. Honest question, I've been trying to figure out the best way to do this. Even without considering deploying secrets to a new machine, doesn't 'keep them in environment variables' usually mean store in a .bashrc or something, which is of course still a file?

bri3d 13y ago
Chef encrypted databags or a similar approach where the environment variable is encrypted on disk and decrypted at runtime. Obviously your deployment nodes eventually need the secret in plaintext and all end up with the key, but at least the information is encrypted at rest (for example in your source control, a common source of breaches). It doesn't seem wise to share secrets amongst developers (especially new ones) to me - that sounds like a recipe for disaster. GitHub accidentally deleted their production database by giving developers access to production secrets on their local machines a few years ago - regardless of how much you trust your people it's not a particularly solid plan.
benesch 13y ago
The idea is to keep them out of version control. At least ~/.bashrc won't end up in a repository under normal circumstances. You have no idea what pieces of your code base may eventually be open-sourced. For small teams, a good solution is to keep a GPG-encrypted file in Dropbox or another team file share. When you onboard a new developer, someone reencrypts the file with the new recipient. If you use Chef, the knife-briefcase plugin will handle this for you. For large teams, there shouldn't be any secrets that need to be disributed. In an ideal world, at least. Each user should get his/her own account on each server, his/her own AWS credentials, etc. At some point you'll run into sharing a secret among production servers (SSL certs, for example), but you should never need to share secrets among developers in a well-designed system. Individual accounts allows useful audit trails and limits the damage if a credential is leaked.