Ticket #911 (new defect)

Opened 15 months ago

Last modified 15 months ago

Package uploading is completely unsecured

Reported by: bgamari Owned by:
Priority: high Milestone:
Component: Hackage 2 server Version: 1.8.0.6
Severity: major Keywords:
Cc: ehird Difficulty: unknown
GHC Version: Platform:

Description

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.

Change History

Changed 15 months ago by bgamari

  • priority changed from normal to high

Changed 15 months ago by AntoineLatter

It's been a while since I tested this, but I think we already lock down uploading to existing packages - the only thing un-restricted is uploading new packages.

So part of this is still a problem.

I think at some point there was code to edit the list of 'uploaders' for a package, but I don't know where that is now.

Changed 15 months ago by ehird

  • cc ehird added

(I'm the  original reporter of this issue.)

Correction: "Email the maintainer asking for a package upload" should read "Email the Hackage maintainer asking for package upload status".

Note: See TracTickets for help on using tickets.