Open Krakonos opened 8 years ago
Confirming, thanks for the report. I'll test on upstream Drone CI to make sure if it is an upstream bug or Tea CI bug.
I added a warning to http://docs.tea-ci.org/usage/secrets/ .
This upstream patch might help: https://github.com/drone/drone/pull/1591
But I'm not able to upgrade the server soon because there are some patches need to manually rebase, will do that later next week, sorry for the delay.
Yes, this looks like the actual documented feature. I'll be looking forward to it!
Hi @Krakonos , I've deployed Drone 0.4.2 code to https://tea-ci.org, could you see if this issue has been fixed?
Thanks!
I won't be able to test it anytime soon, but will try if I find some spare time.
A note for any potential contributors (mostly myself XD) Drone 0.5 use a very different encryption method compares to Drone 0.4.*: http://readme.drone.io/0.5/usage/secrets/
Drone stores secrets in separate file ".drone.sec". This file is supposed to be decrypted and applied to .drone.yml on runtime.
According to drone documentation: http://readme.drone.io/usage/secrets/ (see Checksums), the .drone.sec is decrypted and injected ONLY IF it's embedded hash of .drone.yml matches.
This does not seem to be the case with Tea-CI, and thus .drone.sec is not secure with Pull Request builds enabled. It should be fine without pull requests, though you need to take care not to merge any malicious PRs.
The attack vector is simple: an attacker can make a PR with modified .drone.yml, which would expose the variables inside .drone.sec.
Note that limiting the secret use to the part of that readme does not protect against PR attacks in this case.