RPM Package Signing
In our current work with RPMs, we’re adding digital signatures to our PHP packages to enhance their security.
Package Signing ensures the integrity of a package at rest by detecting and deterring tampering. A package is signed with a private key, which is then validated by the public key provided by the package builder and installed by the user. This technique complements TLS encryption, which guards against tampering and snooping in transport.
The remainder of this article explains how to use RPM package signing when installing—or building—RPMs for IBM i.
User’s Perspective
When installing a repository on IBM i and setting it up in Yum, you also want to install the public keys provided by the maintainer of the repository. Without these keys, your system can’t determine the integrity of each package—the packages might be signed, but by whom? Because of the importance of the public keys, always check to make sure the one you have is legitimate.
To install a public key into RPM, use the rpm --import command on a file or URL. You can use the rpm -q gpg-pubkey --qf '%{name}-%{version}-%{release} --> %{summary}\n' command to see what public keys are installed.
Verification is done automatically when using Yum, provided the repository has the signing option in the repository file. (You can check this yourself by looking at the repository files in /QOpenSys/etc/yum/repos.d.) If you’re installing RPMs manually, you can use the rpm --checksig command on an RPM to do an integrity check, including both signatures and checksums. PGP should be mentioned as passing.
RPM Package Not Signed?
Some repositories do not yet support package signing. If not explicitly stated, you can still tell because they don’t mention what keys they have. If you still want to use a repository that doesn’t support signing, ask the maintainer of the repository to add it because of the security implications.
Packager’s Perspective
You need to generate a GPG key and set up the RPM environment to use one. You can sign packages from any system, even if you built them elsewhere. This might be useful if you want to keep your keys on a system you trust locally.
To make a GPG key, you can run the gpg --gen-key command and follow its instructions. The gpg --list-keys command can be used to verify that they’ve been generated.
To make a public key file, you can run the gpg --export -a 'My Name' > public_key_filer command (substituting your name in and anything needed to disambiguate it in case, as well as the file name for the key). You can proceed to import the key into RPM; your users will have to do this as well.
The name associated with your key should be put into your RPM macros file (~/.rpmmacros); for example, %_gpg_name My Name (again, substitute your name and any other required details here). When this is done, you can use the rpm --sign command on an RPM. Again, the rpm --checksig command can be used to make sure it now has GPG verification.
Multiple keys
If you have multiple keys (for example, maintaining separate repositories), you can remove the _gpg_name from your RPM macros file (optionally, to avoid accidentally signing with the wrong key) and then explicitly state which key you want to sign with when running the sign command; for example, rpm -D "_gpg_name My Name (Comment)" --addsign package.rpm. Here, you might have multiple keys with the same name and use a comment to disambiguate them.
To add a comment when making a key, you may need to use the --full-gen-key flag with GPG. Similarly, when exporting the GPG public key, the comment or email can be specified for disambiguation.
Leave a Reply
Want to join the discussion?Feel free to contribute!