Storing source code
All our source code is open by default, and stored on well-known, public code hosting services. At the MOJ, we use GitHub.
We follow the principles set out in the service manual for managing the code that we write:
You should keep secrets separate from source code, and keep them private.
GitHub
New repositories for products and services live in the ministryofjustice organisation on GitHub.
Repositories should be clearly named and have an appropriate licence and enough documentation that someone new can get started with the project.
Creating a new project from this template repository will add the
correct licence file, as well as adding our organisation default
.gitignore file and github actions.
If your repository contains secrets rather than code, make it private and restrict the people who have access to it. Discuss with the security engineering team whether you should encrypt the contents of the repository.
Private repositories
By default, any ministryofjustice organisation member has no additional privileges. This means they can clone and pull public and internal repos only. Internal repos are essentially org-public, and anyone in the organisation can interact with them. Unless explicitly and strictly defined on a per-repository basis to override default permissions: private repositories should be considered “private” to your team/project.
Delivery teams are responsible for setting correct permissions on their repos. This includes ensuring the right users have access, and removing privileges when they leave the team. It’s often helpful to manage permissions across all of a delivery team’s GitHub repositories in one place, by setting up a GitHub team for the people on a delivery team, and giving that GitHub team read/write privileges for the repos.
Converting private or internal repositories to public
If you are in a position to make source code open to the public after it was kept private for a while, you need to make sure there is no sensitive data in the commit history. This does not apply just to the current state of the main branch, but to all commits in the history of the repository. A good place to start is by going to the Security tab in the repository and checking for any secrets that may have been committed at any point.
If you do find sensitive information has been committed, you need to cycle it out of use and then scrub your git history to remove it. It is very important that you cycle the credentials, because even after scrubbing, they will still be present in any cached and local copies and will still be vulnerable.
In case any user information has been committed, you need to talk to the security and data privacy teams before proceeding.
GitHub access
Your account
If you already have a GitHub account from before you joined MOJ, you can choose to use it at MOJ or create a new one. Some people prefer to have continuity with previous work; others value the separation.
You must add your MOJ email address to your account. It needs to be the ‘primary email’ address on the account to enable SSO onto other developer related tooling. You may want to use that email for notifications.
In preparation for when you leave MoJ, it’s suggested you add a home email address to your account as the ‘backup email’. The reason is that the account is yours, not MoJ’s, so it remains your responsibility. When you leave you should actively close or keep control of the account. Whilst you won’t retain MOJ repo permissions, you may have to relinquish other access you’ve gained in the course of your work (for example cross-government work) - check your user settings for Organizations, Repos and Applications. And it might be prudent to retain the ability to change your account’s public profile or delete public comments. Home email addresses are not exposed to GitHub organisation admins, aside from what is already public.
You don’t have to use your real name or photo - just let your colleagues know your username.
Member of the MoJ organisation
Being a member of the MoJ organisation is for staff who are permanent employees or contractors working directly with the MoJ.
To be added to the ministryofjustice organisation, first ensure you’ve enabled two-factor authentication.
Then make a request to the operations-engineering team to be added / removed via email or the #ask-operations-engineering.
Outside Collaborator
Being an outside collaborator is for third party suppliers who are maintaining code on behalf of the MoJ.
Outside collaborators can only access specific repositories and are limited in what they can do within the MoJ organisation. They are not able to access private repositories outside of the ones they’ve been assigned to. They do not have access to the Cloud Platform cluster. Collaborators cannot be added to GitHub teams.
Users do not require an MoJ email address to be added as outside collaborators.
You can add outside collaborators via the github-collaborators repository.
The operations-engineering team track Outside Collaborators on the MoJ GitHub Organisation via the github-collaborators repository.