[webkit-dev] New EWS Non-Unified builder

[dpino via webkit-dev]

Hi everyone,

In Igalia we have been discussing the need of deploying a new builder
which builds WebKit using non-unified sources, and we know that at least
the folks at Sony are also in favor.

One side effect of Unified Source building is that it hides compilation
errors. The kinds of errors that usually get hidden by unified builds
are missing headers inclusions and missing definitions of functions
declared inline; the latter being tricky to debug because it results in
mysterious linker errors. This is caused by unified builds stashing
several .cpp files together for compilation, so the definitions and
header inclusions done in one “leak” into the others. As for missing
header inclusion errors, a source file might include a header definition
as a co-lateral effect of being stashed together with another file that
indeed includes the missing header.

These hidden compilation errors may arise later at some point if unified
source files are stashed together in a different manner.

The current situation is requiring periodical maintenance. You can check
build fixes commits due to unified source compilation with:

$ git log --pretty=short --grep "Non-unified"

Here are some examples:
https://bugs.webkit.org/show_bug.cgi?id=222652
https://bugs.webkit.org/show_bug.cgi?id=222755
https://bugs.webkit.org/show_bug.cgi?id=221701

A new builder which builds WebKit with non-unified Source will highly
help to improve this situation. Compilation errors will be detected as
soon as possible and will save a lot of time not only for the developers
who are currently doing this manual maintenance but for anyone who would
like to build WebKit, and may stumble on compilation errors accidentally
introduced due to unified sources.

While correct compilation of the codebase can only be guaranteed with
non-unified source builds, we do not propose switching the current EWS
compilation builders to non-unified because it's slower and the EWS
LayoutTests and API test bots use the products built by the EWS builders
— we do not want to delay getting results from those. That's why we are
proposing a new builder: it will run on parallel, resulting in no
slowdown for the other EWS builders, which will keep using unified
builds.

How this new builder will impact developers? The EWS LayoutTest bots
take at least 1 hour to complete a build. We think that as long as this
new EWS Non-Unified builder is within that time budget, this new EWS
wont' slow down development speed.

Thoughts?

Best regards,

Diego
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position: Removing 3DES from TLS

[Alex Christensen via webkit-dev]

They are aware of this thread now, but I can’t comment on any future plans.  I 
do have a few quick questions, though. 

A quick glance at the client hellos sent by browsers shows this:
Safari on Big Sur sends TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008) and 
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) in its supported cipher suites 
section of the client hello.
Firefox 88 sends TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Chrome 90 sends no cipher suites with 3DES.

This might be why Chrome measures 0.00% use of TLS_RSA_WITH_3DES_EDE_CBC_SHA - 
because it doesn’t advertise that it supports it.  It seems to me that you’ve 
already removed support for 3DES in Chrome.  What was the measured use of 3DES 
cipher suites in the release before you removed support?  We have measured 
slightly above 0.00% use in a browser that does send 3DES cipher suites in its 
client hellos.

If you haven’t already removed support, how would one use it?  I’ll admit I 
haven’t gone through all the possibilities of renegotiation that TLS has.

> On Apr 28, 2021, at 8:21 AM, Alex Christensen via webkit-dev 
>  wrote:
> 
> Your measurement of 0.00% use in Chrome is exciting.
> 
> Making this change would almost certainly not be a change in WebKit but I’ve 
> reached out to the people who manage our crypto code.
> 
>> On Apr 28, 2021, at 7:14 AM, Michael Catanzaro via webkit-dev 
>>  wrote:
>> 
>> 
>> Looks like this change is clearly safe.
>> 
>> I doubt Safari controls its own TLS ciphersuite settings. In WebKitGTK, 
>> they're controlled by the operating system's TLS backend and crypto policy. 
>> 3DES has been disabled for a while now on modern systems, and users have not 
>> reported any compat issues, which is not surprising given your finding of 
>> 0.00%.
>> 
>> Michael
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] New EWS queue: Stress Test EWS

[Alexey Proskuryakov via webkit-dev]

Hi,

This issue is tracked as https://bugs.webkit.org/show_bug.cgi?id=225126 


- Alexey

> 28 апр. 2021 г., в 3:23 AM, Manuel Rego Casasnovas via webkit-dev 
>  написал(а):
> 
> Hi,
> 
> The stress test EWS has some issue when dealing with testharness.js tests.
> 
> Every now and then it thinks it's a different type of test and it dumps
> the layout tree, and it fails as the actual result has nothing to do
> with a layout tree dump.
> 
> Actually it dumps an empty layout tree:
> layer at (0,0) size 800x600
>   RenderView at (0,0) size 800x600
> layer at (0,0) size 800x600
>   RenderBlock {HTML} at (0,0) size 800x600
> RenderBody {BODY} at (8,8) size 784x584
> 
> Last example I've seen:
> https://ews-build.webkit.org/#/builders/62/builds/1903
> 
> I guess there might be some timing issue or something like that, as it
> looks like it doesn't even load the test properly before comparing the
> results.
> 
> Cheers,
>  Rego
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position: Removing 3DES from TLS

[Alex Christensen via webkit-dev]

Your measurement of 0.00% use in Chrome is exciting.

Making this change would almost certainly not be a change in WebKit but I’ve 
reached out to the people who manage our crypto code.

> On Apr 28, 2021, at 7:14 AM, Michael Catanzaro via webkit-dev 
>  wrote:
> 
> 
> Looks like this change is clearly safe.
> 
> I doubt Safari controls its own TLS ciphersuite settings. In WebKitGTK, 
> they're controlled by the operating system's TLS backend and crypto policy. 
> 3DES has been disabled for a while now on modern systems, and users have not 
> reported any compat issues, which is not surprising given your finding of 
> 0.00%.
> 
> Michael
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Detecting and handling unresponsive web processes

[Michael Catanzaro via webkit-dev]

On Wed, Apr 28 2021 at 04:14:16 PM +0200, Miguel Gomez via webkit-dev 
 wrote:

But if we give the option to disable this behavior, then we need to
provide a way for the apps to handle the situation, don't you think?
And this means adding new API (being it the one to retrieve the 
process

ID or the one to kill the web content process directly).


Would an application ever want to do something to handle the situation 
other than load a new page? Perhaps you would want to use 
webkit_web_view_load_alternate_html() to display an error page, for 
example.


An API to allow killing the process is only needed if the application 
wants to do something when the process is killed *without* loading a 
new page, yes?



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Detecting and handling unresponsive web processes

[Miguel Gomez via webkit-dev]

On Wed, 2021-04-28 at 13:11 +, Michael Catanzaro wrote:
> On Tue, Apr 27 2021 at 10:18:04 AM +0200, Miguel Gomez via webkit-dev
>  wrote:
> > * Have some API method that allows to kill the problematic web 
> > process,
> > and let the browser call it when needed. The next load will create
> > a
> > new web process.
> 
> We only need this API if we are unable to fix the existing 
> webkit_web_view_load_* APIs to work when the web process is 
> unresponsive, right? So we probably do not need it.

Right. If we adapt the load APIs to handle the situation we don't need
any new API.

> > * Modify some of the existent load/reload API calls so they check
> > whether the web process is responsive or not. If it's unresponsive,
> > kill the process before trying to do anything else, and a new web
> > process will be created when the rest of the code is executed.
> 
> This behavior is a better default for most client applications.

It's easier for them for sure, as they don't have to do anything
special other than reload the page or load a new one.
 
> Applications that want more control would just need a way to disable 
> this behavior, right?

But if we give the option to disable this behavior, then we need to
provide a way for the apps to handle the situation, don't you think?
And this means adding new API (being it the one to retrieve the process
ID or the one to kill the web content process directly). 

-- 
Miguel Gomez
Igalia - www.igalia.com

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position: Removing 3DES from TLS

[Michael Catanzaro via webkit-dev]

Looks like this change is clearly safe.

I doubt Safari controls its own TLS ciphersuite settings. In WebKitGTK, 
they're controlled by the operating system's TLS backend and crypto 
policy. 3DES has been disabled for a while now on modern systems, and 
users have not reported any compat issues, which is not surprising 
given your finding of 0.00%.


Michael


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Request for position: Removing 3DES from TLS

[David Benjamin via webkit-dev]

Hello WebKit friends,

We're looking at dropping 3DES cipher suites from TLS. For us, this is
just TLS_RSA_WITH_3DES_EDE_CBC_SHA.
Looks like Safari additionally supports TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
and TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, which would also fall under that
category.

After TLS 1.0 and 1.1 were removed, our metrics report a whole 0.00% of TLS
connections using TLS_RSA_WITH_3DES_EDE_CBC_SHA. (And, of course, no sites
use the other two in Chrome, since we don't support them in the first
place.)

For additionally background and motivation, see the blink-dev posting here.
https://groups.google.com/a/chromium.org/g/blink-dev/c/RShdgyaDoX4/m/JikQYHPuBQAJ

David
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Detecting and handling unresponsive web processes

[Michael Catanzaro via webkit-dev]

On Tue, Apr 27 2021 at 10:18:04 AM +0200, Miguel Gomez via webkit-dev 
 wrote:
* Have some API method that allows to kill the problematic web 
process,

and let the browser call it when needed. The next load will create a
new web process.


We only need this API if we are unable to fix the existing 
webkit_web_view_load_* APIs to work when the web process is 
unresponsive, right? So we probably do not need it.



* Modify some of the existent load/reload API calls so they check
whether the web process is responsive or not. If it's unresponsive,
kill the process before trying to do anything else, and a new web
process will be created when the rest of the code is executed.


This behavior is a better default for most client applications. 
Applications that want more control would just need a way to disable 
this behavior, right?



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] New EWS queue: Stress Test EWS

[Manuel Rego Casasnovas via webkit-dev]

Hi,

The stress test EWS has some issue when dealing with testharness.js tests.

Every now and then it thinks it's a different type of test and it dumps
the layout tree, and it fails as the actual result has nothing to do
with a layout tree dump.

Actually it dumps an empty layout tree:
 layer at (0,0) size 800x600
   RenderView at (0,0) size 800x600
 layer at (0,0) size 800x600
   RenderBlock {HTML} at (0,0) size 800x600
 RenderBody {BODY} at (8,8) size 784x584

Last example I've seen:
https://ews-build.webkit.org/#/builders/62/builds/1903

I guess there might be some timing issue or something like that, as it
looks like it doesn't even load the test properly before comparing the
results.

Cheers,
  Rego
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Mailman web interface missing

[Adrian Perez de Castro via webkit-dev]

On Mon, 26 Apr 2021 13:07:47 -0700 Darin Adler  wrote:
> > On Apr 26, 2021, at 1:03 PM, Adrian Perez de Castro via webkit-dev 
> >  wrote:
> > 
> > - https://lists.webkit.org/listinfo/webkit-wpe/ results in “Not Found”
> > - https://lists.webkit.org/admindb/webkit-wpe/ results in “403 Forbidden”
> 
> I took a look and it seems that the URLs have simply changed, perhaps as a 
> result of an update:
>
> https://lists.webkit.org/mailman/listinfo/webkit-wpe

Thanks, you're right—this URL works!

> https://lists.webkit.org/mailman/admin/webkit-wpe 
> 

…but this one still results in “403 Forbidden” (it won't work even with a
fresh profile to rule out saved cookies).

Regards,
—Adrián


pgphr0Fkgq0k3.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev