ADDITIONAL_CA_CERT_BUNDLE doesn't work for some analyzers

Summary

It appears that analyzer containers are not honouring certs passed through the env variable ADDITIONAL_CA_CERT_BUNDLE.

So far, I have tested secrets:3 and gosec-sast:2 and both did not work.

Steps to reproduce

For testing, I created my own copis of Secret-Detection.gitlab-ci.yml and SAST.gitlab-ci.yml from the original templates.

I have modified them to include a script field to print the contents of /etc/ssl/certs/ca-cert-additional-gitlab-bundle.pem. Relevant changes from Secret-local.yml below:

<snip>
  script:
    - cat /etc/ssl/certs/ca-cert-additional-gitlab-bundle.pem
    - /analyzer run
</snip>

.gitlab-ci.yml contents:

include:
  - local: Secret-local.yml
  - local: Sast-local.yml 

variables:
  C_DEBUG_TRACE: "true"
  ADDITIONAL_CA_CERT_BUNDLE: |
    -----BEGIN CERTIFICATE-----
    MIICPDCCAaUCED9pHoGc8JpK83P/uUii5N0wDQYJKoZIhvcNAQEFBQAwXzELMAkG
    A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFz
    cyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2
    MDEyOTAwMDAwMFoXDTI4MDgwMjIzNTk1OVowXzELMAkGA1UEBhMCVVMxFzAVBgNV
    BAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmlt
    YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
    ADCBiQKBgQDlGb9to1ZhLZlIcfZn3rmN67eehoAKkQ76OCWvRoiC5XOooJskXQ0f
    zGVuDLDQVoQYh5oGmxChc9+0WDlrbsH2FdWoqD+qEgaNMax/sDTXjzRniAnNFBHi
    TkVWaR94AoDa3EeRKbs2yWNcxeDXLYd7obcysHswuiovMaruo2fa2wIDAQABMA0G
    CSqGSIb3DQEBBQUAA4GBAFgVKTk8d6PaXCUDfGD67gmZPCcQcMgMCeazh88K4hiW
    NWLMv5sneYlfycQJ9M61Hd8qveXbhpxoJeUwfLaJFf5n0a3hUKw8fGJLj7qE1xIV
    Gx/KXQ/BUpQqEZnae88MNhPVNdwQGVnqlMEAv3WP2fr9dgTbYruQagPZRjXZ+Hxb
    -----END CERTIFICATE-----

Above cert is of Verisign Root.

Error message I got:

$ cat /etc/ssl/certs/ca-cert-additional-gitlab-bundle.pem
cat: can't open '/etc/ssl/certs/ca-cert-additional-gitlab-bundle.pem': No such file or directory

Example Project

What is the current bug behavior?

Analyzers won't honour ADDITIONAL_CA_CERT_BUNDLE.

What is the expected correct behavior?

Analyzers should honour ADDITIONAL_CA_CERT_BUNDLE.

Relevant logs and/or screenshots

Please see summary above.

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 
System information
System:		Ubuntu 18.04
Proxy:		no
Current User:	git
Using RVM:	no
Ruby Version:	2.7.2p137
Gem Version:	3.1.4
Bundler Version:2.1.4
Rake Version:	13.0.3
Redis Version:	6.0.10
Git Version:	2.29.0
Sidekiq Version:5.2.9
Go Version:	unknown

GitLab information
Version:	13.10.2-ee
Revision:	cc4224220e6
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	PostgreSQL
DB Version:	12.6
URL:		https://ps-gitlab.sr.gitlab.support
HTTP Clone URL:	https://ps-gitlab.sr.gitlab.support/some-group/some-project.git
SSH Clone URL:	git@ps-gitlab.sr.gitlab.support:some-group/some-project.git
Elasticsearch:	no
Geo:		no
Using LDAP:	no
Using Omniauth:	yes
Omniauth Providers:

GitLab Shell
Version:	13.17.0
Repository storage paths:
- default: 	/var/opt/gitlab/git-data/repositories
GitLab Shell path:		/opt/gitlab/embedded/service/gitlab-shell
Git:		/opt/gitlab/embedded/bin/git

Results of GitLab application Check

Expand for output related to the GitLab application check 
Checking GitLab subtasks ...


Checking GitLab Shell ...


GitLab Shell: ... GitLab Shell version >= 13.17.0 ? ... OK (13.17.0)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Internal API available: OK
Redis available via internal API: OK
gitlab-shell self-check successful


Checking GitLab Shell ... Finished


Checking Gitaly ...


Gitaly: ... default ... OK


Checking Gitaly ... Finished


Checking Sidekiq ...


Sidekiq: ... Running? ... yes
Number of Sidekiq processes (cluster/worker) ... 1/1


Checking Sidekiq ... Finished


Checking Incoming Email ...


Incoming Email: ... Reply by email is disabled in config/gitlab.yml


Checking Incoming Email ... Finished


Checking LDAP ...


LDAP: ... LDAP is disabled in config/gitlab.yml


Checking LDAP ... Finished


Checking GitLab App ...


Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... skipped (no tmp uploads folder yet)
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ...
2/1 ... yes
1/2 ... yes
1/3 ... yes
1/4 ... yes
1/5 ... yes
1/6 ... yes
3/7 ... yes
1/8 ... yes
1/9 ... yes
1/10 ... yes
1/12 ... yes
1/13 ... yes
Redis version >= 4.0.0? ... yes
Ruby version >= 2.7.2 ? ... yes (2.7.2)
Git version >= 2.29.0 ? ... yes (2.29.0)
Git user has default SSH configuration? ... yes
Active users: ... 1
Is authorized keys file accessible? ... yes
GitLab configured to store new projects in hashed storage? ... yes
All projects are in hashed storage? ... yes
Elasticsearch version 7.x (6.4 - 6.x deprecated to be removed in 13.8)? ... skipped (elasticsearch is disabled)


Checking GitLab App ... Finished


Checking GitLab subtasks ... Finished

Possible fixes

  • One customer confirms that setting GIT_SSL_NO_VERIFY: "true" for the time being works around this problem.
Edited by Katrin Leinweber