[Automated comment] Less than 2 weeks to go before stable on M54, manual review required.

Richard, could you please approve this merge since this is an ongoing process.

Merge approved for M54

Merging to branch 2840 right now.

Also, I just noticed there is a typo in the hash of the link in the first comment; the `0` at the end should not be there:
https://chromium.googlesource.com/chromium/src.git/+/bf314ad606b8153e52f64068e5550c61a320cdb3

> Merging to branch 2840 right now.

This failed because of a merge conflict, and I haven't figured out why (it should apply cleanly). Looking right now.

Found out what it was

https://chromium.googlesource.com/chromium/src/+/960fde37768267fb16f8b7ffd7bc4d4bac10bb4c changed a small amount of binary data, which needs to be merged first for a clean patch.

Merging both 960fde37768267fb16f8b7ffd7bc4d4bac10bb4c and bf314ad606b8153e52f64068e5550c61a320cdb30, per chat with ligimole@.

(I could have run transport_security_state_generate in the merge directory produced by `git-drover`, but that is more risky. In particular, the merge directory doesn't even contain the pins file, which means I need to do a fragile custom checkout of the pins file in order to even do that.)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a098fb135e247b02b70b8a9628922456be7f9750

commit a098fb135e247b02b70b8a9628922456be7f9750
Author: Lucas Garron <lgarron@chromium.org>
Date: Wed Oct 19 22:59:38 2016

Use the Google report-uri for badssl Expect-CT site

This change goes along with
https://github.com/chromium/badssl.com/pull/206, which adds the
preloaded-expect-ct.badssl.com to badssl.com and serves the Expect-CT
header with no SCTs. Along with this CL, we'll get an easy way to
manually test Expect-CT end-to-end, by visiting
preloaded-expect-ct.badssl.com in Chrome and seeing that a report gets
generated and logged on the server side.

BUG= 655854 

Review-Url: https://codereview.chromium.org/2336373002
Cr-Commit-Position: refs/heads/master@{#418425}
(cherry picked from commit 960fde37768267fb16f8b7ffd7bc4d4bac10bb4c)

Review URL: https://codereview.chromium.org/2436523003 .

Cr-Commit-Position: refs/branch-heads/2840@{#761}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/a098fb135e247b02b70b8a9628922456be7f9750/net/http/transport_security_state_static.h
[modify] https://crrev.com/a098fb135e247b02b70b8a9628922456be7f9750/net/http/transport_security_state_static.json
[modify] https://crrev.com/a098fb135e247b02b70b8a9628922456be7f9750/net/http/transport_security_state_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/93786d31433b6c3513da5680dfe121c9b1aa5ef2

commit 93786d31433b6c3513da5680dfe121c9b1aa5ef2
Author: Lucas Garron <lgarron@chromium.org>
Date: Wed Oct 19 23:26:09 2016

HSTS preload list removals for Chrome 55.

eyyit.com:
> I jumped the gun on hsts preloading and now have a subdomain that needs to
> read xml feeds from non-https sites.  This HSTS preload including subdomains
> broke that.  Instead of waiting for the feeds to update their site to https,
> I'd rather get the removal process started soon so I have some options.

svallee.fr:
> • home.svallee.fr (many services, not all with HTTPS available)

vjirovsky.cz:
> axure.vjirovsky.cz – it’s branded (CNAME) version of axshare.com and they are
> not able to have certificate for axure.vjirovsky.cz

tradeacademy.in:
> list.tradeacademy.in -> We are using this domain for our newsletter
> application & we don't have Wildcard SSL certificate so whenever we open
> list.tradeacademy.in it goes to HTTPS in chrome.

almeria.fr:
> store.almeria.fr – problem with our website supplier

almeria-si.fr:
> store.almeria-si.fr – this site is managed by a partner, and we are not ready
> to migrate to https.

vozp.cz:
> • maps.vozp.cz – subsite dont using SSL
> • intranet.vozp.cz – internal application
> • helpdesk.vozp.cz – internal application

zen-trader.com:
> We cannot support HTTPS on the following subdomains:
> • status - Not under our control (third party server)
> • email - Not under our control (third party server)
> • clk - Not under our control (third party server)
> • mailsrv - Not under our control (third party server)

bratteng.me:
> dell.bratteng.me - some of the ports other than 80 and 443 does not support
> https yet

soleus.nu:
> We are a non-profit hosting association, and almost all subdomains are
> assigned to members (with their own vps and hosting services).

chrishamper.com:
> I had enabled the HSTS header with the "preload" directive on my domain while
> following an online guide related to HSTS, which didn't explain the meaning or
> repercussions of that directive. It is now causing much trouble when
> attempting to do development work using subdomains I'm spinning up as needed.

elisa.ee:
> tanama.elisa.ee – it needs to be opened with HTTP

mijailovic.net:
> • www.mijailovic.net - I’m moving my website from custom server to GitHub
> pages, but GitHub doesn’t support https on their custom subdomains.

skyo.com:
> • Skyo.com/api/ - Most Clients using API part of our site only support weak
> SSLv3 or dont support SSL/TLS at all. This had a huge impact on our business
> and we have found temporary ways around this until we can get off the preload
> list. We eventually will add the main site, skyo.com (www.skyo.com), back to
> HSTS but our backend Admin and API sections we will avoid the change due to
> too many clients not running modern systems.

mitell.jp:
> • [staging.mitell.jp, test.mitell.jp] - They are for test and our project
> cannot apply SSL for test sites.

callcap.com:
> We have several callcap.com subdomains that are used internally only that
> cannot work with HTTPS. The preload directive was configured by mistake on our
> webservers but has since been removed.

BUG= 527947 ,  655854 
TBR=palmer@chromium.org

Review URL: https://codereview.chromium.org/2306423004 .

Cr-Commit-Position: refs/heads/master@{#423678}
(cherry picked from commit bf314ad606b8153e52f64068e5550c61a320cdb3)

Review URL: https://codereview.chromium.org/2431163006 .

Cr-Commit-Position: refs/branch-heads/2840@{#762}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/93786d31433b6c3513da5680dfe121c9b1aa5ef2/net/http/transport_security_state_static.h
[modify] https://crrev.com/93786d31433b6c3513da5680dfe121c9b1aa5ef2/net/http/transport_security_state_static.json

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a098fb135e247b02b70b8a9628922456be7f9750

commit a098fb135e247b02b70b8a9628922456be7f9750
Author: Lucas Garron <lgarron@chromium.org>
Date: Wed Oct 19 22:59:38 2016

Use the Google report-uri for badssl Expect-CT site

This change goes along with
https://github.com/chromium/badssl.com/pull/206, which adds the
preloaded-expect-ct.badssl.com to badssl.com and serves the Expect-CT
header with no SCTs. Along with this CL, we'll get an easy way to
manually test Expect-CT end-to-end, by visiting
preloaded-expect-ct.badssl.com in Chrome and seeing that a report gets
generated and logged on the server side.

BUG= 655854 

Review-Url: https://codereview.chromium.org/2336373002
Cr-Commit-Position: refs/heads/master@{#418425}
(cherry picked from commit 960fde37768267fb16f8b7ffd7bc4d4bac10bb4c)

Review URL: https://codereview.chromium.org/2436523003 .

Cr-Commit-Position: refs/branch-heads/2840@{#761}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/a098fb135e247b02b70b8a9628922456be7f9750/net/http/transport_security_state_static.h
[modify] https://crrev.com/a098fb135e247b02b70b8a9628922456be7f9750/net/http/transport_security_state_static.json
[modify] https://crrev.com/a098fb135e247b02b70b8a9628922456be7f9750/net/http/transport_security_state_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/93786d31433b6c3513da5680dfe121c9b1aa5ef2

commit 93786d31433b6c3513da5680dfe121c9b1aa5ef2
Author: Lucas Garron <lgarron@chromium.org>
Date: Wed Oct 19 23:26:09 2016

HSTS preload list removals for Chrome 55.

eyyit.com:
> I jumped the gun on hsts preloading and now have a subdomain that needs to
> read xml feeds from non-https sites.  This HSTS preload including subdomains
> broke that.  Instead of waiting for the feeds to update their site to https,
> I'd rather get the removal process started soon so I have some options.

svallee.fr:
> • home.svallee.fr (many services, not all with HTTPS available)

vjirovsky.cz:
> axure.vjirovsky.cz – it’s branded (CNAME) version of axshare.com and they are
> not able to have certificate for axure.vjirovsky.cz

tradeacademy.in:
> list.tradeacademy.in -> We are using this domain for our newsletter
> application & we don't have Wildcard SSL certificate so whenever we open
> list.tradeacademy.in it goes to HTTPS in chrome.

almeria.fr:
> store.almeria.fr – problem with our website supplier

almeria-si.fr:
> store.almeria-si.fr – this site is managed by a partner, and we are not ready
> to migrate to https.

vozp.cz:
> • maps.vozp.cz – subsite dont using SSL
> • intranet.vozp.cz – internal application
> • helpdesk.vozp.cz – internal application

zen-trader.com:
> We cannot support HTTPS on the following subdomains:
> • status - Not under our control (third party server)
> • email - Not under our control (third party server)
> • clk - Not under our control (third party server)
> • mailsrv - Not under our control (third party server)

bratteng.me:
> dell.bratteng.me - some of the ports other than 80 and 443 does not support
> https yet

soleus.nu:
> We are a non-profit hosting association, and almost all subdomains are
> assigned to members (with their own vps and hosting services).

chrishamper.com:
> I had enabled the HSTS header with the "preload" directive on my domain while
> following an online guide related to HSTS, which didn't explain the meaning or
> repercussions of that directive. It is now causing much trouble when
> attempting to do development work using subdomains I'm spinning up as needed.

elisa.ee:
> tanama.elisa.ee – it needs to be opened with HTTP

mijailovic.net:
> • www.mijailovic.net - I’m moving my website from custom server to GitHub
> pages, but GitHub doesn’t support https on their custom subdomains.

skyo.com:
> • Skyo.com/api/ - Most Clients using API part of our site only support weak
> SSLv3 or dont support SSL/TLS at all. This had a huge impact on our business
> and we have found temporary ways around this until we can get off the preload
> list. We eventually will add the main site, skyo.com (www.skyo.com), back to
> HSTS but our backend Admin and API sections we will avoid the change due to
> too many clients not running modern systems.

mitell.jp:
> • [staging.mitell.jp, test.mitell.jp] - They are for test and our project
> cannot apply SSL for test sites.

callcap.com:
> We have several callcap.com subdomains that are used internally only that
> cannot work with HTTPS. The preload directive was configured by mistake on our
> webservers but has since been removed.

BUG= 527947 ,  655854 
TBR=palmer@chromium.org

Review URL: https://codereview.chromium.org/2306423004 .

Cr-Commit-Position: refs/heads/master@{#423678}
(cherry picked from commit bf314ad606b8153e52f64068e5550c61a320cdb3)

Review URL: https://codereview.chromium.org/2431163006 .

Cr-Commit-Position: refs/branch-heads/2840@{#762}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/93786d31433b6c3513da5680dfe121c9b1aa5ef2/net/http/transport_security_state_static.h
[modify] https://crrev.com/93786d31433b6c3513da5680dfe121c9b1aa5ef2/net/http/transport_security_state_static.json

The changes were reverted. It's unclear if this was necessary/the right choice, but it's done. We'll leave the preload list in M54 as-is.

This is the first time the merge process has run into issues, and I really want to get rid of it.

 Issue 595493  for solve it, but larger Rietveld upload limits would be a good stopgap.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a739725e13c66cd34417847fb9f4a08854a5902f

commit a739725e13c66cd34417847fb9f4a08854a5902f
Author: Lucas Garron <lgarron@chromium.org>
Date: Thu Mar 02 03:23:20 2017

HSTS preload list removals for Chrome 58.

safic.net:
> • [oakwood] - audio stream server will not properly support https, oversite on
>   configuration preload and subdomains have been removed from headers.

BUG= 655854 

Review-Url: https://codereview.chromium.org/2649223002 .
Cr-Commit-Position: refs/heads/master@{#454161}

[modify] https://crrev.com/a739725e13c66cd34417847fb9f4a08854a5902f/net/http/transport_security_state_static.h
[modify] https://crrev.com/a739725e13c66cd34417847fb9f4a08854a5902f/net/http/transport_security_state_static.json

Aargh, I forgot that `git cl upload` takes the commit message from Rietveld, not from t commit.

The full intended commit message:

HSTS preload list removals for Chrome 58.

safic.net:
> • [oakwood] - audio stream server will not properly support https, oversite on
>   configuration preload and subdomains have been removed from headers.

medwayindia.com:
> We cannot support HTTPS on domain and we are removing it since our website
> provides only information and doesn't have payment or login functions that
> would require SSL.
>
> It was a mistake installing SSL which is not actually required by our static
> information purpose website.

sangwon.org:
> My blog service cannot support https

whiskeyriver.co.uk:
>  the reason for this is that I have recently taken over this domain, which I
>  have since discovered used to go to an https and is preloaded into the HSTS
>  list, but my brand new [and far superior] band website is created by Weebly,
>  http only and therefore will not work using this domain [it has been the
>  band’s domain for the last 9 years]. To add SSL to my new site so it will
>  work would cost more than the band can afford and so I am humbly asking if
>  you could remove it

jf.duckdns.org:
> This website is a dynamic DNS site hosted on my Raspberry Pi... I was just
> testing SSL on my site and enabled HSTS (recommended by ssllabs site tester)
> without being fully aware of the implications.  I have since removed this
> header in my apache conf however as you can see it's in the Chrome preload
> list.

avril4th.com:
> *.avril4th.com - This is blog which I take care of. However, it was moved to a
> naver blog (I was against that, but it's not my decision), which does not
> support https. At all.

builtritetrailerplans.com:
> No longer have ssl on [builtritetrailerplans.com] we have moved to
> builtritetrailerplans.com.au

x-case.de:
> [Subdomain with] Local SAP System with public DNS

BUG= 655854 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/95afc44bbf2a48971c4b0de896003b6dd9684c81

commit 95afc44bbf2a48971c4b0de896003b6dd9684c81
Author: Lucas Garron <lgarron@chromium.org>
Date: Mon Mar 06 20:53:22 2017

HSTS preload list removals for Chrome 58.

safic.net:
> • [oakwood] - audio stream server will not properly support https, oversite on
>   configuration preload and subdomains have been removed from headers.

BUG= 655854 

Review-Url: https://codereview.chromium.org/2649223002 .
Cr-Commit-Position: refs/heads/master@{#454161}
(cherry picked from commit a739725e13c66cd34417847fb9f4a08854a5902f)

Review-Url: https://codereview.chromium.org/2738533002 .
Cr-Commit-Position: refs/branch-heads/2987@{#772}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/95afc44bbf2a48971c4b0de896003b6dd9684c81/net/http/transport_security_state_static.h
[modify] https://crrev.com/95afc44bbf2a48971c4b0de896003b6dd9684c81/net/http/transport_security_state_static.json

Is this require a merge to M58?

Nope!