July 2014 - cabal-devel

Proposal: cabal-install: verify OpenPGP signatures
by Nikita Karetnikov 26 Sep '14

26 Sep '14

Following up on the “cabal-install: Replacing HTTP with HTTPS” thread. I think we can do better. I want to make sure that people will notice if someone compromises the packages on hackage.haskell.org. Here’s a rough plan: 1. Patch ‘hackage-server’ to allow uploading of OpenPGP signatures. 2. Patch ‘cabal-install’ to use GPG for verification. (GPG trust levels could be useful here.) ‘cabal install’ should also support ‘--skip-verification’ or some such to avoid disaster during the adoption stage. In addition, ‘cabal update’ would fetch the list of fingerprints from Hackage and cache each revision. A warning would be raised if a fignerprint cannot be found in the cache. If a maintainer wants to use a new key, it must be signed with the previously used one. If a maintainer loses their private key, for instance, this should be resolved by the admins. For example, an admin (admins?) could sign the new key. After a while, a web of trust would be formed. The fingerprints of active maintainers would be well-known. I’ve been thinking about this for quite a while and don’t see other ways to achive the same level of trust while allowing arbitrary uploads. The proposal also doesn’t require much manual intervention. What do you think? I’m willing to work on this but want to make sure that my time won’t be wasted. Will you accept such a patch?

3 11

Fw: cabal-install-latest is not pointing to latest release
by Konrad Gądek 30 Jul '14

30 Jul '14

Hi, It seems that http://www.haskell.org/cabal/release/cabal-install-latest/ is pointing to cabal-install-1.20.0.1 while there is 1.20.0.3 already — is this a "whoopsie" or is there a reason for this? -- Konrad Gądek

3 5

Killing or resurrecting version tags for good
by Edward Z. Yang 26 Jul '14

26 Jul '14

Hello all, A while back, I was nattering around the parsing code for Cabal, and I noticed that Cabal still had code for parsing version tags, but was explicitly *not* printing out version tags. I proposed that we should get rid of the parsing code as well, but when I mentioned this on #ghc Mark Lentczner (cc'ed) mentioned that they were using version tags to identify different versions during a build, e.g. what Git version things correspond to. I am not going to claim to know the right answer to this question, but in either case, it is terrible that we are PARSING tags but not PRINTING them. This leads to terrible error messages, among other things, such as in this case: $ ghc-pkg describe json-0.7-foo ghc-pkg: cannot find package json-0.7 (NB: json-0.7 is installed.) So if we're keeping tags around, at least for the immediate future, then we should print them; otherwise, we should get rid of them entirely! Edward

2 2

[PATCH] Print a more friendly message when http_proxy is down.
by Nikita Karetnikov 26 Jul '14

26 Jul '14

An attempt to fix #1962. I think the exception comes from ‘connect’ in ‘Network.Socket’. I doubt that the proposed error message is friendly enough. Ideas? Also, can ‘handleJust’ catch ‘IOException’s that are not related to http_proxy?

3 4

[PATCH] Change 'whenCacheOutOfDate' to use '>' again.
by Nikita Karetnikov 25 Jul '14

25 Jul '14

As some of you may know, I’m trying to make ‘cabal install’ verify OpenPGP signatures that come from Hackage. I modified ‘updatePackageIndexCacheFile’ to ask whether a certain OpenPGP public key should be trusted, but I later discovered that the mentioned function is called twice during ‘cabal update’*, which means that all questions are also asked twice. I believe this doesn’t affect #1443 anymore. If so, please apply the attached patch. * ‘update’ uses ‘updateRepo’ and ‘checkForSelfUpgrade’. The former runs ‘updatePackageIndexCacheFile’ via ‘updateRepoIndexCache’. The latter calls ‘updatePackageIndexCacheFile’ via a sequence of calls from ‘getSourcePackages’ to ‘getSourcePackages’’ to ‘readRepoIndex’ to ‘whenCacheOutOfDate’.

2 3

Removing GHC's dependency on Cabal
by Edward Z. Yang 24 Jul '14

24 Jul '14

Hello all, I know Duncan and SPJ have been keen on removing GHC's dependency on Cabal for some time now. Simon and I were chatting about the subject today, and we wanted to propose an alternative way of doing the remodularization. Here are diagrams of the proposals: http://web.mit.edu/~ezyang/Public/ghc-cabal-refactor.pdf As I understand it, Duncan's proposal is to take the current constellation of libraries, and just remove the dependency to Cabal from GHC and bin-package-db, duplicating data structures as necessary. ghc-pkg is now responsible for converting between Cabal's format and GHC's format. Simon suggested that this 'ghc-pkg' functionality (which specifies the database format and how to handle it) should be placed in a library of its own. So in the third graph, we have a new package ghc-db which everyone depends on. Cabal no longers shells out to ghc-pkg to modify database, instead it directly converts to ghc-db's format and then invokes library functions in the library. We were wondering if there was any reason to prefer the former situation over the latter. One answer might be that Cabal is less keen to have a dependency on a very GHC specific library (although the ghc-pkg dependency is quite a fairly tightly coupled one.) Cheers, Edward

6 8

Re: Enhancement: Default cabal to `-p` profiling enabled
by Johan Tibell 24 Jul '14

24 Jul '14

It will be less painful to enable profiling by default when someone finishes the parallel build support for profiling "ways". That would mean that we can build the vanilla and profiling version of a library at the same time, saving quite a bit of time.

1 0

Multi-instance packages status report
by Edward Z. Yang 21 Jul '14

21 Jul '14

Hello all, As you may have noticed, I've been knocking around GHC and Cabal the past few weeks. One of the tasks that has been on my list is essentially reimplementing Philipp Schuster's 2012 GSoC, with a few small but important architectural differences. Here is a status report of what is going on. In my copy of GHC and Cabal [1,2], you can now install multiple copies of a package with differing dependencies to the package database, i.e. q-1.0 compiled against p-1.0, and against p-2.0. The packages in the database are distinguished via a *package key*, which is an md5 hash of the package id (e.g. q-1.0) and the sorted list of the package IDs of the transitive closure of dependencies (e.g. p-1.0 or p-2.0). The package key is used to generate linker symbols for packages, so it's possible to link together both copies of q in the same program, as long as you rename the modules appropriately (of course, the redefined types are considered unequal). When registering a package, ghc-pkg now checks and removes duplicate package keys, as opposed to package IDs. I've also implemented many of the necessary niceties for making it pleasant to deal with duplicated package IDs: for example, GHC's output logic has been adjusted to only qualify a package ID with the package key when there are multiples of the same package ID exposed in the database. I've also adjusted GHC's build system to use package keys rather than package IDs to refer to packages when building. Like the original GSoC project, we still need to have decisions on some of the major design choices. I think the most pressing one is "simplistic dependency resolution" when you use, e.g. ghc -package foo-1.0 or ./Setup configure --with-constraint="foo==1.0". Right now, I pick dependencies in an unspecified manner, check if they are consistent, and bail out if they are not. As it turns out, both GHC and ./Setup configure will already compute the transitive closure of dependencies, so I suspect we might be able to do something clever here. Less pressing but eventually necessary is clueing in cabal-install. Comments would be especially appreciated. Cheers, Edward [1] https://phabricator.haskell.org/D80 [2] https://github.com/haskell/cabal/pull/2002

1 0

Heads up: Updating Cabal pointer to Cabal HEAD
by Edward Z. Yang 18 Jul '14

18 Jul '14

Hello folks, In the interest in as small changes as possible, I am planning on updating the version Cabal we're tracking against to Cabal HEAD (after my build finishes validating, that is!) At a later point, when someone finally merges https://github.com/haskell/cabal/pull/1991 I'll make a smaller bump. I'll also file a bug on GHC Trac milestoned for 7.10 to make sure we get a new Cabal release before next release. Edward Excerpts from Edward Z. Yang's message of 2014-07-03 14:45:02 +0100: > Hello all, > > I am working on module reexports (https://ghc.haskell.org/trac/ghc/ticket/8407) > and this functionality requires concurrent changes to GHC and Cabal. > However, GHC is currently tracking 1.20, but Cabal HEAD has marched on. > > My question is, if I am to do this development on HEAD, what is the > standard operating procedure for retargeting GHC to a recent version of > Cabal? Of course I have to go and validate the build, but are there > any other considerations? Is this recorded anywhere? > > Thanks, > Edward

1 0

Library version choosing of cabal sandbox build
by Daniel Trstenjak 16 Jul '14

16 Jul '14

Hi, if I'm having a cabal file without an upper bound for a library, the newest available version of the library is 3, there's a local/user installation of the version 2 of the library, which version of the library is a cabal sandbox build supposed to use? In my case I can see that version 2 of the library is used. If this is intended, how can I ensure that always the newest version is used independent of any local/user installations? Thanks! Greetings, Daniel

4 12