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