Skip to content
This repository has been archived by the owner on Feb 9, 2021. It is now read-only.

Issue #52, There is a real binary distribution trust issue. #55

Closed
MSP-Greg opened this issue Jan 23, 2020 · 6 comments
Closed

Issue #52, There is a real binary distribution trust issue. #55

MSP-Greg opened this issue Jan 23, 2020 · 6 comments

Comments

@MSP-Greg
Copy link
Contributor

MSP-Greg commented Jan 23, 2020

@bryanmacfarlane @ethomson

'There is a real binary distribution trust issue.'

That seems to be the main issue here, and ruby/ruby has never released binaries. Obviously, other languages have, but there's also several copies of OpenSSL binaries on the Windows image because OpenSSL doesn't release binaries. To my knowledge, for some of the builds one cannot even get to the build code or a log of the build behind an https CI system.

So, GH wants 'binary distribution trust', but it doesn't want to host the binaries themselves.

I think there needs to be another solution.

The build system (rbenv/ruby-build) used by use-ruby-action has a few maintainers that are GH staff.

If a repo/org account was started that was more of a 'collective' of people, could it create and host the binary builds? Not part of GH, but 'approved' by GH? Certainly could contain whatever 'due diligence, but if you really want secure' language as needed...

@eregon
Copy link
Contributor

eregon commented Jan 23, 2020

Note that I proposed to consider moving my actions under the ruby organization in #44 (comment) but it seems there was no interest.

@bryanmacfarlane BTW, I think there was no need to lock #52 (comment). Closing would be enough.
I think that's rude, as I had open questions left for understanding what ethomson said, and I would like to clarify some things since I think they were misunderstood (your own way refers to the ADR, using packages, etc). You also didn't reply to the issue of discoverability for the marketplace.

@bryanmacfarlane
Copy link
Member

bryanmacfarlane commented Jan 23, 2020

@MSP-Greg - yes, that's the crux of the issue.

Right now, our actions/setup-xxx actions (1) resolve to what's on the virtual-environments VM or (2) optionally pull from a trusted binary distribution if the version spec cannot be satisfied by the VM image.

For example, if you look at setup-node action, it pulls from the official node dist. The same one users acquire node from. It's trusted. The comment and other discussions here was referring to an individual repo with a release distributed by an individual user. Note ruby-build is a build solution, not a trusted distribution.

The virtual-environments team is building a tool cache of built rubies and I believe they are planning on open sourcing it. I referred to this in the ADR . I'm discussing with that team how we could consume the same store of binaries. The vm gen and this action should pull from the same trusted store. So the problem is not just with this action.

@bryanmacfarlane
Copy link
Member

Coming up with a common way to consume prebuilt binaries should occur in the ADR instead of various issues: #49

@bryanmacfarlane
Copy link
Member

@MSP-Greg - I'm going to close since this is a dupe of #49 - if it's not clear in that ADR, it should address the topic there. OK?

@bryanmacfarlane
Copy link
Member

Thanks @MSP-Greg! Let's iterate on the ADR ☝️ and also in actions/runner-images#281

Since the VM team is iterating on building a cache of images relevant to their VM environments, I think that's an interesting path to pursue. I'll update the ADR with details around that option. I met with them this week to understand where that is heading. More in the ADR soon.

Closing this for now but let me know if there's anything else I can answer.

@dentarg
Copy link

dentarg commented Jan 24, 2020

Closing this for now but let me know if there's anything else I can answer.

@bryanmacfarlane I saw this comment at #52 (comment)

If the demand for specific versions becomes an issue, It will push the priority of #49 ( note that we're discussing that right now as well ).

I know it been 3 days since you made it, so maybe your understanding has changed since, but if not, I just want to reiterate that I think specific versions should be your top priority, if you want to attract adoption of GitHub Actions as CI for Ruby projects and applications.

I understand you are working on it and you have your process for it, and hopefully you can get it done sooner rather than later.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants