-
-
Notifications
You must be signed in to change notification settings - Fork 936
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
Comparing gem's source code on source repository and what's inside the .gem in rubygems #1943
Comments
Thanks for this. I'm not a rubygems maintainer, but have a big interest in this issue (I run Dependabot, which creates dependency update PRs on GitHub and links to the source code diff for those updates). I'm super keen to help in any way on this one. If we need to link up with folks at GitHub then I work with them pretty closely thanks to Dependabot. If we want a third party to do the work of gem verifying then Dependabot could do that work (there's already an issue on our feedback repo suggesting that). If it needs a bunch of engineering time then I can put in time on this. |
It's a great idea. My only minor concern is that this interconnects (and thus mandates) GitHub, but not everyone on rubygems.org may have (or want) to have an account at GitHub. I understand that third party may mean less work though. If possible, my personal favourite here would be to be able to do so through the account on rubygems.org - what is done behind the scene would then be not so important (for me as a user), but I think it would be fairly bad if users would be forced to have multiple accounts at several separate/disparate websites. |
If I understand it well, this would be fixed by adopting SLSA. |
Hi,
I think that would be great to have some kind of "reproducible builds" (like Debian does).
This doesn't totally prevent issues like hidden backdoors but could be a good step (the attacker would need commit access on Github and push access on rubygems).
The text was updated successfully, but these errors were encountered: