Tim Lucas

One concern I've thought of, is that if the readmes of the plugins are updated to use this new syntax, people might copy+paste them and try to run it on...

Yeah we could, I thought of that too. I reckon you'd want the job to fail still though yeah? So either you fail the job on the backend with some...

> Do we want to allow partial sha1 matches? E.g let folks provide 7-10 digits of the sha1 prefix? For the sake of security, I was thinking not. I wasn't...

I added a few things, but I couldn't quite get the new `--require-plugin-digests` to work — it seems nil/false in the bootstrap 🤔 Would love a hand getting this finished...

> Shall we merge this without the flag @toolmantim and look at something like #1034 next? Yeah, you're totally right! We should just merge digest support first.

> `--no-plugins --allow-plugins-with-org=buildkite --allow-plugins-with-digests --allow-vendored-plugins` I really like this one I think! 👌🏼

> > `--no-plugins --allow-plugins-with-org=buildkite --allow-plugins-with-digests --allow-vendored-plugins` > I really like this one I think! 👌🏼 Actually, I was hoping that `--require-plugin-digests` would become the new default in a future version...

> I reckon it’s going to get too complicated to do with flags Fair call! > I’m still also a bit unsure about whether requiring everyone use digests should be...

> I'd like to hear more about this! Specifically the approached taken in this PR vs: >> Providing a digest here should avoid the need to vendor plugins for the...

How about we start by adding this digest support to the pipeline.yml (as per the PR)? It's optional, and people can use agent hooks to enforce their existence if they...