twistedpair
Their APIs are garbage from an agentic perspective. Try using Terraform to curate your GH org of a few hundred repos. Just running the `tf plan` will take 10min, because it's making thousands of API calls. Where's the bulk and batch APIs? No such thing. They are simply not agentic scale. Want to rerun the plan for your entire cloud vendor with thousands of VMs, IAM roles, buckets, etc... it'll run faster than checking on your repo labels.
GH needs rewritten from the ground up. The "repo is everything" arch has been creaking and falling over form many years now.
How funny that GitHub Actions' lack of tools forces you to make a bunch of billed cloud runs with GitHub for workflow edits. I'm sure their PMs are very concerned about this trend.
Or, maybe your #1 IT priority was moving everything to Azure instead ;)
> This requirement will be progressively enforced over time.
In the first Gulf War, we placed the Patriot batteries around Israel, as they said that if an Iraqi biological or chemical SCUD attack hit Tel Aviv, they would vitrify Baghdad.
Having nukes doesn't prevent _anyone_ from attacking you, but it does constrain those attacks to conventional means. And what if you pulled off a decapitation attack against Tel Aviv? Well their fleet of nuclear capable subs would make you pay.
What a joke. I suggest folks read up on the very poor performance of US ICBM interceptor systems. They're barely a coin flip, in ideal conditions. How is Claude going to help with that? Push the launch interceptor button faster? Maybe Claude can help design a better system, but it's not turning our existing poor systems into super capable systems by simply adding AI.
Are the other providers offering much better uptime GitLab, CircleCI, Harness? Saying this as someone that's been GH exclusive sicne 2010.
Enter K8s in 2017 and life became MUCH easier. I literally have clusters that have been running since then, with the underlying nodes patched and replaced automatically by the cloud vendor. Deployments also "JustWork", are no downtime, and nearly instant. How many sysadmins are needed (on my side) to achieve all of this, zero. Maybe you're thinking of more complex stateful cases like running DBs on K8s, but for the typical app server workload, it's a major win.
The simple B64 encoding didn't hide these creds from anyone, so every vendor out there's security team can collect them (e.g. thinking big clouds, GitHub, etc) and disable them.
If you did a simple encryption pass, no one but you would know what was stolen, or could abuse/sell it. My best guess is that calling node encryption libs might trigger code scanners, or EDRs, or maybe they just didn't care.
Let's say you have a limited life, package specific scoped, IP CIDR bound publishing key, running on a private GH workflow runner. That key only exists in a trusted clouds secret store (e.g. no one will have access it from their laptop).
Now let's say you're a "trusted" publisher, running on a specific GitHub workflow, and GitHub Org, that has been configured with OIDC on the NPM side. By virtue of simply existing in that workflow, you're now a NPM publisher (run any publish commands you like). No need to have a secret passed into your workflow scope.
If someone is taking over GitHub CI/CD workflows by running `npm i` at the start of their workflow, how does the "Trusted Publisher" find themselves any more secure than the secure, very limited scope token?
Sure, it might be a little bit of noise, but if you get a notice @ 3am of an unexpected publishing, you can jump on unpublishing it.
1. Does not default to running post-install scripts (must manually approve each)
2. Let's you set a min age for new releases before `pnpm install` will pull them in - e.g. 4 days - so publishers have time to cleanup.
NPM is too insecure for production CLI usage.
And of course make a very limited scope publisher key, bind it to specific packages (e.g. workflow A can only publish pkg A), and IP bound it to your self hosted CI/CD runners. No one should have publish keys on their local, and even if they got the publish keys, they couldn't publish from local.
Even @ 9:30am ET this morning, after this supposedly was clearing up, my doctor's office's practice management software was still hosed. Quite the long tail here.
I laud the recent efforts to remove the JS from JS tools (Go in TS compiler, esbuild, etc), as you don't need 100% of your lang utils written in the same interpreted lang, especially slow/expensive tasks like compilation.
What kind of crazy AI could possible have noticed that on the NPM side?
This is frustrating as someone that has built/published apps and extensions to other software providers for years and must wait days or weeks for a release to be approved while it's scanned and analyzed.
For all the security wares that MS and GitHub sell, NPM has seen practically no investment over the years (e.g. just go review the NPM security page... oh, wait, where?).
We need your help to scale up our cloud based, AI testing software startup and put our 40M Series C raise to work.
We’re a 100% serverless operation built on Google Cloud Platform that rapidly develops and deploys features on a CI/CD model. Seven years in, we’re a Gartner recognized industry player and growing our engineering ranks to keep building out our platform.
Our open positions:
- Software Engineer - Mobile Infrastructure (Onsite / Hybrid US)
- Software Engineer - Integrations Team (Remote India)
Our stack is built with modern Java 17, TypeScript, and Infrastructure as Code
Drop me (an engineer), any questions joe at-symbol mabl.com, and checkout our careers site [1]. We can’t wait to work with you.
Best practice would be to store such keys in an encrypted state, to prevent such breaches from non-production datasource access, or _even_ direct production database access.