May 2005 - Libraries - Haskell.org

RE: SearchPath (was RE: hackage, cabal-get, and security)
by Simon Marlow 18 May '05

18 May '05

On 18 May 2005 17:59, S. Alexander Jacobson wrote: > On Wed, 18 May 2005, Simon Marlow wrote: >> On 17 May 2005 17:14, S. Alexander Jacobson wrote: >>> 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. >> >> But how do you know what module maps were being used by the author of >> the module you download? Don't you have to download their module map >> file too? > > The reality is that, no matter what, you always have to assume that > the user and author of a particular module/package need to live in > basically the same universe of modules and packages. So in fact I *cannot* locally modify my module map to use a different version of an imported module. The module map is fixed and global, although I can extend it locally. So basically, there's no versioning, because everyone has to use the same version of everything. Right? Well, except that I can enter into a pact with another module author to use a certain version of a third party's module, and we both have to remember that we have the pact because the information doesn't travel with the module sources (unlike Cabal, where dependencies are explicit, I might add). > With Cabal, if you download two packages, how do you know that they > won't require conflicting versions of another module/package? As discussed before, the fact that you can't use two versions of a package simultaneously is a missing feature in the implementation, nothing more. Cheers, Simon

2 1

wash, ghc 6.4
by Frederik Eaton 18 May '05

18 May '05

Hi Peter, I've attached a patch to make Wash compile under ghc-6.4. I'm guessing you'll probably want to release a new version that *only* compiles under 6.4, rather than try to differentiate compiler versions, so I didn't add any logic for that. Anyway, please take a look. Frederik -- http://ofb.net/~frederik/

1 1

RE: hackage, cabal-get, and security
by Simon Marlow 18 May '05

18 May '05

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(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries

3 7

hackage, cabal-get, and security
by Dominic Steinitz 18 May '05

18 May '05

> 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 Isaac, Thanks for doing this. It clarifies what we are protecting against and in my opinion is a pretty good solution. 1. How do we handle key management? For example, if I lose my key or someone hacks into my machine and steals my key. How do we revoke the key? If the package only accepts updates from a keyholder and the key is revoked, how do we issue a new key and allow the package to accept updates from the new keyholder? 2. How do I get a trusted key given I am not likely to meet anybody "trusted" in the near future? Registration is often a weak point in security schemes. 3. What constitutes a "trusted" key? Is it, if it signed by two people on the library mailing list? Dominic.

4 3

hackage, cabal-get, and security
by Dominic Steinitz 17 May '05

17 May '05

> Dominic Steinitz writes: > > > 1. How do we handle key management? For example, if I > > lose my key or someone hacks into my machine and steals > > my key. How do we revoke the key? > > If GnuPG is used -- and I am strongly in favor of this --, > then encourage contributors to generate the revocation > certificate at the same time they generate the key itself. > Then instruct them to put that certificate on a CD, DVD, or > whatever, so that they can distribute it when the secret key > is lost or compromised. Most people are unable revoke their > keys because they have quite simply forgotten their pass > phrase. If you have a revocation certificate already, that > isn't a problem any longer. > > Since people will without a doubt lose the revocation > certificates too, encourage them to generate keys that > expire after a sensible period of time. Both GnuPG and PGP > offer a pretty straightforward sub-keying mechanism which > allows you to switch keys, say once a year, without losing > the signatures that authenticate your key to others. > Sounds reasonable. So I should generate a key with a revocation certificate on a secure medium but then only sign my package with a subkey with an expiry date. Is someone going to write this down so that we all know what the rules are when we use Hackage? There's going to have be instructions both for the packager and for the user of the package on downloading and using pgp. Do we need to agree on algorithms and key lengths etc? I'm still not clear what happens with Hackage when I revoke my subkey. Can I use a new subkey and Hackage accepts this? And assuming the worst, I have to revoke my master (can I call it that in pgp?) key, what does Hackage do? Someone has got to tell Hackage that there is now an association between the new key and me and therefore the package can be updated by things signed with the new key (i.e. by me). > > > 2. How do I get a trusted key given I am not likely to > > meet anybody "trusted" in the near future? > > Unfortunately, that is impossible. Your best bet is to have > everybody sign everybody else's key at every possible > opportunity, and that still won't mean that the key Joe Doe > downloaded from the Internet will be for real. But less likely :-) > > Your best bet to ensure that the keys are authentic is to > publish their fingerprints at every chance you get so that > people can verify the key they downloaded through other > means than a web site. Publishing fingerprints in the > printed version of the Haskell standard would be a good > start, for example. Good but I don't think this helps me get bootstrapped. I'll have to hope I meet up with someone trusted at some point. > > > > 3. What constitutes a "trusted" key? > > There are no trusted keys. The decision of whether to trust > a key or not _must_ be made by the person who downloads the > package -- the user. Nobody else can make that decision for > him. I feared this but it's probably acceptable in this environment. Dominic.

1 0

CTime problem
by Frederik Eaton 17 May '05

17 May '05

It looks like CTime (Foreign.C.Types) used to be an Integral but isn't anymore, why? Isn't it just an integer? Frederik -- http://ofb.net/~frederik/

3 2

RE: CTime problem
by Simon Marlow 17 May '05

17 May '05

On 17 May 2005 04:57, Frederik Eaton wrote: > It looks like CTime (Foreign.C.Types) used to be an Integral but isn't > anymore, why? Isn't it just an integer? time_t isn't necessarily an integral type (see the Single Unix spec). Cheers, Simon

1 0

RE: [Haskell] Haddock Problem
by Simon Marlow 16 May '05

16 May '05

On 14 May 2005 12:40, Duncan Coutts wrote: > On Sat, 2005-05-14 at 13:05 +0100, Dominic Steinitz wrote: >> Can someone point out what I am doing wrong? >> >> Thanks, Dominic. >> >> [dom@tility Codec]$ haddock Codec/Utils.hs >> --read-interface=http://www.haskell.org/ghc/docs/latest/html/base,/usr/s hare/doc/ghc-6.4/libraries/base/base.haddock >> >> Warning: Codec.Utils: the following names could not be resolved: >> Integral Word8 Int > > I don't believe that Haddock will download from a URL. > > Try downlading the base.haddock file first: > $ haddock Codec/Utils.hs --read-interface=base.haddock > > In this case it would be better if Haddock gave you an error about > there being no such (local) file as "http://www.haskell.org/g...", > rather than ignoring it. I'd call this a user interface bug. Dominic was using it correctly - the syntax for --read-interface is --read-interface=U,F where U is a url, and F is the path to the .haddock file. If you name a non-existent file, Haddock does indeed complain. Dominic: are you using Haddock 0.7? The interfaces shipped with GHC were generated by 0.7, which has a new interface format. Unfortunately I haven't got around to actually releasing 0.7 yet, but the sources are in CVS. Cheers, Simon

1 0

Haddock Problem
by Dominic Steinitz 14 May '05

14 May '05

Can someone point out what I am doing wrong? Thanks, Dominic. [dom@tility Codec]$ haddock Codec/Utils.hs --read-interface=http://www.haskell.org/ghc/docs/latest/html/base,/usr/share/doc/ghc-6.4/libraries/base/base.haddock Warning: Codec.Utils: the following names could not be resolved: Integral Word8 Int

2 1

Extending Cabal
by Krasimir Angelov 13 May '05

13 May '05

Hello Guys, I have started to extend Cabal with new feature. What I need is to have multiple Haskell source directories for one package. This feature is not substantial if you are packaging library, since it is supposed to have hierarchical namespace, but it is useful if you have executable. It is not mandatory to have hierarchical namespace for executables but if you are using flat namespace then with Cabal you will be restricted to keep all your source files in single directory. The extension that I have in mind will allow to break this restriction. GHC source tree is a good example of such type of project. It uses flat namespace but its source files are separated in multiple directories. The only visible change that is required is to replace hs-source-dir field to hs-source-dirs where the latter will accept a list of directories. The parser can still accept hs-source-dir for backward compatibility. I would like to hear any suggestions or objections against this extensions. I don't want to waste my time if this extension will not be accepted. Cheers, Krasimir

7 8