After updating to 14.5 a info message now appears on any client trying to push or pull that is confusing. Is this something new or something turned on in the 14.5 release?
❯ git pull
time=“2021-11-22T17:58:31Z” level=info msg=“SSL_CERT_DIR is configured” ssl_cert_dir=/opt/gitlab/embedded/ssl/certs/
Already up to date.
The logging comes from the new gitlab shell Version. When you have configured the
ssl_cert_dir in your gitlab shell config.yml it will be logged.
On a default omnibus installation it appears the
ssl_cert_dir is configured by default
From what I can tell the
gitlab.rb file is responsible for writing the shell’s config.yml
$ head -n 5 /var/opt/gitlab/gitlab-shell/config.yml
# This file is managed by gitlab-ctl. Manual changes will be
# erased! To change the contents below, edit /etc/gitlab/gitlab.rb
# and run `sudo gitlab-ctl reconfigure`.
I’m guessing it must be something else causing this. I upgraded to 14.5 last night, this morning checked:
cat /var/opt/gitlab/gitlab-shell/config.yml | grep ssl_cert
I have it enabled in config.yml, but when I do git pull etc I don’t have that message in the output text. The question is, what is causing it? I clone over https rather than ssh, so not sure if this will have something to do with it, unless something in
.git/config for that repo is causing it or the global
.gitconfig for the user. Or perhaps something in gitlab.rb, but not sure what.
The only thing I can think of in gitlab.rb would be:
# gitlab_shell['log_level'] = 'INFO'
mine is commented, so default level of INFO - perhaps it has been configured to something else.
I’m seeing the same message, with every remote git action (over ssh). Also just updated to 14.5.
Same message from my Gitlab omnibus installation since this morning. It just updated to 14.5 last night.
I’m getting the same thing and AFAIK I haven’t configured our GitLab installation in a nonstandard way, either in terms of the logging level or the cert dir. Now all my coworkers’ clients seem to be exposing information on where server certificates are stored. Surely that’s not a deliberate action on the team’s part?
Shouldn’t this be more of a DEBUG level logging level and server-side only? Is there any way I can find out if folks are aware of this and working on it?
Actually I just found an issue that has been raised on this and this topic is linked in it. Glad to see it’s getting attention!
This one too : issue #346336
FYI, @stanhu shared a workaround in the issue for building gitlab-shell until a fixed release comes out.