Indeed, we'd better get some security concerns before it becomes an issue ;
Let me point what feels like weak areas at the moment: * No restriction on what the package scripts can do (other than running as user). Not writing outside of the switch prefix would be a good start, but that's more a concern of preventing mistakes than real security since you install executable code there anyway. * No repo or package signing. What we have at the moment is only: - metadata downloaded through HTTPS (no specific certificate constraint) - checksums on client-downloaded metadata (MD5, generated on the server by opam-admin) - (non-mandatory) MD5 checksums on downloaded archives (verified by the client, OR by the mirroring server, which will then happily put a valid MD5 on the repackaged archive -- to be checked) - no extra checks done on the other available repository or package upstream kinds (rsync, git, etc.) This was originally designed as a way to check the integrity of downloads and detect changes, not as a security mesure. * Handling of external dependencies: a bit out of the scope here, but we need to push on the discussion on the design of this, it's at the moment underspecified ; of concern here, there is a feature that allows to specify a URL in the "depexts" field that will be downloaded and executed by opam-depext (mine or Anil's) without any check. Not sure what to do with that. So yes, signing of packages would be a good start, but there are many possibilities ; assuming the Github repo is trusted (as well as the link between that and opam.ocaml.org), having opam-admin add some signatures and the OPAM client check those would certainly go in the right direction while remaining somewhat light. Asking contributors to sign their pull-requests, as mentionned in the LWN article forwarded by Gabriel, is another story (we could be using 'git tag --sign' and integrating that into opam-publish, for example). Cheers, Louis > - Anil Madhavapeddy, 18/01/2015 21:11 - > [+opam-devel to CC] > > On 17 Jan 2015, at 15:19, Gabriel Scherer <[email protected]> wrote: > > > > There is an excellent piece at LWN.net (do consider subscribing to > > this source of quality technical news) about a recent discussion in > > the Python community on how to "secure" their package manager > > http://lwn.net/SubscriberLink/629426/bf933f7acea8466c/ > > > > The article discusses in particular a library called TUF (The Update > > Framework) that aims to help solve the problem in a > > package-manager-agnostic way. > > http://theupdateframework.com/ > > (this page has some other interesting links, eg. to a similar > > discussion in the Ruby community about RubyGems) > > > > Is there a reference point to a discussion of the security aspects of > > the OPAM package manager? What I found so far is this 2013 issue by > > Edwin Török on signing packages: > > https://github.com/ocaml/opam/issues/423 > > > > As far as I know, the current status is that OPAM checks downloaded > > packages against the checksum in opam-repository, so it protects > > against an attacker changing upstream releases, assuming the > > opam-repository remains trusted and there is no man-in-the-middle > > (MITM) attack when the user downloads the metadata -- afaik it uses > > only HTTP currently. > > This is certainly something that needs to go on the roadmap sooner > rather than later, and issue #423 is still the place to record > your opinions. > > Having a signify-like model to let an OPAM mirroring script sign > distfiles would be a good first step, since the complexities of > managing a per-contributor signing infrastructure would be quite > significantly more work. > > Note that the OPAM remote is HTTPS by default since OPAM 1.1. > > -anil > > _______________________________________________ > Platform mailing list > [email protected] > http://lists.ocaml.org/listinfo/platform > _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
