# Package signature

[conda presentation](https://docs.google.com/presentation/d/1aKZqHHVAA8y9fJAf6_5q7cx0gBWScuYAtT5C1Uoky44/edit#slide=id.ga2b8d8b98e_0_283)

## With Anaconda Inc.

### May 11, 2021 meeting

#### Preparation

Current work:
- start with a 1st working implementation similar or using `conda-content-trust` to:
- sign repodata.json metadata
- read and update roles from the client
- verify packages signatures

Future work:
- handling of multiple servers/channels
- TUF model scalable at channel level (= 1 root key/channel)?
- how to deal with multiple servers/channels having their own root certificates/keys
- Issues with v1.0 spec
- different roles (`snapshot`, `timestamp` in v1.0), (`key_mgr` in v0.6)
- sign the repodata.json itself
- no delegation of the root role itself but of the top-level targets role
- scalability
- handling large repodata.json files
- compatibility with json patches
- numerous delegations
- filesystem bottleneck (on win)
- etc.
- v0.6
- published?
- what versions are audited ? https://theupdateframework.io/audits/
- does v0.6 contains known vulnerabilities?
- what workflow for the final user
- integration with CI/runners
- support for maintainers privates keys? or only server signing online?
- reproducible builds?

Meeting objectives:
- advertise Anaconda Inc about our current work
- feel if collaboration is possible
- us providing manpower on `conda-content-trust`
- new features, tests, etc.
- migration to TUF v1.0 or similar, if relevant
- open to PRs?
- them providing guidance/experience?
- write a conda content trust spec/model together?
- Understand how they want to handle delegation of signatures
- open the discussion about future work

#### meeting minutes

Attendees:
- Sebastien Awwad (Anaconda Inc)
- Cheng Lee (Anaconda Inc)
- Sylvain Corlay (QS)
- Wolf Vollprecht (QS)
- Adrien Delsalle (QS)

Discussion:
- how to sign a package at build time and persist that signature
- when moving package through channels, or servers (mirrors, etc.)
- `conda-content-trust` uses an adaptation of TUF
- mainly to simplify the implementation
- we still need to take care about the diff to TUF spec
- for security
- TUF is audited and it provides some guarantees about its design
- having a spec/design doc about conda content trust would be great
- maybe just a diff vs TUF vx.y.z is enough!
- we can join efforts to do that
- snapshot, timestamp, targets -> requires to know what's in the repo
- more protections (mix match, etc.) would be great
- have to figure out how to implement it in the future
- QS people will be happy to open PRs on `conda-content-trust` repo
- use JSON schema?
- work on using GPG or other ED25519 key storage?
- etc.

Wolf notes:
- To not download too much metadata: hashed bin delegations (https://github.com/theupdateframework/tuf/blob/develop/docs/TUTORIAL.md#delegate-to-hashed-bins)
- Interesting reference papers: diplomat or mercury papers

Actions:
- QS: start to contribute on `conda-content-trust` / provide feedback on it
- Sebastien: figure out if it's possible to sign a delegation for QS, for testing compatibility
- Sebastien: provide doc about signing protocol
- All: start a conda trust model/spec? or diff vs TUF?

###### tags: `projects`, `mamba`, `conda`, `TUF`, `The Update Framework`