PKG Deploy

Docs

Security

Security is taken very seriously at PKG Deploy.

GPG signing

Repository metadata is signed via GPG allowing you to ensure that the metadata we provide is generated by us and not by anyone else. If you follow the documentation to add the package repository to a machine, GPG checks will be automatically carried out.

rpm packages are also signed before they are published, YUM also runs GPG verification on these packages.

deb packages are not signed as APT does not come with an easy way to verify package signatures by default.

An export of our public key can always be found at https://www.pkgdeploy.com/pkgdeploy_gpg.asc

Package repository access

When a package repository is created, a set of access keys are generated for it to ensure the content of the repository is kept private. This means that if these access keys are leaked, anyone that knows them potentially has access to your packages.

It is very important to keep these access keys secure. Remember they can be accessed by anyone that has access to the package repository and they are also baked into the installer created for each package repository. This means the repository installers should not be shared around.

We are looking at other ways to secure package repositories in the future.

Rolling access keys

If you believe a package repositories access keys have been compromised you can roll the access keys. Warning this will block access to the package repository for any machine configured with the old keys until they have been updated.

  1. Navigate to the Package repos page using the left-hand menu
  2. Select the package repository which has had its keys compromised
  3. Click on the settings cog top right of the page
  4. Press the Roll tokens and create new installer button. This will instantly disable the old keys and create new ones. A new installer for the package repository will be created
  5. Download and install the new installer on any machine with the old access keys

Project triggers

Both the GitHub and API trigger types are secured by API tokens to ensure requests are authorised on behalf of the projects owner. A different API token is generated per project when the project is set up.

They need to be kept secure as they could be used to create a large number of releases quickly or by a bad actor with access to a GitHub repository to distribute dangerous code.

Rolling API tokens

If an API token has been leaked it should be updated ASAP. Warning this will block access to the package repository for any machine configured with the old keys until they have been updated.

  1. Navigate to the Packages page using the left-hand menu
  2. Select the project which has had its token compromised
  3. Click on the settings cog top right of the page
  4. Press the Generate new token button. This will instantly disable the old token and create a new one
  5. If the project is using a GitHub trigger a new Webhook with the new API token will be created
  6. If the project is using the API endpoint trigger, you will need to update the API token header value anywhere it is set in 3rd party systems

Code and infrastructure