Support config signing

[6543]

... like the Drone YAML signature feature https://docs.drone.io/signature/ ...

source: https://fosstodon.org/@xoxys@social.tchncs.de/110662955010365152

To Decide:

• how to integrate the signature in the pipeline config ...
• how to validate signatures

[anbraten]

As in most repos the steps are using scripts or other files like, go.mod, package.json, a makefile, ... Even if the config files can not be tampered a potential attacker could easily extend the makefile or publish a go / npm package executing malicious code. So I am not quite sure if this would really help TBH. Could that be somehow prevent as well without needing to sign the whole code base which would make the the signature aspect useless as it would always be a signature change 🤔

[6543]

a god question!

if it's about secrets - we can already make the save with current settings-options ensure config is not tampered would not add any more security ...

[6543]

cc @xoxys

[xoxys]

As in most repos the steps are using scripts or other files like, go.mod, package.json, a makefile, ...

You are absolutely right, in that case signing the config doesn't help at all and in the worst case creates a false sense of security as secrets exposed to PRs can be extracted by changing the code of a used Makefile/script etc. But if you avoid using scripts and using plugins or steps with static commands instead, signing the config prevents any malicious changes to the CI configuration.

if it's about secrets

Correct, it's all about secrets. Exposing secrets to PRs is dangerous, especially on public repos and external contributors but in the reality it is required in some cases e.g. tokens to upload coverage reports, tokens to add comments to the PR etc.

While using Drone, this was incredibly painful to cover because the gated feature (Approve/Decline button) is IMO implemented in the wrong way (without blocking every PR from project owners). In Woodpecker, this seems to be different, and repos with the enabled Protected flag prevents external malicious changes reliable.

So long story short, I agree with you both, adding another feature might be the wrong direction and the effort would be better invested in extending/improving the gated/protected repo feature.

[xoxys]

Form the Woodpecker docs:

Every build initiated by a user (not including the project owner) needs to be approved by the owner before being executed

What's the technical definition of owners? Everyone with the admin role in the repo, or is write access enough already?

[6543]

Uh thatvwas changed ... the docs are wrong, can you point me to this doc via link?

[xoxys]

Sure, https://woodpecker-ci.org/docs/usage/project-settings#protected

[6543]

And about gated feature: #336

[6543]

Sure, https://woodpecker-ci.org/docs/usage/project-settings#protected

Ah that's v0.15.x ... thats old - it was that way back then :)

[xoxys]

I'm confused, isn't 1.15.x the latest stable release and the latest docs version? Even in the next version of the docs it's explained like that https://woodpecker-ci.org/docs/next/usage/project-settings#protected

[6543]

Uh thats a bug then ... i'll change it

Well it's latest stable ... but we progressing fast towards v1.0.0

[xoxys]

Thanks for fixing the docs. I think the current state of the "protected" repo feature is a good enough for now, even if an allow/block list as proposed in #336 will be a huge improvement. Especially core maintainers/owners should be able to create changes without approval. I think we can close this issue, what do you think?

[xoxys]

But with the current implementation of the protection, that also means PRs from e.g. renovate bot will also not execute automatically, right? That's a bit sad as it will slow down any automation/automerge setup.

[anbraten]

cron and manual pipelines are by-passing the protection so if renovate is executed via a cron from woodpecker it should work

[xoxys]

Thanks. That's not the case. Renovate creates regular Pull Requests as a user. Maybe I can script something to approve PRs for some users via the API and schedule it every x minutes as a workaround.