GitHub Actions is an excellent platform for building CI/CD pipelines for your projects. StepSecurity builds open-source security solutions for CI/CD platforms. We are excited to announce that we are releasing a new GitHub Action called Wait-for-secrets. Wait-for-secrets enables the use of multi-factor authentication for release workflows.
GitHub is the largest hosting platform for open-source projects. Maintainers of these projects publish to popular package registries, such as the npm registry and DockerHub.
The de facto standard maintainers use is publishing from their personal computers. Releasing packages from a local developer machine creates a security risk. The build artifact may be tampered with if the developer’s machine is compromised. It also makes it hard to generate provenance and for others to validate the release process.
Publishing using CI/CD platforms such as GitHub Actions helps solve these problems. GitHub Actions hosted runners, for example, are ephemeral VMs, where each job runs in a separate fresh VM.
The downside of publishing from a CI/CD pipeline is that developers lose the ability to use multi-factor authentication. Package registries, such as npm and PyPi, enforce multi-factor authentication for popular packages. But for publishing from CI/CD, developers have so far had to use single-factor automation tokens.
StepSecurity built the Wait-For-Secrets GitHub Action to give developers the best of both options. To publish from a CI/CD pipeline and use multi-factor authentication for the release process.
Case Study
The popular eslint-plugin-react package uses Wait-for-secrets to publish to the npm registry using a one-time password (OTP).
Here is a testimonial from Jordan Harband (https://github.com/ljharb), who integrated it into the eslint-plugin-react package’s release workflow:
> For years, I’ve resisted publishing from CI — publishing is the one truly irrevocable action, and I strongly believe it should require manual human intervention. This is one of the first workflows of “publish from CI with manual human interaction” that I’ve seen that doesn’t require me to self-host anything, doesn’t lose the “two-factor” by using a single factor of a secret token, and works just as well on desktop as it does on mobile.
> I’ll be abstracting this to a reusable workflow soon, so I can use it on many more of my packages. This will also enable me to start ergonomically using Github Releases for the first time, since I can chain an action post-publish that automatically creates the release text based on my changelog; I can also wire up Slack and mobile push notifications. This will result in a significant percentage of npm’s download traffic no longer relying solely on the security of my personal computer.
The release workflow looks like this.
Here is a screenshot of the build log showing eslint-plugin-react published using a one-time password (OTP).
Integrating Wait-for-secrets in your GitHub Actions workflow
To integrate Wait-for-secrets GitHub Action in your publishing workflow, follow these steps:
1. Add the Wait-for-secrets Action before the step where you need the publishing secret.
Here is a demo workflow
2. When you run the workflow, the Wait-for-secrets Action step will print a URL in the build log. You can also configure the GitHub Action to send a Slack notification.
3. When you are ready for publishing, click on the URL in the build log. A website will open with details about the workflow run.
4. Enter the temporary credentials such as a one-time password on this website.
5. The Wait-for-secrets Action step will receive the multi-factor authentication token and stop blocking. The publishing step can use the token and proceed with publishing.
Wait-for-secrets GitHub Action and the backend API it uses are open-source. You can find sample workflows in this repository:
https://github.com/step-security/wait-for-secrets
