https://github.com/haskell/cabal/issues/936 Suggest that package be masked as a warning to potential users.
> dev-haskell/cabal-install does not use TLS to download packages For what it's worth it's true. > Suggest that package be masked as a warning to potential users. I'd say it's not practical unless there is cabal-install which is able to https://.
I would welcome such a mask. I for one would not have installed cabal-install had I known of this.
(In reply to Sergei Trofimovich from comment #1) > > dev-haskell/cabal-install does not use TLS to download packages > For what it's worth it's true. > > > Suggest that package be masked as a warning to potential users. > I'd say it's not practical unless there is cabal-install which is > able to https://. That's my point: there's no way for cabal-install to use TLS. The mask would be so users can make an informed decision as to whether to continue to use it. As it stands there might be people using it under the assumption it is secure.
(In reply to R030t1 from comment #3) > > That's my point: there's no way for cabal-install to use TLS. The mask would > be so users can make an informed decision as to whether to continue to use > it. As it stands there might be people using it under the assumption it is > secure. Uploads to Hackage aren't even secure, so the lack of a secure download method doesn't lose you much at the moment. This is a well-known bug in the Haskell ecosystem: https://www.haskell.org/pipermail/cabal-devel/2014-April/009739.html We have some practical reasons of our own. Like for example that the Haskell Platform depends on the cabal-install package. And, you're not supposed to use cabal-install to install packages anyway. Almost anything you can think of is in the overlay, and we're usually pretty quick to add new packages if you open an issue at https://github.com/gentoo-haskell/gentoo-haskell/issues.
> Uploads to Hackage aren't even secure, so the lack of a secure download > method doesn't lose you much at the moment. This is a well-known bug in the > Haskell ecosystem: > > https://www.haskell.org/pipermail/cabal-devel/2014-April/009739.html > Yes, this is also something that is touched upon in the bug I referenced and is also something that potential users should be made aware of. > We have some practical reasons of our own. Like for example that the Haskell > Platform depends on the cabal-install package. > Then the "Haskell Platform" would end up being uninstallable due to the mask on cabal-install until the mask was removed by the user. > And, you're not supposed to use cabal-install to install packages anyway. > Almost anything you can think of is in the overlay, and we're usually pretty > quick to add new packages if you open an issue at > https://github.com/gentoo-haskell/gentoo-haskell/issues. > I wasn't aware; a mask on cabal-install could have made me aware. I noticed some libraries were in portage but a great many are not - one's first instinct is to turn to the language's package manager.
(In reply to R030t1 from comment #5) > > Uploads to Hackage aren't even secure, so the lack of a secure download > > method doesn't lose you much at the moment. This is a well-known bug in the > > Haskell ecosystem: > > > > https://www.haskell.org/pipermail/cabal-devel/2014-April/009739.html > > > > Yes, this is also something that is touched upon in the bug I referenced and > is also something that potential users should be made aware of. > > > We have some practical reasons of our own. Like for example that the Haskell > > Platform depends on the cabal-install package. > > > > Then the "Haskell Platform" would end up being uninstallable due to the mask > on cabal-install until the mask was removed by the user. > I just think that's a bit extreme for this sort of issue. Will we be masking Firefox and Chrome as well? I'm not saying we should close it -- we can update this whenever some progress is made upstream. But I'm pleading "not it" to masking one of the more important platform utilities. I don't use it to install packages, but `cabal repl` and things like that come along with `cabal install`. > > And, you're not supposed to use cabal-install to install packages anyway. > > Almost anything you can think of is in the overlay, and we're usually pretty > > quick to add new packages if you open an issue at > > https://github.com/gentoo-haskell/gentoo-haskell/issues. > > > > I wasn't aware; a mask on cabal-install could have made me aware. I noticed > some libraries were in portage but a great many are not - one's first > instinct is to turn to the language's package manager. This is IMO a much better reason to mask cabal-install =)
My two cents; The suggested action is security hardening and not applicable for the Gentoo Security team as the use would be outside the ordinary expected use of the tree. There is no immediate vulnerability that would require a GLSA and the package is only stable for two arches; ppc and ppc64. Should we re-assign this to the haskell herd?
(In reply to Kristian Fiskerstrand from comment #7) > Should we re-assign this to the haskell herd? Yeah, haskell@ is a proper place for it.
Recently released Cabal-1.24 / cabal-install-1.24 got basic support for https:// URI. Masked ebuilds are currently available in ::haskell overlay but it will take a while upstreams to port their Setup.hs to Cabal-1.24.
