-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 On 03/11/2015 02:39, Louis Gesbert wrote: > # On the current state > > the current client-server protocol and repackaging of archives are > kind of there by legacy more than by design, and this could be a > good opportunity to improve on them
great to hear. > # Proposal (just random remarks) > > Threat model: * an attacker can compromise the repository what does this mean? as mentioned, I'd prefer to have the repository being untrusted. > Package signature: this should probably sign over * the package > definition, excluding the url file (everything under > `~repo/packages/<pkg>/<pkg>.<version>/`) * the upstream package > archive (and possibly its url and mirrors ?) I'd hash all the files of the package definition, and the tarball, and keep a list in the file "checksums": <name>,<size>,[<hash-algorithm>,<hash-value>]+ thus, replacement (or multiple) hash algorithms can be used. the <checksum> in url is no longer needed. let's start with SHA-256. signature is made on the SHA-256 hash of "checksums". > Key delegation: * We can simply delegate to sub-directories of the > repository * OPAM should probably be changed not to accept package > definitions anywhere in the hierarchy then (I _think_ > `~repo/foo/foo.1/bar.1/` would work as a definition for `bar.1` at > the moment, OPAM makes no assumptions on the hierarchy) both good points. > Root key: * TUF propoposes several root keys with a threshold. That > could be a nice security since it makes revocation of root keys > possible. agreed. > claimed/unclaimed/recently claimed maintainer keys (from Python's > pep480): * I think we'll need some kind of 'unclaimed' at least to > ensure the progressive migration to signed packages, having all > maintainers sign up-front before rolling 1.3 sounds difficult. Then > we don't have Pypi's flow of incoming packages, so we may not need > as much infrastructure -- having a default delegated maintainer > could be enough. true. > Timestamp server: * I'd love to see that done by a unikernel that > fetches from github, signs, then pushes back to the repository HTTP > server. Still needs to get its key from somewhere though. in fact, that was my idea as well. > # open questions > > * Allowing non-maintainer updates: I have been wondering about this > as well. It's not easy, and modification of dependency constraints > can be an attack vector already (adding a dep to a compromised > package, or even an unsafe older package version). Sometimes, there > is also a trivial packaging bug, and the repository maintainers > should be able to fix it if the package maintainer is not > responsive enough. We could try and detect 'innocuous' changes, but > that sounds like something that can get too complex very quickly > and will open more weaknesses. No better solution than letting the > modified package get signed by a general repository maintainer, > maybe with a time window for the rightful owner to sign it ? I'll > think some more about it. sounds good. > * opam-publish: I'd like to see it get more widely used. Maybe I > should make it more clear that the first step (`opam publish > prepare`) only gathers metadata locally and is very generic, while > the second (`opam publish submit`) is github specific and bound to > opam-repository by default. Anyway, the signing process will be > open and should be reproducible by hand, with minimum hassle. But > having opam-publish generate, and manage keys would be a definite > gain in usability IMO. it should prepare "checksums" > * dependencies to command-line utilities: OPAM's parallel command > engine relies on parallelism at the sub-process level (we don't > want to embed lwt into OPAM); but having our own download handling > would certainly help with several issues, also including > portability. and running opam within a unikernel :) > # some more * Would we want to use the TUF specified json format ? or sexp, since that's already a first-class citizen! > * Last, I'd like your advice and opinion on the algorithms and > signing to use. Small elliptic-curve based signature (ed25519) seem > to be all the hype now with stuff like signify or minilock. What is > the state of what we currently have in native OCaml, and what would > you recommend ? this whole minilock seems to be a not-yet-though-out-idea (looking into the thread https://moderncrypto.org/mail-archive/messaging/2015/001559.html) what we have - - cryptokit (RSA/DH/hashes) - - cryptohash (hashes) - - ocaml-sha (sha) - - ocaml-nocrypto (RSA/DH/DSA/hashes) - - ocaml-sodium (bindings to libsodium/nacl [curve 25519]) what I'd recommend: be agile! use a keytype and keydata field -- initially support both RSA and ED25519 keys (I believe PyPi people did the same). hannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCQAGBQJVACy+AAoJELyJZYjffCju8ggP+wYwMU7bPLVNYBlS4PyXSPrM HLEFToldVAREWLciKfrGn2/tcpLiiBFLU5luyKt0i4l5Wtx4icZbS4o+BzKyFJMW e1TKOmmjrI8DphNRraI/4URIgFHCjRib9PRTtQYaQ3hW89/SnShgkALE9lO+3Fr6 3GOIqIBR5g0LayJ8slUm3c2Fj+cx3OuDYBtMYiNqSkAW1UPheSckOuHcop/DvSAz x7xnuVqhybi+/+UZQKQnFBACOv6DmNdCj6AB+IE/L0p4EABxc/HodLHX05UPR2ru Uk/fxHtUph3JkxcuoJuRvjgaQpOVDh7/nFDIWwRnwW0ZZdEkjNE3MluRQy0ZfCNK Mz0RK2PD7E5LqIVDiZj4tW9bt2EIH9lYeleU9ZPgQDJzuQ3pAscIiAIZxYHORVLV gihXpUfNKYK7Ps7aYHYlmGQgsqsLK1yJo/LGsLJLYiByB63H1AJIuYh7/20juep0 lqkWcntfuExtvxUOefZheVrdsX5wC06bf4zx6GicMka9r9dqE9Td1p+eqCEVMY4k C/6XePWfDY5Cjp6Q5X3+XpXKphX6lLo+BsPaaMZPKO6SOF8hrvMYk/Hf7CVJbNHj mMim/qOIT40D2LVyszbuMgG4lsNt3BSVMKPgp5v4cR3ELYkJ63dyBPNX4sNup8T0 GYVB6WCq7o0cGjDrA870 =xtFb -----END PGP SIGNATURE----- _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
