Gain insights into creating Alpine Linux packages. Delve into APKBUILDs, packaging basics, and repository management. Discover quality assurance and enhance your Alpine Linux and DevOps skills.

Doxx.tar.gz

In this course, you will learn how packaging software works in Alpine Linux, the most popular Docker Linux distribution.

You’ll first learn the basics: what is Alpine Linux and what are its advantages over other distributions, especially in a Docker environment? Next, you’ll cover the basics of packaging software: what are apk and APKBUILD, where should files be installed, and how can we create basic APKBUILDs and submit them for inclusion in Alpine Linux official repositories? You’ll also learn what makes an Alpine Linux package low or high quality. Finally, you’ll explore APKBUILDs for different programming languages and finish by creating your own private Alpine Linux repository with complex subpackages. 

By the end of the course, you will be able to create APKBUILDs which easily pass Alpine’s quality assurance. Overall, this course will increase your understanding of Alpine Linux and Linux in general and help you improve your DevOps skills.

Creating Alpine Linux Packages

## 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:

# 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:

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

Introduction

Using abuild

Alpine's FHS

Creating Your First APKBUILD

Creating More Complex APKBUILDs

Hosting Our Own APK Repository

Additional APKBUILD Examples

Conclusion

Set Up Repository on Other Clients

Preface

Digression: Public and private keys

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