Checkout step of build fails after release on 19 May 2022

[markwhitfeld]

Checkout step of build fails after release on 19 May 2022

[felicianotech]

@JalexChen are you able to take a look at this? A quick fix would be to tag the second most recent commit to main as 'monthly' and push it up.

Assuming you find an issue with this release

[markwhitfeld]

It is related to a vulnerability fix in GIT:
https://github.blog/2022-04-12-git-security-vulnerability-announced/

Github actions had to make adjustments to fix their checkout step.
Have a look at these issues (and related PRs):
actions/checkout#759
actions/checkout#760

It was reported on CircleCI discuss about a month ago, but it looks like nobody took note:
https://discuss.circleci.com/t/unable-to-checkout-code/43672

What is your process around testing these cimg releases?
I don't see much in the way of automated checks in your CI for this repo before publishing.

[felicianotech]

So this then isn't a regression in the image so to speak. Setting a working_directory outside of /home/circleci isn't technically supported in Convenience Images. Considering the type of change git made and the fact that our images already allow passwordless sudo, I don't think it's unreasonable to set the default git behavior back to the old one. I believe I saw that was possible. I will double check.

In the meantime, possible solutions forward here:

1. Change (or don't set) your working directory.
2. Use the previous base image release, 2022.04.

As for testing, we have some testing in this repository and some in external repositories. We are gearing up to quadruple down on the amount of testing that all images under cimg/ get in the next couple of months.

---

I'm going to keep this issue open to track the git behavior change request.

[Dunedan]

So this then isn't a regression in the image so to speak. Setting a working_directory outside of /home/circleci isn't technically supported in Convenience Images.

The CircleCI documentation explicitly suggests using /mnt/ramdisk as working_directory: https://circleci.com/docs/2.0/executor-types/#ram-disks

So how is it no regression that official CircleCI images don't work with suggested configuration?

[felicianotech]

The CircleCI documentation explicitly suggests using /mnt/ramdisk as working_directory:

If you want to use that feature yes. It doesn't say it works with a Convenience Image. Even in the example provided in that doc it uses the Docker Library alpine image, which is not one of our images.

So how is it no regression that official CircleCI images don't work with suggested configuration?

We shipped an updated version of git that works as git intended. This is the change they wanted.

---

As I mentioned above, I've been following this. Git introduced a config flag to add individual directories to be ignored by this new security feature. Then, in a version of git newer than what the May update provides, they allow an * to be used, basically allowing us to have git work like it did before the CVE. I have a PR in place for this change. Please see #171 for info on when you can use it.

In the meantime, you can run the following in your config BEFORE - checkout to get around this now, that's if you don't want to use one of my previous two suggestions:

- run: git config --global --add safe.directory '*'
# or
- run: git config --global --add safe.directory '/mnt/ramdisk'
- checkout

I hope that helps.