SearchPath (was RE: hackage, cabal-get, and security)

[S. Alexander Jacobson]

>  - versioning

With SearchPath, you supply the URLs of the module maps you want to 
use.  SearchPath then uses these map to locate, download and "install" 
needed libraries without further user intervention.

A module map is just a file mapping module names to the base URLs of 
directories in which they reside.  If you want to supply the URL of a 
particular version of a module map rather than "latest" you are free 
to do that.

Since module maps just point to the URLs of basedirs, you can have 
them point either to darcs/svn repositories of projects that serve out 
the latest version or to static directories holding a particular 
version.  SearchPath doesn't yet support explicit WebDAV or darcs 
version identifiers, but I hope to get it added soon.  Then the step 
of maintaining static checked out versions will become unnecessary.

>  - pre-compiled libraries
>  - FFI (external C libraries & bundled C code)

Right now SearchPath only supports module directory base URLs in map 
files.  I'd love for it to support automatic download and build for 
Cabal file and package URLs as well. I just don't know how to do it. 
Perhaps you guys can help on this?

-Alex-

______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com




On Tue, 17 May 2005, Simon Marlow wrote:

> On 17 May 2005 15:19, S. Alexander Jacobson wrote:
>
>> My solution in SearchPath (released yesterday) is to rely on a
>> combination of HTTPS and links.
>
> I don't want to start another huge debate, but I think your solution at
> least lacks support for some fundamental (IMO) features:
>
>  - versioning
>  - pre-compiled libraries
>  - FFI (external C libraries & bundled C code)
>
> What's your story for these?  e.g. what you do intend to happen when
> someone imports Graphics.UI.WX?
>
> Cheers,
> 	Simon
>
>> The user selects module directories that they trust.  They access that
>> directory via HTTPS.  The module directory maps module names to
>> package/module URLs.  The user can decide that they only want to
>> retrieve via HTTPS.
>>
>> This is effectively a web of trust model, but the only key management
>> needed is getting an SSL cert from a CA like Verisign or Thawte.
>>
>> The open question here is whether it is easier to convince people to
>> serve modules via HTTPS web servers or whether they prefer gnupg key
>> management. A reason to believe that the former will be preferable to
>> the later is that people can easily delegate SSL hosting to others.
>> Delegating gnupg key management is non-trivial.
>>
>> -Alex-
>>
>> ______________________________________________________________
>> S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
>>
>>
>> On Mon, 16 May 2005, Isaac Jones wrote:
>>
>>> At the request of Dominic Steinitz, I'll outline the threats that I
>>> think this proposal protects against.
>>>
>>> The signing of packages prevents a number of attacks between the
>>> packager and the server:
>>>
>>> 1) Accidentally or purposely hijacking a package that is signed by
>>> (belongs to) someone else.
>>>
>>> 2) Uploading a malicious package to replace someone else's good
>>> package.
>>>
>>> 3) Man-in-the-middle attcks between the packager and Hackage.
>>>
>>> Checking signatures on the client side prevents:
>>>
>>> 1) Man-in-the-middle attcks between hackage and the client
>>>
>>> 2) Automatic installation of anonymous malicious packages
>>>
>>>
>>> Building a trusted network of keys prevents:
>>>
>>> 1) Someone creating a key pretending to be someone else
>>>
>>> 2) Unchecked anonymous uploads (running arbitrary code from an
>>> unknown   source)
>>>
>>> One question that comes up is: how does the so-called "web of trust"
>>> help out with this situation?  The signing of keys ties the identity
>>> of an individual (via their state-issued identification) to a
>>> particular key.  Now if someone attempts one of the above attacks,
>>> after being "trusted" we know who they are in real life.  So it's not
>>> really a "web of trust" but more like a "web of identity".  We will
>>> need to put procedures in place for handling a variety of
>>> situations, like loss of trust, etc.
>>>
>>> This proposal doesn't cover all of that, but it puts a bit of
>>> structure into place to raise the bar for an attacker sufficiently
>>> high in my opinion, and gives the end-users the tools they need to be
>>> as paranoid as they care to be.
>>>
>>> peace,
>>>
>>>  isaac
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>
> ** CRM114 Whitelisted by: ijones at syntaxpolice.org **
>