2 ms·
IMHO the idea that source code in any place outside of crates.io should in any way be relevant for reviewing code uploaded to crates.io is deeply flawed. Even
by dathinab 5y ago
IMHO the idea that source code in any place outside of crates.io should in any way be relevant for reviewing code uploaded to crates.io is deeply flawed.
Even if you make it technically work there are endless ways this could be abused in a social engineering context.
Like even if you when uploading check the code is the same, how do you check it stays the same. How do you check it's the same for any way the site is accessed (e.g. git vs. html code preview). How do you make sure there is not other social engineering in place (misleading tags etc.). You can't, reliable, in a good way.
Also don't forget, the client which uploads thinks can't be trusted. So you would need to push a full git (maybe sparse) branch to the server instead of just uploading a subset of the current checkout, that's pretty much a no-go for various reason.
Through it's not hat there are no ways to reach something similar like e.g.:
What you can do:
- sign uploaded packages
- automatically include the commit hash or other vcs history ids (but then it's in the client so they CAN be tempered with)
- all some form of "external-signing" that attaches "labels" to crates
- then you can e.g. have a GitHub service which verifies that the uploaded code matches a checked from a repository on GitHub and adds an appropriate label, similar services with all the service specific nobs could be made for various repository hosters. But this would not be a part of cargo/crates, but 3rd party services (e.g. provided by the hosters).
- Similar a company doing reviews could add a "reviewed by us" label.
- Or cargo-crev could attach a "there are reviews" label.
How this "labels" then interact with the UI and if they are even stored on crates.io is a different matter altogether.