[opam-devel] OPAM 1.3 roadmap

[Roberto Di Cosmo]

Thanks David, this seems quite a useful app for people on Windows, but I
did not find out whether it can be used as a console command: the
documentation seems to imply that one needs to run its GUI, which is not
gonna work for Opam...

Maybe also on Windows we should stick to LD_PRELOAD, but I never tried that
in practice... I wonder whether it will work with the cygwin/mingw
toolchain.

2015-02-23 10:09 GMT+01:00 David Allsopp <david.allsopp at metastack.com>:

> Roberto Di Cosmo wrote:
> > On Mon, Feb 23, 2015 at 10:07:58AM +0900, Louis Gesbert wrote:
> > > That's starting to sound fairly consistent:
> > >
> > > # Secure OPAM itself a bit:
> > >
> > >   * Sandbox the build step: not sure how to do it, but it should be
> > without network access, and only allowed to write to its build dir.
> >
> > This is really *not easy* in the current state of affairs
> >
> >  -> opam calls whatever command is declared in the build:/install: fields
> >
> >  -> this command can do whatever it wants; a sloppy Makefile might very
> > well end
> >     up removing all the user-writeable files on a machine; think of
> > something like
> >
> >     PREFIX=$(HOME)/$(MYNICELOCALVAR)   # ooops ... using a var defined
> > only on the dev machine!
> >
> >     install:
> >         rm -rf $(PREFIX) # clean up dest dir on the dev machine; rm -rf
> > $(HOME) everywhere else!
> >         ....
> >  -> it's easy to pass through the integration test on opam-repository
> too:
> > if
> >     somebody really wants to make bad jokes, one can simply check the
> >     environment to be nice when going through Travis, and wreak havoc
> > elsewhere
> >
> > In the GNU/Linux distribution world, we face a similar challenge, with
> > install scripts being on top run as root; the very stringent QA process
> > enforced by these communities mitigates the problem quite a bit, of
> > course, but it is still there and s*it happens.
> >
> > That's why I was asking for the characteristics of the sandboxing
> > techniques we known. As with security, "sandbox" is a term easy to use,
> > but difficult to achieve.
> >
> > My best bet is _really_ the ptrace approach followed by Mcqueen in
> > http://robot101.net/files/trace.tar.gz as it allows to monitor _all_
> file
> > access even by statically linked binaries, and is able to make a backup
> > copy of modified files (to restore them, if something goes wrong).
> >
> > What I do not know is whether something similar is available for *BSD,
> and
> > even less for Windows.
>
> See http://www.sandboxie.com/ for Windows.
>
>
> David
>



-- 
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 320 (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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/opam-devel/attachments/20150224/f458eb82/attachment.html>