[opam-devel] OPAM 1.3 roadmap

[Simon Cruanes]

Sandboxing the build would also be a big security improvement. I think cabal now does it, and signing packages doesn't protect against malicious or buggy packages (see: bumblebee's uninstall target). That also goes hand in hand with file tracking. I don't know how difficult it is, though.

Cheers! 

Le 21 février 2015 05:01:56 UTC+01:00, Louis Gesbert <louis.gesbert at ocamlpro.com> a écrit :
>With 1.2.1 almost out of the door, time has come to review the roadmap
>discussed back in December and choose where we'll be going for 1.3.
>Original mail attached for reference.
>
>
>The topic that is burning hot at the moment is, specially after the
>Debian Haskell build host has been compromised, security: we have no
>signing at all at the moment, and we need to improve on this before it
>becomes a problem. TUF [1] has devised a sane amount of rules for
>repository management and signing that should make it easier to get it
>right in OPAM. Hannes has mentionned writing an OCaml implementation
>for TUF, which could get very helpful.
>
>
>Also of importance is Windows support. It should at least be
>straighforward and documented to get a basic Cygwin setup working. That
>goes with adding automated tests (appveyor can now be added in Github
>alongside Travis). Related is cleaning up external command usage (even
>if not really justified by a Windows port only, as David Allsopp
>pointed out) -- replacing curl calls by cohttp, use ocaml-fileutils...
>
>
>These are the other main features, that'll probably take more time if
>we are to focus eg. on security:
>
>* a plugin mechanism with plugins for example for OCaml (for better
>agnosticity), external dependency handling [2], documentation
>generation...
>
>* a 'provides:' field in OPAM files [3]. This is a loose requirement if
>we want to switch the repository to have OCaml itself in a package
>(which is already possible, but the system compiler may yet be an
>issue).
>
>* More flexible switch handling (multi-switch packages, per-switch
>remotes, layered switches for cross-compilation...)
>
>* Tracking of files installed by packages. While unrelated to repo
>signing, this might have some security implications, so we might want
>to bring it in.
>
>* With file tracking, generating a binary repo (with some limitations)
>could be quite straight-forward.
>
>
>Which of these do you think is most important ? Have I forgotten
>anything ?
>
>Cheers,
>Louis
>
>
>[1] http://theupdateframework.com/
>[2]
>https://github.com/ocaml/opam/blob/master/doc/design/depexts-plugins
>[3] https://github.com/ocaml/opam/blob/master/doc/design/provides.md
>
>----- message suivi
>----------------------------------------------------
>
>De : Louis Gesbert <louis.gesbert at ocamlpro.com>
>À : opam-devel at lists.ocaml.org
>Envoyé : Wed Dec 17 11:07:40 UTC+01:00 2014
>Objet : [opam-devel] OPAM Roadmap -- what next ?
>
>Hi all,
>
>with some lag after the 1.2 release, I'd like to open some space for a
>collective discussion of the priorities for where the energies should
>go next. We have mainly 3 directions for improvements: first,
>portability, with the main goal of a Windows version. Second,
>agnosticity, with the goal to make OPAM more generic, and try and open
>it to users outside of the OCaml community (wouldn't OPAM for Haskell
>be fun ?). Third, there are always lots of features and improvements
>that have been asked for, and would improve the experience of current
>users.
>
>So here is a summary of what I've gathered. Feel free to add your own.
>
>
>
>## Portability
>
>- **Rewrite parallel command engine.** / done.
>
>- **Native system manipulation (cp, rm, curl...).**
>These are mostly done through calls to the shell or external programs.
>It's
>not very pretty but quite pragmatic actually... until we want to run on
>Windows without Cygwin. Anyway, this wouldn't be the end of portability
>  issues.
>
>- **Windows support.**
>  for OPAM itself to begin with. This should be pretty close.
>
>- **Packages on Windows.**
>  Locate common issues and attempt to find generic fixes.
>
>- Allow **direct use of more solvers** or solver servers.
>
>- **Support cross-compilation**
>  This is quite an open issue at the moment.
>
>## Agnosticity
>
>- **Isolate OCaml-specific stuff.**
>  E.g. specific opam-file variables. See ocaml-specific.md
>
>- **Separate as plugins**
>  To open the gate to OPAM without these plugins, or with other ones
>
>- **Compilers as packages.**
>This should mostly work now, but needs some tests and strengthening.
>The main
>thing still to do is to handle the system compiler changes properly ;
>that
>  part should be made more generic anyway (see discussion on hooks)
>
>## Features
>
>- A **provides** field. Generally useful, but particulary so with
>  compilers-as-packages
>
>- Releasing the **"features" field** for easier package configuration
>
>- **Track installed files**
>
>- **Improve security**: just checking md5s is quite light ; package
>scripts can
>  write anywhere
>
>- **OS-specific handling of dependencies** (eg dependencies on packages
>from the
>  OS) with plugins (#1519)
>
>- Specify and implement **hooks**
>
>- Find a nicer way to **share dev repos** / undoable "pinning sources"
>
>- **Per-switch remotes**
>
>- **Multi-switch packages**
>
>- Support for (automatic generation of) **binary packages**
>
>- Nicer **ocamlfind interaction**
>
>
>
>Cheers,
>Louis Gesbert
>
>------------------------------------------------------------------------
>
>_______________________________________________
>opam-devel mailing list
>opam-devel at lists.ocaml.org
>http://lists.ocaml.org/listinfo/opam-devel
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>opam-devel mailing list
>opam-devel at lists.ocaml.org
>http://lists.ocaml.org/listinfo/opam-devel

-- 
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/opam-devel/attachments/20150221/c4bd8ff3/attachment.html>