Shameless plug, I tried to document basic opam usage for people who have experience with npm. It turns ok it can also be an introduction to total newcomers. Hope it can help some people. https://khady.info/opam-npm.html On Sat, Dec 1, 2018, at 2:31 AM, Louis Gesbert wrote: >> - John F Carr, 27/11/2018 13:40 - >> I have a related request. I am not a trusting person. I do not like >> "curl | sudo sh" type installation methods.> > You're not the only one :) > Some notes on opam's security model: > > - opam 2.0 uses, by default `bubblewrap` [1] on Linux and `sandbox- > exec` on OSX to ensure that package scripts:> * don't make any network access > * don't interact with other processes > * don't write outside of their build dir, /tmp, and (in the case of > install) the switch prefix (excl. opam files)> > - this is done using simple wrapper scripts [2] and some default hooks > configuration in ~/.opam/config, so if you know about built-in > sandboxing engines for other OSes, it is fairly easy to experiment > with them, and a contribution would be very welcome.> > - while I expect this to be reasonably secure, it's intended first and > foremost to avoid dramatic errors, not to protect against malicious > repositories> > - package scripts are protected but **not any use made by the users of > the programs or libraries that were installed through opam**. In > other words, building should be safe, but there is no guarantee > about what the result of the build will do: that is not restrained > by opam in any way> > - the effort to provide end-to-end package signatures in the > repository [3] is still ongoing. Cheers to Hannes Mehnert for the > awesome work he has already done here. Most of the work should be > done, but then we need to integrate all that, and there is a lot of > work on the tooling so that it won't add to much burden on users and > repository maintainers (this commonly results in most disabling the > security features, which is as good has having no security features > to begin with).> > - we do advertise `curl | sh` on the installation page as the easiest > entry point, but the script is quite trivial and only uses root to > copy to your prefix; it's very easy to fetch the binary by hand from > Github if you prefer not to run it, and of course, you can also > build from source using the bootstrap scripts.> >> If a package has 'rm -rf $BUILD/', or equivalent ocaml code, are >> its ill>> effects confined when BUILD is unset? > > yes, that's the whole point of the sandboxing that was > introduced in 2.0> >> Can the build process grab screenshots from the background? > > not sure. Probably not on Linux since we use a different process > space, but maybe on OSX. In anycase, since network access is blocked > in both cases, that wouldn't do much harm.> >> One reason I like make is, if the Makefile is simple you know what >> it's going to do.> > I would object that opam package definition files (`opam` or > `foo.opam`) should be at least as straightforward to read even if you > have never seen the syntax, are less error-prone, and are generally > much shorter. Just look for the "build:" and "install:" parts. But I > agree you need to know first to look at them, and since they are > generally an indirection to some build-system (`make`, `dune`, > `topkg`...), you would just start digging...> >> Also, the xkcd on standards seems relevant: https://xkcd.com/927/ > > We have __actually__ been converging as of late, though. > > > Best, > Louis Gesbert — OCamlPro > > > > [1] https://github.com/projectatomic/bubblewrap > [2] https://github.com/ocaml/opam/blob/master/src/state/shellscripts/bwrap.sh> and > https://github.com/ocaml/opam/blob/master/src/state/shellscripts/sandbox_exec.sh> [3] https://github.com/hannesm/conex > >> Whatever one true packaging system we use, I want to trust it not to >> let the build process mess up my system. For example, I see opam >> makes some attempt to contain the build process on some systems. >> It's not clear to me how much it does and how effective. And it >> appaerntly does not work on BSD. If a package has 'rm -rf $BUILD/', >> or equivalent ocaml code, are its ill effects confined when BUILD is >> unset? Can the build process grab screenshots from the background? >> And so on.>> >> One reason I like make is, if the Makefile is simple you know what >> it's going to do.>> >> Also, the xkcd on standards seems relevant: https://xkcd.com/927/ >> >>> On Nov 26, 2018, at 05:14 , Oliver Bandel >> berlin.de> wrote:>>> >>> Hello, >>> >>> a while ago it looked like there were not enough build- and >>> installation-tools>>> for OCaml. I remember some discussions about that. >>> >>> Now it seems to me that there are a lot of them. >>> So, developers can pick the one they know about. >>> >>> For all these tools there might be good reasons to use them, >>> and those>>> developers who looked at these tools and choose them for their >>> projects, will>>> know them well enough. >>> >>> The situation differs, if one wants to package the written software,>>> and one needs to know many of those tools, just to compile the >>> stuff.>>> So, when one just wants to compile and install some software, >>> just for that, it would take much effort to learn the different build- >>> tools.>>> >>> So, packaging has become more complicated, even though for the >>> developers>>> these tools may save time. >>> >>> It would be nice if people who used one of the many new >>> building tools>>> could provide a Makefile that allows just to type >>> "make" and "make install", instead of expecting everyone who wants >>> to compile>>> the software to first learn just-another-build-tool. >>> >>> Also it would be good, to mention early, which installation tools >>> (make-dependencies)>>> are in use, and too mention needed packages (opam or others) to just >>> build the stuff.>>> >>> Thanks and regards, >>> Oliver Bandel >>> >> >> >> > Email had 1 attachment: > * signature.asc 1k (application/pgp-signature) -- Caml-list mailing list. Subscription management and archives: https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list Forum: https://discuss.ocaml.org/ Bug reports: http://caml.inria.fr/bin/caml-bugs