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 3:14 PM, Mark Lentczner wrote:

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

Well yes, but that's a rather important "if".