| Summary: | Update boringssl to c8ff30cbe716c72279a6f6a9d7d7d0d4091220fa | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | youenn fablet <youennf> | ||||||||||||||
| Component: | Media | Assignee: | youenn fablet <youennf> | ||||||||||||||
| Status: | RESOLVED FIXED | ||||||||||||||||
| Severity: | Normal | CC: | achristensen, alex, commit-queue, eric.carlson, mcatanzaro | ||||||||||||||
| Priority: | P2 | ||||||||||||||||
| Version: | WebKit Nightly Build | ||||||||||||||||
| Hardware: | Unspecified | ||||||||||||||||
| OS: | Unspecified | ||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
youenn fablet
2017-06-21 16:10:17 PDT
Created attachment 313560 [details]
Patch
Created attachment 313635 [details]
Patch
Created attachment 313637 [details]
Patch
Created attachment 313655 [details]
Patch
Created attachment 313657 [details]
Patch
Comment on attachment 313657 [details]
Patch
Fix the ChangeLog
Make sure it compiles on x86_64, arm64, and armv7
Created attachment 313757 [details]
Patch
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 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. 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 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. 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. > Having an alternate TLS stack is bad.
Right. That said, WebRTC prefers DTLS usually.
(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. (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. |