241–250 of 267 posts
Earlier quoted context omitted.
What are Depot runners?
Founder of Depot here. We provide faster and more reliable GitHub Actions runners (as well as other build performance services) at half the cost of GitHub [0] [0] https://depot.dev/
> 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…
> 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. This all seems right, but the rea…
Earlier quoted context omitted.
You might want (or _need_) to sign your binary, for example. Or you might want to trigger a deployment. Github actually is doing something right here. You can set it up as a trusted identity provider in AWS, and then use Github to assume a role in your AWS account. And from there, you can get access to credentials stored in Secret Manager or SSM.
Yeah I sign my project APKs so people can install them from the action's artefact - name: Retrieve keystore for apk signing env: KEYSTORE: ${{ secrets.KEYSTORE }} run: echo "$KEYSTORE" | base64 --decode > /home/runner/work/keystore.pfk
GitHub should instead let you store that key as a different type of secret such that a specific workflow step can sign with it. Then a compromised runner VM could possibly sign something that shouldn’t be signed but could not exfiltrate it.
Even better would be to be able to have a policy that the only thing that can be signed is something with a version that matches the immutable release that’s being built.
I've not understood the propensity for using yaml for CI pipelines and workflows in general. A decent programming language would be a big improvement. Why not just build the workflows themselves as docker images? I guess running other docker images in the workflow would then become a problem.
Dagger does what you're describing: https://dagger.io/
Also, using the dagger github action should make the transition easier I suppose: https://github.com/dagger/dagger-for-github
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.
> Their entire ecosystem is basically held up with duct tape and gets very little investment. That isn't gonna get better anytime soon. "GitHub Will Prioritize Migrating to Azure Over Feature Development" [1] [1] https://thenewstack.io/github-will-prioritize-migrating-to-a...
We had a critical outage because they deprecated Windows 2019 agents a month earlier than scheduled. MS support had the gall to both blame us for not migrating sooner, and refuse to escalate for 36 hours!
Earlier quoted context omitted.
> I've not understood the propensity for using yaml for CI pipelines and workflows in general. A decent programming language would be a big improvement. Because it's clear to write and read. You don't want your CI/CD logic to end up being spaghetti because a super ninja engineer decided they can do crazy stuff just because they can. Same reason why it's a bad idea to create your infrastructure directly in a programmi…
IME on a Pulumi for IaC team, writing infra in a real language (TypeScript) is MILES better than- you can do conditions, have typed outputs, etc and not have it be a bastardized imperative YAML mess. YAML is fine for data, but inevitably stuff like workflows end up tacking on imperative features to a declarative language.
You can have conditions and types without having the full flexibility allowing madness of a full language with HCL.
Earlier quoted context omitted.
CircleCI and I believe GHA support injecting signed JWTs you can use to bootstrap identity be it an IAM role or some other platform where you can trust an OIDC issuer
> injecting signed JWTs How is that not secrets management?
Earlier quoted context omitted.
> I've not understood the propensity for using yaml for CI pipelines and workflows in general. A decent programming language would be a big improvement. Because it's clear to write and read. You don't want your CI/CD logic to end up being spaghetti because a super ninja engineer decided they can do crazy stuff just because they can. Same reason why it's a bad idea to create your infrastructure directly in a programmi…
IME on a Pulumi for IaC team, writing infra in a real language (TypeScript) is MILES better than- you can do conditions, have typed outputs, etc and not have it be a bastardized imperative YAML mess. YAML is fine for data, but inevitably stuff like workflows end up tacking on imperative features to a declarative language.
Earlier quoted context omitted.
IME on a Pulumi for IaC team, writing infra in a real language (TypeScript) is MILES better than- you can do conditions, have typed outputs, etc and not have it be a bastardized imperative YAML mess. YAML is fine for data, but inevitably stuff like workflows end up tacking on imperative features to a declarative language.
I've thought about using Pulumi many times. Sounds like dagger.io can be a good complement for the workflow use case?
I really really want to use dagger, but I don’t think there’s organizational interest in it.
Has anyone built a “deep fork” tool that lets you make a private fork of all dependencies, then modifies their transitive dependencies to point to private forks, and so on? Ideally in a way where updates can be pulled in manually? Seems feasible.
If you do, please submit a "show HN." I'd love to use it.