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.

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:

We have _actually_ been converging as of late, though.

Louis Gesbert — OCamlPro


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:

On Nov 26, 2018, at 05:14 , Oliver Bandel <> wrote:


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: