From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by c5ff346549e7 (Postfix) with ESMTP id DFC7A5D5 for ; Fri, 30 Nov 2018 16:33:30 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.56,299,1539640800"; d="asc'?scan'208";a="358202936" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 30 Nov 2018 17:33:29 +0100 Received: by sympa.inria.fr (Postfix, from userid 20132) id 9E4C48255D; Fri, 30 Nov 2018 17:33:29 +0100 (CET) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 8CF28824CF for ; Fri, 30 Nov 2018 17:31:25 +0100 (CET) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=louis.gesbert@ocamlpro.com; spf=PermError smtp.mailfrom=louis.gesbert@ocamlpro.com; spf=Pass smtp.helo=postmaster@mail.antislash.info IronPort-PHdr: =?us-ascii?q?9a23=3ACouTVR8AOtjsf/9uRHKM819IXTAuvvDOBiVQ1KB3?= =?us-ascii?q?0+wcTK2v8tzYMVDF4r011RmVBdWds6oMotGVmpioYXYH75eFvSJKW713fDhBt/?= =?us-ascii?q?8rmRc9CtWOE0zxIa2iRSU7GMNfSA0tpCnjYgBaF8nkelLdvGC54yIMFRXjLwp1?= =?us-ascii?q?Ifn+FpLPg8it2O2+557ebx9UiDahfLh/MAi4oQLNu8cMnIBsMLwxyhzHontJf+?= =?us-ascii?q?RZ22ZlLk+Nkhj/+8m94odt/zxftPw9+cFAV776f7kjQrxDEDsmKWE169b1uhTF?= =?us-ascii?q?UACC+2ETUmQSkhpPHgjF8BT3VYr/vyfmquZw3jSRMMvrRr42RDui9b9mRh/2hi?= =?us-ascii?q?kaOTA382bXhc5+jK1UvB2svBN/z5LObYyPKPZyYqHQcNUHTmRBRMZRUClBD5u6?= =?us-ascii?q?YYsIEuoBPP1YpJT8qVQQthuxHhejBPnzyjRVgXL22ao60/kgEQHdxgAgEMwBsG?= =?us-ascii?q?/Po9rrLqcSTfu4zK7UwjrZavNW3S/96JLPchw7vf6MWrdwfNPXxEIyGQ3FiVCQ?= =?us-ascii?q?ppbkPzOTzukNvGmb7/ZgVeKykGErsR1+oj+qxss0hYjJhZ4axU3e+Splx4Y1IN?= =?us-ascii?q?u1Q1N4b968CJZduSOXO5FrTs4hQWxkojg2x7IJtJKhciUHyZIqzAPFZfOdaYiH?= =?us-ascii?q?+BfjWf6RIThmgHJlf6qyhxOo/kihzu3wTNO70FBWripEidnMsmoC1wfT6sSdS/?= =?us-ascii?q?t9+Emh2TGX2wDS7OFLP1w0mLLVJpMj2LI8i5kevEbZEiPol0j7g7Wae0sl9+Sw?= =?us-ascii?q?7uToeLTmppuSN49ujQH+N7wjmsi4AeQlMwgORHKX+eui27345kL2Xq9KjuEtn6?= =?us-ascii?q?nerJ/VP8EbpqqhAw9P1YYv8QqwDzCj0NgAh3kIMEpFeA6bj4juI1zBPOr3DfK7?= =?us-ascii?q?g1i1lDdrxuvGPqH6D5XWLnnDla/hcqxn505dzgoz19Ff6IhOBrEPOvKgEnP24d?= =?us-ascii?q?fRCxt8Nw2v387mDs9838UQQybHIKiZNuv8+XSB/Phnd+uCb6cQuSq7JvQ4sa3A?= =?us-ascii?q?l3g8zHsaYKiylbQac3q1BOgud0GefHv3xNgMCm0HpBYWS+fjjVmaSzkVbHG3Cf?= =?us-ascii?q?FvrgonAZ6rWN+QDrumh6aMiX/iT89mI1teA1XJKk/GMoCNWvMCciWXe5MzlTcN?= =?us-ascii?q?ULy5UYhn3har5lGjl+hXa9HM8yhdjqrNkcBv7rSPxxY5/DlwF96alWqKSjMsxz?= =?us-ascii?q?5ad3oNxKl65HdF5BKD3Kx/2aUKENVS47VAVBs7LprV1Ow8Ctb8XVCYcw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BqBgAdZQFc/yT0uyVjDg4BAQEEAQEHB?= =?us-ascii?q?AEBgWWCanASJ4N5iHeNOI4KgkKIdggFJYFSgnUCCINHBwEDNBIBAwEBAgEBAQE?= =?us-ascii?q?BbBwMgjYigmQBAQEBAgEjWwsLGAkhAgIPAUcGARKDIoF5DAumKIEvhC0BhXoFg?= =?us-ascii?q?m2LBD+DdS6DBRkChGWCVwKJCZZXVQcCgh4EhF2KUAqBUYgBM4cQgnmGAoQ4LIp?= =?us-ascii?q?+gV0hgVUzGiNQgmyGCIoYPEEwjlABAQ?= X-IPAS-Result: =?us-ascii?q?A0BqBgAdZQFc/yT0uyVjDg4BAQEEAQEHBAEBgWWCanASJ4N?= =?us-ascii?q?5iHeNOI4KgkKIdggFJYFSgnUCCINHBwEDNBIBAwEBAgEBAQEBbBwMgjYigmQBA?= =?us-ascii?q?QEBAgEjWwsLGAkhAgIPAUcGARKDIoF5DAumKIEvhC0BhXoFgm2LBD+DdS6DBRk?= =?us-ascii?q?ChGWCVwKJCZZXVQcCgh4EhF2KUAqBUYgBM4cQgnmGAoQ4LIp+gV0hgVUzGiNQg?= =?us-ascii?q?myGCIoYPEEwjlABAQ?= X-IronPort-AV: E=Sophos;i="5.56,299,1539640800"; d="asc'?scan'208";a="287446700" Received: from antislash.info (HELO mail.antislash.info) ([37.187.244.36]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Nov 2018 17:31:21 +0100 From: Louis Gesbert To: caml-list@inria.fr, John F Carr Date: Fri, 30 Nov 2018 17:31:18 +0100 Message-ID: <7429727.XKSIZ6bzdz@agaric> Organization: OCamlPro In-Reply-To: <469288B6-200B-400D-8BCB-C3C53B0954B3@exchange.mit.edu> References: <20181126101448.3ee5jgz4c6ulsbbr@first.in-berlin.de> <469288B6-200B-400D-8BCB-C3C53B0954B3@exchange.mit.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7844105.R3KUQcB0V3"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Validation-by: louis.gesbert@ocamlpro.com Subject: Re: [Caml-list] Build-/Installation-Tools - not enogh of them? Reply-To: Louis Gesbert X-Loop: caml-list@inria.fr X-Sequence: 17196 Errors-to: caml-list-owner@inria.fr Precedence: list Precedence: bulk Sender: caml-list-request@inria.fr X-no-archive: yes List-Id: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --nextPart7844105.R3KUQcB0V3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" > - John F Carr, 27/11/2018 13:40 - > I have a related request. I am not a trusting person. I do not like "cu= rl | sudo sh" type installation methods. You're not the only one :) Some notes on opam's security model: =2D 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 insta= ll) the switch prefix (excl. opam files) =2D this is done using simple wrapper scripts [2] and some default hooks co= nfiguration in ~/.opam/config, so if you know about built-in sandboxing eng= ines for other OSes, it is fairly easy to experiment with them, and a contr= ibution would be very welcome. =2D while I expect this to be reasonably secure, it's intended first and fo= remost to avoid dramatic errors, not to protect against malicious repositor= ies =2D package scripts are protected but **not any use made by the users of th= e programs or libraries that were installed through opam**. In other words,= building should be safe, but there is no guarantee about what the result o= f the build will do: that is not restrained by opam in any way =2D 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 a= lready done here. Most of the work should be done, but then we need to inte= grate 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 resul= ts in most disabling the security features, which is as good has having no = security features to begin with). =2D we do advertise `curl | sh` on the installation page as the easiest ent= ry point, but the script is quite trivial and only uses root to copy to you= r prefix; it's very easy to fetch the binary by hand from Github if you pre= fer 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, t= hat wouldn't do much harm. > One reason I like make is, if the Makefile is simple you know what it's g= oing to do. I would object that opam package definition files (`opam` or `foo.opam`) sh= ould 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 fo= r 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-sys= tem (`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 =E2=80=94 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/sandbo= x_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 at= tempt to contain the build process on some systems. It's not clear to me h= ow 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 screensho= ts from the background? And so on. >=20 > One reason I like make is, if the Makefile is simple you know what it's g= oing to do. >=20 > Also, the xkcd on standards seems relevant: https://xkcd.com/927/ >=20 > > On Nov 26, 2018, at 05:14 , Oliver Bandel w= rote: > >=20 > > Hello, > >=20 > > a while ago it looked like there were not enough build- and installatio= n-tools > > for OCaml. I remember some discussions about that. > >=20 > > Now it seems to me that there are a lot of them. > > So, developers can pick the one they know about. > >=20 > > 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. > >=20 > > 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-t= ools. > >=20 > > So, packaging has become more complicated, even though for the develope= rs > > these tools may save time. > >=20 > > 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 c= ompile > > the software to first learn just-another-build-tool. > >=20 > > Also it would be good, to mention early, which installation tools (make= =2Ddependencies) > > are in use, and too mention needed packages (opam or others) to just bu= ild the stuff. > >=20 > > Thanks and regards, > > Oliver Bandel > >=20 >=20 >=20 >=20 --nextPart7844105.R3KUQcB0V3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEbvv1DIVPNISNNdcMGDmcR4apvJgFAlwBZdYACgkQGDmcR4ap vJhLnQf7Bs5NK7TlUaHuYZirX1+YvDFkdkTsGQDNoqs3dzck4Ky7kZ6CyDmTYI7k +vMvw9tdd5M59CY/ms9vY0ZJPI3FlTRV+3A/AbvgkDS89jZNX95SuzjRb7yNhTJR rCUUx87NTNxCtiVEReZrcioIuR8EjLYpr8g73rkUTgd/YdDAQXOHeOxOqQYuxxQj 836VnqXGvkJYGnyjM5aPo7dLBTUNgiowUaAvyd/lBAFbnnEsv16wKpQhz46Puirw aoljkdLIT9VyRBFhE06ALE9yLMwwfjZoohmeOTJgpszsA2Riveg69oc2dZT/1hng uqqNx+CHWnwpQFJpwP+1UiphXvV0pQ== =UFnj -----END PGP SIGNATURE----- --nextPart7844105.R3KUQcB0V3--