[opam-devel] OPAM 1.3 roadmap

[Anil Madhavapeddy]

On 23 Feb 2015, at 09:54, Peter Zotov <whitequark at whitequark.org> wrote:
> 
> Roberto Di Cosmo wrote:
>> What I do not know is whether something similar is available for *BSD, and
>> even less for Windows.
> 
> I have spent an extended amount of time on this issue in OS X.
> Plain and simple, it is not possible to intercept syscalls on XNU.
> The ptrace API does not implement PTRACE_SYSCALL, and the equivalent
> Mach API, task_set_emulation, has not ever been implemented.
> I've looked into the XNU sources too and there is simply no codepath
> that performs what you need.
> 
> Forget about this kind of user-space sandboxing on OS X.

The other issue with ptrace-based sandboxing is just how slow it
is due to all the context switching that's imposed.  I don't think
it would fly for day-to-day use.

> However, OS X provides an explicit sandboxing mechanism since 10.5.
> I don't think it will work for opam either:
> 
> The app sandbox container directory has the following characteristics:
> It is located at a system-defined path, within the user’s home directory.
> The container is in a hidden location, and so users do not interact with it directly.
> 
> (from https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW6)

I think this could be made to work, but it all depends on how viable
it is to sign the opam binary with the right entitlements.  If anyone
who has a Mac App store account can experiment with this with a toy
binary and report back, that would be most useful...

Maybe we should rewrite OPAM in Swift, Louis? :-)

-anil