-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Security concerns about secrets. #7
Comments
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: harness/harness#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 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.
The text was updated successfully, but these errors were encountered: