Is this running in a container? In CI we have to set --no-sandbox because Chromium's sandbox doesn't work inside docker containers.

AIUI the service runner running Proton is firejailed. Is that correct @pmiazga, @Pchelolo?

In T213363#4869156, @phuedx wrote:

AIUI the service runner running Proton is firejailed. Is that correct @pmiazga, @Pchelolo?

That is correct @phuedx

I think I know why we have ignoreHTTPSErrors and it shouldn't be necessary anymore. I'll check all params and I'll get back to you.
@Legoktm - the service itself doesn't run in a docker container, but the build process is run via docker, that may be the issue.

Sandboxing in Chromium is confusing. The SUID sandbox is apparently on its way out (although this other place lists it as maintianed)? The sandbox disabled with --no-sandbox seems Windows only? But there is also the namespace sandbox which is the successor of SUID sandbox, but has no disable switch? And the [[https://chromium.googlesource.com/chromium/src/+/master/docs/linux_sandboxing.md#the-sandbox-1|Seccomp-BPF]] sandbox, which does not have an off switch either.

No idea where that leaves us.

We cannot remove the --ignoreHTTPSErrors flag. It was added to the config https://github.com/wikimedia/mediawiki-services-chromium-render-deploy/commit/17fc7bb4cda2e1b408d6289c27685624d35e8714 because:

We use a self-signed certificate for our domains (since the CA is our Puppet). However, that results in Chromium HTTPS errors. Given that Proton cannot communicate with the outside world, it is safe to use the ignoreHTTPSErrors configuration flag since requesting HTML from our appservers is all the service does.

Instead of removing the IgnoreHTTPSErrors flag, I'll document why it is used.

Done: https://wikitech.wikimedia.org/wiki/Proton#Puppeteer_configuration

@Tgr @Jhernandez please check the puppeteer config documentation and let me know if it meets your expectations.

In T213363#4902258, @pmiazga wrote:

We use a self-signed certificate for our domains (since the CA is our Puppet).

Which sites are those? Public Wikimedia sites use certificates signed by GlobalSign. Beta uses LetsEncrypt certificates which are technically also not self-signed.

(Also if we use self-signed certificates somewhere we could just import those to the cert store of the Chromium instance. Although if Proton will connect to the websites internally, maybe not worth the effort as HTTPS encryption does not play much of a security role anyway. Is that the case for Proton instances in the passive DC, though?)

@Tgr - Public Wikimedia sites and Beta certs are set for public domains. Proton render used to access Wikipedia servers using internal network names (as it was inside internal network). The internal servers use the CA generated by Puppet.
Switching between HTTP/HTTPS modes is available via config (the config file has the URL template used to build the article URL).

I checked, and it looks like it's difficult (most probably not possible). Puppeteer doesn't allow to modify browser certificates - if it did - it would be a big security loophole.

@mobrovac can provide more details on this problem.

I see. Is there a point in using internal domain names, though? All the resources linked in the page (including some dynamic ones like ResourceLoader URLs) will use the public ones anyway.

(In theory you can programmatically manage certificates through the NSS store. But yeah probably not worth spending a lot of time on.)

I'll ping @mobrovac once again, as he decided to use internal domain names (previously we were using the public domains).

We are currently using the projects' FQDNs in MW API requests becasue this was the only way to get the CSS we needed for the printable version (not sure why that is the case, but that's a problem for another day). So, for the time being, SSL certificates are being honoured by Chromium.

That said, we would like to use the internal domain as this is the standard way to contact the appservers in production.