Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails 4.1.0 beta1 released

weblog.rubyonrails.org

Post reply on HN
Print view View original

31–40 of 61 posts

Re: Rails 4.1.0 beta1 released

#31

Post by xs_kid »

1qaz2wsx3edc wrote: post #27
tomphoolery wrote: post #20

Earlier quoted context omitted.

> 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/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: And reference it with that `Rail…

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.

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)

Re: Rails 4.1.0 beta1 released

#32

Post by jrochkind1 »

1qaz2wsx3edc wrote: post #10

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 po…

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?

Re: Rails 4.1.0 beta1 released

#33

Post by bri3d »

jrochkind1 wrote: post #32
1qaz2wsx3edc wrote: post #10

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 po…

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?

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.

Re: Rails 4.1.0 beta1 released

#34

Post by benesch »

jrochkind1 wrote: post #32
1qaz2wsx3edc wrote: post #10

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 po…

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?

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.

Re: Rails 4.1.0 beta1 released

#36

Post by 1qaz2wsx3edc »

xs_kid wrote: post #31
1qaz2wsx3edc wrote: post #27

Earlier quoted context omitted.

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.

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)

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...

Re: Rails 4.1.0 beta1 released

#37

Post by jenseng »

whalesalad wrote: post #7

Wow. These are STELLAR improvements! Check out the release notes here: https://github.com/rails/rails/blob/master/guides/source/4_1... So excited about all of it. Native enum is a blessing. Took me a while to figure it out but here is the required line for your Gemfile: gem 'rails', '4.0.1.beta1' # This works too, but isn't required (thanks to cantoniodasilva's comment below) # gem 'rails', github: 'rails/rails', tag…

It's a shame these aren't actual database ENUMs, but rather ints (with the mapping in ruby land): https://github.com/rails/rails/commit/db41eb8a6ea88b854bf5cd...

Even a text column would be preferable IMO ... you wouldn't need to worry about remapping if a value got removed, it's more easily queryable, and it's certainly more legible if you're looking at raw data (say, via psql). Plus you probably won't really save much (any?) space with an (64-bit) int.

Re: Rails 4.1.0 beta1 released

#38

Post by whalesalad »

jenseng wrote: post #37
whalesalad wrote: post #7

Wow. These are STELLAR improvements! Check out the release notes here: https://github.com/rails/rails/blob/master/guides/source/4_1... So excited about all of it. Native enum is a blessing. Took me a while to figure it out but here is the required line for your Gemfile: gem 'rails', '4.0.1.beta1' # This works too, but isn't required (thanks to cantoniodasilva's comment below) # gem 'rails', github: 'rails/rails', tag…

It's a shame these aren't actual database ENUMs, but rather ints (with the mapping in ruby land): https://github.com/rails/rails/commit/db41eb8a6ea88b854bf5cd... Even a text column would be preferable IMO ... you wouldn't need to worry about remapping if a value got removed, it's more easily queryable, and it's certainly more legible if you're looking at raw data (say, via psql). Plus you probably won't really save m…

I agree with all of your points, but I don't think it's a shame. It's an awesome contribution and will make my work a lot easier on future projects. I'm personally going to try and take a stab at implementing this with strings versus ints though, since I agree you don't really save much by using the int and it's much friendlier for debug and future changes.

Re: Rails 4.1.0 beta1 released

#39

Post by bratsche »

danso wrote: post #15
1qaz2wsx3edc wrote: post #10

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 po…

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 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 a…

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.

Re: Rails 4.1.0 beta1 released

#40

Post by yxhuvud »

jenseng wrote: post #37
whalesalad wrote: post #7

Wow. These are STELLAR improvements! Check out the release notes here: https://github.com/rails/rails/blob/master/guides/source/4_1... So excited about all of it. Native enum is a blessing. Took me a while to figure it out but here is the required line for your Gemfile: gem 'rails', '4.0.1.beta1' # This works too, but isn't required (thanks to cantoniodasilva's comment below) # gem 'rails', github: 'rails/rails', tag…

It's a shame these aren't actual database ENUMs, but rather ints (with the mapping in ruby land): https://github.com/rails/rails/commit/db41eb8a6ea88b854bf5cd... Even a text column would be preferable IMO ... you wouldn't need to worry about remapping if a value got removed, it's more easily queryable, and it's certainly more legible if you're looking at raw data (say, via psql). Plus you probably won't really save m…

Considering the sad state of mysql enums with the pitfalls it have, it really isn't a shame.

I totally agree that a text column would have been preferable though.

Post reply on HN