On 11 Mar 2015, at 02:39, Louis Gesbert <[email protected]> wrote: > > * 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.
I do think it's important that we retain the ability to do packaging updates without the maintainer signing it. Most obviously, this would let the tools do mechanised rewrites, as we did for several migrations in the past. Any such updates would have to be signed with the correct maintainer key, of course. > > * 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. > Agreed. The only reason I'm not using opam-publish right now is that it conflicts with ctypes (due to Dose). That's fixed in the upcoming Ctypes 0.4... > * We should require maintainers to sign their packages -> the clients > shouldn't accept unsigned packages by default, but there could be "unclaimed" > (repository maintainer handled) signatures on the repo to begin with. Right -- that would be all of them to start with, and the moral equivalent of "[email protected]" :-) > > * 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. I have a nice little way to do mirroring of distfiles btw. An `opam-fetch-url` that checks to see if it has a copy of the distfile URL+checksum in opam-repository/distfiles and just returns that if so, rather than going to the Internet. It just works with OPAMFETCH in OPAM 1.2.1 without requiring any further modifications. Yay! -anil _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
