The security researcher also recommended we consider using GPG signing for Homebrew/homebrew-core. The Homebrew project leadership committee took a vote on this and it was rejected non-unanimously due to workflow concerns.
This is incredibly sad and makes me wonder what part of the workflow would have been impacted. Git automatically signs the commits I make for me once I have entered my password once, thanks to gpg-agent.
They have a bot which commits hashes for updated binary artifacts. If all commits needed to be signed, it’d need an active key, and now you have a GPG key on the Jenkins server, leaving you no better off.
But gpg cannot work with multiple smartcards at the same time, so maybe that’s a reason for some people. Either way there are simpler ways to deal with signing than gpg
GPG signing wouldn’t have fixed this vulnerability as such, since presumably the same people not thinking about the visibility of the bot’s token would have equally failed to think about the visibility of the bot’s hypothetical private key
This is incredibly sad and makes me wonder what part of the workflow would have been impacted. Git automatically signs the commits I make for me once I have entered my password once, thanks to
gpg-agent.They have a bot which commits hashes for updated binary artifacts. If all commits needed to be signed, it’d need an active key, and now you have a GPG key on the Jenkins server, leaving you no better off.
But gpg cannot work with multiple smartcards at the same time, so maybe that’s a reason for some people. Either way there are simpler ways to deal with signing than gpg
GPG signing wouldn’t have fixed this vulnerability as such, since presumably the same people not thinking about the visibility of the bot’s token would have equally failed to think about the visibility of the bot’s hypothetical private key
See https://lobste.rs/s/lvq9j7/how_i_gained_commit_access_homebrew_30 for another side of this story.