#214: Package security ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: project(> week) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): We discussed this on #ghc this afternoon. For reference some other obvious ways to make a trojan package are: * with build-type Custom using a malicious Setup.hs * with build-type Configure using a malicious ./configure * with build-type Simple using a malicious custom pre-processor and {{{ghc-options: -F -pgmF dist/build/foo/foo}}} * with build-type Simple using {{{ghc-options: -F -pgmFrm -optF-rf}}} I assume the tricks with ghc options work just as well in {-# OPTIONS #-} pragmas in source files. Then of course there is TH as in today's example which can do arbitrarily bad things, since it has access to IO via runIO and unsafePerformIO. So clearly it's not sensible to try and patch all these holes just so that we can build (but not run) hostile packages safely, when the obvious way to do that is using OS sandboxing features. As for users downloading bad packages, perhaps we should ask why they might be more likely to download and run an unknown package from hackage than say `132.73.41.22/hax0r.sh`. We should be careful not to give any false sense of security. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/214#comment:6 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects