Ward against random code execution during package installs

[lspitzner]

Does cabal currently have any way to only allow a whitelist to use the more powerful compile-time features, like a custom Setup.hs or TemplateHaskell?

Or is this a futile approach to adding more security to cabal users?

Motivation is that there exist several packages on hackage that are one typo away from from existing, well known packages. It does not feel safe that if I ever place a typo when modifying some of my "build-depends", some random package might end up executing random code. One may say one should containerize everything and vet every dependency and use a custom mirror etc. but I'd bet a majority of cabal users are not sufficiently paranoid about this.

(Of course this a client-side approach where we might prefer a server-sided one. If such exist or are in the works, please link them. But I don't think we generally want to block the entire "typo-environment" of existing package names, so a client-sided feature seems to have its merits.)

[gbaz]

I'd suggested to @deian sometime back that something based on the LIO (https://github.com/PLSysSec/lio) work would be suitable to replace the unrestricted IO in the GHC and Setup.hs subsystems. (We'd need some way to restrict unsafeperformIO too of course, maybe via safe-haskell -- there it gets tricky).

Whitelisting custom setup.hs is feasible. Whitelisting TH would be more work as I think you can have some not in cabal files. Not to mention that if you use a build-type of config, then in theory you could smuggle whatever you want into makefiles, etc.

So I think a LIO-style solution (in the spirit of Shill, which Deian pointed me to: http://shill.seas.harvard.edu/) would be the "real" solution.

Absent that, work on package collections will let us setup universes of "trusted" packages or let people run overlays with such. Additionally, if anyone wanted to implement the author-signing part of hackage-security, then we people could manually choose to whitelist only certain author/uploader keys.

Anyway, that's the range of approaches and ideas I've collected on this sort of thing thus far.

We do intend to fix capitalization stuff, ideally sooner rather than later (a contributed commit on haskell/hackage-server#352 would be welcome). But I also agree that general typo-squatting prevention is not reasonable to implement server-side. (And even that doesn't prevent against attacks like, e.g., someone hijacking someone else's account to upload something malicious).

[23Skidoo]

Something like LIO would be nice to have, but requires quite a lot of work to implement. A potential future GSoC project?

[gbaz]

I was thinking gsoc, or trying to convince a grad student to take it up and try to wring a publishable paper about the implementation :-)

[deian]

I would love to see this happen! I'm also happy to try to find the right student and help advise them. Having buy-in from ya'll would make a huge difference, so doing it as a GSoC or internship (I'm happy to host) where a few of us are involved would be amazing.

[gbaz]

There's definitely buy-in as far as I'm concerned :-). GSoC would be a way to make the process more formal. I'd suggest you write-up a proposal when we put out the call for proposals next-year for gsoc ideas. Actually, you can submit a PR to the repo now (but we should only act on it once this round is done): https://github.com/haskell-org/summer-of-haskell.

If you do find a student interested, I can't speak for everyone, but I highly suspect that there'd be plenty of people willing to help give advice to provide the greatest chance of a successful outcome. The ability to execute arbitrary code on setup is a pretty famous longstanding issue with cabal, so I expect people will really look forward to a solution here.