Hacker News new | ask | show | jobs
by gravitas 2058 days ago
Distributions who have built GPG keychecks into the process use the keyparts distributed by themselves; meaning that on RHEL systems (and the clones - CentOS, OracleLinux, etc.) use the GPG keyparts delivered via the vendor "release" packages sitting in /etc/pki/rpm-gpg/, an Arch system uses "archlinux-keyring" which populates /use/share/pacman/keyrings/ and so forth. A 3rd party vendor source (think Nginx, Percona MySQL, Zabbix, etc.) who runs their own yum repo provides their own trusted GPG key and signs their packages with their key, so you install the "foobarvendor-release" package which contains their keys.

System package installs then do a GPG check against those known good keyparts from trusted vendors which you've allowed and stop you when you have an unsigned package (being a bit light on detail here, each distribution handles it their own way). So the NPM (or Artifactory, etc.) ecosystem could invent an installable package of their GPG keys, and require all packages sourced from their server to be signed with this key -- this is how the EPEL 3rd party community repo works for example. These are all based on trusted humans having access to the signing keys and process, so there are layers of vetted/known folks required (not just anyone can walk into Mordor here).

This does not work though for some Linux distributions such as Ubuntu due to their original design. Debian/Ubuntu systems for example are at somewhat of a disadvantage here; from the beginning the DEB system design has eschewed GPG signing individual packages and instead sign repositories (which tends to also get disable/ignored if even used), they're at least now recommending HTTPS around apt which is nice.