Re: libelf now depends on openssl

2021-01-15 Thread Robbie Harwood 
"Colin Walters"  writes:

> On Fri, Jan 15, 2021, at 9:47 AM, Simo Sorce wrote:
>> 
>> There is of course no problem to have it in Fedora, but if this is
>> something that is going to end up in RHEL one day, it would be better
>> to do the work now to make it use OpenSSL rather than scramble later.
>
> Isn't it at least part of the purpose of Fedora ELN to detect
> situations like this earlier?  A dependency on boringssl in the Fedora
> "Everything" repositories is a distinct thing from it in ELN.

Part of the problem is that boringssl isn't a separate package - it
typically gets bundled.  (This causes mysterious failures because
boringssl stomps on the openssl names.)  So there wouldn't be a
dependency to detect.

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: libelf now depends on openssl

2021-01-15 Thread Simo Sorce 
On Fri, 2021-01-15 at 14:22 -0500, Colin Walters wrote:
> 
> On Fri, Jan 15, 2021, at 9:47 AM, Simo Sorce wrote:
> > There is of course no problem to have it in Fedora, but if this is
> > something that is going to end up in RHEL one day, it would be better
> > to do the work now to make it use OpenSSL rather than scramble later.
> 
> Isn't it at least part of the purpose of Fedora ELN to detect situations like 
> this earlier?  A dependency on boringssl in the Fedora "Everything" 
> repositories is a distinct thing from it in ELN.  If there was a change that 
> brought it into ELN, AFAIK the ELN builds wouldn't fail, presumably we'd want 
> to treat it as an important bug and possibly drive reverting the change in 
> "Everything" or so, right?
> 
> Similarly, we definitely would try really hard to avoid adding another crypto 
> library to Fedora CoreOS.
> 
> So I think the use of the bare term "Fedora" here isn't right.

At the moment the only impediment to add a crypto library in Fedora,
that I know of, is legal issues (like patents). The barrier is higher
in RHEL.

ELN and Fedora Core OS are still Fedora, so I leave it to the
maintainers and FESCO to decide if they want to add any rules or
restrictions to Fedora.

I would rather not see unbounded proliferation of crypto library, given
quality issues in those components are not merely bugs, they are often
serious CVE with potentially dire consequences (loss of key material or
other confidential information), but I am not signing up to be in the
Fedora Crypto police, I have enough on my hands as RHEL Crypto Police
:-D

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: libelf now depends on openssl

2021-01-15 Thread Colin Walters 


On Fri, Jan 15, 2021, at 9:47 AM, Simo Sorce wrote:
> 
> There is of course no problem to have it in Fedora, but if this is
> something that is going to end up in RHEL one day, it would be better
> to do the work now to make it use OpenSSL rather than scramble later.

Isn't it at least part of the purpose of Fedora ELN to detect situations like 
this earlier?  A dependency on boringssl in the Fedora "Everything" 
repositories is a distinct thing from it in ELN.  If there was a change that 
brought it into ELN, AFAIK the ELN builds wouldn't fail, presumably we'd want 
to treat it as an important bug and possibly drive reverting the change in 
"Everything" or so, right?

Similarly, we definitely would try really hard to avoid adding another crypto 
library to Fedora CoreOS.

So I think the use of the bare term "Fedora" here isn't right.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: libelf now depends on openssl

2021-01-15 Thread Simo Sorce 
On Fri, 2021-01-15 at 09:33 -0600, Michael Catanzaro wrote:
> On Fri, Jan 15, 2021 at 9:47 am, Simo Sorce  wrote:
> > Which is one of the reasons we do not admit boringssl in RHEL.
> > 
> > There is of course no problem to have it in Fedora, but if this is
> > something that is going to end up in RHEL one day, it would be better
> > to do the work now to make it use OpenSSL rather than scramble later.
> 
> It won't even wind up in Fedora since we need WebKit to remain 
> GPL-compatible. So WebRTC stays disabled until upstream finds a way to 
> get rid of boringssl. The plan is to switch from libwebrtc to GStreamer.
> 
> So not such a big deal for me right now, but might be a big deal for 
> anyone hoping to transition to openssl 3.0 anytime other than exactly 
> the same time debuginfod does.

The transition to openssl 3.0 may be a little bumpy for libraries
indeed, but there isn't much we can do about it. We'll definitely try
to minimize impact as much as possible.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: libelf now depends on openssl

2021-01-15 Thread Michael Catanzaro 


On Fri, Jan 15, 2021 at 9:47 am, Simo Sorce  wrote:

Which is one of the reasons we do not admit boringssl in RHEL.

There is of course no problem to have it in Fedora, but if this is
something that is going to end up in RHEL one day, it would be better
to do the work now to make it use OpenSSL rather than scramble later.


It won't even wind up in Fedora since we need WebKit to remain 
GPL-compatible. So WebRTC stays disabled until upstream finds a way to 
get rid of boringssl. The plan is to switch from libwebrtc to GStreamer.


So not such a big deal for me right now, but might be a big deal for 
anyone hoping to transition to openssl 3.0 anytime other than exactly 
the same time debuginfod does.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: libelf now depends on openssl

2021-01-15 Thread Simo Sorce 
On Fri, 2021-01-15 at 10:25 +0100, Florian Weimer wrote:
> * Zbigniew Jędrzejewski-Szmek:
> 
> > On Thu, Jan 14, 2021 at 08:24:03AM -0600, Michael Catanzaro wrote:
> > > On Thu, Jan 14, 2021 at 12:52 am, Kevin Kofler via devel
> > >  wrote:
> > > > Do the boringssl symbols not have hidden visibility in libwebrtc?
> > > > If they
> > > > do, why are they getting interposed anyway? If they don't, why
> > > > not? I assume
> > > > the library is private to libwebrtc and its symbols should not be
> > > > exported.
> > > 
> > > libwebrtc is a static lib, and so is boringssl. So all symbols,
> > > except unused symbols, will be directly included in libwebkit2gtk.
> > > In release builds, they would then be hidden by a linker script, but
> > > in developer builds everything is exported because API tests depend
> > > on internal symbols.
> > 
> > Would it be possible to get rid of boringssl? Having yet another
> > crypto library is ... bad.
> 
> Especially since it's not expected to be used outside of Google:
> 
> > BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
> > 
> > Although BoringSSL is an open source project, it is not intended for
> > general use, as OpenSSL is. We don't recommend that third parties
> > depend upon it.
> 
> 

Which is one of the reasons we do not admit boringssl in RHEL.

There is of course no problem to have it in Fedora, but if this is
something that is going to end up in RHEL one day, it would be better
to do the work now to make it use OpenSSL rather than scramble later.

HTH,
Simo.

> Thanks,
> Florian
> -- 
> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael 
> O'Neill
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: libelf now depends on openssl

2021-01-15 Thread Florian Weimer 
* Zbigniew Jędrzejewski-Szmek:

> On Thu, Jan 14, 2021 at 08:24:03AM -0600, Michael Catanzaro wrote:
>> On Thu, Jan 14, 2021 at 12:52 am, Kevin Kofler via devel
>>  wrote:
>> >Do the boringssl symbols not have hidden visibility in libwebrtc?
>> >If they
>> >do, why are they getting interposed anyway? If they don't, why
>> >not? I assume
>> >the library is private to libwebrtc and its symbols should not be
>> >exported.
>> 
>> libwebrtc is a static lib, and so is boringssl. So all symbols,
>> except unused symbols, will be directly included in libwebkit2gtk.
>> In release builds, they would then be hidden by a linker script, but
>> in developer builds everything is exported because API tests depend
>> on internal symbols.
>
> Would it be possible to get rid of boringssl? Having yet another
> crypto library is ... bad.

Especially since it's not expected to be used outside of Google:

| BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
| 
| Although BoringSSL is an open source project, it is not intended for
| general use, as OpenSSL is. We don't recommend that third parties
| depend upon it.



Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: libelf now depends on openssl

2021-01-15 Thread Zbigniew Jędrzejewski-Szmek 
On Thu, Jan 14, 2021 at 08:24:03AM -0600, Michael Catanzaro wrote:
> On Thu, Jan 14, 2021 at 12:52 am, Kevin Kofler via devel
>  wrote:
> >Do the boringssl symbols not have hidden visibility in libwebrtc?
> >If they
> >do, why are they getting interposed anyway? If they don't, why
> >not? I assume
> >the library is private to libwebrtc and its symbols should not be
> >exported.
> 
> libwebrtc is a static lib, and so is boringssl. So all symbols,
> except unused symbols, will be directly included in libwebkit2gtk.
> In release builds, they would then be hidden by a linker script, but
> in developer builds everything is exported because API tests depend
> on internal symbols.

Would it be possible to get rid of boringssl? Having yet another
crypto library is ... bad.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: libelf now depends on openssl

2021-01-14 Thread Michael Catanzaro 
On Thu, Jan 14, 2021 at 12:52 am, Kevin Kofler via devel 
 wrote:
Do the boringssl symbols not have hidden visibility in libwebrtc? If 
they
do, why are they getting interposed anyway? If they don't, why not? I 
assume
the library is private to libwebrtc and its symbols should not be 
exported.


libwebrtc is a static lib, and so is boringssl. So all symbols, except 
unused symbols, will be directly included in libwebkit2gtk. In release 
builds, they would then be hidden by a linker script, but in developer 
builds everything is exported because API tests depend on internal 
symbols.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: libelf now depends on openssl

2021-01-13 Thread Kevin Kofler via devel 
Michael Catanzaro wrote:
> I notice that WebKit, when built with WebRTC enabled, now crashes
> during the build:
> 
> https://bugs.webkit.org/show_bug.cgi?id=214812#c7
> 
> It's a symbol conflict between boringssl (used by libwebrtc) and
> openssl.

Do the boringssl symbols not have hidden visibility in libwebrtc? If they 
do, why are they getting interposed anyway? If they don't, why not? I assume 
the library is private to libwebrtc and its symbols should not be exported.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

libelf now depends on openssl

2021-01-13 Thread Michael Catanzaro 

Hi,

I notice that WebKit, when built with WebRTC enabled, now crashes 
during the build:


https://bugs.webkit.org/show_bug.cgi?id=214812#c7

It's a symbol conflict between boringssl (used by libwebrtc) and 
openssl. But why is openssl involved at all? It's a dependency of 
libcurl, which is a dependency of debuginfod, which apparently gets 
initialized by a library constructor of elfutils:


https://sourceware.org/git/?p=elfutils.git;a=blob;f=libdwfl/debuginfod-client.c;h=99b66b6eedf4a8a06024b2bb89da4824847fcd4d;hb=HEAD

So my first thought was: does elfutils get linked into... everything? 
It seems the answer is "no" because I can run /usr/bin/true under gdb, 
break on __libdwfl_debuginfod_init, and verify that it doesn't get 
called. Same for gnome-clocks. But when I try running nautilus under 
gdb, I find:


(gdb) break __libdwfl_debuginfod_init
..
(gdb) r
..
(gdb) bt
#0 0x7fffce58dda0 in __libdwfl_debuginfod_init () at 
/lib64/libdw.so.1

#1 0x77fe18ee in call_init
   (l=, argc=argc@entry=1, 
argv=argv@entry=0x7fffe168, env=env@entry=0x7fffe178)

   at dl-init.c:74
#2 0x77fe19d8 in call_init (env=0x7fffe178, 
argv=0x7fffe168, argc=1, l=)

   at dl-init.c:37
#3 _dl_init (main_map=0x55ab, argc=1, argv=0x7fffe168, 
env=0x7fffe178) at dl-init.c:121

#4 0x76e7a095 in __GI__dl_catch_exception
   (exception=, operate=, 
args=) at dl-error-skeleton.c:182
#5 0x77fe5e35 in dl_open_worker (a=0x7fffd840) at 
dl-open.c:783

#6 0x76e7a038 in __GI__dl_catch_exception
   (exception=0x7fffd820, operate=0x77fe5a50 , 
args=0x7fffd840)

   at dl-error-skeleton.c:208
#7 0x77fe566e in _dl_open
   (file=0x7fffd820 "\344\025\207UUU", mode=-2147483647, 
caller_dlopen=0x77064bff , nsid=-2, argc=1, 
argv=0x7fffe168, env=0x7fffe178) at dl-open.c:864
#8 0x7654439c in dlopen_doit (a=a@entry=0x7fffda70) at 
dlopen.c:66

#9 0x76e7a038 in __GI__dl_catch_exception
   (exception=exception@entry=0x7fffda10, operate=0x76544340 
, args=0x7fffda70)

   at dl-error-skeleton.c:208
#10 0x76e7a103 in __GI__dl_catch_error
   (objname=0x557789d0, errstring=0x557789d8, 
mallocedp=0x557789c8, operate=, args=out>) at dl-error-skeleton.c:227
#11 0x76544bd9 in _dlerror_run (operate=0x76544340 
, args=0x7fffda70) at dlerror.c:170
#12 0x76544428 in __dlopen (file=, 
mode=) at dlopen.c:87

#13 0x77064bff in g_module_open () at /lib64/libgmodule-2.0.so.0
#14 0x5561cfce in nautilus_module_load ()
#15 0x771e927b in g_type_module_use () at 
/lib64/libgobject-2.0.so.0

#16 0x5561e8e7 in nautilus_module_setup ()
#17 0x555ae75a in nautilus_application_startup_common ()
#18 0x771e2080 in g_signal_emit_valist () at 
/lib64/libgobject-2.0.so.0

#19 0x771e21a3 in g_signal_emit () at /lib64/libgobject-2.0.so.0
#20 0x772e61c9 in g_application_register () at 
/lib64/libgio-2.0.so.0
#21 0x772e689e in g_application_real_local_command_line () at 
/lib64/libgio-2.0.so.0

#22 0x772e6c46 in g_application_run () at /lib64/libgio-2.0.so.0
#23 0x555ab2be in main ()

What is nautilus dlopening?

#12 0x76544428 in __dlopen (file=, 
mode=) at dlopen.c:87
   args = {file = 0x55933ce0 
"/usr/lib64/nautilus/extensions-3.0/libtotem-properties-page.so", mode 
= 1, new = 0x3, caller = 0x77064bff 


And, yes:

$ ldd /usr/lib64/nautilus/extensions-3.0/libtotem-properties-page.so | 
grep elf

libelf.so.1 => /lib64/libelf.so.1 (0x7f6d4f17c000)

So not everything links to libelf, and only things that link to it are 
affected:


$ ldd /usr/lib64/libwebkit2gtk-4.0.so | grep elf
libelf.so.1 => /lib64/libelf.so.1 (0x7f159b53c000)

I guess it's being transitively pulled into these libs via... 
something... but I'm not sure via what.


Anyway, does debuginfod really need to always be initialized? Could it 
be loaded only when running under gdb, perhaps? If it's not truly 
needed, that would be the path of least resistance. Otherwise, I 
suspect openssl 1.2 -> openssl 3.0 may be a more difficult transition 
than expected.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org