[gentoo-user] Firefox depends on rust??

[Danny YUE]

Hi guys,

I just found during upgrading my system that Firefox 54.0 depends on
dev-lang/rust and cannot be disabled?!

It really takes a long time to compile rust, and I do not want to add
such a burden to my system compilation time.

Does anyone knows why? Any idea?

Thanks.

Danny

[Vadim A. Misbakh-Soloviov]

> Does anyone knows why? Any idea?

The reason is in that fact, that many of it's components are in rust.
And since it was possible to dodge it until now, maintainers considered it is
not a way since now.

And, by the way, it is not that many time to build rust, as you think:
> Thu Jun 22 12:34:00 2017 >>> dev-lang/rust-1.16.0
> merge time: 1 hour, 48 minutes.
Than was on 1.9GHz with hardly limited portage (MAKEOPTS="-j5 -l2",
NICENESS=18, ionice -c3, and cgroupped on cpu shares and ram).

So, ~20 mins would be enough on non-limited portage and full power of that i7.

[Rasmus Thomsen]

Hi,

since firefox 54 rust isn't optional anymore, you could use firefox 52 esr/firefox-bin (?) if you don't want to compile rust.

Regards,
Rasmus



-------- Original Message --------

[Danny YUE]

Thank you all for replying.

So it can be around 30~40 minutes or so on my i5 machine.
Just it feels strange to install something large that I would probably
never use myself.

I am considering using binary package instead of compiling it myself.

But I am afraid that using firefox-bin package would cause some
dependency problem. I once tried libreoffice-bin, but found it really
painful to resolve dependency issues during system upgrading.

Anyone tried firefox-bin smoothly?

Danny

[Rasmus Thomsen]

I'm using firefox-bin ( and libreoffice-bin ) on my laptop and I didn't have problems with either of them

Regards,
Rasmus
-------- Original Message --------

On 22 Jun 2017, 09:34, Danny YUE < shee...@gmail.com> wrote:

[Alexey Eschenko]

Last time I used libreoffice-bin and firefox-bin, first was really hard
to satisfy dependencies (I was needed some packages to downgrade to old
versions incompatible to other packages in my system). But with
firefox-bin a had no such problem.

But it was "last time".

--
Kind regards,
Alexey Eschenko
https://skobk.in/

[Danny YUE]

On 2017-06-22 07:43, Rasmus Thomsen <Rasmus....@protonmail.com> wrote:
> I'm using firefox-bin ( and libreoffice-bin ) on my laptop and I didn't have problems with either of them
>
> Regards,
> Rasmus
> -------- Original Message --------

> On 22 Jun 2017, 09:34, Danny YUE wrote:
>
> On 2017-06-22 07:23, Vadim A. Misbakh-Soloviov wrote:
>>> Does anyone knows why? Any idea?
>> The reason is in that fact, that many of it's components are in rust.
>> And since it was possible to dodge it until now, maintainers considered it is
>> not a way since now.
>>
>> And, by the way, it is not that many time to build rust, as you think:
>>> Thu Jun 22 12:34:00 2017 >>> dev-lang/rust-1.16.0
>>> merge time: 1 hour, 48 minutes.
>> Than was on 1.9GHz with hardly limited portage (MAKEOPTS="-j5 -l2",
>> NICENESS=18, ionice -c3, and cgroupped on cpu shares and ram).
>>
>> So, ~20 mins would be enough on non-limited portage and full power of that i7.
>
> Thank you all for replying.
>
> So it can be around 30~40 minutes or so on my i5 machine.
> Just it feels strange to install something large that I would probably
> never use myself.
>
> I am considering using binary package instead of compiling it myself.
>
> But I am afraid that using firefox-bin package would cause some
> dependency problem. I once tried libreoffice-bin, but found it really
> painful to resolve dependency issues during system upgrading.
>
> Anyone tried firefox-bin smoothly?
>
> Danny

> @mva.name>

Well, I ran into the same problem with libreoffice-bin *last time*, as
Alexey.

It seems that version number of libreoffice-bin is always smaller than
libreoffice. So dependency issue is always a problem with it.

I noticed firefox-bin only has *usual* packages as dependencies...
By the way what is the difference between compiled and binary firefox
from a user's perspective?

P.S. Someone told me that people in this list do not like top-posting.

Thanks.
Danny

[Alexey Eschenko]

For me it was a *slightly* less quicker start. Which I think don't means
much when speaking about browser.

[Danny YUE]

I agree.

Anyway I just start my Emacs and Firefox and keep them open until system
shutdown.

I just installed firefox-bin and did not feel any difference.

I will try to compile firefox just for curiosity.

Thank you all.

Danny

[Vadim A. Misbakh-Soloviov]

> >=dev-lang/rust-1.15.1 to >=dev-lang/rust-1.15.1-bin.
... to >=dev-lang/rust-bin-1.15.1

// fixed ;)

[Nils Freydank]

Hi,

Am Donnerstag, 22. Juni 2017, 09:13:24 CEST schrieb Danny YUE:
> Hi guys,
> I just found during upgrading my system that Firefox 54.0 depends on
> dev-lang/rust and cannot be disabled?!

as mentioned by others here FF 54 uses now some code written in Rust, so
USE="-rust" could not build the browser.

> It really takes a long time to compile rust, and I do not want to add
> such a burden to my system compilation time.
>
> Does anyone knows why? Any idea?
>
> Thanks.
>
> Danny

There is actually rust-bin in the tree - we just have to push our maintainers
a bit to use it =)

https://bugs.gentoo.org/show_bug.cgi?id=622136

I guess the best workaround for you would be copying the firefox ebuild from
tree to a local overlay[1], bumping it to -r1 and renaming the dependency
>=dev-lang/rust-1.15.1 to >=dev-lang/rust-1.15.1-bin.

If the compilations works fine & and the compiled firefox runs well a small
message plus the output of "emerge --info firefox rust" in the bugreport could
be useful aswell.


[1] https://wiki.gentoo.org/wiki/Ebuild_repository/Local_overlay

Hope that helps while waiting for a proper fix.

Greetings,
Nils

--
GPG fingerprint: '00EF D31F 1B60 D5DB ADB8 31C1 C0EC E696 0E54 475B'
Nils Freydank (proxy maintainer)
IRC: holgersson on freenode IRC servers
XMPP: nils [at] holgersson [dot] xyz

[Vadim A. Misbakh-Soloviov]

> I just installed firefox-bin and did not feel any difference.
>
> I will try to compile firefox just for curiosity.

Well. Only flags that can give you any difference is bindist (logos and so on),
pgo (hard-way optimization), custom-*, and system-* ones.

So, taking default "fx-bin" vs "fx" doesn't give you much difference.

Although, I myself distrust any "*-bin" packages, and I'd never run them
outside of `firejail` with blacklisted access to anywhere on the filesystem.

Although, I running even built-from-source firefox under firejail anyway (to
prevent java, js, drm and other crap to do anything on my system. even in home
dir.

[Nils Freydank]

Am Donnerstag, 22. Juni 2017, 13:33:33 CEST schrieb Vadim A. Misbakh-Soloviov:
> > >=dev-lang/rust-1.15.1 to >=dev-lang/rust-1.15.1-bin.
>
> ... to >=dev-lang/rust-bin-1.15.1
>

> // fixed ;) /* Thanks! */
err... thanks! =-D

[R0b0t1]

This is kind of troubling because much like Cabal it seems like the
Rust package management system is insecure. Does the Firefox build
process make use of it?

[Nils Freydank]

Am Donnerstag, 22. Juni 2017, 16:41:54 CEST schrieb R0b0t1:
> [other quote]

> This is kind of troubling because much like Cabal it seems like the
> Rust package management system is insecure. Does the Firefox build
> process make use of it?

Could you please specify what in your eyes is insecure in rust’s pm?

[R0b0t1]

I spent the most time looking at Cabal (Haskell's package manager) and
so as far as code-related specifics go I have the best references in
relation to it. I admit Rust may be different and that I haven't had a
great deal of time to look at it, but I have seen this pattern in a
few language-specific package managers to date.

The gist of it is that the package managers are typically designed to
download and run unsigned code as root. Releases are not signed and
code may be fetched over plain HTTP. This is something even Windows
doesn't let you do by default now.

My research on Rust's crate system reached a point a while ago where I
think I need a developer to chime in on it.

[Michael Orlitzky]

On 06/22/2017 10:41 AM, R0b0t1 wrote:
>
> This is kind of troubling because much like Cabal it seems like the
> Rust package management system is insecure. Does the Firefox build
> process make use of it?
>

It would be against our ebuild policy if it does so. The sources for a
package should be listed in SRC_URI and are downloaded and verified by
your Gentoo package manager. After that, network access is forbidden.

[R0b0t1]

You might be interested in this bug I submitted:
https://bugs.gentoo.org/show_bug.cgi?id=537162. While there's a lot of
packages in dev-haskell my use of GHC and Cabal showed me it was
impossible to prevent Cabal's maintenance scripts from running; those
scripts download and execute unsigned code. This seems to imply to me
that the entire language needs to be masked or removed from portage
until security is added upstream.

My personal take on both Rust and Haskell is I don't want to install
either of them on my main system even just to experiment with them
because they are so insecure. If someone can comment on the security
of Rust specifically that would be helpful.

[Michael Orlitzky]

On 06/22/2017 04:57 PM, R0b0t1 wrote:
>>
>> It would be against our ebuild policy if it does so. The sources for a
>> package should be listed in SRC_URI and are downloaded and verified by
>> your Gentoo package manager. After that, network access is forbidden.
>>
>
> You might be interested in this bug I submitted:
> https://bugs.gentoo.org/show_bug.cgi?id=537162.

I commented on that bug over two years ago =)

Don't use cabal-install to install packages. Stick to portage and you'll
be fine.

[Danny YUE]

Well, I finally compiled firefox and rust and used them.

Just...keep it the Gentoo way ;)

[R0b0t1]

I tried to reference that in my post. I tried to install the packages
that constitute the Haskell platform but cabal related utilities were
still firing off on their own.

[Michael Orlitzky]

On 06/23/2017 01:15 AM, R0b0t1 wrote:
>
> I tried to reference that in my post. I tried to install the packages
> that constitute the Haskell platform but cabal related utilities were
> still firing off on their own.
>

The dev-haskell/cabal libraries are used in the build system of most
haskell packages, but that portion is akin to the usual

./configure && make && make install

and doesn't access the network. It only builds the source code that has
already been downloaded by portage.

If you're worried about this stuff (and have network namespace support
built-in to your kernel), you can set FEATURES="network-sandbox" in your
make.conf to prevent ebuilds from accessing the network. Then if any
package tries to do something fishy, it will fail.

[R0b0t1]

On Fri, Jun 23, 2017 at 6:58 AM, Michael Orlitzky <m...@gentoo.org> wrote:
>
> If you're worried about this stuff (and have network namespace support
> built-in to your kernel), you can set FEATURES="network-sandbox" in your
> make.conf to prevent ebuilds from accessing the network. Then if any
> package tries to do something fishy, it will fail.
>

That's good to know, thanks!

[Sergei Trofimovich]

On Thu, 22 Jun 2017 15:57:34 -0500
R0b0t1 <r03...@gmail.com> wrote:

> You might be interested in this bug I submitted:
> https://bugs.gentoo.org/show_bug.cgi?id=537162. While there's a lot of
> packages in dev-haskell my use of GHC and Cabal showed me it was
> impossible to prevent Cabal's maintenance scripts from running; those
> scripts download and execute unsigned code. This seems to imply to me
> that the entire language needs to be masked or removed from portage
> until security is added upstream.

It seems to me you are conflating a few unrelated
things into a single statement. Let's split them one by one:

1. "it was impossible to prevent Cabal's maintenance scripts from running"

Please provide a few example packages from dev-haskell/*::gentoo
and example script file that you want to prevent from running and why.

I don't quite understand if you are talking about "Setup.hs" code or
something else.

2. "those scripts download and execute unsigned code"

Please provide a few examples from dev-haskell/*::gentoo that do that
as part of package build or installation process. So I would understand
why you see this problem as language- or ecosystem-specific and not
package specific.

3. "This seems to imply to me that the entire language needs to be masked

or removed from portage until security is added upstream."

I fail to see the connection of the language to the online package repository.

It seems you are implying you already have a mechanism to defend against
arbitrary code executed by ./configure or 'make' and those (shell and GNU make)
languages are fine. What is the difference?

--

Sergei

[Sergei Trofimovich]

On Sun, 25 Jun 2017 23:38:44 -0500
R0b0t1 <r03...@gmail.com> wrote:

> On Sun, Jun 25, 2017 at 7:13 AM, Sergei Trofimovich <sly...@gentoo.org> wrote:
> > On Thu, 22 Jun 2017 15:57:34 -0500
> > R0b0t1 <r03...@gmail.com> wrote:
> >
> >> You might be interested in this bug I submitted:
> >> https://bugs.gentoo.org/show_bug.cgi?id=537162. While there's a lot of
> >> packages in dev-haskell my use of GHC and Cabal showed me it was
> >> impossible to prevent Cabal's maintenance scripts from running; those
> >> scripts download and execute unsigned code. This seems to imply to me
> >> that the entire language needs to be masked or removed from portage
> >> until security is added upstream.
> >
> > It seems to me you are conflating a few unrelated
> > things into a single statement. Let's split them one by one:
> >
> > 1. "it was impossible to prevent Cabal's maintenance scripts from running"
> >
> > Please provide a few example packages from dev-haskell/*::gentoo
> > and example script file that you want to prevent from running and why.
> >
> > I don't quite understand if you are talking about "Setup.hs" code or
> > something else.
> >
>

> I mean that, to my knowledge, installing GHC and Cabal via Portage
> will still result in Cabal fetching something - I assume packages or
> an update of some kind - on its own. I need to try again using the
> option Michael mentioned. Unless something was updated fairly recently
> I honestly expect it to fail.

It never was the case.

> > 2. "those scripts download and execute unsigned code"
> >
> > Please provide a few examples from dev-haskell/*::gentoo that do that
> > as part of package build or installation process. So I would understand
> > why you see this problem as language- or ecosystem-specific and not
> > package specific.
> >
>

> I might later, but if you look at the bug you will see one of the
> developers agree with me. I'm pretty sure it is the code in Setup.hs.
> My memory tells me the dev-haskell packages are "safe" but my usage of
> Haskell on Gentoo in the past led to Cabal somehow being run despite
> how many things I manually selected in Portage to avoid running Cabal.

Code in Setup.hs downloading stuff from internet is not much more frequent
than on autotools packages. Of all the 1500 packages in ::haskell overlay
I can remember maybe 3 of them. I have FEATURES=network-sandbox enabled.

> > 3. "This seems to imply to me that the entire language needs to be masked
> > or removed from portage until security is added upstream."
> >
> > I fail to see the connection of the language to the online package repository.
> >
> > It seems you are implying you already have a mechanism to defend against
> > arbitrary code executed by ./configure or 'make' and those (shell and GNU make)
> > languages are fine. What is the difference?
> >
>

> New programming languages tend to be very closely entwined with their
> own package manager. Haskell is no different. Unless things have
> changed it's nearly impossible to use Haskell without Cabal. The last
> time I experimented with it on Linux (slightly less than a year ago?)
> Cabal would somehow be run by trying to install packages when I did
> not explicitly invoke it.

Sound scary. What precisely did you do?

> Autotools isn't a package manager. Autotools is run after you have
> downloaded and verified the source code. Autotools scripts could fetch
> things themselves, but they usually don't and I don't know of a single
> project that employs them in that way. If they did and the downloads
> were not verified I would have a similar complaint as this one.
>
> The part that confused me the most was that I needed Cabal to be
> installed even if I just wanted to get the Haskell platform to get
> along with the dev-haskell packages installed through portage.

I think you are mixing up two things:
build system (Cabal library) and package manger (cabal tool):

dev-haskell/cabal
Description: A framework for packaging Haskell software

dev-haskell/cabal-install
Description: The command-line interface for Cabal and Hackage

Build system (aka Cabal) is used in every haskell package. It has no
special support to download packages from internet. It is not a package
manager.

It's typical usage is:
- you download the package from internet yourself
- verify it however you want
- run 'runhaskell Setup.hs configure'
- run 'runhaskell Setup.hs build'
- run 'runhaskell Setup.hs install'

This process only verifies existing dependencies and builds needed
files locally. Unless you yourself put the arbitrary code in Setup.hs.

Package manager (aka cabal tool) talks to the internet.
It's precise function is: download package index from hackage server,
fetch all the dependencies from hackage server and use Cabal library
to build a haskell package.

You can configure it not to use hackage sevrer and use a local mirror
on your filesystem if you want.

Gentoo haskell packages happen not to use 'cabal tool' at all
at package's build process.

--

Sergei