4 ms·

It may be possible to publish from a local folder and offer the user no history or context. However, I think it makes sense to privilege packages which can be

It may be possible to publish from a local folder and offer the user no history or context. However, I think it makes sense to privilege packages which can be cryptographically verified as deriving from a specific commit within an open source commit history, in a public repository at a specific URL.

jhugo 5y ago
I'd almost say that publishing from a nonpublic repository (or no repository) is a misfeature. At least when there is no good way to rapidly audit the source of crates on crates.io. Most people will go looking for a public git repo, but there's often no quick way to be certain that it's the same code as was published on crates.io.
- dathinab 5y ago
  It's less about a non-public repository and more about a non-git repository. (And some big company/mono repo/history-less CI-auto clones.) So if you add a "trust"/"signing" system you probably want to make it version control system independent, which doesn't mean there couldn't also be something build on top which isn't vcs independent ;=) > people will go looking for a public git repo And worth the will likely read the code shown through the http-code preview of the repository hoster of whatever the default branch is :=( I have seen to many issue in issue trackers because of that. I hope you don't mean "using the code preview of the hoster" when you wrote "rapid audit".
  - jhugo 5y ago
    My implication with "rapid audit" was that crates.io would provide a nice code preview, so that people can get the feature that they currently go to GitHub for, while actually viewing the code from the same source they're depending on the crate from rather than from GitHub where there is no guarantee it's the same code. Of course the best thing to do would be to look locally at the source of the crate that was actually downloaded by cargo. That's what I do. But you have to recognise that most people are going to weight convenience quite highly, and are going to be lazy when they should be thorough, and so on, so if you want to improve the security and trust in the ecosystem as a whole, you should try to make the safe path as low-friction as possible. The docs.rs code browser is currently the most "convenient" way to see the code for a specific crates.io release, so improving that would also be worthwhile. Right now I think there's no way to see the source of build.rs in that browser, and the formatting & navigation is nowhere as nice as on the likes of GitHub.
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.

jhugo 5y ago

I'd almost say that publishing from a nonpublic repository (or no repository) is a misfeature. At least when there is no good way to rapidly audit the source of crates on crates.io. Most people will go looking for a public git repo, but there's often no quick way to be certain that it's the same code as was published on crates.io.

dathinab 5y ago
It's less about a non-public repository and more about a non-git repository. (And some big company/mono repo/history-less CI-auto clones.) So if you add a "trust"/"signing" system you probably want to make it version control system independent, which doesn't mean there couldn't also be something build on top which isn't vcs independent ;=) > people will go looking for a public git repo And worth the will likely read the code shown through the http-code preview of the repository hoster of whatever the default branch is :=( I have seen to many issue in issue trackers because of that. I hope you don't mean "using the code preview of the hoster" when you wrote "rapid audit".
- jhugo 5y ago
  My implication with "rapid audit" was that crates.io would provide a nice code preview, so that people can get the feature that they currently go to GitHub for, while actually viewing the code from the same source they're depending on the crate from rather than from GitHub where there is no guarantee it's the same code. Of course the best thing to do would be to look locally at the source of the crate that was actually downloaded by cargo. That's what I do. But you have to recognise that most people are going to weight convenience quite highly, and are going to be lazy when they should be thorough, and so on, so if you want to improve the security and trust in the ecosystem as a whole, you should try to make the safe path as low-friction as possible. The docs.rs code browser is currently the most "convenient" way to see the code for a specific crates.io release, so improving that would also be worthwhile. Right now I think there's no way to see the source of build.rs in that browser, and the formatting & navigation is nowhere as nice as on the likes of GitHub.

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.