Introduction

To ensure Click package integrity from the application developer all the way to the end user, signatures will be used. Developers will be required to sign Click packages with their private key before they are accepted by the MyApps portal, and the Ubuntu Software Store will provide a signature for Click packages that are to be installed on the end-user devices.

Developer signatures

All packages uploaded to the MyApps portal need to be cryptographically signed by the developer using their GPG key and the debsigs tool. The Click package will not be subsequently modified in any way before being installed on the user's device, besides appending the store signature. This allows non-repudiable proof of the package's origin.

Overview

• The Ubuntu SDK will help developers generate a GPG keypair.

• The developer will upload their public key to the MyApps portal.

• The developer will sign their click package using the debsigs tool and the 'maint' signature type.

• On upload, the MyApps portal will validate the debsigs 'maint' signature on the click package.

See this list post for a brief description on using debsigs.

Future Usage

If certain devices need to be locked down in the future to prevent package side-loading, debsigs may also be used as a means of validating packages in enterprise-wide deployment scenarios, or possibly to allow developers to sign up beta testers for their packages. (TBD)

Software Store Signatures

For Software Store Signatures, the following GPG key chain will be used:

• Store master key (Never expires)
• Store signing key (expired periodically)

Once a Click package has been uploaded to the store, and the developer 'maint' signature verified, the store will then append a debsigs 'origin' signature to the package using the Store signing key.

When a device searches for information on a package (sample query), the metadata returned must contain the following fields:

• download_url: contains the URL of the click package
• download_sha512: contains the SHA-512 hash of the click package

The SHA-512 hash is to be used by the Download Manager service to validate download integrity.

Overview

• Developer uploads package to MyApp

• Store signs package using a debsigs 'origin' and the Store signing key
• Store generates SHA-512 sum of newly-signed click package
• Click Scope performs query on a Click package the user wants to install on their device
• Click Scope requests download of Click package from Download Manager
• Download Manager downloads Click package and validates SHA-512 to make sure it has not been corrupted in transit
• Download Manager starts install helper, passing click filename

• Install Helper asks PackageKit to install Click package

• PackageKit validates Click package by verifying debsigs 'origin' signature against Store signing key

• Install Helper reports package installation success or failure just like it currently does

Unsigned packages

We currently allow the user to install unsigned Click packages with PackageKit. If being able to install unsigned packages is desirable, this should be a manual procedure with an appropriate warning.

• Packages installed through the Click Scope should fail to install if the signature is invalid or missing.
• Packages manually installed through the command line tool with a debsigs 'origin' signature type that could not be validated using the Store signing key should fail.
• Packages manually installed through the command line tool without a debsigs 'origin' signature type should present an appropriate warning and ask the user for confirmation.
• Configuring the system to allow installing unsigned packages should not be exposed via the UI and only available via the command line/adb

Developer signed packages

TBD - possible (future?) support for adding a developer key to the system to allow verification to succeed with either the store key or the developer key. This should not be exposed via the UI and only available via the command line/adb.

Store key Compromised procedure

TBD.

Store key Rotation procedure

TBD.