Description
What's the problem this feature will solve?
We introduced build API keys in order to improve security inside builders, so instead of having one single key with access to all projects via the API, we generate one temporary key valid just for one project for each build.
That's definitely better than one global key, but this key still grants access to any version of that project, since builds are attached to one version, we should scope it just to that version. For example, if a build from a PR manages to leak the build API key, it will be able to interact with all the versions.
Describe the solution you'd like
Instead of attaching build API keys to a project, they should be attached to a build (after all they are named build api keys, not project api key :D).
readthedocs.org/readthedocs/api/v2/models.py
Lines 31 to 45 in 77758cd
We may be tempted to just add a "version" field, but that has the downside of being able to interact with all the builds linked to that version, again, we want that key to be the more scoped possible.
Additional context
I think I decided to link the keys to a project since we make use of some APIs that update or retrieve some information about the project, while that's a valid use case, they should be special cases that only grant limited access to resources of the project.