• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

Overview

• Launchpad entry: https://blueprints.edge.launchpad.net/soyuz/+spec/signed-archives

• Created: [2008-07-17] by JulianEdwards

• Contributors: CelsoProvidelo, MuharemHrnjadovic

• Depends on: n/a

• Bugs: https://bugs.edge.launchpad.net/bugs/125103

Overall Summary

Summary: PPA repositories will be signed in the same way that the Ubuntu one is. Signing keys will be generated and stored in Launchpad, and can optionally be signed by the archive's owner.

Goal/Deliverables: We'll deliver a UI that will allow a user to manage private keys for an archive, and published archives will be signed with the key registered for that archive.

We will know we have finished when PPA Release files get signed after each modification.

Release Note

Not yet.

Rationale

Despite serving archive contents via a secure protocol (HTTPS) we are not able to certify that the content being transported is what the user believes it is (the certified origin).

APT already uses OpenPGP signatures before installing anything from a specific archive.

Soyuz should be able to sign archive Release files, per-owner request, when they want to distribute certified packages.

Why per-PPA keys?

Consider the following scenario if we were to use a site-wide ppa.launchpad.net key:

• Bob produces a shiny new lolcats-backgrounds package and uploads it to his Launchpad PPA
• Alice loves lolcats, and adds his PPA to her sources.list.
  • This pulls in the ppa.launchpad.net key as an authorized key
• Evil Eve uploads a newer, trojan-ed, lolcats-backgrounds to her Launchpad PPA
• Evil Eve MITMs Alice (e.g. via Kamnisky DNS poisoning) and redirects Alice's traffic from ppa.launchpad.net to harhar.evileve.com which contains a mirror of her PPA
  • Alice's apt thinks it's downloading from ppa.launchpad.net/~bob-ppa
  • The repository being served by Evil Eve has been signed by LP and is thus trusted by Alice's apt

  • -> profit for Evil Eve, loss for Alice and Bob

Use cases

• Arthur has a Launchpad PPA and wants to allow his users to verify if they are really installing packages provided by him.
• Ford uses Arthur's PPA and would be less concerned on each update if he could verify if the packages being installed are the ones provided by Arthur.

Assumptions

Users are happy to have a private key kept on their behalf;

It will be mandatory to have signing-keys set for PPAs.

There is no need to model the existence of a corresponding private part of a GPG key in LP, it will be implicit in the fact that a GpgKey record is set as signing-key for any archive.

Revoking launchpad-generated keys will be considered a crisis/corner-case and will be handled on demand since it will be only necessary if the PPA machine gets compromised.

Users will manifest their trust in lp-generated keys by signing its corresponding public part already published in the global keyring. That will be done externally, using the current gpg infrastructure, i.e. doesn't require any LP support.

User Interface

The signing GPG key pair will be generated sometime after the PPA activation. Since they are mandatory nothing will change in this form, apart of a clear indication of what will be done.

Of course there will be a minor change in the PPA index page pointing users to the public part of the key used to sign it and also instructions about how users/clients should use it.

Implementation

We will assume LP environment is secure enough (specially germanium, the PPA machine) and generate the keys directly on disk (associated with more secure and reliable backups). The private key will be retrieved from disk on-the-fly, based on the fingerprint of the public part when a signature is required. Later we can migrate them to a distributed location using the appropriate security artifacts (KEK).

A key generation will be triggered by the fact that there are Archive WHERE purpose=PPA AND sigining_key is NULL, gpgkey-guard will perform the follwoing actions for each missing-signing-key:

• Generate a key pair, export the private key into a file in the private-key-path;
• Export and upload the public part to the keyserver;

• Record the pub part existence in the GpgKey table;

• Record the just created Archive.sigining_key existence.

publish-distro will cope fine with archives with unset signing-keys and skip the release file signature until it gets generated.

Estimations:

• Schema - 1 hour, plus discussions
• GPGHandler changes to generate, sign and upload keys - 4 days.

• gpgkey-guard and signing release files - 2 days

• UI - 1 day

Code Changes

• GPGHandler changes:

  • IGPGHandler.generateKey(comment='Signing key for <archive.title>', can_encrypt=False)

  • IGPGHandler.uploadPublicKey(fingerprint)
  • IGPGHandler.importPrivateKey(content)
  • IGPGHandler.signContent(content, fingerprint, deattached=False)

• gpgkey-guard;

  • key pair generation;
• UI:
  • +archive/+index: pointer to the signing key and instructions about how to use it;
• Publisher:
  • Signing archives with generated signing-keys;

Schema Changes

Archive: simply adding a 'nullable' signing_key FK to GpgKey.

Migration

The first time gpgkey-guard runs in production it will generate keys for all existing PPA, and subsequent runs will catch up with new PPA activations.

Unresolved issues

Which Person will be set as owner of the GpgKey record corresponding to the public part of a signing-key ?

CelsoProvidelo: the most precise thing we can do is to use a lp-celebrity for that. Choosing and storing a real for the time we need it (key generation) can't fit in the current schema change. The downside is that something might have to be done in the current GPG UI otherwise <celebrity>/+editgpgkeys will be very likely to be misleading and/or timeout very often (1100 keys to start with.)

Will Archive.signing_key have to be nullable forever, not only for the migration period ?

CelsoProvidelo: There are other Archives that don't have to be signed (REBUILDS for instance). After the migration time we can add a NOT NULL constraint WHERE purpose = PPA if it contribute for safety.

Should Archive.signing_key not be UNIQUE in order to allow sharing the same key across archives (not necessarily PPAs) ?

CelsoProvidelo: It may be necessary, if we decide to host signing-keys for PRIMARY & PARTNER archives as well. Unless we are absolutely sure that each signed archive should have its exclusive key.