Yes, I'm on it, there has been a little bit of lag on my part as I was quite busy refactoring OPAM's infrastructure [1], which should really pay off when we start the implementation, and make it more robust. Rest assured the signing ideas keep maturing in the meantime :)
[1] https://github.com/ocaml/opam/issues/2106 > - Hannes Mehnert, 17/04/2015 09:51 - > Gabriel, > > On 04/17/2015 08:52, Gabriel Scherer wrote: > > (Since this thread was last active there have been very promising > > discussions on security that could see the day for OPAM 1.3.) > > > > This list may be interested in the recent plan/proposal for > > security in Hackage (Haskell's package distribution > > infrastructure), which are basically "follow TUF": > > http://www.well-typed.com/blog/2015/04/improving-hackage-security/ > > thanks for the pointer. A very well written proposal. Some > discussion was on the opam-devel mailing list [1]. The general idea > is very similar to Haskell: use TUF, make it painless for package > maintainers. Louis and I wanted to come up with concrete usage > scenarios (client / maintainer / new maintainer / key revocation/loss). > > > hannes > > > 1: http://lists.ocaml.org/pipermail/opam-devel/2015-March/000991.html > > _______________________________________________ > Platform mailing list > [email protected] > http://lists.ocaml.org/listinfo/platform >
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Platform mailing list [email protected] http://lists.ocaml.org/listinfo/platform
