"S. Alexander Jacobson" writes:

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:

We actually talked about exactly this idea (thanks to Ross) last month. I understand what you're looking for here, but I don't think you'll be able to get any extra security without unduly limiting the system...

1. installation has no sideeffects beyond making a module available for import

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.

2. import has no sideeffects beyond making functions in a module available

This is already true (besides some stuff with type classes, of course).

3. the installer and perhaps end-user is notified if functions in a module/package use unsafeperformIO or some equivalent and perhaps what IO functions the IO monad code actually does use (if any).

This would be nice, but in absence of this (which is outside the scope of this project, since it'll require changing the compilers), your (1) above becomes less useful, and we limit ourselves to just libraries for the sake of ineffective security. I have no idea how difficult all of that would be. Maybe some of the implementation authors can speak to that.

I don't want to have to trust a random downloaded Setup.lhs (I don't want to have to read/understand its source) and I suspect it is easy enough to make sure that I don't have to.

I suspect that implementing real security here will be harder than it looks, and I don't want to delay the package infrastructure until all those problems are sorted out and the compilers implement them. For now, I'm afraid, trust is an all-or-nothing venture when it comes to running someone else's code. It would be really cool to have a "secure library infrastructure" which is more limited but which provides more guarantees. I just think it's overly ambitious for now. peace, isaac

Keith Wansbrough writes:

This looks great! A few comments:

Thanks :)

1. In the document, Angela uses `#! runhugs' or `#! runghc' at the top of her Setup.lhs. But Joe is running an nhc install. Angela can't know which compiler Joe is using, and so she shouldn't have to specify at the top of Setup.lhs. I propose that she write `#! runhs' instead, and the compiler writers all provide a `runhs' script (or symlink) as appropriate.

This is an idea that I've been promoting for over a year :) Simon Marlow recently implemented runghc, btw. It would be great to have a runhaskell. It doesn't actually matter which haskell implementation Joe is using to execute the Setup script, since he specifies the target compiler on the command-line. The reality is that Joe is meant to execute the setup script however he can. He can even compile it and run the executable. We'll somehow have to make this clear in the end-user documentation, until we can deploy a runhaskell script to standardize things. I'll try to clarify the document in this regard. I imagine that in a GUI environment like windows, you can execute the script via some kind of GUI wrapper that understands the Setup interface.

2. In section 4.1, the syntax for pkg.desc is discussed. I think the simplest and least surprising syntax to use would be the RFC-2822 email message header syntax (specifically sections 2.2 and 2.2.3). That is, each field is first written as

I'm leaning toward the Haskell read / show syntax.

3. In section 3.1.3, it is unclear whether a user package (on being registered) may expose a module with the same name as one in an (already-existing) system package.

I believe that it is fine for a user package to expose a module that's already exposed by a system package. I hope SimonPJ can confirm, though.

In section 3.2, is the checking mentioned at the end of the section performed lazily or eagerly? (i.e, if the program does not mention a module name that overlaps, is this still an error?).

IMO, it should be eager, and I think that the Simons and Malcolm agreed about that (correct me if I'm wrong). Take this for-instance: - The user uses packages P and Q, with overlapping module name M. She uses module A from P and module B from Q, but not module M and the compiler allows this (this is the "lazy" approach). - This goes on for a long time, and she has lots of code that depends on both P and Q. - Suddenly, she wants to use module M from package P, which is completely different from module M from package Q. She is stuck, and now has to choose between module M and package Q, which she will have to back out of. Better to stop her early before she becomes dependent on Q. Oh, and there are other issues where if P:A depends on P:M then if the compiler needs to stick Q:M in the same program, it'll have to qualify the module symbols with the package name (and version?) This isn't my area, though. Can you suggest a wording which would make it unambiguous that this is eager?

5. In three places you say "setup" rather than "./Setup.lhs": s4.2.1 bullet 1, s5.4 "setup configure" and "setup build".

Thanks. It is actually possible that ./setup is a compiled program that the user wants to run, but it would be best to be consistent.

--global under 4.2.3 should repeat the rubric of --user regarding "This flag has no effect under --install-prefix".

Period missing at end of s3.0 sentence.

Thanks. peace, isaac

At 16:02 02/06/04 +0100, Keith Wansbrough wrote:

...

I think SimonM's suggestion of an RFC2822-like syntax is reasonable, but it

[my suggestion, not SimonM's!]

Oops, sorry!

...

would probably be better to not simply cite RFC2822, since some

I agree, we should give an explicit definition. I don't think it's likely to be very complicated.

Indeed.

...

complications might arise. An alternative might be XML, which would be a more "modern" choice.

Ugh! No! Please! No! No reason to do this - remember, this file is written by Angela Author, who has just written a Haskell module or two, and doesn't have a handly XML structured editor to hand. She just wants to fire up her text editor and write three lines.

I wasn't strenuously arguing for that, just noting a possible alternative.

...

Some nits to look out for with RFC2822 format are: + Internationalization and non-ASCII characters

We should specify either Latin-1 or Unicode/UTF-8. The latter, I guess.

Yes, Unicode would seem appropriate, and UTF-8 is a popular encoding.

...

+ Case (in)sensitivity of header field names

Insensitive would follow the Principle of Least Surprise.

I think so.

...

+ No support for structured information (text string values only). + No facility for grouping information + Comments in some header field values

I was imagining that the text string would almost always be a Haskell value, using the Haskell lexer and a Haskell-related parser. This would give us comments and structure.

I wasn't aware that there was a comment convention for Haskell *values*, just Haskell code. I guess that's what you meant.

...

+ Extensibility model

Yes, this should be specified. The document already implies "ignore headers you don't understand", which is good.

The minimum requirement seems to be a combination of: (a) ignore what you don't understand, unless (b) the document says you *must* understand certain headers or fail entirely.

Try this, using the Haskell Report grammar syntax, and Section 2.2 of the Haskell Report for the definitions of <lexeme>, <newline>, and <whitespace>:

<description> ::= { <descline> }

<descline> ::= <fieldname> : { <lexeme> | <foldedwhitespace> } <newline>

<foldedwhitespace> ::= <whitespace> | <newline> <whitespace>

with the proviso that any <newline> in <foldedwhitespace> has no semantic significance.

Alternatively, we could provide Haskell code as specification here.

Sure, that bit's easy enough. But there's devil in them there details. Not too much, though. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

At 17:22 06/06/04 -0400, Isaac Jones wrote:

Graham Klyne writes:

...

General:

After a first reading, I find myself a little confused about the module naming invariant (sect 2.2), and subsequent comments about prefixes (e.g. 4.2.1, 4.2.3). I think that the term "prefix" is used exclusively to refer to file location, but the name suggests something "deeper" is intended.

True. Can you suggest a wording that would be more clear? For instance, the explanation of the flags in section 4.2 say that they "specifies where the installed files for the package should be installed".

I'm replying without context properly "swapped in", so my apologies if these comments seem a bit disconnected... If the term prefix is used purely to indicate the file location, then I suggest calling it a "path name prefix". I think my confusion may be that I'm not clear about the interaction (if any) between path names and module names. With current Haskell systems, my experience is that a hierarchical module name corresponds with the trailing components of the path where the module is stored. So there's a leading path component that might be interpreted as a "prefix". It's difficult to make concrete suggestions about something where I'm not confident of the actual facts, but I think an added sub-section 2.x (say, just after 2.2) that explains the relationship between module names, file names and packages; e.g. (and the details here may be wrong): [[ 2.x Packages, file names and module names In [some|many] Haskell implementations, hierarchical module names are related to the location of the module files that the Haskell compiler uses for the module definition. For example, when a compiler imports a module, it uses specified file location(s) as the starting point for a search to locate the module definition file. Suppose the specified file location is <path>, then the compiler may look for module "Foo.Bar.Baz" in location: <path>/Foo/Bar/Baz (or similar, depending on the hosts system directory and file naming syntax). When a package is installed, the value of <path> is a "package path name prefix", or just "prefix", that indicates where the package files are installed. Subdirectories of this prefix location correspond to the module hierarchy declared within the package. Module names are not themselves affected by the package path name prefix used, so differenct versions of a module hierarchy may be stored in different locations. ]]

What if I change it to: "specifies where the installed files for the package should be installed (ie the location of the files themselves)."

[Sorry, I've lost context to respond to that particular point; I hope the above thoughts help.]

...

I'm also (mildly) concerned that the invariant might create problems for distributing and installing large libraries (cf. the problem noted in section 3.1.2).

While appreciating the desire noted in 2.2 for avoidance of complexity, I can't help wondering if there's a "minimal" approach to qualifying module names that would allow module version-mixing in a program. I'm thinking of something like a "hidden" qualification of each module name that is derived from the particular source of the module (location, hash of content, or something else). Then, different versions of a module might be made visible to different source files without prohibiting multiple versions appearing in a program. The details of such differentiation would be entirely compiler dependent, so I think the design space is not unduly prejudiced.

These issues involve tricky compiler symbol naming issues which I won't comment on (maybe one of the compiler hackers can explain). Perhaps in the future, we can relax these requirements, however.

I was peripherally aware of some of that discussion, but I thought the biggest problems may have been that the earlier proposals forced a particular naming architecture on the compiler implementations in an area which is quire implementation sensitive. I was hoping that the "hidden" qualification might mitigate that difficulty. But, in truth, if there is scope for future relaxation of the framework, I think that this issue should properly be deferred. One day, if Haskell truly succeeds as we'd like, I think the ability to have different versions of a package within a single program will be an important consideration. For example, one of the problems with Microsoft's DLL architecture has been the problems caused when one application upgrades a DLL which is used by other applications. Maintaining total backward compatibility can be really hard; the alternative (AFAICT) is to allow some components to continue to use an older version as newer versions are introduced. (A random thought that crosses my mind is source preprocessing, so that, e.g.: import Foo.Bar.Baz might be replaced with import Foo.Bar.Baz.V10 as Foo.Bar.Baz as a package is installed. That would (maybe) be messy to do, but it suggests a possible approach in the Haskell compiler front-end which would not impact the complex code analysis phases that come later? Maybe a stop-gap might be to incorporate appropriate functionality into cpphs? I don't really like all this, I'm just trying to offer ideas.)

...

Section 1.2 and elsewhere:

I find the use of Unix scripting features may be less easy to operate on (say) Windows systems. I think Simon Marlow's suggestion may be better: (snip runhaskell explanation)

I just commented on this in my reply to Keith. This scripting feature is a convenience for Unix and has no real effect on the behavior for windows. In windows, the script must somehow be executed. In any system, the user may choose to compile the module by hand.

OK, maybe then play down that aspect slightly? E.g. in section 1.2, after the example: [[ The Haskell program imports a main program from Distribution.Simple, which impleemnts the HPS simple build infrastructure. The first line is present for Unix systems to ensure that, when it is run, the file is interpreted by the program runhugs. On other operating systems, different mechanisms may be used to ensure that the file is interpreted as a Haskell program. ]] Hmmm... I'm still not entirely happy with this. It seems that the "universal" setup.lhs format is being adapted to serve the needs of a single operating system. Indeed, to serve a particular Haskell system (Hugs).

One thing that the windows community might do is write a program which reads the first line of an .hs or .lhs file to see if it's a #! line, and if so executes it with the given compiler, if not, drops you into an interpreter, or an editing environment or whatever.

Isn't this akin to what Simon suggested, except that his suggestion was independent of any particular operating system?

I just don't know what the default double-click behavior for windows should be, really. Can you have a right-click "Open With" context menu? Can windows prompt you with the options (run, load in interpreter, or edit)?

(For Windows, it's normally based on the file extension and registry entries; this may be problematic if there are multiple Haskell installations on a single machine.) [...]

...

So what's my concrete suggestion? Maybe (a) to emphasize the Setup test option (sect 4.2), and (b) define a default location in the install path for a test suite, or an entry in the package description (4.1, and elsewhere) specifying a command to run the test suite.

It occurs to me that this is one of the tasks that can be implemented somewhat independently of most of the system.

Yes, I think it's mostly a documentation thing, maybe with a couple of helpful defaults to minimize the barriers to actually shipping self-test code.

...

Section 3.1.1, final para:

I found this paragraph really hard to understand. It seems to be contradicting itself (...are separate...all use the same user packages...), but maybe I'm just not understanding.

It says that since the package database depends on the compiler and version, you should be careful if you have two installations of the same compiler and the same version.

Lets say that a user mounts his home directory on his linux machine and on his solaris machine. He also uses ghc-6.2 on both machines. His user packages are installed in ~/ghc-6.2-packages (or something) and are compiled for Linux. Now he had better be careful using the solaris version of the compiler, because his packages are compiled for Linux, and they're in a spot where the solaris compiler will find them!

Your 1st paragraph above is much clearer. Let's see if I can make it fit to replace the text I commented on... [[ The package database takes account of the compiler and version, but not the host system. So, if there are multiple installations of the same compiler/version on different hosts, they may not share a library package installation. ]] If that catches the essence of what you are saying, details can be elaborated as needed by subsequent sentences. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact