On Mar 14, 2013, at 11:08 PM, Jason Dagit <dag...@gmail.com> wrote: > My real reason for reviving this thread: Can I get a status update, please?
Sure. I don't have as much time as I'd like these days for open-source projects, but with Jan's help the code has been cleaned up quite a bit in general, and a lot of old bit-rot has been fixed. I have not specifically addressed security yet, but it's not as dire a situation as I think it sounded from my earlier remarks. Basically, security is currently a bit "DIY". If there are any holes, they are probably quite subtle because there are very, very few moving parts on lambdabot's side. mueval and Safe Haskell are used to enforce resource limitations and type-safety, respectively, but -fpackage-trust is not (yet) turned on. So all packages installed on the system are available for the interpreted code (if imported using a command such as "@let import Foo.Bar"), as long as Safe Haskell permits. This is the main potential security hole - the system may have modules installed and marked "Trustworthy" that the administrator has not explicitly decided whether to trust, and which are not, in fact, as safe as the author asserts. Currently, lambdabot trusts such packages. My intention is to add some commands (available only to lambdabot admins) or maybe a static configuration option for managing a list of packages to explicitly trust, with all others being untrusted. And of course, for a "production" system an OS-enforced sandbox is a great idea no matter how secure you believe the code do be. Aside from that caveat, I think that the code could be put on hackage today and I'd have few, if any, reservations about it. -- James _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
