[opam-devel] opam 1.3 status

[Louis Gesbert]

Removing `--insecure`: absolutely, I would be glad to if I get agreement from 
the repository team.

Sandboxing: we've actually been studying this recently with Grégoire, and it 
seems it's not that difficult to do on Linux, using the namespaces. The related 
features are actually available with just some calls to `unshare` and `mount`, 
and we wrote a quick script that makes ~ read-only, while keeping only the 
build dir read-write, and disabling network. That's for build, for install, 
only the switch prefix should be rw, and the build dir ro. It's absolutely not 
secure for now, but it's a good start.

With that, my idea for 2.0 was to provide a generic way to configure wrappers 
for package commands in the different scopes, document how to put the namespace 
control in place, and do it on our automated tests on Linux: this would allow 
to test the feature well, and provide a good sanity check, if nothing more 
except for opt-in users. This would also allow to try implementations on other 
OSes (I am sure the Docker guys would be glad to help, this is their stuff 
after all ? ;)). If successful, the next release could include it built-in.

How does this sound ?

Le vendredi 4 mars 2016, 11:46:17 Hannes Mehnert a écrit :
> Hello,
> 
> 
> what I miss from this mail is sandboxing - while "tracking installed
> files" is included - but what about containing the build process in a
> chroot-like environment (there was somewhere a long discussion what is
> suitable and what not on which platforms).  Is anyone putting effort
> into this?
> 
> 
> Since signing won't make it into 1.3 (or 2.0, however you name it), I'd
> like to propose to remove the "--insecure" and "--no-check-certificate"
> arguments from the download program [curl/wget] (in
> src/repository/opamDownload.ml).
> 
> The history of this starts in https://github.com/ocaml/opam/issues/55 -
> some sites had invalid/untrusted certificates.  A followup is in
> https://github.com/ocaml/opam/issues/2006 .
> 
> My reasoning: certificates which are trusted with the OS shipped trust
> anchors are nowadays easy to get (let's encrypt hands those out for
> free, startssl and others also provide free certificates).  In order to
> improve this Internet, it is better to be picky (so that people will
> actually fix their https infrastructure).  Also given that some work has
> been done to transparently mirror packages, there'll be a (secure!?)
> fallback in case package authors mess sth up.
> 
> People who don't bother can still manually setup their download tool to
> sth which does not check any certificates.  Secure should be the default
> (also for downloading the opam repository, which is done via https, but
> no certificates are checked).
> 
> I'm sure someone (either opam weather status or dockerized scripts, or
> the mirror) will be easily able to setup infrastructure to report
> archive download failures immediately and report them upstream.
> 
> 
> Thanks for working on this, Louis (and others), and I'm looking forward
> to a new release really soon now,
> 
> hannes