Daniel15
commented
5 years ago Using a custom keyring seems like a reasonable approach, depending on complexity.
Open lambdafu opened 5 years ago
Daniel15
commented
5 years ago Using a custom keyring seems like a reasonable approach, depending on complexity.
lambdafu
commented
5 years ago For a custom keyring, I recommend the following command line options (quoted here from my blog):
gpg_tmp=`mktemp -t yarn.gpg.XXXXXXXXXX`
curl -f -sS https://dl.yarnpkg.com/debian/pubkey.gpg | gpg --dearmor > "$gpg_tmp/pubkey.gpg"
gpg --no-options --no-default-keyring --no-auto-key-retrieve --no-auto-check-trustdb --trust-model=always --batch --no-tty --keyring "$gpg_tmp/pubkey.gpg" --verify -- "$1.asc" $1
Responsible Disclosure Timeline
Bypassing signature verification in install.sh
The basic issue is that the E2E signature verification in yarn's install.sh script does not do certificate pinning. Any key in the local keyring or automatically downloaded from keyservers will be accepted for verification. This is because the yarn release key is imported into the user's keyring and then gpg is called with "gpg --verify" not specifying either a minimal keyring with acceptable keys or parsing the output to check for a valid signature by a particular key.
Mitigation
Mititagion is not easy, as GnuPG lacks friendly interfaces for the intended use case. Some options include a temporary home directory, specifying a custom keyring, or parsing the status lines output. See my blog entry for details.
Impact
The impact is dependent on what the signature is supposed to protect. The first line of defense for yarn surely is HTTPS, and that means that the impact of this bug is probably small in practice. But I can't tell for sure. It is possible that the E2E signature verification protects some nightly build servers or so.