June 2014 - cabal-devel

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

27 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

InstalledPackageInfo, IPI641, IPI642
by Edward Z. Yang 30 Jun '14

30 Jun '14

Hello all, I am currently adding support for packages to reexport modules (proper) from other packages, but I've run into a nasty bit of BC in Cabal that I don't quite understand; namely, InstalledPackageInfo, IPI641 and IPI642. So, I understand in principle why we might want these data structures: GHC is compiled with a specific version of Cabal, but one might want to use a version of cabal-install with a different version of Cabal. What I don't understand is why we have both InstalledPackageInfo and IPI642. Additionally, what is the procedure for making changes to the IPI format? This seems to have only been done once before, and I am not sure how the current scheme generalizes. Thanks, Edward

1 0

Re: Any more bug fixes for the next cabal-install 1.20 release?
by Johan Tibell 26 Jun '14

26 Jun '14

This is what I have so far: - 086a62e82d9dc3bfa66b57d738ba9f94a641ffad Don't attempt to rename dist if it is already named correctly - a46df9dbfe14df0df60c8cc401221c4128ad675e Remove an unnecessary 'createDirectoryIfMissing' call. (cherry picked from commit 5c46e7853a09a484698064824b7bf72c5c761993) - 5b63fce601997009376522c5de9b11275c3681ee Treat all flags of a package as interdependent. - 302b0dce271bf194b42afa3f90c57cffff35cc72 Print full build log instead of only the last 10 lines - ffd67e5e630766906e6f4c6655c067a79f739150 Allow template-haskell to be upgradable again Note that the commit IDs are different since these are cherry-picked form master. On Tue, Jun 24, 2014 at 5:41 PM, Bardur Arantsson <spam(a)scientician.net> wrote: > On 2014-06-24 09:38, Johan Tibell wrote: > > I'm making another cabal-install release from the 1.20 branch to fix some > > more solver issues. In particular, I'm releasing this commit > > > > 3f777568 Treat all flags of a package as interdependent. > > > > Are there any other bug fixes *already in master* that are safe/useful > > enough to include in the next cabal-install 1.20 release? > > > > -- Johan > > > > > > Any chance of getting 2cbe6498650c9bf676571ba5321b8fd6b9ad512e in? > > Seems pretty useful and harmless, but then I'm probably biased ;). > > Regards, > >

2 5

Any more bug fixes for the next cabal-install 1.20 release?
by Johan Tibell 24 Jun '14

24 Jun '14

I'm making another cabal-install release from the 1.20 branch to fix some more solver issues. In particular, I'm releasing this commit 3f777568 Treat all flags of a package as interdependent. Are there any other bug fixes *already in master* that are safe/useful enough to include in the next cabal-install 1.20 release? -- Johan

1 0

ETag support broken on hackage.haskell.org
by Gintautas Miliauskas 17 Jun '14

17 Jun '14

Hi, first of all, a shout out to all ZuriHac2014 folks, thanks for the gentle introduction to the deeper trenches of Haskell infrastructure! I spent a bit of time looking into why "cabal update" always redownloads the entire package list even though the code has explicit support for etags, and it looks like etags are broken on the server side. The server does serve "Etag" headers, but does not react to If-None-Match: $ curl -I --header 'If-None-Match: "1ea6c9a3168b9c186d5bbafd065ce5ec"' hackage.haskell.org/packages/index.tar.gz HTTP/1.1 200 OK Server: nginx/1.6.0 Date: Mon, 09 Jun 2014 23:22:49 GMT Content-Type: application/x-gzip Content-Length: 7193838 Connection: keep-alive Content-MD5: 1ea6c9a3168b9c186d5bbafd065ce5ec ETag: "1ea6c9a3168b9c186d5bbafd065ce5ec" Last-modified: Mon, 09 Jun 2014 23:10:44 GMT In this case the server is supposed to return a 304 code because the ETag matches, but it returns the usual 200. Here's a well-behaved server for comparison: $ curl -I --header 'If-None-Match: f89ef04efbcb1bbd413c9170523beeb1' http://upload.wikimedia.org/ HTTP/1.1 304 Not Modified Last-Modified: Thu, 03 Oct 2013 22:29:34 GMT Etag: f89ef04efbcb1bbd413c9170523beeb1 X-Timestamp: 1380839374.33426 X-Object-Meta-Mtime: 1366745378.0 Content-Type: text/html X-Varnish: 2552484147 2541352860, 2937266545 2853346814, 523731362 Via: 1.1 varnish, 1.1 varnish, 1.1 varnish Accept-Ranges: bytes Date: Mon, 09 Jun 2014 23:29:36 GMT Age: 38954 Connection: keep-alive X-Cache: cp1064 hit (336), cp3010 hit (1791), cp3007 frontend miss (0) Access-Control-Allow-Origin: * Access-Control-Expose-Headers: Age, Content-Length, Date, X-Cache, X-Varnish Note the 304 return code. I do not know about the configuration in use on the server, but something seems to be wrong there. There are some nginx bug reports [1] about similar issues, not sure if they are relevant here. [1] https://github.com/rgrove/rawgit/issues/13 Best regards, -- Gintautas Miliauskas

3 4

Shell Monad and my zurihac2014 project
by Greg Horn 14 Jun '14

14 Jun '14

Hello all, My Zurihac2014 project was to address https://github.com/haskell/cabal/issues/975. I thought the cleanest way was to make two passes: 1. put executeInstallPlan into a Shell Monad to force printing debug/status messages through the monad, and track the current status of the parallel build. and 2. Use this information to write a nice UI I have implemented (1) and here is the pull request https://github.com/haskell/cabal/pull/1940. I'd appreciate if someone could make a thorough code review as it's my first commit to cabal and I only understand a small corner of the code base. If this is accepted then I also look forward to working on (2), probably based on ncurses. Best, Greg

1 0

Re: Broken documentation on Hackage.
by selinger＠mathstat.dal.ca 09 Jun '14

09 Jun '14

Good point. But could you remind me what package this Makefile is in? As far as I remember, this Makefile is for the private use of package authors, and is not included in any publicly available code. -- Peter Serge Kosyrev wrote: > > Peter, > > A notable detail we should consider is -- not sending the user password > unencrypted over the wire: > > --- Makefile 2014-06-08 18:13:44.205418114 +0400 > +++ Makefile.orig 2014-06-08 18:32:50.999706699 +0400 > @@ -27,7 +27,7 @@ > tar -Hustar -zcf ${PACKAGE}-${VERSION}-docs.tar.gz ${PACKAGE}-${VERSION}-docs > > doc-upload: ${PACKAGE}-${VERSION}-docs.tar.gz > - echo -n "Hackage password for ${HACKAGE_USER}: "; read PASSWORD; curl -X PUT -H 'Content-Type: application/x-tar' -H 'Content-Encoding: gzip' --data-binary @${PACKAGE}-${VERSION}-docs.tar.gz http://${HACKAGE_USER}:$$PASSWORD@hackage.haskell.org/package/${PACKAGE}-${VERSION}/docs > + echo -n "Hackage password for ${HACKAGE_USER}: "; read PASSWORD; curl -X PUT -H 'Content-Type: application/x-tar' -H 'Content-Encoding: gzip' --data-binary @${PACKAGE}-${VERSION}-docs.tar.gz https://${HACKAGE_USER}:$$PASSWORD@hackage.haskell.org/package/${PACKAGE}-${VERSION}/docs > > install: dist/setup/setup > cabal install > > -- > с уважениeм, > Серёга Косырев >

1 0

Re: Broken image?
by Duncan Coutts 04 Jun '14

04 Jun '14

Cheers! Fixed. I've stashed copies of all the Cabal logo files in http://www.haskell.org/cabal/images/ (FYI the cabal website is a darcs repo) On Tue, 2014-04-08 at 13:19 -0700, Jonan Scheffler wrote: > Who can fix this? > On Apr 8, 2014 11:47 AM, <cabal-devel-owner(a)haskell.org> wrote: > > > You are not allowed to post to this mailing list, and your message has > > been automatically rejected. If you think that your messages are > > being rejected in error, contact the mailing list owner at > > cabal-devel-owner(a)haskell.org. > > > > > > > > ---------- Forwarded message ---------- > > From: Jonan Scheffler <jonanscheffler(a)gmail.com> > > To: cabal-devel(a)haskell.org > > Cc: > > Date: Tue, 8 Apr 2014 11:47:02 -0700 > > Subject: Broken image? > > The Cabal logo image on http://www.haskell.org/cabal/ is broken. Is there > > someplace I could put in an issue/PR? > > > > Jonan > > -- > > Jonan Scheffler > > @1337807 <http://twitter.com/1337807> > > jonanscheffler(a)gmail.com > > (503) 985-6626 > > > >

1 0