ADDITIONAL_CA_CERT_BUNDLE variable in glab releases does not support "path/to/file" contents
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Summary
The release tooling integration with glab does not support the capability to populate the ADDITIONAL_CA_CERT_BUNDLE variable with a path to a file of of X509 certs to trust. This is a feature that was implemented previously in the release-cli tool which glab purports to have feature parity with. As release-cli is now deprecated in favor of glab this should be considered a bug in backwards compatible interfaces.
Steps to reproduce
On a self hosted gitlab instance attempt to use the glab release features while setting ADDITIONAL_CA_CERT_BUNDLE to /etc/gitlab-runner/certs/ca.crt as a compliment to the documented guidance on adding additional trusted certs for use during cicd stages. You will observe that all interactions with the gitlab instance over HTTPS will fail with an error such as:
+ glab release create -R fooble/gooble 0.0.4 --experimental-notes-text-or-file 'Release 0.0.4 of components repository fooble/gooble' --ref 6614d673189bfff09cb3a8e97fa7f617c491a9c5 --no-update --no-close-milestone
• Creating or updating release repo=fooble/gooble tag=0.0.4
ERROR
Get "https://gitlab.example.com/api/v4/projects/fooble/gooble/releases/0%2E0%2E4": tls:
failed to verify certificate: x509: certificate signed by unknown authority. However populating ADDITIONAL_CA_CERT_BUNDLE with the contents of the same CA file results in the glab commands passing TLS verification and the component working as documented.
What is the current bug behavior?
Setting the ADDITIONAL_CA_CERT_BUNDLE to a file path does not cause the file at the given path to be used as a source of CA trust and https communications that require that trust fail.
What is the expected correct behavior?
ADDITIONAL_CA_CERT_BUNDLE can be set to either a file path OR a string representation of x509 CA trusted certificates and the release integration with glab will correctly use either source in evaluating TLS trust.
The expected behavior is documented here: !193000 (comment 2805301738) and https://gitlab.com/gitlab-org/release-cli/-/tree/master/docs/examples/additional-ca-cert-bundle
You can use the ADDITIONAL_CA_CERT_BUNDLE CI/CD variable to configure a custom SSL CA certificate authority, which is used to verify the peer when the release-cli creates a release through the API using HTTPS with custom certificates. The ADDITIONAL_CA_CERT_BUNDLE value should contain the text representation of the X.509 PEM public-key certificate or the path/to/file containing the certificate authority.