On 06/05/2015 12:59 PM, Hannes Mehnert wrote: > Hi all, > > After a couple months of research and discussions between Louis > Gesbert and myself, the proposal for a secured OPAM repository > (featuring both end-to-end signing, and repository signing), is ready > for a wider review. > > The result has just been posted at > https://opam.ocaml.org/blog/Signing-the-opam-repository/ > > This thread is intended as the official channel for comments and > discussion on the proposal above.
Thanks for working on this, I think this is an important piece in the opam infrastructure. - there's been a few downgrade/MiTM attacks related to legacy cryptography in TLS or Jwt and I'd like to avoid that here. Can we require that minimum key sizes and algorithms are always specified outside the file itself that contains the signature? For example client-side enforcement of minimum SHA-256 [*] and RSA-2048 for the entire chain, otherwise someone could create a signed file specifying md5 as algo, and perform an md5 collision on the signature, or introduce a weak RSA key in the delegation chain. As long as the format supports multiple hashes you can of course still include md5, sha1 for compatibility with old opam versions, and when you want to upgrade the algo or hash you can just bump the minimum requirement in the next opam version and provide both signatures in the repository. In fact its probably better to have multiple hashes even if one of them is weaker as it is probably much harder to generate a collision with the same file for multiple hashes - packages with git or local directory as source These should probably not be signable with anything higher than a snapshot key, because the remote git repository can change any time without signature verification. And local directory sources are probably similarly unsafe (could be NFS mounted, etc.) Package signatures with a high trust path must always contain a hash of the source tarball. - Github PR merge security Author of PR can push more commits (even rewrite the whole PR history with force push) which might create a race condition between reviewing a PR and merging the PR. Can the snapshot bot add a comment to each PR after it finished the Travis build with the Git commit hash? - opam --trace-sigs Perhaps you intended to include this in opam-admin, but would be useful to be able to display the full signature chain, and all the files and signatures involved in it in the client too (think: dig +trace). - how expensive is it to check signatures? Will the client check each package's full chain, or just for the root and the packages that are to be installed/upgraded? [*] I know Git uses SHA1, but that shouldn't prevent us from using SHA-2 (too) for the signatures Best regards, --Edwin _______________________________________________ Platform mailing list [email protected] http://lists.ocaml.org/listinfo/platform
