deployment #7

hannesm opened this Issue Sep 13, 2016 · 1 comment


None yet

1 participant

hannesm commented Sep 13, 2016 edited

code (library)

  • OpenSSL crypto provider (bootstrapping, conex_verify)
  • handle wrapping of Uint (Conex_resource, Uint.succ exposes bool)
  • handle wrapping of counter of index (janitor approval) - warn on overflow in conex_author (sign_index ignores atm)
  • restrict package names and identifiers (provide a check_ function, private constructors?)
  • verification: allow reset of counter (if janitor signed) see #8
  • sync code with paper (Uint; accounts)
  • use opam-data-format instead of Data
  • partial verification: only those bits with an authorisation & releases file
  • handle version field (compare) and future-proof (what to do with a file with a higher version? ignore? assume that files will only be extended, basic semantic will always be valid)
  • safety in Conex_persistency: read and write can fail (currently throwing exceptions)
  • build system
  • encrypt private keys (write the PKCS supporting code in X.509)
  • remove keystore, only idx is signed
  • integrate publickey and index (on disk, load_id, write_id)
  • sign accounts
  • now that Publickey has a type (atm RSA = 0) in Conex_data_persistency, we should add a type and id to signature as well, shouldn't we?
  • monotonicity requirements should be pure and in Conex_repository


  • conex (still need to parametrise IO, crypto, and Logs)
  • conex.unix (see Conex_persistency)
  • conex_verify (binary using conex-core with openssl crypto provider (todo), uses conex.unix IO (done), and custom Logs (done))
  • conex.ext (depends on Logs and nocrypto)
  • conex_author (binary using conex.ext and conex.unix to sign stuff (maybe rename to conex_sign?))
  • timestamp service (using conex.ext, and a MirageOS Conex_persistency (or Conex_provider): private key material has to be provided via other means (Conex_sign uses e.g. Unix.getenv "HOME")

tool (analysis)

  • infer actual maintainers and teams for smooth transition (analysis/
  • author-guided view: for a GitHub id, show team membership and authorised package
  • empirical data (downloads: popular packages, adaption rate of new releases)
  • empirical data (repo: median/average time between releases and new packages)

tool (verify)

  • accept TA fingerprints via commandline
  • quorum passed via commandline
  • strict (only accept everything signed) non-strict (if there is a releases file, all must be signed)
  • full (initial) verification vs incremental

tool (author) - warns on read&verification errors

  • generate key (+public info)
  • sign package (+all releases +authorise me)
  • sign release Y of package X
  • renew key
  • apply for/revoke team membership
  • find local changes (and approve them in your index, although not janitor/authorised)

tool (janitor)

  • revoke key
  • locate PRs which need signatures
  • sign PR X

tool (snapshot)

  • isolate Unix dependencies (in Conex_persistency used by Conex_provider, Conex_private (and Conex_opam_layout))
  • implement

tool (future)

  • report statistics (whom do I trust, who is central)
  • blacklist &/| whitelist specific keys locally (I don't trust A)
  • who owns P (extending all Ts)?, what becomes invalid if A would be no longer be member of T?
hannesm commented Feb 20, 2017 edited

write about attacks and mitigations in conex (each attack a separate issue)

  • tuf spec has an extensive list of attacks
  • resource starvation (big input data (files, dir with lots of files, ..)) Sys.max_string_len
  • opam file format parser (decode/encode: what if a filename has "? or unicode? or control characters)
  • filename encoding
  • github id encoding, package name, etc.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment