Live data from Hacker News

GitHub Actions has a package manager, and it might be the worst

nesbitt.io

21–30 of 267 posts

Re: GitHub Actions has a package manager, and it might be the worst

#21
post #7

Earlier quoted context omitted.

This is the first time I've heard of this, do you happen to have an example?

https://github.com/orgs/actions/repositories?language=&q=&so... https://github.com/actions/create-release

The funny thing about the last one is that those actions ultimately boil down to invoking their CLI tool (which is pre-installed on the runners) with "gh release create ...", so you can just do that yourself and ignore the third-party actions and the issues that come with them. Invoking an action isn't really any easier than invoking the CLI tool.

Re: GitHub Actions has a package manager, and it might be the worst

#23
post #8

> The researchers identified four fundamental security properties that CI/CD systems need: admittance control, execution control, code control, and access to secrets. Why do CI/CD systems need access to secrets? I would argue need access to APIs and they need privileges to perform specific API calls. But there is absolutely nothing about calling an API that fundamentally requires that the caller know a secret. I woul…

> But there is absolutely nothing about calling an API that fundamentally requires that the caller know a secret.

There is if you pay for API access, surely?

Re: GitHub Actions has a package manager, and it might be the worst

#24
post #8

> The researchers identified four fundamental security properties that CI/CD systems need: admittance control, execution control, code control, and access to secrets. Why do CI/CD systems need access to secrets? I would argue need access to APIs and they need privileges to perform specific API calls. But there is absolutely nothing about calling an API that fundamentally requires that the caller know a secret. I woul…

CI is arguable, but how do you intend to do deployments with no secrets?

Re: GitHub Actions has a package manager, and it might be the worst

#25
post #9

Yep. I'm switching our workflows to instead use regular utilities running inside a Docker container. This works well for _most_ things. There are some issues with doing docker-in-docker for volume mapping, but they're mostly trivial. We're using taskfiles to run tasks, so I can just rely on it for that. It also has a built-in support for nice output grouping ( https://taskfile.dev/docs/reference/schema#output ) that…

Do you have a write up about this? Actions are great, but my #2 gripe with actions, after the tenuous security posture, is that the default practice is not to run/validate actions locally.

Re: GitHub Actions has a package manager, and it might be the worst

#26
post #19

Earlier quoted context omitted.

> I would argue that a good CI/CD system should not support secrets as a first-class object at all. Instead steps may have privileges assigned. At most there should be an adapter, secure enclave style, that may hold a secret and give CI/CD steps the ability to do something with that secret, to be used for APIs that don’t support OIDC or some other mechanism to avoid secrets entirely. CI/CD does not exist in the vacuu…

CI shouldn't do deployments, deployment pipelines should run separately when a new release passes CI Of course the general purpose task runner that both run on does need to support secrets

Hmm, I have long assumed that a perfectly executed CI/CD setup would be based on a generic task runner... But maybe not?

Only the CI part needs to build; it needs little else and it's the only part of a coherent setup that needs to build.

Re: GitHub Actions has a package manager, and it might be the worst

#27
I'm not sure I follow.

If I write actions/setup-python@v1, I'm expecting the action to run with the v1 tag of that repository. If I rerun it, I expect it to run with the v1 tag of that repository...which I'm aware may not be the same if the tag was updated.

If I instead use actions/setup-python@27b31702a0e7fc50959f5ad993c78deac1bdfc29 then I'm expecting the action to run with that specific commit. And if I run it again it will run with the same commit.

So, whether you choose the tag or the commit depends on whether you trust the repository or not, and if you want automatic updates. The option is there...isn't it?

Re: GitHub Actions has a package manager, and it might be the worst

#29
post #19

Earlier quoted context omitted.

> I would argue that a good CI/CD system should not support secrets as a first-class object at all. Instead steps may have privileges assigned. At most there should be an adapter, secure enclave style, that may hold a secret and give CI/CD steps the ability to do something with that secret, to be used for APIs that don’t support OIDC or some other mechanism to avoid secrets entirely. CI/CD does not exist in the vacuu…

CI shouldn't do deployments, deployment pipelines should run separately when a new release passes CI Of course the general purpose task runner that both run on does need to support secrets

you conveniently ignored the "CD" part of CI/CD

Re: GitHub Actions has a package manager, and it might be the worst

#30

What’s more, GitHub has basically stopped maintaining their own actions, pushing people to sketchy forks to do basic things. Their entire ecosystem is basically held up with duct tape and gets very little investment.

Everyone is free to use alternative CI/CD workflow pipelines. These are often better than Github Actions.

These include

- https://circleci.com/

- https://www.travis-ci.com/

- Gitlab

Open source:

- https://concourse-ci.org/ (discussed in the context of Radicle here https://news.ycombinator.com/item?id=44658820 )

- Jenkins

-etc.

Anyone can complain as much as they want, but unless they put the money where their mouth is, it's just noise from lazy people.

Post reply on HN