Skip to content

Dev Meeting 2021.06.11 (Conex)

Jump to bottom
Hannes Mehnert edited this page Jun 11, 2021 · 3 revisions

Community Dev Meeting (Conex)

@avsm introduced: Conex started 3-4 years ago; in the meantime opam-repository has grown considerably, including various diverse opam-repository universes. Also in the meantime we now have increased programmability of the testing on opam-repository (ocurrent + opam-repo-ci, etc.).

Overall goal today is just to sync up.

  • It's a shame that Conex isn't deployed yet!
  • So what are the next steps?
    • OCSF (via Gabriel Scherer) happy to fund four months of Hannes's time this year in order to advance the integration of Conex with opam
  • Primary aim of Conex is to ensure that packages installed are trusted and that compromise of a key is limited only to the packages which that key is permitted to sign (i.e. the entire repository does not become compromised)
  • Three "views"
    • Software user
    • Software developer
      • https://sigstore.dev - "LetsEncrypt for developers". Allows public keys and identities to be hosted publicly.
    • Repository maintainer
  • Required support for Conex has been in opam since 2.0; it's just a deployment question.
  • @avsm: what happens if a package maintainer disappears? @hannesm: in this case, a quorum of repository maintainers create a new delegation for that package. Similar system exists for key rollover (e.g. for compromised/loss of key)
  • @dra27: so if a maintainer disappears, the package can be forked to a new repo (e.g. to ocaml-community), a new maintainer signs a new release from there and then a quorum of repository maintainers delegate a new trust for the package name to that maintainer.
  • @avsm: it's also possible to add maintainers? So for example here a maintainer could be added for the package, rather than removed.
  • Suggestion to finally switch to SHA256/SHA512 for opam-repository, hiding it in the simultaneous download and installation in opam 2.1
  • @avsm: is it possible to be more specific with fields which require re-signing. For example, if the bug-tracker is updated, not require re-signing. @altgr: this partially exists already for working out if packages need to be recompiled on upstream updates.
  • Story with pinning is not entirely clear yet: where does the signature get stored?
  • @avsm: overlap of opam pin and opam repo - can one be implemented with another? @dra27 repo feels like the larger feature. @avsm: however, does the other way around work better? @altgr: the main thing that's not available with overlays at the moment is that you can't directly hide other versions (which pinning does). Worth exploring the idea of making repos the first-class way of distributing sets of development (vs pin-depends).
  • @altgr: on the pinning workflow, an experimental tool could synthesise packages with pin-depends to an opam repository.

Slides

Clone this wiki locally