There are a few people who have the credentials to the Puppet forge accounts (theforeman and katello). That means only these people can do module releases.
Releasing Puppet modules via Travis
Travis CI is capable of releasing a Puppet module to the Puppet forge. The typical workflow would be on a tag.
We have an example in obal:
As can be seen the password is encrypted so it can be stored in git. Encryption of secrets is documented but here’s the gist:
Travis CI uses asymmetric cryptography. For each registered repository, Travis CI generates an RSA keypair. Travis CI keeps the private key private, but makes the repository’s public key available to everyone. For example, the GitHub repository foo/bar has its public key available at https://api.travis-ci.org/repos/foo/bar/key. Anyone can run travis encrypt for any repository, which encrypts the arguments using the repository’s public key. Therefore, foo/bar’s encrypted values can be decrypted by Travis CI, using foo/bar’s private key, but the values cannot be decrypted by anyone else (not even the encrypter, or “owner” of the foo/bar repository!).
Implications
It means that anyone with access to a Github account can release Puppet modules to the Puppet Forge. We have no granularity.
I have considered checking GPG-signatures of git tags but since the Travis configuration is also in git, this would be trivial to bypass.
An alternative could be to build a similar solution in Jenkins where we control how jobs are built but storing these secrets on Jenkins slaves might be less secure because other jobs could be abused to retrieve the password.
Work done
There is an open PR to add it to our Puppet modules.
Before I proceed I’d like a conceptual ACK. I’m especially interested in the opinion of @mmoll, @ehelms and @stbenjam because they’ve done releases in the past.
Access to a github account with push permissions to a repository. It means that a compromised Github account or SSH key now also gains access to publishing Puppet modules to the Forge.
I hadn’t read about the ESLint compromise when I created this RFC, but it reminds me that we should be careful and there are still a lot of bad actors around.
On a related note: all developers should check that they haven’t installed any of the compromised NPM packages.
I’m generally in favor of this change, but in light of the eslint event, I agree we should tread carefully. Perhaps we should start enforcing 2FA with anyone to commit to any repo in theforeman or katello organizations. Owners of the respective orgs can view the 2FA status of members, I think.
