Bug 173676 – Update boringssl to c8ff30cbe716c72279a6f6a9d7d7d0d4091220fa

• Component: Media
• Status: RESOLVED FIXED

[youenn fablet]

Refresh boringssl to c8ff30cbe716c72279a6f6a9d7d7d0d4091220fa

[youenn fablet]

Created attachment 313560 [details]
Patch

[youenn fablet]

Created attachment 313635 [details]
Patch

[youenn fablet]

Created attachment 313637 [details]
Patch

[youenn fablet]

Created attachment 313655 [details]
Patch

[youenn fablet]

Created attachment 313657 [details]
Patch

[Alex Christensen]

Comment on attachment 313657 [details]
Patch

Fix the ChangeLog
Make sure it compiles on x86_64, arm64, and armv7

[youenn fablet]

Created attachment 313757 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 313757 [details]
Patch

Rejecting attachment 313757 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-03', 'land-attachment', '--force-clean', '--non-interactive', '--parent-command=commit-queue', 313757, '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit

Last 500 characters of output:
ing rebase:
:040000 040000 63761c0b2fd6e461ca4c24ada885447d550ccbb4 745241f159b2d81b369356f58bbebb1b784c7dd3 M	Source
Current branch master is up to date.
ERROR: Not all changes have been committed into SVN, however the committed
ones (if any) seem to be successfully integrated into the working tree.
Please see the above messages for details.


Failed to run "['git', 'svn', 'dcommit', '--rmdir']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit
Updating OpenSource
Current branch master is up to date.

Full output: http://webkit-queues.webkit.org/results/3990916

[Alex Christensen]

https://trac.webkit.org/changeset/218850/webkit

[Michael Catanzaro]

You know, this is bad. Having an alternate TLS stack is bad. Wouldn't the relevant TLS developers at Apple be pretty disappointed to discover that WebKit has started to bundle boringssl? To enable WebRTC for Igalia's ports, we're going to have to strip all of this out.

It's not a problem for Chromium, because boringssl is their usual TLS stack. This allows circumventing whatever usual platform-specific configuration you allow. And it could result in TLS connections to the same server possibly not working, or working differently or with different security properties, depending on whether the connection is via WebRTC.

[Alejandro G. Castro]

Ideally we will like to strip this out in the future, but for the current development branch we have updating boringssl was in the TODO, so this is good news because it gets us closer to master and we can forget about the patch. I'll test it this week and check if we can start sending patches upstream, thanks.

https://github.com/alexgcastro/webkit/commit/6dd565aa8122eaf9eb69755d9fdbf8d9f58bae71

[youenn fablet]

It makes sense to use system boringssl if available with all necessary features.
For other systems, checked-in boringssl source code might be helpful especially since it is planned to be synced with libwebrtc.

Agreed that it is bloating the repository.
As soon as nobody is using it anymore, it will be great to remove it from the repo.

[Alex Christensen]

I agree that it is bad to have boringssl in WebKit, and we plan to remove it as soon as we can.  Unfortunately, that will be a while.

[youenn fablet]

> Having an alternate TLS stack is bad.

Right. That said, WebRTC prefers DTLS usually.

[Michael Catanzaro]

(In reply to youenn fablet from comment #14) 
> Right. That said, WebRTC prefers DTLS usually.

FWIW: our TLS stack supports DTLS in addition to normal TLS.

[Michael Catanzaro]

(In reply to youenn fablet from comment #12)
> It makes sense to use system boringssl if available with all necessary
> features.

I don't think boringssl is a system library on any platform, unless I'm much mistaken.