Re: Status of Haskell Platform 2014.2.0.0

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
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

As per comments: Done: - hashable can be bumped to 1.2.2.0. - network can be bumped to 2.4.2.3 - unordered-containers can be bumped to 0.2.4.0 - happy bumped to 1.19.4 - bump cabal-install to 1.18.0.5 Unsure: - Not sure if you want QuickCheck 2.7.5 rather than 2.6 -- cc'ing QuickCheck devs: Would they like to weigh in? Not Changed: - attoparsec will remain at version 0.10.4.0, as newer attoparsec depends on the new package scientific - cabal-install will stay at the 1.18 level (not bump to 1.20.*) because it needs to remain in sync with 7.8.3's Cabal package, Johan has been great about back-porting fixes to 1.18 for this reason.

On Tue, Jul 15, 2014 at 6:44 AM, Mark Lentczner
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.

Hi, On Tue, Jul 15, 2014 at 10:56:24AM -0700, Bryan O'Sullivan wrote:
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.
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? Ciao, Kili

On Tue, Jul 15, 2014 at 12:25 PM, Matthias Kilian
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 10:56 AM, Bryan O'Sullivan
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.
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?

On Tue, Jul 15, 2014 at 1:43 PM, Mark Lentczner
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
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
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
participants (4)
-
Bryan O'Sullivan
-
Johan Tibell
-
Mark Lentczner
-
Matthias Kilian