[opam-devel] OPAM 1.3 roadmap
Simon Cruanes
simon.cruanes.2007 at m4x.org
Sat Feb 21 09:58:08 GMT 2015
The one I'm most familiar with is fakeroot, used by archlinux for building its packages; it's relevant because the average user (me) can install unsupported software from AUR (a large repository of user-contributed, unsupported packages). Fakeroot is used during the compilation of such packages, before a proper archive is built (one that the distribution package manager, pacman, can use to install/uninstall). Apparently fakeroot emulates a filesystem in a sub-directory and makes believe the untrusted software that is being compiled that it has root privileges to write in the filesystem.
It is probably impossible to do that in a portable way across all OSes, so I think the first step is building in a temporary directory. For Windows support, using shell commands is discouraged (as far as I understood) so opam could provide its own file manipulation directives that would respect the boundaries of the temporary directory.
Le 21 février 2015 10:16:03 UTC+01:00, Roberto Di Cosmo <roberto at dicosmo.org> a écrit :
>Anil, Simon, can you provide more details on the sandboxing mechanisms
>you know of?
>
>We looked into all this for Mancoosi years ago; the most complete tool
>out there was installwatch (now checkinstall) that hijacks filesystem
>modifying
>commands using the standard LD_PRELOAD trick and a wrapper for system
>calls.
>Checkinstall does not alter user priviledges, though, so one sometimes
>needed
>a combination of fakeroot (that only alter user priviledges) with it.
>
>The best approach I know of was described in a Master thesis from ...
>Cambridge
>:-) It was under the supervision of Peter Sewell, and used the ptrace
>mechanism
>instead of the LD_PRELOAD trick, because LD_PRELOAD is blind to
>statically
>compiled binaries that have system calls hardcoded, while ptrace gets
>them all.
>
>The dissertation is still available today here
>http://robot101.net/files/diss.ps.gz
>and contains a very nice discussion of the issues related to monitoring
>and
>rolling back file system changes performed by a command in the Linux
>system.
>The source code is also available here
>http://robot101.net/files/trace.tar.gz
>and one can get in touch with Robert Mcqueen that will be delighted to
>see his
>work being used.
>
>Since all this is almost 10 years old, I suppose many exciting new
>ideas, tools
>and approaches surfaced in the meantime, and I'd really like to know
>more.
>
>Cheers
>
>--
>Roberto
>
>On Sat, Feb 21, 2015 at 09:37:07AM +0100, Simon Cruanes wrote:
>> 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
>> À : 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
>
>> _______________________________________________
>> opam-devel mailing list
>> opam-devel at lists.ocaml.org
>> http://lists.ocaml.org/listinfo/opam-devel
>
>
>--
>Roberto Di Cosmo
>
>------------------------------------------------------------------
>Professeur En delegation a l'INRIA
>PPS E-mail: roberto at dicosmo.org
>Universite Paris Diderot WWW : http://www.dicosmo.org
>Case 7014 Tel : ++33-(0)1-57 27 92 20
>5, Rue Thomas Mann
>F-75205 Paris Cedex 13 Identica: http://identi.ca/rdicosmo
>FRANCE. Twitter: http://twitter.com/rdicosmo
>------------------------------------------------------------------
>Attachments:
>MIME accepted, Word deprecated
> http://www.gnu.org/philosophy/no-word-attachments.html
>------------------------------------------------------------------
>Office location:
>
>Bureau 3020 (3rd floor)
>Batiment Sophie Germain
>Avenue de France
>Metro Bibliotheque Francois Mitterrand, ligne 14/RER C
>-----------------------------------------------------------------
>GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3
>
--
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/opam-devel/attachments/20150221/f894f40e/attachment.html>
More information about the opam-devel
mailing list