“Detected dubious ownership” issue when using php-actions/composer@v6
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?
I think this is related to https://github.com/composer/composer/issues/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.
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?
No fix yet but some more discussion here https://github.com/composer/composer/issues/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.
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
I also got round this by removing composer caching from my build.
@Stubbs - could you please elaborate a bit more on how you do that in the context of a GitHub Action?
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