gbaz
commented
6 years ago 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 https://github.com/haskell/hackage-server/issues/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
deian
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.)