but what’s going to stop a bad actor from, for instance, changing a unit test to fail with an error containing
Secrets are not exposed to pull requests by default, which prevents this exact scenario.
I think calling this a dealbreaker for all open source projects is a bit exaggerated. We use drone for hundreds of open source projects and have never needed to restrict builds based on whether or not the pull request is coming from a fork. We limit secrets to push and tag events (the default behavior) to mitigate the attack vector you described.
The signature can be an effective tool when you need to expose secrets to pull request for use with plugins, which is the most common use case (send slack notifications, upload reports, etc). The signature is typically very effective for these use cases because an attacker would need to change the yaml in order to expose the secret, which would cause signature verification to fail.
There are of course some gaps in our approach. One example use case would be running unit or integration tests against a third party service that requires an API key, but only wanting to expose this secret to intra-repository pull requests. Lack of support for this use case could be problematic for some open source projects, and is something we will consider for future releases, but should not be a dealbreaker for most projects.