- Libraries - Haskell.org

Re: Proposal: Add the unordered-containers package and the hashable package to the Haskell Platform
by Roman Cheplyaka 21 Mar '13

21 Mar '13

* Thomas Moertel <tom(a)moertel.com> [2013-03-21 15:58:58-0400] > On Wed, Mar 20, 2013 at 5:05 PM, Johan Tibell <johan.tibell(a)gmail.com>wrote: > > > The problem is that if the secure hashing makes HashMap as slow as Map, > > there's no point in having the former in the first place, as it only exists > > to provide speed. > > > > I understand that HashMap exists to provide speed, but are we sure that > everyone who uses it for speed understands the security implications? > > Regardless of whether speed-first or security-first is the default, users > of HashMap can be partitioned into two groups: those who knowingly choose > between speed and security, and those who do not. For the first group, > either default is safe because members of that group will have the > opportunity to choose the other option. But for the second group, only > security-first is safe: if it’s not the default, members of the second > group won’t have the option to choose it. Why not simply educate them by placing a prominent notice in the haddock? > The problem for the Haskell Platform is that the second group is likely to > be large. The whole point, after all, is to make a curated set of tools and > libraries available to a large audience that doesn’t necessarily have the > time or knowledge to make its own informed choices. So if we decide, on > behalf of this audience, that the Haskell Platform is going to be less > secure to get more speed, aren’t we exposing a lot of Haskell users to > preventable security risks? > > I’m not just arguing the case of HashMap but of the whole Haskell Platform. > I’d like to think that a widely used platform should be safe by default and > offer danger-with-benefits as an option. The whole security issue is that, in some cases, the complexity of the code may be unexpectedly bad. Unfortunately, it is already the case with Haskell. Laziness makes it extremely hard to make guarantees about the worst-case complexity of a non-trivial code base. Roman

1 0

Re: Proposal: Add the unordered-containers package and the hashable package to the Haskell Platform
by Johan Tibell 20 Mar '13

20 Mar '13

On Wed, Mar 20, 2013 at 1:04 PM, Thomas Moertel <tom(a)moertel.com> wrote: > On the speed vs. security trade-off, there’s a good argument for the > Haskell Platform to choose security as its default policy: speed problems > are obvious and have understandable consequences and remedies, but security > problems are hidden and have poorly understood consequences and often lack > remedies altogether. You can’t go back in time to remedy being pwned. > > Therefore, if we make speed the default, we leave open to harm everybody > who fails to fully understand the security implications of their libraries’ > default choices, which is just about everybody. But if we make security the > default, nobody will be taken unaware, either by speed or preventable > security problems. > > Yes, those people who need the extra speed will have to suffer the cost of > opting-in to the faster implementations, but that cost is predictable and > relatively small. The point is that nobody is going to be taken unaware by > failing to make the right choice up front. The first time you run your code > and it’s too slow, you’ll know. > The problem is that if the secure hashing makes HashMap as slow as Map, there's no point in having the former in the first place, as it only exists to provide speed.

1 0

Re: Proposal: Add the unordered-containers package and the hashable package to the Haskell Platform
by Johan Tibell 20 Mar '13

20 Mar '13

On Wed, Mar 20, 2013 at 11:40 AM, Bardur Arantsson <spam(a)scientician.net>wrote: > On 03/20/2013 07:14 PM, Johan Tibell wrote:> Just as > > sandboxing is a better way to run untrusted software than trying to plug > > every whole in your code/RTS, > > (Citation needed). There have been lots of exploits of VMs and > sandboxes. This is also irrelevant to DoS prevention, AFAICT. > > > generic anti-DoS techniques are usually > > better than trying to figure out every possible way someone can DoS you. > > (Citation needed.) > > There's no excuse for not preventing obvious an relatively easily > preventable problems. Security in Depth and all that. My only citation is that this is how we do things, but I think you can make a theoretical argument for it as well. This is what I tried to do with the sandboxing analogy. The reason that sandboxing works well is that it's a whitelist approach (instead of a blacklist approach). I should note that when I talk about sandboxing I don't really mean a VM, but rather a chroot/process isolation approach, like AppEngine. If you only allow the e.g. AppEngine user code to modify the system via a few select RPCs and then block all file system access by default, you can avoid having to audit every single API that the platform offers. Now, for DoS protection we can do something similar. We have a detector for bad behavior (e.g. long running connections that time out, etc) and a generic mechanism for rejecting such users (IP blocking). That way we don't have to inspect everything the app itself does that could open it up for a DoS attack. You're of course right that current Haskell frameworks don't do this. There hasn't really been a need yet. -- Johan

1 0

Re: Proposal: Add the unordered-containers package and the hashable package to the Haskell Platform
by Bardur Arantsson 20 Mar '13

20 Mar '13

On 03/20/2013 07:40 PM, Bardur Arantsson wrote: > On 03/20/2013 07:14 PM, Johan Tibell wrote: > >Hash flooding is only one of many ways to DoS a server. You can try other > >things, like building a bot net and trying to flood the connection. > > Sure, but that's another step up in difficulty from using a single > client to DoS a server trivially. > I should also add: Whatever DDoS protections your ISP may (or may not) have in place does nothing to protect you if your host has a DoS vulnerability which is exploitable with a single connection.

1 0

Re: Stricter WriterT (Part II)
by Gabriel Gonzalez 19 Mar '13

19 Mar '13

> Presumably we'll also need > > writerT :: m (a, w) -> WriterT w m a Yes, we would need that, too: writerT m = WriterT $ \w -> do (a, w') <- m let wt = mappend w w' wt `seq` return (a, wt) > Is there any reason to keep Control.Monad.Trans.Writer.Strict, or should this replace it? If we replace the old one, it will break existing code that used the `WriterT` constructor. Same thing for the strict RWST constructor if we similarly modify that. However, I don't know exactly how many packages use those constructors. I will try to do a text search of Hackage this coming weekend to check and see if it is feasible to ask downstream packages that use `WriterT`/`RWST` constructors to set upper bounds on `transformers`.

2 1

Re: Data instance for Data.Version
by Administrator 18 Mar '13

18 Mar '13

> Hi, > > Can we derive Data for Data.Version.Version? It would benefit Cabal. > > Thanks, > David On a related note, what about also moving some (maybe all) of the nice Distribution.Version related functions from the Cabal package to Data.Version? I am sure other libraries would also be interested in using this functionality without having to include Cabal as a whole. One example is the Ghc runtime itself: this could be one small step in removing dependencies from Ghc to Cabal.

2 1

instance Applicative Data.Map
by Henning Thielemann 17 Mar '13

17 Mar '13

An ZipList-like Applicative instance for Data.Map would be nice. I have an application where I like to write liftA3 f amap bmap cmap meaning Map.intersectionWith ($) (Map.intersectionWith f amap bmap) cmap But I cannot complete the instance implementation because there is no sensible definition for 'pure' for Data.Map. :-(

14 31

Re: Data instance for Data.Version
by Administrator 15 Mar '13

15 Mar '13

I.e. move Distribution.Version code that is not deprecated and not parsing- or pretty printing related (these depend on other Cabal modules). On Fri, Mar 15, 2013 at 7:26 PM, Administrator <admin(a)rodlogic.net> wrote: >> Hi, >> >> Can we derive Data for Data.Version.Version? It would benefit Cabal. >> >> Thanks, >> David > > On a related note, what about also moving some (maybe all) of the nice > Distribution.Version related functions from the Cabal package to > Data.Version? I am sure other libraries would also be interested in > using this functionality without having to include Cabal as a whole. > One example is the Ghc runtime itself: this could be one small step in > removing dependencies from Ghc to Cabal.

1 0

Re: Advance notice that I'd like to make Cabal depend on parsec
by Roman Cheplyaka 15 Mar '13

15 Mar '13

* Heinrich Apfelmus <apfelmus(a)quantentunnel.de> [2013-03-15 10:38:37+0100] > Duncan Coutts wrote: > >Hi folks, > > > >I want to give you advance notice that I would like to make Cabal depend > >on parsec. The implication is that GHC would therefore depend on parsec > >and thus it would become a core package, rather than just a HP package. > >So this would affect both GHC and the HP, though I hope not too much. > > > >[..] > > > >Why did I choose parsec? Practicality dictates that I can only use > >things in the core libraries, and the nearest thing we have to that is > >the parser lib that is in the HP. I tried to use happy but I could not > >construct a grammar/lexer combo to handle the layout (also, happy is not > >exactly known for its great error messages). > > Reuse is good, but the implication I'm worried about is this: Can I > upgrade the parsec package installed on my system by doing a user > install from hackage ? Without an implementation of more flexible > package installations (multiple versions installed simultaneously), > any dependency of GHC has its version number essentially set into > stone. We've had that working for a long time. Right now I even have multiple installed versions of Cabal-the-library itself. It's not that Parsec would be automatically linked into each executable. It's just that ghc-the-program would have Parsec linked into it. Roman

2 2

RE: Advance notice that I'd like to make Cabal depend on parsec
by Simon Peyton-Jones 14 Mar '13

14 Mar '13

Yes I think that'd be a great plan. It's bizarre that GHC depends on *all* of Cabal, but only uses a tiny part of it (more or less the Package data type I think). Simon | -----Original Message----- | From: cabal-devel-bounces(a)haskell.org [mailto:cabal-devel-bounces@haskell.org] | On Behalf Of Administrator | Sent: 14 March 2013 15:23 | To: Duncan Coutts | Cc: Lentczner; cabal-devel; Haskell Libraries; ghc-devs(a)haskell.org | Subject: Re: Advance notice that I'd like to make Cabal depend on parsec | | This GHC dependency on Cabal is putting a rather troubling constraint | in Cabal's evolution, which in my opinion is a serious problem. When I | first took a look at the dependencies between GHC and Cabal I found it | a bit strange that GHC would depend on Cabal as I would expect GHC to | be as low in the dependency tree as possible to avoid exactly these | kinds of problems. | | These GHC dependencies on Cabal are in fact small (see | http://hackage.haskell.org/trac/ghc/attachment/ticket/7740/ghc-2.png | for a summary) and with a little bit of refactoring it would be | possible to split these dependencies into a very small shared package | with minimal or no further dependencies. This would liberate Cabal to | make the necessary refactoring. | | IMHO, the addition of these new dependencies to Cabal should go | together with splitting the GHC-Cabal shared dependencies into a | separate package so that there would be no additional coordination | needed from then on between these two development efforts (except when | dealing with this new package). | | | On Thu, Mar 14, 2013 at 12:12 PM, Duncan Coutts | <duncan.coutts(a)googlemail.com> wrote: | > On Thu, 2013-03-14 at 16:06 +0100, Gregory Collins wrote: | >> On Thu, Mar 14, 2013 at 3:53 PM, Duncan Coutts | <duncan.coutts(a)googlemail.com | >> > wrote: | >> | >> > Hi folks, | >> > | >> > I want to give you advance notice that I would like to make Cabal depend | >> > on parsec. The implication is that GHC would therefore depend on parsec | >> > and thus it would become a core package, rather than just a HP package. | >> > So this would affect both GHC and the HP, though I hope not too much. | >> | >> | >> +1 from me, although the amount of potential knock-on work might be | >> discouraging. The current cabal-install bootstrap process (which is | >> currently pretty easy and is necessary at times) will get a bunch more deps | >> as a result of this change, no? | > | > Yes it will, but given that we do have a script it's not too bad I | > think. And overall I think its worth it to have the better error | > messages, performance and memory use. Do you have any idea how slow it | > is to parse all the .cabal files on hackage, and how much memory that | > takes? You'd be horrified :-) | > | > Duncan | > | > | > _______________________________________________ | > cabal-devel mailing list | > cabal-devel(a)haskell.org | > http://www.haskell.org/mailman/listinfo/cabal-devel | | _______________________________________________ | cabal-devel mailing list | cabal-devel(a)haskell.org | http://www.haskell.org/mailman/listinfo/cabal-devel

3 3