I don’t particularly like the plugin angle, specifying plugins seems a lot more difficult than getting multiple experts interested actively involved in maintaining the portion needed within pip, or moving the functions needed to process attestations into the language (and cpython as an implementation of it) and have installers use the language implementation.
This gets even harder in my view if we extend this to some generic pre/post install hooks rather than this being just a pip extension, as then we also need to specify an interface for these hooks that allows other installers (pdm, hatch, uv, …) to call them, and we would also need to change behavior to be fail if seeing a feature a tool doesn’t understand if it’s a generic hook.
Here’s some initial questions I have:
- What can plugin assume about the environment?
- What should an installer do to communicate with a plugin/hook?
- What prevents a package from installing a hook that overrides another hook
The security model of this approach seems much harder to ensure.
I’m also not arguing against the generic hook approach to push this onto pip or it’s maintainers, I genuinely think this is better for everyone if it’s something that’s in the standard library and that installers can call into, not maintain themselves, but we’d need to be extremely confident in the implementation, which is why my thoughts went to the HACL* project (mentioned above) and making sure the bootstrapping of security starts with the language itself. IMO, it’s fine if this is the minimum, and then pip uses that to go fetch a more full-featured library to do other heavier lifting, implementing only the logic to call libraries and functions that validate, without having to directly maintain any of that.
– I’d love to have a default client-side story for attestations, and I think