Background:
When a malicious party gains access to Bitwarden’s developer accounts, the party has the potential ability to publish arbitrary code as “updates” on the Bitwarden repositories (Github) or distribution channels (Firefox Addons/Chrome Web Store/…), potentially compromising the entire security of this application for a lot of users. This is why securing developer accounts should be one of the highest priorities of the Bitwarden Team.
Problem Description:
A strong password and 2FA are good measures to secure developer accounts. With Git and Github, there is an additional possibility: Signing git commits and/or tags with a GPG key that is kept locally on the developer’s device. This security feature is described here. Signed commits and tags add another layer of security to code publishing, making sure that nobody has taken over Bitwarden’s Github account. With signed tags, we can verify that releases are approved/signed by the Bitwarden Team. People who have doubts about the security of the extension update mechanisms of their browser / worry about potential account compromises could check out the latest signed release from Github and compile the browser extension themselves.
If an attacker gained access to the dev’s account, he could add his public gpg key to the dev’s account and push commit that would be marked as verified too, so the verified badge is not enough : you also need to take a look at the key id
You’re right, now that I’ve read more into it I’m not so sure anymore that this improves security by a lot, in this case.
The main benefit seems to be to prevent that someone can push a commit with an arbitrary user.name and user.email in their .gitconfig without having a proof that proves the identity is correct. For this to happen, the attacker needs write access to the repository, and if that has happened, something went seriously wrong in the first place.
So, it may be a problem with bigger repositories with lots of people having write access and then someone tries to impersonate somebody else. Though having everything being pull requests with manual review seems to pretty much eliminate this possibility.
I’m not an expert on security myself and open for discussion, my initial thought was just that this is suggested by Github, so why not use it, right? But I agree we have to look at where this would add additional security, otherwise this would just be unnecessary.
