starbelly
commented
2 years ago Tagging @ericmj @wojtekmach and @supersimple for hex.pm thoughts.
Closed starbelly closed 1 year ago
starbelly
commented
2 years ago Tagging @ericmj @wojtekmach and @supersimple for hex.pm thoughts.
wojtekmach
commented
2 years ago I believe there is a few things to consider with automatic publishing.
First of all:
Note that care should be used when automating publishing because Hex can output important warnings or even recommendations on how to improve your package that will easily be missed when the process is automated. (...)
(https://hex.pm/docs/publish#publishing-from-ci)
Secondly, we are concerned about putting secrets into public repos that anyone can send PRs to and thus run any code on CI. Perhaps GitHub protects against this well, we just don't know, so any pointers would be appreciated. If an adversary is able to leak the token they could completely take over not only the package but all other packages as well as the account itself. FWIW we plan to add per-package and maybe even per-action (e.g. just publishing but not managing owners) permissions in the future. Moreover, we have basic 2FA support on the Hex.pm website and the next step, probably the most appealing use case for this, was to 2FA-gate package publishing, and I'm not sure how 2FA would play with automatic publishing.
Regarding porting https://github.com/straw-hat-team/github-actions-workflows/tree/c2172066b9e058f6c266d9e5013f5ddf612a28e9/elixir to setup-beam, worth mentioning that setup-beam is project-independent and these workflows are project-dependant, they only make sense in a Mix project. Secondly, setup-beam is used by libraries & apps but Hex publishing is only useful to libraries. Maybe neither of this distinctions matter in practice. Personally I would not add Hex publishing to setup-beam, I think it is orthogonal.
paulo-ferraz-oliveira
commented
2 years ago Personally I would not add Hex publishing to setup-beam, I think it is orthogonal.
I agree with this. At its core, setup-beam is simply about creating an environment for CI on GitHub.
lpil
commented
2 years ago Secondly, we are concerned about putting secrets into public repos that anyone can send PRs to and thus run any code on CI. Perhaps GitHub protects against this well, we just don't know, so any pointers would be appreciated.
Good shout. We'd need to be very careful here.
Secrets don't get shared with pull requests by default, there's a little information on that here, but it would be good to find more detail.
tsloughter
commented
2 years ago Agreed it is orthogonal but I saw adding this to "setup-beam" to mean renaming that repo and all of the actions/workflows still being independent. Its just we would maintain them together.
I just realized I haven't tried mix's CI publishing. For this to work with manual approval we need to have it (and rebar3) output the warnings and details of the package to publish and then there be the required approval.
Maybe a "dry run" will give all those details? So the action could do a dry run, then manual approval requirement, then the actual publish.
Would be cool if it could prompt for 2FA, but I'm sure it can't. Maybe a proposal to send to github. Don't some package managers even require 2FA for popular packages, like rubygems? So maybe something they'd consider implementing.
yordis
commented
2 years ago Also worth saying, I was referring to adding "Workflows" as well, not just the actions, but one step at a time.
starbelly
commented
2 years ago Secondly, we are concerned about putting secrets into public repos that anyone can send PRs to and thus run any code on CI. Perhaps GitHub protects against this well, we just don't know, so any pointers would be appreciated. If an adversary is able to leak the token they could completely take over not only the package but all other packages as well as the account itself. FWIW we plan to add per-package and maybe even per-action (e.g. just publishing but not managing owners) permissions in the future. Moreover, we have basic 2FA support on the Hex.pm website and the next step, probably the most appealing use case for this, was to 2FA-gate package publishing, and I'm not sure how 2FA would play with automatic publishing.
I've always myself discouraged publishing from CI for the reasons you outline and that was my reaction when this was proposed, but then I had to debate with myself :) Basically, I have to ask myself "Are people doing this anyway? Are they going to do it anyway?", both mix hex and rebar3 hex already provide ways to do this, and based on previous issues and commentary I've seen around or involved in, I would say the answer is yes.
If the answer to "Will people do this anyway?" is yes, then we have to ask ourselves, should we provide a vetted way to do this?
But there's also the question of maintenance burden to be discussed and trying to provide solutions that work for many cases.
I think I'd like to see what this might look like before saying yea or nay.
P.S. I love the idea of more granular permissions :)
And I love the ideas that @tsloughter has put out 🥳
starbelly
commented
1 year ago I think this issue can be closed since there hasn't been any traction. If someone has other notions, we can simply re-open.
yordis
commented
1 year ago @starbelly can I do some work in terms of some proposals?
Either by showcasing some examples or providing a more straightforward setup thru templates and whatnot.
starbelly
commented
1 year ago @yordis By all means. I just thought this issue has went to sleep and was just trying to help get a tidy home 😁
starbelly
commented
1 year ago So, I'm back to closing this issue. Fred pointed out something recently that happened via build artifacts and github CI (not necessarily a reflection of github to be clear) :
Novel Pipeline Vulnerability Discovered
That just reinforces my belief that some things should not be automated. People can always automate if they choose to (and they do), but I don't think we should support others in said efforts.
yordis
commented
1 year ago That just reinforces my belief that some things should not be automated. People can always automate if they choose to (and they do), but I don't think we should support others in said efforts.
What do you think about giving proper setups? Therefore, people avoid common mistakes in setting things up, which is why I brought attention to the topic.
I don't think discouraging people from having a proper setup for releasing packages is the solution to the problem. It is already painful to deal with some packages full of comments asking for libraries to be released, maintainers that do not have access to Hex being able to help, and many other situations that could be optimized.
Being said, people should be concerned with the topic. I am not proposing to do it without solid consideration about it.
ferd
commented
1 year ago The risk is that unless your CI tool has the ability to have distinct environment vars from branch operations vs. main operations, and that they are properly segmented, anyone with a prior commit can extract the credentials to publish a package and then start publish worm-like behavior that also actively and invisibly extracts credentials of other repos (when pulled in as a dependency).
This is fundamentally going to be a behavior that relies on each individual project configuring things safely. I'm not sure there's currently a great way to enforce any of that.
Background
A proposal by by @yordis on EEF slack was made in regards to adding publishing abilities to setup-beam or perhaps as another action. I will drop the idea whole sale as was below :
Yordis has offered to put up a PR for this, with the understanding it may be rejected. The sense of the few people (including myself) is this would be fine, yet there are some open questions and/or concerns that should be discussed. Ultimately this issue serves as place to track the progress of this work.
Objective(s)