The next task in our Pivotal Tracker is to work with a .gitignore file. First and I'm going to walk through the process of how we do this and then we will discuss why it is important.

Open your .gitignore file in sublime text.

Also, open your secrets.yml file.

It will be helpful to look at both files at once, so I suggest you set up multiple sublime panes with view < layout < rows:2 . Place the .gitignore file in one pane and the secrets.yml in the other.

What is .gitignore?

.gitignore is a file where we can specify which files should not be checked into version control or saved on GitHub.

Since I don't want my secrets.yml file to be checked in, I'm going to add these lines to my .gitignore file:
# I don’t want to show my secrets
/config/secrets.yml


Be sure to save your changes. Also, make sure you follow this same pattern of including the slash at the beginning of the line that states where the file is found. (See line 8 for a sample)

Now, do a git status and you will see that your .gitignore file has been modified. This is what we want.

However, the process gets a little bit problematic if we make a change to our secrets file.

Add a small change to your secrets.yml file, such as adding the line: aws_secret_key: aeiou

Now run another git status . You will see that the change was recorded with Git, as it shows the file has been modified. We definitely do not want this!

To correct this issue we can use the command: git checkout config/secrets.yml

That command essentially removes all the changes previously made to our file. Now, if you go to your secrets.yml file, you'll see that the changes you made are not there anymore.

The reason this hiccup occurs, is that Git wants to be as quick and as efficient as possible. Git therefore uses a caching mechanism. We have to clear the cache to ensure that our secrets.yml doesn't show up when we make changes. The command to clear the cache is: git rm . -r --cached

Now, we can do another git status . There is a list of files here, but they do not include the cache, so we can go ahead and do a git add . (git add all). Followed by git commit -m ‘cleared git cache’ (remember -m is an option to add a message), and git push.

Verify .gitignore is Working

Now that we’ve done this process, let's go back to our secrets.yml file. Once again, add a random secret key for testing, such as aws_secret_key: aeiou and save the file.

Now, type the command git status again. You'll see that there is nothing to commit.

This is because we cleared the cache, which allowed us to work on a clean version of Git, and our .gitignore file is now working.

This issue can be a stumbling block for developers who are new to working with Git, so if that seemed involved, don't worry. I just wanted you to know the configuration and setup. We'll likely not add anymore to our .gitignore file during the remainder of this course.

Why your Keys need to be Secret

Now that have the steps to remove the cache and fix the .gitignore file issue, let's talk about why we need to keep our keys secret.

Looking at your secrets.yml file, you'll see that there are different environments listed and secret keys associated with each one. The secret keys for development and test are perfectly fine for sharing. In fact, you can even copy these values. The application can not be hacked with the development or test keys.

However, the production key is important to keep safely hidden. With it, someone could hack into the application. In fact, Rails uses this secret key base as the starting point for all encryption.

Rails and Security

The good news is that Rails takes its security very seriously. In fact Rails finds security so critical that it gives each application its own unique type of encryption. This uniqueness is important, otherwise, if a hacker broke one Rails app encryption, then they could break all the Rails websites and applications in the world!

To circumvent this problem, Rails developers created something called a secret_key_base. The secret_key_base protects your specific application because even if a hacker where to crack the Rails encryption algorithm, they would still need this key to hack into your specific application.

Production Key

If you look at your secrets.yml file, on line 22, you will see the the production key is not displayed. Instead, there is a ENV secret_key_base call. Essentially, the server will store the key and this file will look to the server to provide the production secret_key_base. This is the way you keep this key safe.

Additional Keys

The reason we want to keep this file out of version control is that we may need to add more secret keys to it. For example, if I wanted to connect to the AWS S3 CDN, by creating a file uploader, then I would have to store an API key in this file.

Even if I only used the key in my development environment, if I pushed that key up to GitHub and another user/hacker gained access to it, they could take that key and use it to create their own server, and I could get charged for them using my access.

Incidentally, this did happened to me once. I had a developer who was working for me that was still fairly new to rails, and didn’t realize the importance of keeping these keys safe. He pushed my AWS keys to a public repository. Hackers have all kinds of scripts and they are constantly monitoring applications on GitHub to see if anyone will make such kinds of mistakes.

The developer pushed the file around noon, and by 2:00, I received a call from Amazon. They said “We noticed you charged $16,000 on your AWS account over the last two hours, you normally spend $50 per month, so we wanted to see if someone has hacked your account.” Obviously, someone did.

It is important to know that if you have any items that need to be kept secure the best place to store them is the secrets.yml file. It is vital that you first check it into your .gitignore file. If you do not do that at the start of your application, make sure you follow this process of removing the cache, and testing it out, to ensure you do not push your secrets.yml file to a public repository.

Because we have properly added our secrets.yml file to .gitignore, any changes we make to secrets.yml from this point on will not be pushed to the public repo on GitHub.

You can quickly test this out by making a change to the README.md file. I like to test changes on the README.md file because it is so easy to change things. Go to your README.md file and add the line Some content to the file, and save.

Now when you type git status, only the README.md file will show up as modified. Even though we added the sample key to our secrets.yml file, Git is ignoring it.

Next do a git add . ,
followed by git commit -m ‘Updated readme content’,
and a git push

Now go and look at your GitHub repository. Refresh the page to show your latest updates. You should see 4 commits at this point. Click on the config directory of your latest version and you will see the secrets.yml file is no longer there. You can be assured that you can add to it securely now, and the items will only be available on your local machine.