7 ms·

Wow. Please, please tell me that these are just hobby projects which have this happening. I can understand a beginner who doesn't understand git ignore doing

by JPKab 14y ago

Wow. Please, please tell me that these are just hobby projects which have this happening. I can understand a beginner who doesn't understand git ignore doing this, but if there are people building products with this ignorance, that is troubling. I can see why a lot of greybeards hate frameworks, because someone who builds web apps with a much more bare bones framework, (Sinatra, Webapp2, Express, etc) most likely understands the fundamentals of encryption/hashing simply because of the fact that lighter frameworks require understanding the fundamentals in general. This isn't to say that a developer for one of these frameworks couldn't easily overlook adding the files with secret_tokens in them to the .gitignore.

iaw 14y ago
I consider this in the same realm as storing passwords to plain text. People do it out of ignorance until they're learn the hard way not to (or some kind soul saves them from that disaster).
- ajross 14y ago
  How is this not considered a framework bug? "Secret tokens" are project-specific configuration more or less by definition. Putting them in something that lives in a source directory is simply asking for this kind of mistake. Rails deployments aren't leaking their ssh keys or database content because that is stored separately. To paraphrase the title: these things are stored separately for a reason. Get this thing out of the source, guys.
  - kawsper 14y ago
    database.yml is also placed in config-directory. secret_token.rb is placed where it is, because it is a initializer. http://guides.rubyonrails.org/configuring.html#locations-for-initialization-code http://guides.rubyonrails.org/configuring.html#locations-for...
    - ajross 14y ago
      How is "because it is a initializer" a response to the point? The fact that it is implemented as Ruby code has nothing to do with whether or not it should be stored in a source code directory. Clearly it should not. Yet it is. That's a framework bug.
jrochkind1 14y ago
I could see lots of people doing it, only because Rails auto-generates the secret_token.rb file -- it's easy to just not think about it, forget it exists, put your whole source tree in the repo -- remember to keep database passwords and such out, but not ever even think about secret_token.rb, it just ends up in there. Rails does the right thing by putting the secret token in it's own file that's even _called_ secret_token.rb (it could have just jammed it in the middle of config/application.rb or something instead, where it would be even easier to miss and/or not realize it should be kept private). So I don't know it's people who don't 'understand' it -- whether you understand it or not, the file is named "secret_token", if you actually look at a file listing and think about "should this be kept secret?", the answer is obviously yes even if you know nothing. But... there's still a lot going on, and it's something easy to forget about, since you ordinarily _never_ need to think about the secret_token.
- JulianMorrison 14y ago
  A file named "secret_token.rb" looks to me like "ruby code to operate on secret tokens", just like a file called "sha256.rb" would be expected to compute hashes, not contain them. Should have been called "secret_token.yml". Should live in the config, or even better, a "secret_config" top level directory, not a subdirectory.
  - jrochkind1 14y ago
    yeah, that might be an improvement, that perhaps should be considered since it's clearly a developer usability problem. But I think it's not unreasonable to have expected it was clear that ./config/initializers/secret_token.rb was a file to initialize a secret token, that included a secret token in it.
dlisboa 14y ago
> I can see why a lot of greybeards hate frameworks, because someone who builds web apps with a much more bare bones framework, (Sinatra, Webapp2, Express, etc) most likely understands the fundamentals of encryption/hashing simply because of the fact that lighter frameworks require understanding the fundamentals in general. Usually what ends up happening is people build less secure systems because they don't understand those basics. Giving people less tools don't equate in them building better solutions on their own.

by JPKab 14y ago

iaw 14y ago

I consider this in the same realm as storing passwords to plain text. People do it out of ignorance until they're learn the hard way not to (or some kind soul saves them from that disaster).

ajross 14y ago
How is this not considered a framework bug? "Secret tokens" are project-specific configuration more or less by definition. Putting them in something that lives in a source directory is simply asking for this kind of mistake. Rails deployments aren't leaking their ssh keys or database content because that is stored separately. To paraphrase the title: these things are stored separately for a reason. Get this thing out of the source, guys.
- kawsper 14y ago
  database.yml is also placed in config-directory. secret_token.rb is placed where it is, because it is a initializer. http://guides.rubyonrails.org/configuring.html#locations-for-initialization-code http://guides.rubyonrails.org/configuring.html#locations-for...
  - ajross 14y ago
    How is "because it is a initializer" a response to the point? The fact that it is implemented as Ruby code has nothing to do with whether or not it should be stored in a source code directory. Clearly it should not. Yet it is. That's a framework bug.

jrochkind1 14y ago

I could see lots of people doing it, only because Rails auto-generates the secret_token.rb file -- it's easy to just not think about it, forget it exists, put your whole source tree in the repo -- remember to keep database passwords and such out, but not ever even think about secret_token.rb, it just ends up in there. Rails does the right thing by putting the secret token in it's own file that's even _called_ secret_token.rb (it could have just jammed it in the middle of config/application.rb or something instead, where it would be even easier to miss and/or not realize it should be kept private). So I don't know it's people who don't 'understand' it -- whether you understand it or not, the file is named "secret_token", if you actually look at a file listing and think about "should this be kept secret?", the answer is obviously yes even if you know nothing. But... there's still a lot going on, and it's something easy to forget about, since you ordinarily _never_ need to think about the secret_token.

JulianMorrison 14y ago
A file named "secret_token.rb" looks to me like "ruby code to operate on secret tokens", just like a file called "sha256.rb" would be expected to compute hashes, not contain them. Should have been called "secret_token.yml". Should live in the config, or even better, a "secret_config" top level directory, not a subdirectory.
- jrochkind1 14y ago
  yeah, that might be an improvement, that perhaps should be considered since it's clearly a developer usability problem. But I think it's not unreasonable to have expected it was clear that ./config/initializers/secret_token.rb was a file to initialize a secret token, that included a secret token in it.

dlisboa 14y ago

> I can see why a lot of greybeards hate frameworks, because someone who builds web apps with a much more bare bones framework, (Sinatra, Webapp2, Express, etc) most likely understands the fundamentals of encryption/hashing simply because of the fact that lighter frameworks require understanding the fundamentals in general. Usually what ends up happening is people build less secure systems because they don't understand those basics. Giving people less tools don't equate in them building better solutions on their own.