Trusted Woodpecker plugin can persist clone credentials in the shared workspace

Component

server

Describe the bug

For a private repository, the pipeline compiler passes clone credentials to an ordinary plugin step when its image is on the trusted-clone-plugin allowlist. plugin-git accepts a pipeline-controlled home setting and writes the netrc there. Setting home: /woodpecker leaves the credential in the shared workspace, where a later ordinary command step can read it.

Steps to reproduce

1. Use the pinned source checkouts and run attachments/reproduce.sh as described in report.md.
2. The compiler and builder probes admit the credential-bearing plugin step.
3. The runtime replay runs the plugin with PLUGIN_HOME equal to the shared workspace, then starts a separate shell process against that workspace.
4. The second process reads ci-secret from .netrc.

Attachments detailed report: report.md

attachments: attachments.zip

Expected behavior

Clone credentials should not be persisted below a workspace shared with later ordinary steps. A later step should not be able to read credentials supplied to a trusted clone helper.

System Info

Woodpecker source commit `409e2b9fc6ce7d24a857ece34f9266b55a24112c`; plugin-git
source commit `6155f679de956e41ba676a2bcc8a1f2dde869f00`; Linux amd64; Go
toolchain used by the pinned source checkouts.

Additional context

The replay uses a local bare repository and synthetic values only. The attached report.md contains the source path analysis; attachments.zip contains the compiler tests and runtime script.

Validations

• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Checked that the bug isn't fixed in the next version already [https://woodpecker-ci.org/versions]