[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