Current situation
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 athttps://api.travis-ci.org/repos/foo/bar/key
. Anyone can runtravis 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, usingfoo/bar
’s private key, but the values cannot be decrypted by anyone else (not even the encrypter, or “owner” of thefoo/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.