Set Up Repository on Other Clients

Learn how to set up an HTTP repository on other clients and how to transfer signing keys.


To use our web server in another Alpine Linux instance, we have to add it to the /etc/apk/repositories file of the other instance and copy the public key of our repository.

Digression: Public and private keys

In asymmetric cryptography, two keys exist, a private and a public key. The difference between these two keys is given below:

Category Private Key Public Key
Privacy Must never be shared with third parties Has to be shared with third parties to be useful
Signing Can sign new packages Can’t sign any new packages
Verification Can verify packages Can verify packages

To summarize, the private key is only held by the party that creates packages, signs them, and adds them to the repository. They need to be able to sign new packages and verify existing ones. However, third parties that download packages from the repository should only be able to verify existing packages and not be able to sign new ones. This guarantees that all packages that pass verification have been signed by the maintainer of the repository (who holds the private key).

Additionally, this makes sure that packages have been properly transmitted because verification will pass only if the package isn’t corrupted.

This is also why it’s okay to use HTTP for apk repositories. Even without encryption of the download, apk will make sure that packages and indexes haven’t been tampered with during transit. Using HTTP also makes it easier to cache packages in case we’re distributing packages to multiple machines on the same network and want to speed up the download.

Public and private keys with apk

The key pair used with apk is generated by abuild-keygen, which we’ve already used. Running abuild-keygen generates a 2048-bit RSA key pair that is used for signing and verification:

Get hands-on with 1200+ tech skills courses.