new Library Infrastructure spec.

S. Alexander Jacobson haskell at
Wed Jun 2 14:22:48 EDT 2004

On Wed, 2 Jun 2004, Simon Peyton-Jones wrote:
> But remember that you are installing a library that you will later
> (presumably) run, and that might be bad too.

We have two different issues here: the safety of
*running* a library and the safety of *installing*
a library.

Obviously, if I run a lib in the IO monad without
a sandbox, I am totally at risk of whatever the
code does (but see below)

However, if I run a library outside the IO Monad
(and I can be certain that the lib does not call
unsafeperformIO) then I have a high level of
confidence in the safety of running the code. And,
if that lib also comes with quickcheck/hunit/proof
code, then I can have a really high level of
confidence in using the code almost immediately.

Isaac Jones observed that unless you and the other
compiler authors say that it is easy/possible to
make it safe to *run* libraries, there is no point
in trying to make it safe to *install* them. So,
the questions on the table for you is whether
there is an easy way of guaranteeing that non IO
Monad code does not do unsafeperformIO.

If ensuring safety of non IO Monad code IS
possible, it may be worth thinking about making
installation safe as well (depending among other
things on the volume of anticipated IO Monad
libraries w/r/t non-IO Monad libraries, but see
#1 below).

Regarding making installation safe, Isaac Jones asked:
> What about packages that install binary tools or data files?  I don't
> want to limit the system to just libraries for the sake of this
> security feature.

and Simon noted:
>  Setup.lhs runs in the IO monad else it would not be able to move
> files or run a compiler.

Moving (data) files can be done completely
declaratively and safely.  Bob the Builder and Sam
Sysadmin just needs to know if existing files or
paths are being changed in the process.

Compiling is perhaps more difficult but it is not
clear to me that you can't define compilers
available to the installation system and know that
these compilers do nothing except produce
binaries.  (Especially because 99% of compilation
will be the Haskell compiler itself and involving
other compilers is guaranteed to be a headache no
matter what you do)

The only other IO that an installer may want is
the ability to solicit user input and the ability
to download files from the net based on that
input.  I assume the former awaits a further
proposal elaboration if it turns out to be
necessary at all (as compared to command line
flags).  I assume the later can be defined in
terms of the former also in some declarative

For exampe, here is a simple safe strawman
installer data structure:

  data Install = Install  [CommandLineOption]
  type CommandLineOption = String
  type CommandLineValue = String
  type CommandLinePair = (String,String)
  data Download = [CommandLinePair] -> URL
  data Compile = (String,[CommandLinePair]) -> (Compiler,Options,[String]))
  data FileMove = (String,FilePath)

For more flexibility, I could imagine a more
procedural one that has only the verbs GET, PUT,
POST with respect to various resources including
compilers and file systems.


#1 Java and Python provide control/visibility into
what libraries/native-functions a foreign lib
uses.  I assume that Haskell could do this at
compile/download time rather than runtime which
would be substantially cooler.  Downloadable code
in combination with Haskell's emerging generic
programming infrasturcture could be really really
useful and powerful.  I imagine a server to which
you upload code that navigates arbitrary data
structures (e.g. a database) and acts based on the
data it finds in some safe manner.

S. Alexander Jacobson                  mailto:me at

> | > I like the simplicity but would also like the spec
> | > to make it easy for me to guarantee that that I
> | > don't end up running/installing malware.
> | >
> | > I think Haskell's typesystem and purity should
> | > make it relatively easy to make sure that:
> I don't think so, alas.  The IO monad lets you do *anything*, and of
> course Setup.lhs runs in the IO monad, else it would not be able to move
> files or run a compiler.
> So I'm not optimistic.  Perhaps a package whose Setup.lhs did nothing
> but import Distribution.Simple (which you perhaps trust) would be more
> trustworthy than a big pile of goop.
> But remember that you are installing a library that you will later
> (presumably) run, and that might be bad too.
> I'm not optimistic here.
> Simon

More information about the Libraries mailing list