mtl-2.1 severly broken, cabal needs blacklisting
After 2 days of shrinking 251 modules of source code to a few lines I realized that modify in MonadState causes <<loop>> in mtl-2.1. http://hackage.haskell.org/packages/archive/mtl/2.1/doc/html/src/Control-Mon... The bug has been fixed, apparently seven month ago. https://github.com/ekmett/mtl/pull/1 However, the "malicious" mtl-2.1 still lingers on: it is available from hackage and installed in many systems. This calls for a means of blacklisting broken or malicious packages. cabal update should also pull a blacklist of packages that will never be selected by cabal install (except maybe by explicit user safety overriding). I think such a mechanism is not only necessary for security purposes, but also to safe the valuable resources of our community. Cheers, Andreas -- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/
Mixed feelings here. I personally subscribe to the philosophy of "do one thing and do it well"; perhaps this sort of functionality would be better delegated to a new "curation" tool such as the one described in Michael Snoyman's recent blog post. http://www.yesodweb.com/blog/2012/11/solving-cabal-hell -- Dan Burton (801-513-1596) On Tue, Nov 13, 2012 at 9:27 AM, Andreas Abel <andreas.abel@ifi.lmu.de>wrote:
After 2 days of shrinking 251 modules of source code to a few lines I realized that modify in MonadState causes <<loop>> in mtl-2.1.
http://hackage.haskell.org/**packages/archive/mtl/2.1/doc/** html/src/Control-Monad-State-**Class.html#modify<http://hackage.haskell.org/packages/archive/mtl/2.1/doc/html/src/Control-Monad-State-Class.html#modify>
The bug has been fixed, apparently seven month ago.
https://github.com/ekmett/mtl/**pull/1<https://github.com/ekmett/mtl/pull/1>
However, the "malicious" mtl-2.1 still lingers on: it is available from hackage and installed in many systems.
This calls for a means of blacklisting broken or malicious packages.
cabal update
should also pull a blacklist of packages that will never be selected by cabal install (except maybe by explicit user safety overriding).
I think such a mechanism is not only necessary for security purposes, but also to safe the valuable resources of our community.
Cheers, Andreas
-- Andreas Abel <>< Du bist der geliebte Mensch.
Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY
andreas.abel@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~**abel/ <http://www2.tcs.ifi.lmu.de/~abel/>
______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
On 13.11.2012 17:39, Dan Burton wrote:
Mixed feelings here. I personally subscribe to the philosophy of "do one thing and do it well"; perhaps this sort of functionality would be better delegated to a new "curation" tool such as the one described in Michael Snoyman's recent blog post. http://www.yesodweb.com/blog/2012/11/solving-cabal-hell
I think Michael Snoyman's approach goes farther than mine and solves a slightly different problem. I am not concerned with the "dependency hell" but with a means of safely avoiding bugged packages. Uploading a bugged package can happen to anyone of us, but cabal/hackage does not provide a suitable means to rectify the situation. Cabal's philosophy currently includes a monotonicity assumption: newer is better and more correct. As a consequence, packages do not get removed or replaced since that could break compilation of other packages depending on a special version number of a package. The calamity is that bugged package live on, and cabal install is oblivious of this. If one could blacklist a certain version of a package, cabal could pick the next higher available version, as a sort of redirection mechanism to the fixed package. For instance, if I have issued mylib-2.1 mylib-2.2 mylib-3.0 and I discover a bug in mylib-2.1, I could blacklist mylib-2.1 and upload a bugfix version mylib-2.1.1 that would be picked by cabal instead of mylib-2.1. Those user packages that rely on the specific interface of mylib-2.1 (e.g. having a constraint mylib == 2.1) and do not work with mylib-2.2 would still work, since they would be built with mylib-2.1.1
On Tue, Nov 13, 2012 at 9:27 AM, Andreas Abel <andreas.abel@ifi.lmu.de <mailto:andreas.abel@ifi.lmu.de>> wrote:
After 2 days of shrinking 251 modules of source code to a few lines I realized that modify in MonadState causes <<loop>> in mtl-2.1.
http://hackage.haskell.org/__packages/archive/mtl/2.1/doc/__html/src/Control... <http://hackage.haskell.org/packages/archive/mtl/2.1/doc/html/src/Control-Monad-State-Class.html#modify>
The bug has been fixed, apparently seven month ago.
https://github.com/ekmett/mtl/__pull/1 <https://github.com/ekmett/mtl/pull/1>
However, the "malicious" mtl-2.1 still lingers on: it is available from hackage and installed in many systems.
This calls for a means of blacklisting broken or malicious packages.
cabal update
should also pull a blacklist of packages that will never be selected by cabal install (except maybe by explicit user safety overriding).
I think such a mechanism is not only necessary for security purposes, but also to safe the valuable resources of our community.
Cheers, Andreas
-- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/
My take: Blacklisting equals releasing a bugfix. Using version number conventions, identifying such a release should be easy. If there exists a bugfix release for a package currently in use, then cabal should emit a warning. Cheers, JP. On Nov 13, 2012 6:12 PM, "Andreas Abel" <andreas.abel@ifi.lmu.de> wrote:
On 13.11.2012 17:39, Dan Burton wrote:
Mixed feelings here. I personally subscribe to the philosophy of "do one thing and do it well"; perhaps this sort of functionality would be better delegated to a new "curation" tool such as the one described in Michael Snoyman's recent blog post. http://www.yesodweb.com/blog/**2012/11/solving-cabal-hell<http://www.yesodweb.com/blog/2012/11/solving-cabal-hell>
I think Michael Snoyman's approach goes farther than mine and solves a slightly different problem. I am not concerned with the "dependency hell" but with a means of safely avoiding bugged packages.
Uploading a bugged package can happen to anyone of us, but cabal/hackage does not provide a suitable means to rectify the situation. Cabal's philosophy currently includes a monotonicity assumption: newer is better and more correct. As a consequence, packages do not get removed or replaced since that could break compilation of other packages depending on a special version number of a package. The calamity is that bugged package live on, and cabal install is oblivious of this.
If one could blacklist a certain version of a package, cabal could pick the next higher available version, as a sort of redirection mechanism to the fixed package. For instance, if I have issued
mylib-2.1 mylib-2.2 mylib-3.0
and I discover a bug in mylib-2.1, I could blacklist mylib-2.1 and upload a bugfix version
mylib-2.1.1
that would be picked by cabal instead of mylib-2.1.
Those user packages that rely on the specific interface of mylib-2.1 (e.g. having a constraint mylib == 2.1) and do not work with mylib-2.2 would still work, since they would be built with mylib-2.1.1
On Tue, Nov 13, 2012 at 9:27 AM, Andreas Abel <andreas.abel@ifi.lmu.de
<mailto:andreas.abel@ifi.lmu.**de <andreas.abel@ifi.lmu.de>>> wrote:
After 2 days of shrinking 251 modules of source code to a few lines I realized that modify in MonadState causes <<loop>> in mtl-2.1.
http://hackage.haskell.org/__**packages/archive/mtl/2.1/doc/_** _html/src/Control-Monad-State-**__Class.html#modify<http://hackage.haskell.org/__packages/archive/mtl/2.1/doc/__html/src/Control-Monad-State-__Class.html#modify> <http://hackage.haskell.org/**packages/archive/mtl/2.1/doc/** html/src/Control-Monad-State-**Class.html#modify<http://hackage.haskell.org/packages/archive/mtl/2.1/doc/html/src/Control-Monad-State-Class.html#modify>
The bug has been fixed, apparently seven month ago.
https://github.com/ekmett/mtl/**__pull/1<https://github.com/ekmett/mtl/__pull/1> <https://github.com/ekmett/**mtl/pull/1<https://github.com/ekmett/mtl/pull/1>
However, the "malicious" mtl-2.1 still lingers on: it is available from hackage and installed in many systems.
This calls for a means of blacklisting broken or malicious packages.
cabal update
should also pull a blacklist of packages that will never be selected by cabal install (except maybe by explicit user safety overriding).
I think such a mechanism is not only necessary for security purposes, but also to safe the valuable resources of our community.
Cheers, Andreas
-- Andreas Abel <>< Du bist der geliebte Mensch.
Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY
andreas.abel@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~**abel/ <http://www2.tcs.ifi.lmu.de/~abel/>
______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
On 13.11.12 11:13 PM, Jean-Philippe Bernardy wrote:
Blacklisting equals releasing a bugfix.
Not quite.
Using version number conventions, identifying such a release should be easy.
If there exists a bugfix release for a package currently in use, then cabal should emit a warning.
Warnings are easily overlooked. In a typical cabal install session I see tons of irrelevant warnings floating by.
On Nov 13, 2012 6:12 PM, "Andreas Abel" <andreas.abel@ifi.lmu.de <mailto:andreas.abel@ifi.lmu.de>> wrote:
On 13.11.2012 17:39, Dan Burton wrote:
Mixed feelings here. I personally subscribe to the philosophy of "do one thing and do it well"; perhaps this sort of functionality would be better delegated to a new "curation" tool such as the one described in Michael Snoyman's recent blog post. http://www.yesodweb.com/blog/__2012/11/solving-cabal-hell <http://www.yesodweb.com/blog/2012/11/solving-cabal-hell>
I think Michael Snoyman's approach goes farther than mine and solves a slightly different problem. I am not concerned with the "dependency hell" but with a means of safely avoiding bugged packages.
Uploading a bugged package can happen to anyone of us, but cabal/hackage does not provide a suitable means to rectify the situation. Cabal's philosophy currently includes a monotonicity assumption: newer is better and more correct. As a consequence, packages do not get removed or replaced since that could break compilation of other packages depending on a special version number of a package. The calamity is that bugged package live on, and cabal install is oblivious of this.
If one could blacklist a certain version of a package, cabal could pick the next higher available version, as a sort of redirection mechanism to the fixed package. For instance, if I have issued
mylib-2.1 mylib-2.2 mylib-3.0
and I discover a bug in mylib-2.1, I could blacklist mylib-2.1 and upload a bugfix version
mylib-2.1.1
that would be picked by cabal instead of mylib-2.1.
Those user packages that rely on the specific interface of mylib-2.1 (e.g. having a constraint mylib == 2.1) and do not work with mylib-2.2 would still work, since they would be built with mylib-2.1.1
On Tue, Nov 13, 2012 at 9:27 AM, Andreas Abel <andreas.abel@ifi.lmu.de <mailto:andreas.abel@ifi.lmu.de> <mailto:andreas.abel@ifi.lmu.__de <mailto:andreas.abel@ifi.lmu.de>>> wrote:
After 2 days of shrinking 251 modules of source code to a few lines I realized that modify in MonadState causes <<loop>> in mtl-2.1.
http://hackage.haskell.org/____packages/archive/mtl/2.1/doc/____html/src/Con... <http://hackage.haskell.org/__packages/archive/mtl/2.1/doc/__html/src/Control-Monad-State-__Class.html#modify>
<http://hackage.haskell.org/__packages/archive/mtl/2.1/doc/__html/src/Control... <http://hackage.haskell.org/packages/archive/mtl/2.1/doc/html/src/Control-Monad-State-Class.html#modify>>
The bug has been fixed, apparently seven month ago.
https://github.com/ekmett/mtl/____pull/1 <https://github.com/ekmett/mtl/__pull/1> <https://github.com/ekmett/__mtl/pull/1 <https://github.com/ekmett/mtl/pull/1>>
However, the "malicious" mtl-2.1 still lingers on: it is available from hackage and installed in many systems.
This calls for a means of blacklisting broken or malicious packages.
cabal update
should also pull a blacklist of packages that will never be selected by cabal install (except maybe by explicit user safety overriding).
I think such a mechanism is not only necessary for security purposes, but also to safe the valuable resources of our community.
Cheers, Andreas
-- Andreas Abel <>< Du bist der geliebte Mensch.
Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY
andreas.abel@ifi.lmu.de <mailto:andreas.abel@ifi.lmu.de> http://www2.tcs.ifi.lmu.de/~__abel/ <http://www2.tcs.ifi.lmu.de/~abel/>
_________________________________________________ Libraries mailing list Libraries@haskell.org <mailto:Libraries@haskell.org> http://www.haskell.org/__mailman/listinfo/libraries <http://www.haskell.org/mailman/listinfo/libraries>
-- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/
On Tue, Nov 13, 2012 at 11:39 PM, Andreas Abel <andreas.abel@ifi.lmu.de>wrote:
On 13.11.12 11:13 PM, Jean-Philippe Bernardy wrote:
Blacklisting equals releasing a bugfix.
Not quite.
I propose to *define* blacklisting as such. package-X.Y.Z.W is blacklisted if there exists package-X.Y.Z.V where V > W (maybe I'm off by one position in the version number scheme here, but you get the idea) The advantages of this proposal are * backward and forward compatible with all existing code, including hackage * minimal addition to cabal-install: add some code to detect compilation against a blacklisted version
Warnings are easily overlooked. In a typical cabal install session I see tons of irrelevant warnings floating by.
WARNING: This package is compiled against known incorrect code! You should upgrade the mtl package. would show up at *every compilation*. I am guessing this would have been sufficient to save you from a 250-module shrinking. By the way, the new warning is effective only if one has an up-to-date list of packages. Hence it makes sense to group it with the current warning about an out-of-date list. Cheers, JP.
On Nov 13, 2012 6:12 PM, "Andreas Abel" <andreas.abel@ifi.lmu.de
<mailto:andreas.abel@ifi.lmu.**de <andreas.abel@ifi.lmu.de>>> wrote:
On 13.11.2012 17:39, Dan Burton wrote:
Mixed feelings here. I personally subscribe to the philosophy of "do one thing and do it well"; perhaps this sort of functionality would be better delegated to a new "curation" tool such as the one described in Michael Snoyman's recent blog post. http://www.yesodweb.com/blog/_**_2012/11/solving-cabal-hell<http://www.yesodweb.com/blog/__2012/11/solving-cabal-hell>
I think Michael Snoyman's approach goes farther than mine and solves a slightly different problem. I am not concerned with the "dependency hell" but with a means of safely avoiding bugged packages.
Uploading a bugged package can happen to anyone of us, but cabal/hackage does not provide a suitable means to rectify the situation. Cabal's philosophy currently includes a monotonicity assumption: newer is better and more correct. As a consequence, packages do not get removed or replaced since that could break compilation of other packages depending on a special version number of a package. The calamity is that bugged package live on, and cabal install is oblivious of this.
If one could blacklist a certain version of a package, cabal could pick the next higher available version, as a sort of redirection mechanism to the fixed package. For instance, if I have issued
mylib-2.1 mylib-2.2 mylib-3.0
and I discover a bug in mylib-2.1, I could blacklist mylib-2.1 and upload a bugfix version
mylib-2.1.1
that would be picked by cabal instead of mylib-2.1.
Those user packages that rely on the specific interface of mylib-2.1 (e.g. having a constraint mylib == 2.1) and do not work with mylib-2.2 would still work, since they would be built with mylib-2.1.1
On Tue, Nov 13, 2012 at 9:27 AM, Andreas Abel <andreas.abel@ifi.lmu.de <mailto:andreas.abel@ifi.lmu.**de<andreas.abel@ifi.lmu.de>
<mailto:andreas.abel@ifi.lmu._**_de
<mailto:andreas.abel@ifi.lmu.**de <andreas.abel@ifi.lmu.de>>>> wrote:
After 2 days of shrinking 251 modules of source code to a few lines I realized that modify in MonadState causes <<loop>> in mtl-2.1.
http://hackage.haskell.org/___**_packages/archive/mtl/2.1/doc/** ____html/src/Control-Monad-**State-____Class.html#modify<http://hackage.haskell.org/____packages/archive/mtl/2.1/doc/____html/src/Control-Monad-State-____Class.html#modify> <http://hackage.haskell.org/__**packages/archive/mtl/2.1/doc/_** _html/src/Control-Monad-State-**__Class.html#modify<http://hackage.haskell.org/__packages/archive/mtl/2.1/doc/__html/src/Control-Monad-State-__Class.html#modify>
<http://hackage.haskell.org/__**packages/archive/mtl/2.1/doc/_** _html/src/Control-Monad-State-**__Class.html#modify<http://hackage.haskell.org/__packages/archive/mtl/2.1/doc/__html/src/Control-Monad-State-__Class.html#modify> <http://hackage.haskell.org/**packages/archive/mtl/2.1/doc/** html/src/Control-Monad-State-**Class.html#modify<http://hackage.haskell.org/packages/archive/mtl/2.1/doc/html/src/Control-Monad-State-Class.html#modify>
The bug has been fixed, apparently seven month ago.
https://github.com/ekmett/mtl/**____pull/1<https://github.com/ekmett/mtl/____pull/1> <https://github.com/ekmett/**mtl/__pull/1<https://github.com/ekmett/mtl/__pull/1>
<https://github.com/ekmett/__**mtl/pull/1<https://github.com/ekmett/__mtl/pull/1> <https://github.com/ekmett/**mtl/pull/1<https://github.com/ekmett/mtl/pull/1>
However, the "malicious" mtl-2.1 still lingers on: it is available from hackage and installed in many systems.
This calls for a means of blacklisting broken or malicious packages.
cabal update
should also pull a blacklist of packages that will never be selected by cabal install (except maybe by explicit user safety overriding).
I think such a mechanism is not only necessary for security purposes, but also to safe the valuable resources of our community.
Cheers, Andreas
-- Andreas Abel <>< Du bist der geliebte Mensch.
Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY
andreas.abel@ifi.lmu.de <mailto:andreas.abel@ifi.lmu.**de<andreas.abel@ifi.lmu.de>
http://www2.tcs.ifi.lmu.de/~__**abel/<http://www2.tcs.ifi.lmu.de/~__abel/><; http://www2.tcs.ifi.lmu.de/~**abel/ <http://www2.tcs.ifi.lmu.de/~abel/>>
______________________________**___________________ Libraries mailing list Libraries@haskell.org <mailto:Libraries@haskell.org> http://www.haskell.org/__**mailman/listinfo/libraries<http://www.haskell.org/__mailman/listinfo/libraries> <http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
-- Andreas Abel <>< Du bist der geliebte Mensch.
Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY
andreas.abel@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~**abel/ <http://www2.tcs.ifi.lmu.de/~abel/>
On Wed, 14 Nov 2012, Jean-Philippe Bernardy wrote:
On Tue, Nov 13, 2012 at 11:39 PM, Andreas Abel <andreas.abel@ifi.lmu.de> wrote: On 13.11.12 11:13 PM, Jean-Philippe Bernardy wrote: Blacklisting equals releasing a bugfix.
Not quite.
I propose to *define* blacklisting as such.
package-X.Y.Z.W is blacklisted if there exists package-X.Y.Z.V where V > W (maybe I'm off by one position in the version number scheme here, but you get the idea)
This rule is correct for packages following the Package Versioning Policy. Currently cabal-install and Cabal make no assumptions about the employed versioning scheme.
On 13 November 2012 17:27, Andreas Abel <andreas.abel@ifi.lmu.de> wrote:
This calls for a means of blacklisting broken or malicious packages.
cabal update
should also pull a blacklist of packages that will never be selected by cabal install (except maybe by explicit user safety overriding).
Maybe we can use the existing preferred-versions file that cabal-install uses: http://hackage.haskell.org/packages/archive/preferred-versions Bas
On Tue, 13 Nov 2012, Bas van Dijk wrote:
On 13 November 2012 17:27, Andreas Abel <andreas.abel@ifi.lmu.de> wrote:
This calls for a means of blacklisting broken or malicious packages.
cabal update
should also pull a blacklist of packages that will never be selected by cabal install (except maybe by explicit user safety overriding).
Maybe we can use the existing preferred-versions file that cabal-install uses:
http://hackage.haskell.org/packages/archive/preferred-versions
It is also possible to deprecate a package. Is it possible to deprecate a single version? I'm afraid that the user is also not warned if he installs a deprecated package.
participants (5)
-
Andreas Abel -
Bas van Dijk -
Dan Burton -
Henning Thielemann -
Jean-Philippe Bernardy