[Hackage] #214: Package security
Hackage
trac at galois.com
Mon May 19 16:37:27 EDT 2008
#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
More information about the cabal-devel
mailing list