Hi Jason, Sorry, I didn't see the notification for your reply.
Running rake -T | grep credentials doesn't produce anything. I see that I have a credentials.yml.enc file (although I have no idea what's actually in it), I'm guessing that's what the hangup is. I guess I'm just confused about the whole process of having multiple people work on a repo at the same time, and have versions in production. At the moment, everyone on my team is just using the same master key. This is fine for development, but I haven't found a way to change it at any point in the future. Are we meant to use the same key that is generated when rails is created throughout the entire lifecycle of this project? What would happen if we lost the key, or our current key was compromised? I'm probably just not understanding something really basic and I will probably feel like an idiot when I figure out what that is, but thanks for taking the time to reply to me! - Steve On Friday, January 12, 2018 at 12:42:51 AM UTC-8, Jason Fleetwood-Boldt wrote: > > Steven, > > I think perhaps there is 1 thing you are missing. > > (someone stop me if I'm wrong here) > > the purpose of the master.key is to decrypt .enc files, like > config/credentials.yml.enc > > This way, you can keep the *encrypted* versions of your yml (config) > files in your repository, but not the secret key itself used to decrypt > those files. > > I think it's discussed here in the 5.2.0 beta release notes: > > In Rails 5.2, we’ve rectified the mess by deprecating the two different > kinds of secrets and introduced a new shared concept called Credentials > <https://github.com/rails/rails/pull/30067>. Credentials, like AWS access > keys and other forms of logins and passwords, were the dominant use case > for secrets, so why not just call a spade a spade. So spade it is! > > Credentials are always encrypted. This means they’re safe to check into > revision control, as long as you keep the key out of it. That means atomic > deploys, no need to mess with a flurry of environment variables, and other > benefits of having all credentials that the app needs in one place, safe > and secure. > > In addition, we’ve opened up the API underlying Credentials, so you can > easily deal with other encrypted configurations, keys, and files. > > as well, this Engine Yard article I think explains some parts you are > missing: > > https://www.engineyard.com/blog/rails-encrypted-credentials-on-rails-5.2 > > On your Rails 5.2 apps, what does this give you > > rake -T |grep credentials > > -Jason > > > On Jan 9, 2018, at 5:33 PM, Steven Jeffries <stevenj...@gmail.com > <javascript:>> wrote: > > Is there any documentation on how to set up and use the master key for > development? > > Starting a new rails 5.2 app generates a key in config/master.key. That > file is added to the .gitignore, so when other members of my team check it > out, they do not have the key. > > If another member of my team checks out the repo and attempts to run the > server, they get an error that the key is missing. > > Now, when they generate a key and put it in config/master.key, they get a > *ActiveSupport::MessageEncryptor::InvalidMessage > *error when trying to start up the rails server unless it is the exact > key that was generated when the app was created. > > It seems like rails is trying to decrypt some files (or something) and > needs the key to do so. In the default 5.2 app, which files not in the > .gitignore are being encrypted? > > If the exact starting key is required to run rails, then why is it in the > .gitignore, or even configurable at all? > > Is there a way for different members of my team to use a different key in > development? Is there a way to use a different key in production? Is there > a way to change the key in production periodically? > > Is all of this documented somewhere? > > Sorry for all of the questions. > > Thanks for your time! > > - Steve > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rubyonrails-co...@googlegroups.com <javascript:>. > To post to this group, send email to rubyonra...@googlegroups.com > <javascript:>. > Visit this group at https://groups.google.com/group/rubyonrails-core. > For more options, visit https://groups.google.com/d/optout. > > > ---- > > Jason Fleetwood-Boldt > te...@datatravels.com <javascript:> > http://www.jasonfleetwoodboldt.com/writing > > If you'd like to reply by encrypted email you can find my public key on > jasonfleetwoodboldt.com (more about setting GPG: https://gpgtools.org) > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at https://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
