Hello, thanks for reporting this! 🐻

I know I am taking the risky path here and following the latest tag. This is more of an informative bug report, but I believe this should have continued to work, as we automatically add the directory to the safe property of git. Am I missing something here?

The workaround that I used for fixing #108 was creating a new user in the Docker image (as git-user) and changing the ownership of mounted volume while the container is being run. For doing that, I was copying the .git directory to a new place and utilizing this directory for running git-cliff. Unfortunately, using chown(1) wasn't applicable since it requires root permissions and also changes the ownership of the mounted volume outside the container if not being mounted as read-only.

# contents of entrypoint.sh

#!/bin/sh
cp -r /app /git-home/app
cd /git-home/app
exec git-cliff "$@"

This entrypoint script was required since the mounted volume was not owned by the container user. However, at the end of the day, it made the container run as non-root at all times (which is generally a good thing). This is where this GitLab CI issue originates from.

When you specify an image and empty entrypoint, GitLab runner drops you to the shell of the image. For example, if you run ls you will see the current files in the repository and they are all owned by root.

As you guessed, we are git-user, not root. Thus CVE-2022-24765 strikes again!

Just a note, same cp workaround actually works in case too.

You need to edit your script like this though and it doesn't look good at all:

  script:
    - mkdir app
    - cp -r .git app
    - ls -la app
    - cd app
    - git-cliff

Conclusion

5cb991d4e3a39dd15ae22b661c23d18ccbd45004

I decided to remove git-user and ownership changes from the Docker image. It will solve this issue and make it possible to run git-cliff in GitLab CI. It also works for #108. I think it is the fastest and cleanest way to solve this until a better solution arrives.

0.9.2 is now out.

I missed this back when this issue was fresh (I see it is dates when I was traveling) but having just fought off similar issues in Docker that has to run in all of GH Actions, locally, and on GitLab CI, I came up with a bit different solution. In my case I had to be able to make commits inside the docker run, so just copying the input dir and changing the privs was not an option. I found that, besides setting the safe.directory config inside the Docker container to cover possible volume mounts, running my actual tool behind a wrapper script that uses exec setpriv ... to change to the effective UID/GID of the repository being worked on did the trick. If that's of interest I can point you to sources or send a contribution with the implementation.

Hello @alerque, that sounds great. It's always nice to see the alternative implementations and possibly improve the current workaround. Please feel free to share!