[gentoo-user] electron and sslv3

[gentoo-user] electron and sslv3

[Damo Brisbane]

[-- Attachment #1: Type: text/plain, Size: 2344 bytes --]

Hello,

I am having troubles installing dev-util/electron, related to linking in
"ssl3" in the final step of the ebuild, from build log:

/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
cannot find -lssl3


FYI on ssl, I only want a "working/current" ssl and/or tls installation and
I don't care for the details around the installation other than I would
like - as much as possible - "ssl" to be future proof and compatible with
current and new installs; in this case I just want electron, and I can't
install the package because of this linking error. I can successfully build
by hacking the final link step and simply remove the reference to "-lssl",
below:


> cd
$PORTAGE_TMPDIR/dev-util/electron-1.3.13-r1/work/chromium-52.0.2743.82/out/R
> x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--a
....obj/atom/app/electron.atom_main.o  obj/libelectron_lib.a
o... lib/libnode.so lib/libv8.so -lz -lhttp_parser -lssl -lcrypto -


and compiles fine.

There are no "ssl" use flags on electron?:

my build:

[ebuild  N    ~] dev-util/electron-1.3.13-r1  USE="proprietary-codecs
system-ffmpeg tcmalloc -cups -custom-cflags -gnome -gnome-keyring -hidpi
-kerberos -lto (-neon) -pic -pulseaudio (-selinux) {-test}" L10N="en-GB"


from https://packages.gentoo.org/packages/dev-util/electron:

LOCAL USE FLAGS


   - hidpi <https://packages.gentoo.org/useflags/hidpi>
   - lto <https://packages.gentoo.org/useflags/lto>
   - pic <https://packages.gentoo.org/useflags/pic>
   - proprietary-codecs
   <https://packages.gentoo.org/useflags/proprietary-codecs>
   - system-ffmpeg <https://packages.gentoo.org/useflags/system-ffmpeg>
   - tcmalloc <https://packages.gentoo.org/useflags/tcmalloc>



FYI, this is state of ssl on my machine:

*  dev-libs/openssl
      Latest version available: 1.0.2l
      Latest version installed: 1.0.2l

*  dev-perl/IO-Socket-SSL
      Latest version available: 2.24.0
      Latest version installed: 2.24.0

*  dev-perl/Net-SMTP-SSL
      Latest version available: 1.30.0
      Latest version installed: 1.30.0

*  dev-perl/Net-SSLeay
      Latest version available: 1.810.0
      Latest version installed: 1.810.0

*  net-libs/gnutls
      Latest version available: 3.5.13
      Latest version installed: 3.5.13


Any help on how to successfully compile and install electron would be much
appreciated.

[-- Attachment #2: Type: text/html, Size: 6472 bytes --]

Re: [gentoo-user] electron and sslv3

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]

On Sat, Sep 2, 2017 at 6:26 AM, Damo Brisbane <dhatchett2@gmail.com> wrote:

> Hello,
>
> I am having troubles installing dev-util/electron, related to linking in
> "ssl3" in the final step of the ebuild, from build log:
>
> /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
> cannot find -lssl3
>
>
> FYI on ssl, I only want a "working/current" ssl and/or tls installation
> and I don't care for the details around the installation other than I would
> like - as much as possible - "ssl" to be future proof and compatible with
> current and new installs; in this case I just want electron, and I can't
> install the package because of this linking error. I can successfully build
> by hacking the final link step and simply remove the reference to "-lssl",
> below:
>
>
> > cd $PORTAGE_TMPDIR/dev-util/electron-1.3.13-r1/work/
> chromium-52.0.2743.82/out/R
> > x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--a ....obj/atom/app/electron.
> atom_main.o  obj/libelectron_lib.a o... lib/libnode.so lib/libv8.so -lz
> -lhttp_parser -lssl -lcrypto -
>
>
> and compiles fine.
>
> There are no "ssl" use flags on electron?:
>

My first guess would be that your openssl is not compiled with sslv3. The
ebuild for electron only asks for >=dev-libs/openssl-1.0.2g:0=[-bindist]
not openssl[sslv3]. If that's the problem then there's a bug in electrons
ebuild.

What does emerge -pv openssl show for use flags?

However, ssl is pretty much deprecated these days due to security issues,
so unless you have a need to support something that cant do TLS, you're
better off leaving it out. Another issue may be that -lssl may be a loose
term for SSL+TLS...

[-- Attachment #2: Type: text/html, Size: 2707 bytes --]

Re: [gentoo-user] electron and sslv3

[Damo Brisbane]

[-- Attachment #1: Type: text/plain, Size: 2252 bytes --]

Emerge -pv openssl:

[ebuild   R    ] dev-libs/openssl-1.0.2l::gentoo  USE="asm sslv3
tls-heartbeat zlib -bindist -gmp -kerberos -rfc3779 -sctp -sslv2
-static-libs {-test} -vanilla"...

I figured ssl better off without it; I think the issue with this package is
it builds it's own version of chromium as part of the emerge, and I think
this is where the ssl dependency comes in. Right though, I think package
maintainer is where I need to head to next.

Thanks

On Sat, Sep 2, 2017 at 11:40 AM, Adam Carter <adamcarter3@gmail.com> wrote:

> On Sat, Sep 2, 2017 at 6:26 AM, Damo Brisbane <dhatchett2@gmail.com>
> wrote:
>
>> Hello,
>>
>> I am having troubles installing dev-util/electron, related to linking in
>> "ssl3" in the final step of the ebuild, from build log:
>>
>> /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
>> cannot find -lssl3
>>
>>
>> FYI on ssl, I only want a "working/current" ssl and/or tls installation
>> and I don't care for the details around the installation other than I would
>> like - as much as possible - "ssl" to be future proof and compatible with
>> current and new installs; in this case I just want electron, and I can't
>> install the package because of this linking error. I can successfully build
>> by hacking the final link step and simply remove the reference to "-lssl",
>> below:
>>
>>
>> > cd $PORTAGE_TMPDIR/dev-util/electron-1.3.13-r1/work/chromium-
>> 52.0.2743.82/out/R
>> > x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--a ....obj/atom/app/electron.atom_main.o  obj/libelectron_lib.a
>> o... lib/libnode.so lib/libv8.so -lz -lhttp_parser -lssl -lcrypto -
>>
>>
>> and compiles fine.
>>
>> There are no "ssl" use flags on electron?:
>>
>
> My first guess would be that your openssl is not compiled with sslv3. The
> ebuild for electron only asks for >=dev-libs/openssl-1.0.2g:0=[-bindist]
> not openssl[sslv3]. If that's the problem then there's a bug in electrons
> ebuild.
>
> What does emerge -pv openssl show for use flags?
>
> However, ssl is pretty much deprecated these days due to security issues,
> so unless you have a need to support something that cant do TLS, you're
> better off leaving it out. Another issue may be that -lssl may be a loose
> term for SSL+TLS...
>

[-- Attachment #2: Type: text/html, Size: 3669 bytes --]

Re: [gentoo-user] electron and sslv3

[Damo Brisbane]

[-- Attachment #1: Type: text/plain, Size: 3398 bytes --]

FYI this info and use flags worked for me to get a clean *electron* build
(with also getting eg *nodejs *dependency). I think also works for
chromium. I doubt "static-libs" is making any difference:

*/etc/portage>* emerge --info electron

dev-libs/openssl-1.0.2l::gentoo was built with the following:
USE="asm sslv2 sslv3 static-libs tls-heartbeat zlib -bindist -gmp -kerberos
-rfc3779 -sctp -test -vanilla"

*/etc/portage>* emerge --info electron

dev-libs/openssl-1.0.2l::gentoo was built with the following:
USE="asm sslv2 sslv3 static-libs tls-heartbeat zlib -bindist -gmp -kerberos
-rfc3779 -sctp -test -vanilla"

*/etc/portage>* egrep -r "(ssl|electron|nodejs)" pack*

package.accept_keywords:>=dev-libs/openssl-1.0.2l ~amd64
package.accept_keywords:=dev-util/electron-1.3.13-r1 ~amd64

package.mask/mask:=dev-libs/openssl-1.0.1
package.mask/mask:=dev-libs/openssl-1.0.2g
package.mask/mask:=dev-libs/openssl-1.1.0f
package.use/use:>=dev-libs/openssl-1.0.2l ssl sslv2 sslv3 static-libs


On Mon, Sep 4, 2017 at 4:23 PM, Damo Brisbane <dhatchett2@gmail.com> wrote:

> Emerge -pv openssl:
>
> [ebuild   R    ] dev-libs/openssl-1.0.2l::gentoo  USE="asm sslv3
> tls-heartbeat zlib -bindist -gmp -kerberos -rfc3779 -sctp -sslv2
> -static-libs {-test} -vanilla"...
>
> I figured ssl better off without it; I think the issue with this package
> is it builds it's own version of chromium as part of the emerge, and I
> think this is where the ssl dependency comes in. Right though, I think
> package maintainer is where I need to head to next.
>
> Thanks
>
> On Sat, Sep 2, 2017 at 11:40 AM, Adam Carter <adamcarter3@gmail.com>
> wrote:
>
>> On Sat, Sep 2, 2017 at 6:26 AM, Damo Brisbane <dhatchett2@gmail.com>
>> wrote:
>>
>>> Hello,
>>>
>>> I am having troubles installing dev-util/electron, related to linking in
>>> "ssl3" in the final step of the ebuild, from build log:
>>>
>>> /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
>>> cannot find -lssl3
>>>
>>>
>>> FYI on ssl, I only want a "working/current" ssl and/or tls installation
>>> and I don't care for the details around the installation other than I would
>>> like - as much as possible - "ssl" to be future proof and compatible with
>>> current and new installs; in this case I just want electron, and I can't
>>> install the package because of this linking error. I can successfully build
>>> by hacking the final link step and simply remove the reference to "-lssl",
>>> below:
>>>
>>>
>>> > cd $PORTAGE_TMPDIR/dev-util/electron-1.3.13-r1/work/chromium-52
>>> .0.2743.82/out/R
>>> > x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--a ....obj/atom/app/electron.atom_main.o  obj/libelectron_lib.a
>>> o... lib/libnode.so lib/libv8.so -lz -lhttp_parser -lssl -lcrypto -
>>>
>>>
>>> and compiles fine.
>>>
>>> There are no "ssl" use flags on electron?:
>>>
>>
>> My first guess would be that your openssl is not compiled with sslv3. The
>> ebuild for electron only asks for >=dev-libs/openssl-1.0.2g:0=[-bindist]
>> not openssl[sslv3]. If that's the problem then there's a bug in electrons
>> ebuild.
>>
>> What does emerge -pv openssl show for use flags?
>>
>> However, ssl is pretty much deprecated these days due to security issues,
>> so unless you have a need to support something that cant do TLS, you're
>> better off leaving it out. Another issue may be that -lssl may be a loose
>> term for SSL+TLS...
>>
>
>

[-- Attachment #2: Type: text/html, Size: 5463 bytes --]