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. The Click package will not be subsequently modified in any way before being installed on the user's device. 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.

• On upload, the MyApps portal will validate the debsigs 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 signature verified, the store will then generate a detached (.asc) GPG signature of 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
• signature_url: contains the URL of the store's detached signature of the click package (.asc)
• signature_sha512: contains the SHA-512 hash of the detached signature file

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

Overview

• Developer uploads package to MyApp

• Store signs package using Store signing key, and stores detached signature alongside Click package
• Store generates SHA-512 sums of both click package and detached signature
• Click Scope performs query on a Click package the user wants to install on their device
• Click Scope downloads detached signature and checks SHA-512
• Click Scope requests download of Click package from Download Manager, passing detached signature filename as an argument to be used by install-helper script
• 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 and signature filename

• Install Helper asks PackageKit to install Click package

• PackageKit validates Click package by verifying detached 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 detached signature file that could not be validated using the Store signing key should fail.
• Packages manually installed through the command line tool without a detached signature file should present an appropriate warning and ask the user for confirmation.

Store key Compromised procedure

TBD.

Store key Rotation procedure

TBD.