Skip to content
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

Fix verification for steps with plugins, part 2 #2339

Merged
merged 2 commits into from
Aug 31, 2023

Conversation

DrJosh9000
Copy link
Contributor

@DrJosh9000 DrJosh9000 commented Aug 30, 2023

Dogfooding showed that signed steps with plugins still tended to fail verification. After digging around with --debug-http, it turns out that plugin config maps/hashes tend to be reordered by the backend.

On the plus side: we're free to reorder keys within plugin configs! 🎉

Changes here:

  • pipeline.Plugins can now be unmarshaled directly from JSON. For consistency it reuses the underlying UnmarshalOrdered using the same technique as for CommandStep.
  • ordered now has ToMapRecursive, which replaces *Map[string, any] with map[string]any recursively.
  • Each Plugin is unmarshaled using ToMapRecursive.
  • api.Job.ValuesForFields now passes BUILDKITE_PLUGINS through a JSON unmarshal-marshal round-trip. The JSON marshaler writes (plain) map keys in sorted order.

Net effect - signatures should verify.

@DrJosh9000 DrJosh9000 requested a review from a team August 30, 2023 08:04
Copy link
Contributor

@triarius triarius left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SO the problem was that ordered.Map was used all the way down.

Nice fix!

Value: "Kuzco",
},
),
Config: map[string]any{"llama": "Kuzco"},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that this PR was made to address the order of keys in plugin config, we should have a test that would have failed if the order weren't stable.

It might be impossible to write such a test using the json marshaller in go, but it's still worth having. The fact that json.Marshal sorts the keys before writing them is pretty crucial, so we should assert in our tests that it does to prevent regression.

Copy link
Contributor Author

@DrJosh9000 DrJosh9000 Aug 30, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added a test that I think should capture encoding stability problems. It initially failed, but the reason was how I was holding Sign and Verify, so I made their argument processing more consistent.

Verify was fine assuming all env vars come from env, because that's
how the backend produces output. But it made Sign and Verify look
a bit different, and causes confusion when the same arguments don't
verify.
@DrJosh9000 DrJosh9000 merged commit d4ba3a1 into main Aug 31, 2023
@DrJosh9000 DrJosh9000 deleted the why-verification-failed branch August 31, 2023 00:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants