• Signing package repositories is good.
• Letting the keys used to sign package repositories be copied off of the server authorized for that use is bad.
• Hardware-backed key stores exist to provide a means of storing a private key that prevents it from being copied from software.
• The Trusted Platform Module is a widely-adopted standard that provides for such private storage.
• Frank Olbricht's tpmk library exists to allow TPM-backed keys to be operated on from Go.

Aptly should support signing packages with tpmk-backed keys; this way, even a user with all the privileges aptly itself has won't be able to copy that key off and put it to their own uses in the future (but will need to have a persistent compromise of a repo-signing server lasting for the entire duration of time in which they wish to corruptly/incorrectly sign keys).

Detailed Description

The proposal is to add an alternative to the current practice of passing a signing key (or a path to a signing key) and a password to aptly. For example, we might recognize a SecretKeyring of the form tpm:0x81000000 as an instruction to ask the tpmk to load a private key from the given address.

Context

This change will make it possible to trust users to use aptly without giving them enough permissions to impersonate that aptly server in the future.