February 2012 - cabal-devel

[Hackage] #911: Package uploading is completely unsecured
by Hackage 14 Feb '12

14 Feb '12

#911: Package uploading is completely unsecured -------------------------------+-------------------------------------------- Reporter: bgamari | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Hackage 2 server | Version: 1.8.0.6 Severity: major | Keywords: Difficulty: unknown | Ghcversion: Platform: | -------------------------------+-------------------------------------------- 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. {{{ <dcoutts> 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 <dcoutts> since you probably want self-registration for those users <dcoutts> but for uploaders it's sensible to have a human in the loop <bgamari> Certainly <dcoutts> like we do in the current system <dcoutts> so there's an admin user group who can edit other groups <dcoutts> ie grant permissions [...] <dcoutts> 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) <dcoutts> so in the new system malicious people can still upload *new* malicious packages <dcoutts> 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. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/911> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #915: Convert to modular use of type-safe URLs
by Hackage 14 Feb '12

14 Feb '12

#915: Convert to modular use of type-safe URLs -------------------------------+-------------------------------------------- Reporter: bgamari | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Hackage 2 server | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | -------------------------------+-------------------------------------------- -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/915> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #913: New HTML theme
by Hackage 14 Feb '12

14 Feb '12

#913: New HTML theme -------------------------------+-------------------------------------------- Reporter: bgamari | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Hackage 2 server | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | -------------------------------+-------------------------------------------- A mock-up can be found at http://althack.org/hackage/hackage4.png -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/913> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #914: Fix acid-state usage
by Hackage 14 Feb '12

14 Feb '12

#914: Fix acid-state usage -------------------------------+-------------------------------------------- Reporter: bgamari | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Hackage 2 server | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | -------------------------------+-------------------------------------------- Update use of acid-state so that it's properly modular, rather than the current monolithic shim. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/914> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #912: Allow mirror client to set upload user and date
by Hackage 14 Feb '12

14 Feb '12

#912: Allow mirror client to set upload user and date -------------------------------+-------------------------------------------- Reporter: bgamari | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Hackage 2 server | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | -------------------------------+-------------------------------------------- Change the server to allow the mirror client to set the upload user name and date. Change the mirror client to copy the upload name and date from the source index. The point is, mirrored packages should have the info from the original package, and not appear to have been uploaded by the mirroring client itself. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/912> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #916: Verify that HTTP interface is fully/properly implemented
by Hackage 14 Feb '12

14 Feb '12

#916: Verify that HTTP interface is fully/properly implemented -------------------------------+-------------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: high | Milestone: Component: Hackage 2 server | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | -------------------------------+-------------------------------------------- Ensure that server implementation is compliant with interface specified at HackageDB/2.0/URIs -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/916> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (hackage-server): "Use line buffering for mirror client"
by duncan＠lun.haskell.org 14 Feb '12

14 Feb '12

Tue Feb 14 16:49:11 GMT 2012 Duncan Coutts <duncan(a)community.haskell.org> * Use line buffering for mirror client Ignore-this: f63019a6c722a2bd6751ef86a3e84ea2 Handy when monitoring log files to get more incremental output. M ./MirrorClient.hs +2

1 0

Re: [Hackage] #534: cabal haddock should --hyperlink-source by default
by Hackage 14 Feb '12

14 Feb '12

#534: cabal haddock should --hyperlink-source by default ----------------------------------+----------------------------------------- Reporter: adamvo | Owner: Type: enhancement | Status: new Priority: normal | Milestone: _|_ Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- Comment(by darrint): Sorry for the bad formatting. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/534#comment:7> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #534: cabal haddock should --hyperlink-source by default
by Hackage 14 Feb '12

14 Feb '12

#534: cabal haddock should --hyperlink-source by default ----------------------------------+----------------------------------------- Reporter: adamvo | Owner: Type: enhancement | Status: new Priority: normal | Milestone: _|_ Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- Comment(by darrint): I agree with the sentiment that making --hyperlink-source a default is the wrong thing to do. I burned at least a half hour last night looking for a cabal config option similar to "documentation: True," perhaps "hyperlink-source: true." I was surprised to learn that this isn't possible. So I had to just do without. I'm working with yesod, ghc 7.4.1 and virthualenv. So my normal workflow is: 1. download ghc 7.4.1 binaries 2. bunzip 3. run virthualenv --ghc=ghc-tarball 4. Edit cabal config to add "documentation: true." Here is where I wish I could add hyperlink-source. 4. cabal install yesod # wait a long time 5. scaffold site. 6. cabal install --only-dependencies # wait a long time again 7. realize I forgot cabal install alex. 8. cabal install alex 9. cabal install --only-dependencies # wait a long time yet again. 10. Use web browser to go see my 40 or 50 new packages with haddock docs. 11. Wish I knew how to make a root index page. 12. Wish those docs had source linked like I see on Hackage. Because yesod has soooo many dependencies, it isn't practical to run cabal haddock --hyperlink-source for each one, or at least I haven't found a practical way to do the whole lot in one run. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/534#comment:6> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Patch to let hackage-server build with GHC <= 7.4.1
by Bas van Dijk 14 Feb '12

14 Feb '12

Hi, Attached is a patch which lets hackage-server build with GHC <= 7.4.1. It would be great if somebody could apply it. Cheers, Bas

2 4