Set Up Repository on Other Clients

Preface

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: