__group__ ticket summary type severity created _changetime _description _reporter Cabal library 946 Packages are downloaded insecurely defect major 2012-04-26T03:16:56-0700 2012-04-26T03:16:56-0700 "It appears that when running cabal install package, the package is downloaded without any transport security. Anyone who can perform a man in the middle attack could tamper with the package that is being downloaded, resulting in a complete compromise of the cabal user. This makes it impossible to use cabal. The servers should utilize TLS, it is possible to get a free certificate from startcom if price is a concern. Additionally when packages are verified as non-malicious, they should be signed with a ""cabal"" signing key, and then the package signatures should be verified by cabal." cooldude Cabal library 458 inconsistent use of CPPFLAGS, LDFLAGS etc with build-type Configure defect normal 2009-01-16T07:56:12-0800 2012-01-05T08:28:56-0800 "We have a mismatch between the cabal Setup scripts which ignore `LDFLAGS` etc and provide `--extra-lib-dirs` instead, and some `./configure` scripts which grab the `CCFLAGS` etc and bung them into a `.buildinfo` file. This is bad because it means --extra-lib-dirs does not work for those packages and it also means that those packages consult the CCFLAGS etc and others do not. It's quite an inconsistent user interface. We should try to make it more consistent. One approach would be for cabal to consider the CCFLAGS etc, to combine them with the flags passed on the command line and those specified in the .cabal file. (We have code to analyse CC/LD/CPP flags and to split them up into the standard BuildInfo fields.) Then for configure scripts we could pass the whole lot. The danger of course is that the configure scripts duplicate it all and put it into a .buildinfo file. Another tempting option is to call configure with a clean environment so that it cannot pick up these vars. Unfortunately that might break some existing packages. We should be careful with the use of these env vars though, because while it's fine to change the user interface to cabal-install, the interface to the Setup.hs is a machine interface and the more we require of it, the more has to be implemented by every different build system. A case in point is the curl package. It has a .buildinfo file like: {{{ cc-options: @CPPFLAGS@ ld-options: @LDFLAGS@ }}} The `./configure` script checks: {{{ AC_TRY_CPP([#include ],,[no_curl=yes]) }}} Which uses the `CPPFLAGS`. So it's adding an extra package-specific user interface by consulting these environment variables. At the same time the configure script ignores the `--extra-lib-dirs=` and `--extra-include-dirs=` Setup.hs command line flags. This means that users doing what is advertised will find the package does not work. Indeed changing to `build-type: Simple` and deleting the configure script makes it work perfectly. So this mismatch is clearly harmful. See also #262 which should make these checks redundant." duncan Cabal library 564 Cabal doesn't use LD options when testing linking defect normal 2009-06-24T09:00:47-0700 2012-01-05T08:32:55-0800 " When checking to see if the C libraries are available, Cabal isn't using the LD options that it has been given. This example is using GHC's `ghc-cabal` program, but that's just a thin wrapper around the Cabal library. It looks like it's in `checkForeignDeps` in `Distribution.Simple.Configure` that it goes wrong. Note that `--ld-options=""-L/usr/local/lib ""` is passed, but not used in the `gcc` commands that do the linking. {{{ $ ""inplace/bin/ghc-cabal"" configure --with-ghc=""/home/kili/src/ghc/ghc-head/inplace/bin/dummy-ghc"" --with-ghc-pkg=""/home/kili/src/ghc/ghc-head/inplace/bin/ghc-pkg"" --with-gcc=""gcc"" --configure-option=--with-cc=""gcc"" --with-hscolour=""/usr/local/bin/HsColour"" --configure-option=CFLAGS=""-O -I/usr/local/include "" --configure-option=LDFLAGS=""-L/usr/local/lib "" --gcc-options=""-O -I/usr/local/include "" --ld-options=""-L/usr/local/lib "" -v3 -- dist-install libraries/integer-gmp [boring stuff skipped] (""sh"",[""configure"",""--with-compiler=ghc"",""--with-cc=gcc"",""CFLAGS=-O -I/usr/local/include "",""LDFLAGS=-L/usr/local/lib ""]) checking build system type... x86_64-unknown-openbsd4.5 checking host system type... x86_64-unknown-openbsd4.5 checking target system type... x86_64-unknown-openbsd4.5 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for __gmpz_fdiv_qr in -lgmp... yes configure: creating ./config.status config.status: creating integer-gmp.buildinfo config.status: creating gmp/config.mk Reading parameters from ./integer-gmp.buildinfo (""/usr/bin/gcc"",[""-O"",""-I/usr/local/include"",""/tmp/2499.c"",""-o"",""/tmp/2499"",""-O"",""-I/usr/local/include"",""-D__GLASGOW_HASKELL__=611"",""-I."",""-I/home/kili/src/ghc/ghc-head/includes"",""-I/home/kili/src/ghc/ghc-head/libffi/build/include"",""-lgmp""]) /usr/bin/gcc returned ExitFailure 1 with error message: /usr/bin/ld: cannot find -lgmp collect2: ld returned 1 exit status (""/usr/bin/gcc"",[""-O"",""-I/usr/local/include"",""/tmp/2499.c"",""-o"",""/tmp/2499"",""-lgmp""]) /usr/bin/gcc returned ExitFailure 1 with error message: /usr/bin/ld: cannot find -lgmp collect2: ld returned 1 exit status (""/usr/bin/gcc"",[""-O"",""-I/usr/local/include"",""/tmp/2499.c"",""-o"",""/tmp/2499"",""-lgmp""]) /usr/bin/gcc returned ExitFailure 1 with error message: /usr/bin/ld: cannot find -lgmp collect2: ld returned 1 exit status (""/usr/bin/gcc"",[""-O"",""-I/usr/local/include"",""/tmp/2499.c"",""-o"",""/tmp/2499"",""-c"",""-O"",""-I/usr/local/include"",""-D__GLASGOW_HASKELL__=611"",""-I."",""-I/home/kili/src/ghc/ghc-head/includes"",""-I/home/kili/src/ghc/ghc-head/libffi/build/include""]) ghc-cabal: Missing dependency on a foreign library: * Missing C library: gmp This problem can usually be solved by installing the system package that provides this library (you may need the ""-dev"" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. }}} " igloo Cabal library 791 Large libraries not installable on OS X defect normal 2011-01-18T02:08:58-0800 2012-01-05T08:27:21-0800 "For example: {{{ cabal unpack highlighting-kate-0.2.8.1 cd highlighting-kate-0.2.8.1 ghc --make Setup.hs ./Setup configure ./Setup build }}} This fails: {{{ ld: scattered reloc r_address too large for inferred architecture i386 }}} The underlying reason is that Cabal is trying to create an object file for use with GHCi, but that is not possible (see http://hackage.haskell.org/trac/ghc/ticket/3260). Cabal's GHC.hs should not use combineObjectFiles on with GHC >= 7 and OS X." batterseapower Cabal library 943 Synopsis field causes haddock build failure defect normal 2012-04-20T17:48:36-0700 2012-04-21T00:12:13-0700 "For some reason the presence of the 'synopsis' field causes haddock documentation to fail to build. Steps: $ cabal unpack dclabel $ cabal configure $ cabal haddock {{{ Running Haddock for dclabel-0.0.6... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: rts-1.0, cereal-0.3.5.1 Preprocessing library dclabel-0.0.6... : Could not find module `The' Use -v to see a list of the files searched for. }}} I assume something is mis-configured on my system but have no idea what and how to fix it Versions: {{{ $ cabal --version cabal-install version 0.14.0 using version 1.14.0 of the Cabal library $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.4.1 $ haddock --version Haddock version 2.10.0, (c) Simon Marlow 2006 Ported to use the GHC API by David Waern 2006-2008 }}} This is on Ubuntu Linux 11.10." davidt Hackage 2 server 911 Package uploading is completely unsecured defect major 2012-02-14T08:46:42-0800 2012-02-14T20:10:57-0800 "Right now, anyone can register an account (without passing any kind of CAPTCHA or anything, so bots will overrun the place quickly on a live site) and upload new packages to their heart's content. This is a major risk for several reasons (package installation can do evil stuff with custom build types, easy to use up tons of disk space, etc.) Of course, nothing can truly solve the security issue, but I suggest the following: 1. A simple but Hackage-specific CAPTCHA on the registration page (e.g. ""What language are HackageDB packages written for?"") — it's unlikely that spambots will target it specifically, and a simple but unique CAPTCHA will be stronger than a generic solution like reCAPTCHA which has a lot of effort going into breaking it (e.g. someone being paid to fill out CAPTCHAs isn't going to have any idea that the answer is ""Haskell"") 2. Limit package uploading to members of a group which only admins can add to This should be a simple change to the code. The workflow for a package uploader would be: 1. Register an account 2. Email the maintainer asking for a package upload This is basically the same as the Hackage1 registration process, but a bit easier for the maintainer. {{{ bgamari, cmccann, elliott: so the auth system in the new design copes ok with package uploaders, what it does not cover well is casual users who might want to post reviews, vote etc, but not upload packages since you probably want self-registration for those users but for uploaders it's sensible to have a human in the loop Certainly like we do in the current system so there's an admin user group who can edit other groups ie grant permissions [...] elliott, cmccann: right, plus in the new system since there's a per-package uploader group then unknown users cannot subvert well known names (ie packages) so in the new system malicious people can still upload *new* malicious packages but cannot subvert e.g. base }}} An ideal solution would be something like: 1. Reasonable per-user quotas (liftable on request) for disk usage, to stop people spamming the system 2. Users by default can upload packages, but they're in a quarantine: not visible on the site or installable 3. Whenever a user uploads their first package, the maintainer gets an email and can check it out and approve the user (making their packages public) if it looks OK That would be nicer, but probably require a lot more coding than the simpler solution. " bgamari Hackage 2 server 916 Verify that HTTP interface is fully/properly implemented task normal 2012-02-14T09:10:12-0800 2012-02-14T09:10:12-0800 Ensure that server implementation is compliant with interface specified at HackageDB/2.0/URIs bgamari Hackage 2 server 918 Working documentation builder task normal 2012-02-19T15:33:40-0800 2012-02-19T15:33:40-0800 "Currently hackage-build is in the repository and can build documentation, but it depends upon a cabal-install patch adding haddock options to the ""install"" sub-command[1], {{{ 18:21 < dcoutts> he sent a patch for cabal-install 18:21 < dcoutts> and this relies on it 18:21 < bgamari> It was merged? 18:21 < dcoutts> the patch should be in the cabal-devel archives, or in the trac 18:22 < dcoutts> bgamari: I've not yet, I was going to see if it could be done nicer / more generically 18:22 < dcoutts> but perhaps I shouldn't bother 18:22 < dcoutts> the difficulty is it affects the ~/.cabal/config format too 18:22 < dcoutts> so it's harder to change later 18:22 < bgamari> ahh 18:23 < bgamari> Yes, I can understand your hesitance in that case }}} [1] http://www.haskell.org/pipermail/cabal-devel/2011-September/007782.html " bgamari cabal-install tool 945 Fails to find install plan for containers package tests defect major 2012-04-24T11:50:08-0700 2012-04-25T03:40:16-0700 "The containers package has a test-suite section which seems to create a cycle when building the package. Could it be that Cabal treats the package as one unit instead of treating the library and test-suite sections separately, which should remove the cycle. {{{ $ cabal install --enable-tests -v3 searching for ghc in path. found ghc at /usr/local/bin/ghc (""/usr/local/bin/ghc"",[""--numeric-version""]) /usr/local/bin/ghc is version 7.4.1 looking for tool ""ghc-pkg"" near compiler in /usr/local/bin found ghc-pkg in /usr/local/bin/ghc-pkg (""/usr/local/bin/ghc-pkg"",[""--version""]) /usr/local/bin/ghc-pkg is version 7.4.1 (""/usr/local/bin/ghc"",[""--supported-languages""]) (""/usr/local/bin/ghc"",[""--info""]) Reading installed packages... (""/usr/local/bin/ghc-pkg"",[""dump"",""--global"",""-v0""]) (""/usr/local/bin/ghc-pkg"",[""dump"",""--user"",""-v0""]) (""/usr/local/bin/ghc"",[""--print-libdir""]) Reading available packages... Choosing modular solver. Resolving dependencies... [__0] trying: containers-0.5.0.0 (user goal) [__1] next goal: base (dependency of containers-0.5.0.0) [__1] rejecting: base-3.0.3.2, 3.0.3.1 (global constraint requires installed instance) [__1] trying: base-4.5.0.0/installed-f76... [__2] trying: rts-1.0/installedbuil... (dependency of base-4.5.0.0/installed-f76...) [__3] trying: integer-gmp-0.4.0.0/installed-ec8... (dependency of base-4.5.0.0/installed-f76...) [__4] rejecting: containers-0.5.0.0:!test (global constraint requires opposite flag selection) [__4] trying: containers-0.5.0.0:*test [__5] trying: test-framework-quickcheck2-0.2.12.1 (dependency of containers-0.5.0.0:*test) [__6] trying: test-framework-quickcheck2-0.2.12.1:+base4 [__7] trying: test-framework-quickcheck2-0.2.12.1:-base3 [__8] trying: random-1.0.1.1/installed-3be... (dependency of test-framework-quickcheck2-0.2.12.1:+base4) [__9] trying: time-1.4/installed-3e1... (dependency of random-1.0.1.1/installed-3be...) [_10] trying: old-locale-1.0.0.4/installed-29b... (dependency of time-1.4/installed-3e1...) [_11] trying: extensible-exceptions-0.1.1.4/installed-d27... (dependency of test-framework-quickcheck2-0.2.12.1) [_12] trying: test-framework-hunit-0.2.7 (dependency of containers-0.5.0.0:*test) [_13] trying: test-framework-hunit-0.2.7:+base4 [_14] trying: test-framework-hunit-0.2.7:-base3 [_15] trying: test-framework-0.6 (dependency of containers-0.5.0.0:*test) [_16] trying: test-framework-0.6:-tests [_17] trying: test-framework-0.6:+splitbase [_18] trying: hostname-1.0 (dependency of test-framework-0.6) [_19] trying: xml-1.3.12 (dependency of test-framework-0.6) [_20] trying: text-0.11.2.0/installed-a62... (dependency of xml-1.3.12) [_21] trying: bytestring-0.9.2.1/installed-4ad... (dependency of xml-1.3.12) [_22] trying: regex-posix-0.95.1 (dependency of test-framework-0.6) [_23] trying: regex-posix-0.95.1:+splitbase [_24] trying: regex-posix-0.95.1:+newbase [_25] trying: regex-base-0.93.2 (dependency of regex-posix-0.95.1:+newbase) [_26] trying: regex-base-0.93.2:+splitbase [_27] trying: regex-base-0.93.2:+newbase [_28] trying: mtl-2.1/installed-0a8... (dependency of regex-base-0.93.2:+newbase) [_29] trying: transformers-0.3.0.0/installed-f23... (dependency of mtl-2.1/installed-0a8...) [_30] trying: ansi-wl-pprint-0.6.4 (dependency of test-framework-0.6) [_31] trying: ansi-wl-pprint-0.6.4:+newbase [_32] trying: ansi-wl-pprint-0.6.4:-example [_33] trying: ansi-terminal-0.5.5 (dependency of test-framework-0.6) [_34] trying: ansi-terminal-0.5.5:+splitbase [_35] trying: ansi-terminal-0.5.5:-example [_36] trying: unix-2.5.1.0/installed-346... (dependency of ansi-terminal-0.5.5) [_37] trying: QuickCheck-2.4.2 (dependency of containers-0.5.0.0:*test) [_38] trying: QuickCheck-2.4.2:+templatehaskell [_39] trying: QuickCheck-2.4.2:+base4 [_40] trying: QuickCheck-2.4.2:+base3 [_41] next goal: template-haskell (dependency of QuickCheck-2.4.2:+templatehaskell) [_41] rejecting: template-haskell-2.7.0.0/installed-164... (conflict: containers==0.5.0.0, template-haskell => containers==0.4.2.1/installed-7c5...) [_41] trying: template-haskell-2.7.0.0 [_42] trying: pretty-1.1.1.0/installed-7e1... (dependency of template-haskell-2.7.0.0) [_43] trying: HUnit-1.2.4.2 (dependency of containers-0.5.0.0:*test) [_44] trying: HUnit-1.2.4.2:+base4 [_45] trying: ghc-prim-0.2.0.0/installed-bd2... (dependency of containers-0.5.0.0) [_46] trying: deepseq-1.3.0.0/installed-6c1... (dependency of containers-0.5.0.0) [_47] next goal: array (dependency of containers-0.5.0.0) [_47] trying: array-0.4.0.0/installed-0b3... [_48] done cabal: internal error: could not construct a valid install plan. The proposed (invalid) plan contained the following problems: The following packages are involved in a dependency cycle test-framework-hunit-0.2.7, test-framework-0.6, regex-posix-0.95.1, regex-base-0.93.2, containers-0.5.0.0, test-framework-quickcheck2-0.2.12.1, QuickCheck-2.4.2, template-haskell-2.7.0.0 }}} " tibbe cabal-install tool 447 build multiple packages in parallel enhancement normal 2009-01-10T08:01:35-0800 2012-04-24T15:43:38-0700 "The latest version of the gentoo portage tool is rather slick. It can do parallel builds and it displays a nice summary on the command line, eg: {{{ # emerge -uD system -j --load-average=4.5 Calculating dependencies... done! >>> Verifying ebuild manifests >>> Starting parallel fetch >>> Emerging (1 of 14) dev-libs/expat-2.0.1-r1 >>> Emerging (2 of 14) sys-devel/autoconf-wrapper-6 >>> Emerging (3 of 14) sys-kernel/linux-headers-2.6.27-r2 >>> Installing sys-devel/autoconf-wrapper-6 >>> Jobs: 0 of 14 complete, 1 running Load avg: 2.99, 1.59, 0.67 }}} Note how they solve the problem of how to display what is going on when there are multiple builds happening. The answer is not to display it at all! This would have to go hand-in-hand with logging all builds so that we can still diagnose failures. Note the final line, that gets updated to display the current number of jobs running, the number completed etc. It also shows the load average. The job scheduler has two parameters, one is a maximum number of jobs (or unlimited) and the other is a load average. It will only launch new jobs if the load average is less than the given maximum. That allows it to interact reasonably well with builds that use `make -j` internally. In the example above I set the load average to be just slightly more than the number of CPUs I've got. It looks to me like it serialises some bits, like installing, since saturating the disk with multiple parallel installs is generally of no benefit, indeed it can be slower. Also downloads seem to be serialised, again because there is probably little benefit to making multiple connections to the same server. Anyway, the point is, cabal-install ought to be able to do all this. Some bits we can do now. We already have a graph representation of the install plan and we recalculate when a package fails to install. We will need an improved download api, probably involving sending requests off to a dedicated download thread (which would serialise them)." duncan cabal-install tool 453 """cabal fetch"" should take output arguments" enhancement normal 2009-01-12T13:15:22-0800 2012-03-06T10:46:04-0800 "It would be nice if ""cabal fetch"" could output the fetched tarball to a location specified on the command line, i.e.: cabal fetch bytestring -o foo.tgz This probably depends on #423." gregorycollins cabal-install tool 474 cabal-install needlessly reinstalls an existing package defect normal 2009-01-23T11:18:03-0800 2012-04-09T04:27:56-0700 "With ghc-6.10.1, Cabal-1.6.0.1 and cabal-install-0.6 (or HEAD): {{{ $ cabal install cabal-install --dry-run -v [..] Reading available packages... Resolving dependencies... [..] selecting Cabal-1.6.0.1 (installed or hackage) [..] selecting process-1.0.1.1 (installed or hackage) and discarding filepath-1.0, process-1.0.0.0 and 1.0.1.0 [..] In order, the following would be installed: Cabal-1.6.0.1 (reinstall) changes: process-1.0.1.0 -> 1.0.1.1 cabal-install-0.6.0 (new package) }}} The `ghc` package depends on `Cabal-1.6.0.1` and `process-1.0.1.0`, so rebuilding `Cabal` to depend on `process-1.0.1.1` causes `ghc` to have inconsistent dependencies. In particular: {{{ $ cabal install cabal-install [succeeds, but reinstalls Cabal-1.6.0.1] $ cabal install ghci-haskeline Resolving dependencies... cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.0 however process-1.0.1.0 was excluded because ghc-6.10.1 requires process ==1.0.1.1 }}} It seems like the right thing to do would be to use `process-1.0.1.0` when building `cabal-install`." judah hackageDB website 184 cabal-install should report build results to hackage server enhancement normal 2007-11-22T07:44:21-0800 2012-01-05T08:32:04-0800 "One way to get a lot more testing data on hackage packages is if cabal-install could report back to the hackage server about build successes and failures. This information should be kept by hackage and used to distill information about which platforms configurations a package builds successfully and which it does not. This should provide useful information to developers to enable them to discover problems more quickly and useful information to users. An important consideration is privacy. Users should always have the option to not report anything and any information they report that is kept should not contain identifying information. This is particularly important when it comes to build logs which may contain paths etc. It should be clear to users what information they are reporting to the can decide for themselves if it meets their privacy needs. Since cabal can be used to build private code it is vital that it reports only on packages that were obtained from the hackage server. It is also vital that the information is sent to the correct hackage server. It's possible to set up private hackage server instances and it'd may be useful to collect build information ""in house"" too. So what information would be helpful? * build success or failure (qualified by what failed, build, docs, tests) * package name and version * hash of .cabal file just to make sure it's the same one we're all talking about and to detect local modifications. * precise versions of dependent packages that the package was built with. * os and arch strings * compiler flavour and version * versions of important build tools * In the case of a build failure, some part of the build log would be helpful. This is the most problematic part from a privacy point of view. This is quite a bit of raw data and we can expect to have many hundreds of such reports for popular packages. How can we distill useful information from this kind of data? I expect we would want to do some statistical analysis where we look for common traits in the results. The data forms a multi-dimensional space of boolean values. By looking down the rows/columns of this space we should be able to identify trends. For example if it always fails with ghc-6.8.x, or always fails on Windows. Excluding those obvious failures we then may be able to say that it does work on mac osx (except ghc-6.8.1) or that it does work with regex-posix-0.92 (except on windows), etc. This should allow us to give a summary saying yes/no to various properties of the environment. For failure cases developers should be able to get access to the more detailed data including build logs." duncan