I’ve been thinking about what the ALPHA-2 version of ick should be like. One thing that’s fairly clear to me is that ick should, very soon, be able to build its own .deb packages. I’m likely to want to make that a goal for ALPHA-2.

A critical concern about this is handling of secrets. If nothing else, if .deb packages get uploaded, they should be PGP signed. The signing requires a private key, which must be kept secret. Ick gets what is essentially arbitrary, untrusted code and runs that, and it would be unfortunate if the private key gets stolen by the code that gets built.

Thus a design goal for ick needs to be that there are no secrets on the worker host at all, except the secret that the worker-manager needs to authenticate itself to the controller and other ick components. That secret should not be useful for anything else. This way, any repercussions from the secret leaking is minor and easily controllable.

Instead, we introduce the concept of “trusted worker”, which never runs user-supplied code, and can hold secrets needed for external access, such as ssh and PGP private keys.

As an architecture, it might look like this:


actor Developer
component Git
component APT
package "ick" {
        component Controller
        component Trusted
        component Worker
        component Blobs

Git -down-> Controller : trigger build
Controller -down-> Trusted : give work
Git -down-> Trusted : git clone
Trusted -right-> Blobs : upload workspace
Controller -down-> Worker : give work
Blobs -right-> Worker : get workspace
Worker -left-> Blobs : upload .deb
Blobs -> Trusted : download .deb
Trusted -> APT : upload signed .deb
Blobs -up-> Developer : download .deb
Developer -right-> APT : upload signed .deb


The trusted worker has an ssh key that it uses to fetch source code from the git server. It packages up the source code as a blob, and uploads the blob to the blob service, as a “workspace”.

The normal, untrusted worker gets the workspace from the blog service and, after building, uploades any build artifacts (.deb files) back to the build service.

After that, the trusted worker downloads the artifacts from the blob service, PGP signs them, and uploads them to an APT repository.

Altenatively, the developer downloads the .debs from the blob service, does the signing themselves with their personal PGP key, and uploads them to the APT repository. This is what needs to be done if ick is building packages that are to be uploaded to Debian proper, since those uploads need to be signed by a key Debian trusts, and that means it can’t be a key put on some shady service not under direct control by the developer.

In this design, only the trusted worker has ssh and PGP keys that need to known and trusted by external parties.