- Libraries - Haskell.org

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

RE: Extending Cabal
by Simon Marlow 13 May '05

13 May '05

On 12 May 2005 15:49, Isaac Jones wrote: > I don't mind this change much, it might even be good. One thing I > like about the old way, though, is that it encourages people to use > the hierarchical namespace, which is a nice way to organize things > whether you are building a library or an executable. > > But Cabal's purpose is to help folks build tools, not to enforce style > ;) I'd accept it if you feel that you need it. Anyone else have an > opinion? It's a trivial change to make, it doesn't break anything, and it lets us support more existing projects without substantial reorganisation of their file structure. Sounds like a no-brainer to me. Cheers, Simon

4 5

WARNING: package dependencies
by Simon Marlow 12 May '05

12 May '05

Yes, the module overlap restriction has started to bite us. It now turns out that you can't build GHC from CVS if you have wxHaskell installed. Why? Because wxHaskell depends on some older non-hierarchical packages (util in particular, which itself depends on lang). These package populate the top-level module namespace, and steal a bunch of module names that you might want to use in your program. In fact, GHC itself contains a module with the same name as one in the lang package: Generics. The error is real - if we *had* imported something from wxHaskell, then the program would contain two modules called Generics, and since the linker's name space is global, mayhem would ensue. Because we're doing separate compilation, GHC can't tell that we haven't actually imported anything from wxHaskell, so it has to be conservative and assume that we will. New GHCs are a bit stricter about complaining about duplicate modules, with the result that GHC fails to build. We know the reasons for this - they were all discussed at length in a recent thread. What can we do? 1. Package builders should be careful about dependencies. Don't depend on any non-hierarchical packages from an exposed package. Daan - can you fix wxHaskell? 2. The GHC build could start using -fignore-all-packages to insulate itself from the environment (or, simpler but more hacky: -ignore-package lang). This isn't a *solution* as such, because the problem affects everyone, not just us. 3. We could put some safeguards in place to avoid this happening in the future, e.g. warnings from Cabal and/or ghc-pkg. 4. Cabal needs to start using -fignore-all-packages. Isaac? Thoughts? Cheers, Simon

8 8

producing nice tarballs
by Duncan Coutts 11 May '05

11 May '05

Hi all, With my Gentoo Haskell packaging hat on I'd like to grumble slightly :-) There are a number of packages floating around that have various things 'odd' about them. It makes the lives of packaging people much easier if tarballs follow a standard convention. I suggest that the convention should be the same as what autoconf/automake does in the C world (because this is what packaging people are used to and what packaging tools work best with) So if you've got a cabal package with fields: name: FooBar version: 1.2.3 Then the tarball should be "FooBar-1.2.3.tar.gz" (or .zip or .tar.bz2). And that archive should unpack to "FooBar-1.2.3/". There are packages around where the cabal package name is all lower case but the tarball name is all upper case or mixed. Similarly there are packages which unpack to just the package name rather name & version. There are also packages with non-canonical version numbers, eg 5.01 gets normalised to 5.1. Cabal identifies these two version numbers but it's not clear that package authors are aware of this. I know these seem like trivial issues but consistency makes things much easier for (semi-)automatic tools. With the rise of cabal, I think this is a great opportunity to have tools that make it easy for package authors to "do the right thing". For example, the C coders who use automake get package tarball preperation for free. Indeed automake does some quite sophisiticated checks to make sure that a source tarball is complete and consitent (it unpacks the tarball, builds the package and uses it to produce another tarbal which it compares to the original). We (Gentoo packaging folk) are quite eager for cabal's "./setup sdist" feature to be fixed/improved (apparently there are some issues with it currently) so that package authors can be encouraged to use it and produce consistent tarballs that will make packaging that bit smoother. If it's not so high on everyone else's priority list we'll send patches! :-) Duncan

2 2