“Detected dubious ownership” issue when using php-actions/composer@v6

[victorwads]

I am experiencing an issue when using the php-actions/composer action with the following configuration in a GitHub Actions pipeline:

- name: Cache Composer dependencies
  uses: actions/cache@v4
  with:
    path: '/tmp/composer-cache'
    key: "${{ runner.os }}-${{ hashFiles('**/composer.lock') }}"

- name: Install Composer
  uses: php-actions/composer@v6
  with:
    php_version: 8.1
    ssh_key: '${{ secrets.SSH_KEY }}'
    ssh_key_pub: '${{ secrets.SSH_KEY_PUB }}'

The issue occurs during the Install Composer step, showing the following error message:

fatal: detected dubious ownership in repository at '/tmp/composer-cache/vcs/git-github.com-<specific-repository>.git'
To add an exception for this directory, call:

    git config --global --add safe.directory /tmp/composer-cache/vcs/git-github.com-<specific-repository>.git

Details:

• The issue is caused by Git version 2.35.2, which introduced this “safe directory” feature to improve security.
• Manually adding the directories as safe.directory temporarily solved the issue, but this is not scalable.
• Using git config --global --add safe.directory '*' was considered, but it poses a potential security risk.
• Changing ownership with chown did not work to resolve the ownership problem.

Question:

Is there a recommended way to handle this “dubious ownership” issue more efficiently, or could an enhancement be made to the php-actions/composer action to manage this scenario?

[mikemanger]

I think this is related to composer/composer#12158 so it might be an upstream issue.

I'm still testing but I think we got around this by using https/zips for the repository vcs urls.

[g105b]

Let's keep this issue open for a while until the upstream fix makes its way down. I think your comments are all correct, but maybe we won't need to change anything for the https/zip suggestion if this has been fixed in composer?

[mikemanger]

No fix yet but some more discussion here composer/composer#12192

Not my wheelhouse but passing the scope/context to the action might be a workaround? At least that seems to be what happens in a lot of actions.

[mikemanger]

Locking composer to 2.8.1 is probably the easiest workaround I've found.

      - name: Install PHP dependencies
        uses: php-actions/composer@v6
        with:
          # ...
          # Lock composer to working version.
          # See https://github.com/php-actions/composer/issues/120
          version: 2.8.1

[Stubbs]

I also got round this by removing composer caching from my build.

[Inscure]

@Stubbs - could you please elaborate a bit more on how you do that in the context of a GitHub Action?

[daniel-myparcel]

I am experiencing the same issue.

All I do in my workflow is run the following

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Composer
        uses: php-actions/composer@v6