Live data from Hacker News

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

nesbitt.io

101–110 of 267 posts

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

#101

Earlier quoted context omitted.

Can someone explain what this somewhat recent phenomenon is where people feel the need to defend the worlds biggest billion dollar businesses, that are also often subsidized by tax payer money in weird ways? How did we go in 20 years from holding these companies to account when they'd misbehave to acting as if they are poor damsels in distress whenever someone points out a flaw?

I won't "defend" Microsoft in this case, but I am always annoyed by phrases like "world's biggest billion-dollar businesses... bablah". Their size or past misbehaviors shouldn't be relevant to this discussion. Bringing those up feels a bit like an ad hominem. Whether criticism is valid should depend entirely on how GitHub Actions actually works and how it compares to similar services.

> Their size or past misbehaviors shouldn't be relevant to this discussion.

If the past misbehaviours are exactly the same shape, there's not all that much point re-hashing the same discussion with the nouns renamed.

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

#102

Earlier quoted context omitted.

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 i…

Well, actually, no, not everyone is free to use alternatives. Anyone using CI for "Trusted Publishing" of packages to PyPI or npm needs to use GitHub Actions or GitLab CI/CD. CircleCI and Travis CI are not supported. So many big open source projects for the two most popular languages in the world are now locked out of the alternatives you propose. (I find it extremely sketchy from a competition law perspective that M…

I was never convinced that trusted publishing solves any security problem, other than letting pypi eventually solve the problem of banning russian/iranian/whatever people just by relying on github doing it for them.

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

#104
post #65

Earlier quoted context omitted.

> there’s a whole generation of young engineers who don’t know how short their end of the stick actually is I'm from a generation who had to use VSS for a few years. The sticks are pretty long these days, even the ones you get from github.

> VSS I just had trauma! I will say that SourceSafe had one advantage: You could create "composite" proxy workspaces. You could add one or two files from one workspace, and a few from another, etc. The resulting "avatar" workspace would act like they were all in the same workspace. It was cool. However, absolutely everything else sucked. I don't miss it.

So it’s a workspace that includes changes from multiple branches at once, like `jj new revset-1 revset-2 revset-3 …` ?

(Git has octopus merges, jj just calls them “merge commits” even though they may have more than two parents)

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

#105
post #99

Earlier quoted context omitted.

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 i…

I tried to use CircleCI and I gotta say, it is absolutely not better than GitHub Actions…

I have also used Travis. Ditto.

Github Actions is actually one of the better CI options out there, even if on an absolute scale it is still pretty bad.

As far as I can tell nobody has made a CI system that is actually good.

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

#106
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…

“Good CI systems shouldn’t support secrets, at most there should be [the most complicated secret support ever]”

Let’s just call it secret support.

I agree with your suggestion that capabilities-based APIs are better, but CI/CD needs to meet customers where they’re at currently, not where they should be. Most customers need secrets.

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

#107
post #80

Earlier quoted context omitted.

An interesting things is that GitHub is an expensive service and my guess would be that MS makes good money on it. Our small company paid about 200+ USD monthly for GitHub, much larger cumulative cost than Windows licenses. My believe was that Windows is getting worse, because it is considered legacy business by MS in favor of new offerings such as GitHub subscriptions.

I wouldn't be surprised if there isn't some plan to make all of GitHub's backend "legacy" and switch everyone to the dumpster fire that is Azure DevOps and if you thought GitHub Actions was bad...

> I wouldn't be surprised if there isn't some plan to make all of GitHub's backend "legacy"

> and switch everyone to the dumpster fire that is Azure DevOps

The other way around. Azure DevOps is 1/2 a backend for Github these days. Github re-uses a lot of Azure Devops' infrastructure.

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

#108
post #76
post #62

Earlier quoted context omitted.

We use proprietary tools (QNX compiler, Coverity static analysis, ...) and those require access to a license server which requires some secret. I don't really understand what you mean by "secure enclave style"? How would that be different?

With a secure enclave or an HSM, there's a secret, but the users do not have access to the secret. So, if you have a workflow that needs to, say, sign with a given private key, you would get an API that signs for you. If you need to open a TLS connection with a client certificate, you get a proxy that authenticates for you. I suppose I would make an exception for license keys. Those have minimal blast radii if they l…

And how is that exposed to the CI/CD? An environment variable? Some bespoke tool that the CI runs to read the secret from the Secure Enclave?

Your approach boils down to “lets give each step its own access to its own hardware-protected secrets, but developers shouldn’t otherwise have access”

Which is a great way to “support secrets,” just like the article says.

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

#109
post #80

Earlier quoted context omitted.

An interesting things is that GitHub is an expensive service and my guess would be that MS makes good money on it. Our small company paid about 200+ USD monthly for GitHub, much larger cumulative cost than Windows licenses. My believe was that Windows is getting worse, because it is considered legacy business by MS in favor of new offerings such as GitHub subscriptions.

I wouldn't be surprised if there isn't some plan to make all of GitHub's backend "legacy" and switch everyone to the dumpster fire that is Azure DevOps and if you thought GitHub Actions was bad...

When Microsoft bought GitHub they cancelled GitHubs own early CI effort and rebranded the existing Azure DevOps as GitHub Actions.

The GitHub Actions runner source code is all dotnet. GitHub was a Ruby shop.

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

#110
post #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?

The secret is held by the metadata server that the CI instance has access to

Or: the deployment service knows the identity of the instance, so its secret is its private key

Or, how PyPI does it: the deployment service coordinates with the trusted CI/CD service to learn the identity of the machine (like its IP address, or a trusted assertion of which repository it’s running on), so the secret is handled in however that out-of-band verification step happens. (PyPI communicates with Github Actions about which pipeline from which repository is doing the deployment, for example)

It’s still just secrets all the way down

Post reply on HN