Package signature

conda presentation

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
  • 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:

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