Failure to clone zip projects when using OpenShift trusted CA bundle

[l0rd]

Describe the bug

Theia uses curl to download projects zip files. When a zip file is hosted on a server that uses a TLS cert signed by an untrusted CA curl fails to download the file. That's normal.

But if Che is running on OpenShift and the CA certificate is added into OpenShift CA trusted bundle (as described here) curl should not fail anymore. The certificates are correctly mounted in the container where curl runs (theia container) but curl doesn't take them into account.

This is the error:

Couldn't import https://devfile-registry-cip-crw-common.apps.xxxxx.com/resources/spring-boot-http-booster-spring-boot-http-booster-sb-2.3.x.zip:
curl: (60) SSL certificate problem: unable to get local issuer certificate More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not establish a secure connection
to it. To learn more about this situation and how to fix it,
please visit the web page mentioned above.

Che version

nightly

Steps to reproduce

N/A

Expected behavior

Currently Theia looks for an hardcoded crt file (/tmp/che/secret/ca.crt) and if it founds runs curl with the unsecure option -k. The problem is that crt files are currently mounted in folder /public-certs and we should avoid using curl option -k anyway.

Runtime

OpenShift

Installation method

OperatorHub

Environment

Cloud

[l0rd]

A workaround is to pre-create a secret in the workspace namespace so that Che will inject file /tmp/che/secret/ca.crt in every workspace container such as:

apiVersion: v1
kind: Secret
metadata:
  name: file-to-inject
  annotations:
    "che.eclipse.org/automount-workspace-secret": "true"
    "che.eclipse.org/mount-path": "/tmp/che/secret"
    "che.eclipse.org/mount-as": file
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: workspace-secret
data:
  ca.crt: "bWlubmllCg=="

[vzhukovs]

A workaround is to pre-create a secret in the workspace namespace so that Che will inject file /tmp/che/secret/ca.crt in every workspace container such as:

apiVersion: v1
kind: Secret
metadata:
  name: file-to-inject
  annotations:
    "che.eclipse.org/automount-workspace-secret": "true"
    "che.eclipse.org/mount-path": "/tmp/che/secret"
    "che.eclipse.org/mount-as": file
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: workspace-secret
data:
  ca.crt: "bWlubmllCg=="

and then add --cacert /tmp/che/secret/ca.crt to the curl command to consume the certificate. I had similar problem when I was creating a simple sh script to track activity in Che for JetBrains related images[1].

[1] https://github.com/che-incubator/jetbrains-editor-images/blob/master/scripts/prevent-idle-timeout.sh#L22

[azatsarynnyy]

Related to the Welcome Plug-in, so triaged as area/plugins.
cc @ericwill

[vitaliy-guliy]

Probably it's not welcome, but workspace plugin.
@azatsarynnyy we will take a look at this.

[azatsarynnyy]

Here's the example of how it was done for Task Plug-in:
https://github.com/eclipse/che-theia/blob/d504192faa6ad19eade8c5905fdc8cbdcf67a6c1/plugins/task-plugin/src/machine/websocket.ts#L203-L211
It might help as well.

[sunix]

Eventually, we need to have a common way to deal with certificates across all our plugins.

[vitaliy-guliy]

The bug is reproducible.
In fact, there could be several certificates in /tmp/che directory. It needs also to take into account all certs in /public-certs/.
As an option is to pack all available certs into one bundle somewhere in /tmp directory and then give this bundle to curl.