Hello! We're cleaning up the BUL GitHub as best we can, and revoking access to repositories for folks who no longer work here or otherwise shouldn't have access. If we've made a mistake and removed you from a repository you should have access to, please get in touch and we'll get it sorted out.

Never Commit Sensitive Information — even if the repository is private.

Keep private things out of the github code directory

• Keep out of code, and the github code directory:

  • passwords
  • API keys
  • server paths
  • database-structure info (where reasonably possible)
  • private settings
  • shell-scripts that set environmental variables
  • log-files (which can sometimes contain sensitive info)

• Implementation: One common pattern is to have a "project_outer_directory" that contains these things (as well as the "project_code_directory"), and only commit the "project_code_directory" to github.

• Utilize environment variables: Store sensitive information in environment variables, set outside of the git-directory and thus not able to be accidentally committed. All languages support common ways of doing this.

• Do not depend on the .gitignore file for security: Rather, get in the habit of thinking of the .gitignore file as keeping messy-unnecessary-cruft out of github (like auto-compiled *.pyc files), not as basic security. Instead, keep the sensitive info out of the github directory in the first place.

• Include a README, preferably with an explanation of the repo's Purpose, Usage, and Installation
• Make it clear which team at BUL "owns" the repo
• Add a "Description"
• Include "dependencies" in such a way that github can auto-scan them and notify you of vulnerabilities
• If you have a dotenv with private info — as noted above it should not be in the repo — but it's useful to have a sample_dotenv.txt file for users to get a sense of what kind of info is required.
• the main branch is special: it should always work.
• There should be a "release" for every version of the code actually deployed. (That makes it easier to know which commit to revert back to if there's a problem.)

See also:

• Best practices for Django projects at BUL

This document is a draft & will be undergoing revisions.