Is it possible to use OpenSSL and not BoringSSL?

[Guillaume Egles]

Guys,

We are trying to integrate the WebRTC libs into an existing product that relies upon OpenSSL. If I link with BoringSSL, our code as well as third-parties (Curl, SSH, etc) complains about a bunch of unresolved symbols. If I link against the OpenSSL libs, I get unresolved symbols in WebRTC.

I understand the move to BoringSSL, but is there any way for WebRTC to compile/link with the standard OpenSSL libs?

Thanks. G.

[Kaiduan Xie]

What OS do you use? I had build the latest webrtc with OpenSSL without issues.

/Kaiduan

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Guillaume Egles]

Thanks Kaiduan.

I am on Mac (Yosemite) but we eventually need to build cross platforms.

I am actually now able to build WebRTC against the OpenSSL libs, but I had to define "build_ssl=0" and modify a couple of gyp files (mostly base.gyp) to point to the external includes and libraries. Some unittest binaries are still not building properly as they now try to link with both BoringSSL and OpenSSL libs.......

I might have missed it, is there maybe an established/cleaner mechanism to tell the webrtc build to use an external impl of SSL (just setting ssl_root does not seem enough)?

Let me know if there is a better way.

Once compiling, I did face some runtime issue where suddenly the DTLS handshake would not work anymore. After investigation, it appears to be a known issue with webrtc and OpenSSL. See https://code.google.com/p/chromium/issues/detail?id=447431.

I was able to modify the "opensslstreamadapter.cc" with the suggested extra call to SSL_CTX_set_read_ahead(ctx, 1) and now things work again.

How did you deal with this? Is there any established patch out there?

Any help or feedback is much appreciated. Cheers. G.

[Kaiduan Xie]

I set use_openssl as 1 in src/build/common.gypi, and build_ssl as 0 in src/webrtc/build/common.gypi.

/Kaiduan

[Guillaume Egles]

Kaiduan,

Unless I am missing something here, I really don't think just setting build_ssl=0 and use_openssl=1 is enough to actually properly compile with OpenSSL.

For one, use_openssl is already set to 1 by default and is really a misnomer since it really means use_boringssl (as opposed to NSS).

The problem here is subtle. BoringSSL seems to be "code-compatible" with OpenSSL but not ABI compatible. After investigation, it turns out that OpenSSL relies heavily on MACRO functions in its header files whereas BoringSSL actually defines proper functions.

What happens is that one cannot compile using the BorringSSL headers and then try to link with the "-lssl -lcrypto" OpenSSL libs without seeing a lot of unresolved symbols.

From my experience, the only way to compile webrtc with the OpenSSL headers is to set ssl_root to point to the OpenSSL includes directory.

That actually works great, but the WebRTC build sadly stops there and does not allow you to specify to use the external OpenSSL libs instead of the BoringSSL.

Because of this, I can build all the WebRTC libs, but I have to disable all the executables (unittests and examples) ans they still try to link with boringssl at the end of the day.

Even with build_ssl=0 it still seem to build it because of the transitive dependency via usrsctp (still depending on boringssl and not subject to the build_ssl=0).

It really would not be too hard for them to tweak the build a bit to allow for that. I'll see if I can submit a patch or something.

 Hope this helps. Cheers. G.

[Kaiduan Xie]

Yes Guillaume, I forgot to mention I also disabled boringSSL in usrsctp.gyp.

On the platform I am working on, the above changes are enough for me to get it working because OpenSSL is provided by the platform, I do not need to add extra path for OpenSSL headers.

/Kaiduan

[Guillaume Egles]

So, to recap, here is what I had to do to get everything working with OpenSSL on mac (Yosemite):

1) Disable boringssl dependency in src/third_party/usrsctp/usrsctp.gyp:31:

      ['use_openssl==1', {
        'defines': [
          'SCTP_USE_OPENSSL_SHA1',
        ],
        'dependencies': [
#          '<(DEPTH)/third_party/boringssl/boringssl.gyp:boringssl',
        ],
      },

2) Apply the attached patch to base.gyp (in order to explicitly add the "-lssl -lcrypto" to dependent targets.

3) Compile using the GYP_DEFINES="build_ssl=0 ssl_root=/usr/local/Cellar/openssl/1.0.1l"

It would be great if the patches in  1 and 2 were not needed. ....

Should I file an issue? Or do you think they don't actually want people to do this (and force to use boringssl)?

Cheers. G.

[Haseeb Abdul Qadir]

I've successfully managed to build webrtc with OpenSSL without much modification. Before compiling webrtc, I replace src/chromium/src/third_party/boringssl/boringssl.gyp with my own gyp file. In that file I set 'link_settings' and 'libraries' to my own pre-build OpenSSL libraries. I also set include_dirs to point to the OpenSSL implementation. Here's an example:

{

      "variables": {

            "lib_dir": "../../../../../../.."

      },

      "targets": [

            {

                  "target_name": "boringssl",

                  "type": "none",

                  "direct_dependent_settings": {

                        "conditions": [

                              [

                                    'OS=="mac"',

                                    {

                                          "link_settings": {

                                                "libraries": [

                                                      "-L<(lib_dir)/mac",

                                                      "-lssl",

                                                      "-lcrypto"

                                                ]

                                          },

                                          "include_dirs": [

                                          "compat",

                                                "<(lib_dir)/src/openssl/include"

                                          ]

                                    }

                              ],

                        ]

                  }

            }

      ]

[Guillaume Egles]

Haseeb,

Thank you so much, your solution is much better!

By just tweaking it a bit (and setup_links.py to disable boringssl), I am now able to fully check in the patch into my webrtc fork with no need for manual tweaks after an update.

This is great and more elegant. Of course, not as elegant as if the WebRTC folks cared to provide a better config option to set openssl from the outside ;)

Thanks for sharing.

Cheers. G.

[William Cheung]

Hi,

I was wondering if anyone is still watching this post. I've been trying to build with my prebuilt copy of openssl instead of boringssl for the same reasons stated by Guillaume. However I am completely new to GYP and I'm building on Windows not Mac OS. I tried following Haseeb's instruction, I edited \src\third_party\boringssl\boringssl.gyp to look like the following.

{

  'variables':{

      'lib_dir':'C:\workspace\openssl-1.0.1m-src-32-build'

  },

  'targets': [

    {

      'target_name': 'boringssl',  

      'type': 'none',

 'direct_dependent_settings': {

          'conditions': [

              [

                 'OS=="win"',  

{

   'link_settings': {

              'libraries': [

             '-L<(lib_dir)\lib',

             '-lssl',

             '-lcrypto'

              ]

                    },

                   'include_dirs': [

                       'compat',

                       '<(lib_dir)\include',

                    ],

}

              ],

          ]

 },  

    },

  ],

}

I'm getting errors about missing the file 'ssl.lib'. Is this because libeay32.lib and ssleay32.lib cannot be found?

Any insight would be appreciated.

Thanks,

William

[Haseeb Abdul Qadir]

Hi,

Try changing this:

               'libraries': [

              '-L<(lib_dir)\lib',

              '-lssl',

              '-lcrypto'

to:

               'libraries': [

              '-L<(lib_dir)\lib',

              '-llibeay32',

              '-lssleay32'

-- 

--- 
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/muT4irg2dvI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/684e1806-0831-4d55-bb3b-4ee29475044a%40googlegroups.com.

[William Cheung]

Hi Haseeb,

I had to put the full path for each file like so and it works

'-lC:\workspace\openssl-1.0.1m-src-32-build\lib\libeay32.lib',

'-lC:\workspace\openssl-1.0.1m-src-32-build\lib\ssleay32.lib'

For some reason just the individual filename reference did not.

Which is weird because the include_dirs uses the same lib_dir path reference and the include files are found correctly.

Anyway it seems to be working now, so thanks!

[Eric Davies]

It looks like gyp doesn't understand absolute paths, just relative ones. Part of my job description seems to be swearing at google.

[Arik Halperin]

Did you by any chance try this on the latest version? I cannot get this to compile with latest.

Arik

[めたるおもち]

For iOS development to avoid this issue, I made build tools to generate framework (dynamic library).

I succeeded build iOS app dynamic links with webrtc framework which contains boringssl and static links openssl.

I did not test and run enough, but if my understanding is true, this approach will works.

Please try it.

https://github.com/omochi/webrtc-ios-build

2015年12月21日月曜日 14時21分47秒 UTC+9 Arik Halperin:

[William Cheung]

I'm still using the same method as described in my previous post without any issues.

[Dave Wang]

Hi Guys,

    The latest  version webrtc，how to settings.new version using .gn to build.

在 2015年3月1日星期日 UTC+8下午1:14:40，Guillaume Egles写道：

[deng.li...@gmail.com]

Use the follow cmd to gen ninja files for debug and boringssl will build as static library.
gn gen xxx/src/out/Debug --args='is_debug=true is_commponent_build=false'

在 2016年11月1日星期二 UTC+8上午9:32:03，Dave Wang写道：

[Alexander Widerberg]

Is it possible to exclude BoringSSL in favour of OpenSSL in M55 and onwards, with GN?

The reason for this is that more or less all third-party dependencies in applications will solely (more or less) require OpenSSL and NOT BoringSSL..

BoringSSL will thus cause lots of linker errors or runtime-errors in the form of EXEC_BAD_ACCESS.

Is there anyone that can shed some light upon this or are we dead in the water with WebRTC and OpenSSL?

[Sahil Youngs]

I'm also looking for a way to compile using OpenSSL in the new GN system.

I'm trying to use a different library which uses OpenSSL in conjunction with webRTC.

However, it's not running due to the conflicts in BoringSSL and OpenSSL.

[Eric Davies]

one thought I've had is: make a list of all the boringssl exported symbols, and then run something like a sed script to replace them in all the webrtc code with something prefixed to be different than their openssl counterparts. A bit brute force but completely orthogonal to the build system.

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/muT4irg2dvI/unsubscribe.

To unsubscribe from this group and all its topics, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/93da0522-b65b-426e-bbcc-cea7f2bb0d15%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Eric Davies

250 595-0639

[Sahil Youngs]

For what it's worth, I resolved my issues by compiling the other applications with boringSSL instead of openSSL.

However, that was only do-able with significant help from the other developer (since webRTC appears to be immovable currently)