This was discussed earlier. We need to stick with the Cabal that ships with the GHC version we're using and thus we need to stick with cabal-install-1.18. On Tue, Jul 15, 2014 at 9:33 AM, Alois Cochard wrote:

Why not directly to 1.20.x? On Jul 15, 2014 7:59 AM, "Andres Löh" wrote:

...

Hi.

...

Check the version list in Release2014.hs

Would it still be possible to bump cabal-install to 1.18.0.5?

Cheers, Andres _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Tue, Jul 15, 2014 at 6:44 AM, Mark Lentczner wrote:

​Unsure:

- Not sure if you want QuickCheck 2.7.5 rather than 2.6 -- cc'ing QuickCheck devs: Would they like to weigh in?

I would really like to see 2.7.5 go in, as it has a number of both improvements and backwards incompatible API changes that make it impossible to interoperate with 2.6.

Not Changed:

- attoparsec will remain at version 0.10.4.0, as newer attoparsec depends on the new package scientific

attoparsec has some security fixes in recent releases that depend on the

scientific package. It would be a very bad idea to continue with 0.10.4.0.

On Tue, Jul 15, 2014 at 12:25 PM, Matthias Kilian wrote:

Apart from this, i guess future versions of attoparsec (and other libraries included in the HP) will probably depend on more libraries not yet in the HP. So what's the correct way to deal with this?

- Use newer versions for libraries like attoparsec and add additional libraries they depend on?

- Or reduce the number of libraries included in the HP?

This a fundamental tension with having a set of packages like the platform: The point of a library being in the platform is that it forms part of the stable base for all other development work. But then a library in it has become a stable base. If stable library pulls in a new dependency on a library that isn't stable... then the depending library is no longer stable. [Stable here refers to API and expectation stability... not code quality.] Libraries in the platform should, ideally, be very conservative with adding new dependencies. In the past, we have set the bar that a package will not move forward in version in the platform if it requires a dependency that is not in the platform. If we relax this, you can see where it leads: A is admitted into the platform. Later it depends on B, not in the platform... so we bundle B into the platform as well (as A needs it). Now, people start to come to expect that B is "there"... and depend on it... but it hasn't ever signed up to the stability commitment, and so if it changes radically... the platform, as practically seen by users is no longer stable. We are a very fast moving bunch here in the Haskell world. In part because both our language and ecosystem of tools have enabled us to build on their safety. For example: In it's short 9 month life (introduced in Oct 2013), scientific has had 7 major API revisions in 16 releases. That is pretty unprecedented for packages that make up other stable library sets other ecosystems. It would be hard to include a package with that much API motion in a set of stable packages whose API you could code against... and expect it to be relatively unchanged in a year. Imagine if Data.Map's API changed that often.... I certainly don't want to have to constantly fiddle with my project over a year to keep it working with Data.Map. And even if I update my platform once every six months (I know... I know... but *most *years...) then it is *still* wasted time if I need to fiddle with my project to be sure it still works with Data.Map. Of course, Data.Map is stable... and this doesn't happen. We should have this discussion again after the release. We should re-evaluate what we expect from the libraries that are in the platform, and we should set more clear stability metrics. Looking forward to lively discussions on this over beer in Gothenburg! - Mark

On Tue, Jul 15, 2014 at 1:43 PM, Mark Lentczner wrote:

This is rather late to hear this... given that I plan to Alpha this weekend or sooner.

Can you quantify the security fixes? Do they only revolve around floats?

Well, it was rather late to hear that you weren't going to upgrade attoparsec, too ;-) In brief, an attacker can DoS a user of attoparsec by handing them a floating point number with a sufficiently large exponent (e.g. 1e1000000000). This will cause it to try to create an Integer with the given number of digits, thus possibly OOMing a machine or crashing a process.

On Tue, Jul 15, 2014 at 1:59 PM, Bryan O'Sullivan wrote:

Well, it was rather late to hear that you weren't going to upgrade attoparsec, too ;-)

On Sun, Mar 30, 2014 at 1:06 PM, Mark Lentczner wrote:

SO, In anticipation of releasing a HP shortly (1 month?) after GHC 7.8... I'd like to get going on nailing down package versions.

, incLib "attoparsec" "0.10.4.0"

In brief, an attacker can DoS a user of attoparsec by handing them a floating point number with a sufficiently large exponent (e.g. 1e1000000000). This will cause it to try to create an Integer with the given number of digits, thus possibly OOMing a machine or crashing a process.

But only if you use the Data.Atooparsec.Text parsers double, number, and rational parser, right? - Mark

Hi Mark, On Tuesday 15 July, 2014 at 06:44 am, Mark Lentczner wrote:

Unsure:

- Not sure if you want QuickCheck 2.7.5 rather than 2.6 -- cc'ing QuickCheck devs: Would they like to weigh in?

I've uploaded version 2.7.6 which fixes a bug in 2.7.5, BTW. But, as I recall, the problem with QC 2.7 and HP was that we now depend on the tf-random package for random number generation. If I understand correctly this was a showstopper from your point of view, because of tf-random's newness and potential instability. The stability of tf-random doesn't bother me because it's a purely internal dependency of QuickCheck - unless you really dig into the guts of QC you won't find any trace of tf-random, and you certainly don't need to use its API. However, I totally understand that if tf-random got added to the HP, people might start using it outside of QC, and then it would be a problem! I think this change was something we had to do - we've known about the bug in StdGen for almost five years now and at some point we have to give up on it being fixed and switch away. So I'm quite philosophical if we can't get the latest QC in the Platform this time around. However, there should be a plan for getting it into the next release at least. Here are some possibilities: 1. We make sure that tf-random becomes stable and hope it can be included in the next version of the platform. 2. We add a simple TFGen-inspired generator directly to QuickCheck. 3. We fix StdGen by replacing it with a TFGen-inspired implementation. Number 3 would be best for everyone, but if it doesn't happen maybe option 2 is the most pragmatic one. Nick