Can you keep a secret?
Why so serious? ☠️
The last chapter ended in an ominous omen of hurt and pain. How could we have made a mistake already? We have not touched the robot at all!
The issue is quite subtle, but it could have unpleasant consequences in some cases (don't worry, not in this case). Sorry for forcing the mistake, but we feel this lesson is best learned by seeing the issue yourself, with your own eyes. It sticks to your memory better this way. 👀 🤔 🤯
What's the issue? 🔎
Navigate to the tasks.robot file on your computer. What do you see?
Oops. 😬 Having access credentials in plain view is probably not the best practice! But wait. We could delete them, commit the change to version control, and push it to the remote repository. Problem solved?
Not quite. Version control is great because it remembers everything. In this case, though, that is slightly inconvenient. Deleting something permanently from an existing repository is not straightforward. Once something has been committed to version control, it stays there (that's the whole point!).
Even if you delete something from the latest version, it does not delete that from the old version. You can checkout the old version and still see the credentials.
How to deal with the issue? 🩹
In our case, the least painful resolution for this issue would be just changing the credentials in the target system, so that the accidentally committed credentials won't work anymore. To keep this course simple, we will not do that here. Just remember this one option for resolving accidents like this.
That did not sound too serious. What's the big deal? 🤷♀️
Consider a more serious scenario. Let's assume someone accidentally commits the production database backup to version control. The backup contains client information, private financial data, or some other information that should not be publicly available.
In this case, we could not simply change the data as we did with the credentials. You should delete the whole repository (local and remote) and start from scratch. This would delete the history, too. It would not be pleasant but would prevent accessing the data by just checking out old versions. Even if your repository is private at the moment, it might end up in the wrong hands at some point.
Also, remember that there is not just one repository. The more people clone the repository on their machines, the higher the chance of someone unauthorized getting access to it (after stealing a laptop, for example). Since each repository contains everything, including the history, gaining access to any of these would be enough for digging up some secrets.
Professionals won't make these mistakes, right? 😇
Accidentally committing sensitive data is a common thing. Here you can view accidentally leaked secrets in real-time across GitHub, GitLab, and BitBucket. Whoops! 🙈
Anyway. That was the lesson. If you don't remember anything else from this course, at least remember this. It is good to be somewhat paranoid when committing files to your repository. There are some tools (such as truffleHog) that you can include in your workflow to catch the mistakes before they become real issues. Some of the hosted services also notify you privately when they detect suspicious commits.
Rule of thumb 👍
If it is a token, a credential, or some other sort of "secret", you do not hard-code that in your project.
What we learned
- Do not commit secrets in your repository!
- Some accidents can be fixed by changing the credentials in the target system so that the accidentally committed credentials do not work anymore.
- There is usually more than one copy of the repository (at least one for each developer). Any of those could leak accidentally. Do not commit secrets!
- Do.
- Not.
- Commit.
- Secrets!