Trusted keys

[MattDHill]

• [ ] Design scheme for key trust delegation and validation on arbitrary length trust paths
• [ ] Validate signatures against known trust roots
• [ ] If signatures are not validated all the way down to trust roots, warn user about danger
• [ ] Trust revocation

Ultimate Goal: Users should understand WHO they are trusting when installing packages.

[ProofOfKeags]

This seems like it might be two features:

1. Add the ability to add/replace package signing keys from the developer/maintainer
2. Add the ability to add/replace the package repository (registry)

[MattDHill]

Correct, these are separate features, but with multiple marketplaces, trusted keys will become an important protection for users.

Also, services will likely be identified by the conjunction of their ID and the key(s) used to sign the binary. Probably tangential, but an important point.

[ProofOfKeags]

Ok so I will separate them out into their own items. From the sound of your comment, the alt marketplaces one is contingent on having key management infrastructure so that ought to be worked on first.

[ProofOfKeags]

The design has been punted since the package format is versioned. How we handle trust chains will be dealt with in the next package version.

[ProofOfKeags]

0.3.1 SoW: Scope this completely. Do not need to implement for 0.3.1

[MattDHill]

Packages signed with developer pubkey

registries return list of trusted pubkeys for each service id with names

registries return list of pubkeys to revoke

sideloading packages with untrusted pubkey will prompt to trust pubkey

installing dependencies with untrusted pubkey will prompt to trust pubkey

page for managing trusted and revoked pubkeys

cert pinning or tor for registries