Hacker News

zizmor wouldn’t catch that condition at the moment, although it does have similar checks for other unsound conditions and incorrect/vulnerable bot actor checks. This one wouldn’t be too hard to add, though.

(Source: I am zizmor’s maintainer.)

Frankly it's absurd that you don't get a null reference error in that case. I knew Github Actions was bad... I didn't know it was that bad. This is 90% Github's fault.

yeah it is so mad:

TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\\"/g' | sed "s/'/\\\'/g")

Even in ruby it would have been something like

TITLE=shell_escape(github.event.issue.title)

where shell_escape could at least have unit tests. I don't know anything about github actions, but anything that takes user input needs to be processed with a language that uses static typing I believe to help ensure that the user input doesn't get into expressions given to other programs, shell, sql, or whatever.

Unix was just not made for this sort of thing. It was made for in-house people to write patent applications.

Bash script embedded in yaml. Wow, I'd view each of those with heavy suspicion on its own, and they're nonlinearly bad together because of how special chars interact.

YAML seems reasonable because it allows the sequence of steps to be treated as data, which then enables GUI visualisation, introspection, etc... without actually having to run anything.

That's critical for a platform like GitHub and for devops pipelines in general.

The failure is that "data" ends up being a "terrible custom DSL" that is bad at everything: Not good at data, not a good DSL, and not even a proper programming language.

The best approaches I have seen to this kind of thing are:

- Pulumi: You get to run custom code, but it outputs data. In other words, your "build automation script" must be a pure function taking data in and returning data out. The resulting data is then treated as the "thing" that the pipeline executes, which means that all decisions (parameters, inputs, etc...) have to be "baked in", before the pipeline starts executing.

- Google CUE (Configure Unify Execute): lets you build up JSON using a strongly typed constraint language. Great for huge, complex configuration.

There should be an array of arguments instead of space-separated string.

It can be that while also causing problems. It's like when a self driving car crashes, it's big news and everyone runs around like their pants are on fire. When a human driver crashes, it's a blip on local news or not even that.

CI is shell scripts as a service. There is no safe way to use it.

AI does it a lot faster and ignores rules even harder than humans do, but it's not the root problem here.

Sadly I'm not. Either way, how LLMs work mean that traditional software analysis tools are every bit as important as they were in the before times. This is why we see a lot of hype around LLMs and formal verification.

I mean… it’s only Monday!

But yes, there is an interesting change in the past decade, where everything new must be over-hyped.

Perhaps it is attention overload and needing to shout. Perhaps it’s that technological progress has significantly slowed while communication options have exploded (coincidence?).

I look at it a lot like EVs. They’re great, if your use case is inside the specific band. But, that isn’t who they were being marketed to. And now… “pushback” is putting it lightly.

yes, it says "Now you can have beautiful clean workflows!" and links to a youtube video of a TV ad for a dermatologist.

Yes :-)

> I'm interested in how that turns out 6 months later.

That really is the real question, isn't it?

For me it has been a mixed bag so far, I've seen some companies use this tech in a slow and deliberate manner to do what they were already doing but a little bit faster. I've also seen hail Mary passes where the whole codebase was turned over to agents to go wild on with an undersized team and little to no QA. Time will tell...

> but withhold from others, even though the code change itself is likely small.

Prediction: programming is going to change massively not only because the cost of creating code will go down, but because people are so tired of this sort of gatekeeping "we know better" from programmers.

Lack of a local runner is my biggest peeve. Any novel GHA workflow creation results in a PR with 100 commits, until you can finally sort out all the non-obvious idiosyncrasies. For any modestly complex workflow, I move everything to a bash or TS file and call that, and then you can use _coding tools_ and a _local_ dev/eval loop.

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.

And worse: GitHub Actions not a full-fledged programming environment by itself either, so you're inevitably going to have to deal with nontrivial shell scripts on top of all the YAML mess.

The things done in yaml today would've been obscure bash oneliners had YAML not existed.

Jenkins still exists and it's no less complicated than Github Actions. The complexity gets hidden in obscure script files, obscure tabbed UI, and remote services for doing things Jenkins itself can't do. Defaulting to system tooling makes it almost impossible to predict what a job will do unless you know exactly how paths and tooling are set up (and what versions they're running).

None of my personal experiences with Jenkins had scripts that ran locally, they all relied on pre-installed software on the server because that was the thing people would do before the great YAMLification. You could copy-paste the Jenkins job, but unless you have Jabberwocky v2018.3 installed in /home/JabberWock/RELEASE, the script will fail.

The entire software development flow has been made incredibly complex by hooking up automations into every nook and cranny.

All of these complications need to be enabled manually, though. If your flow is complicated, you can cut it down to manageable size by doing a few more processes manually.

Luckily, all of the simplication and reproduction steps for Github also apply to Jenkins. Github YAML files are just scripts with different syntax, after all. Just like you can run bash locally, you can run act and reproduce whatever Github trigger you need. From there, you can simplify pipelines, stop curl2bashing "plugins", and so on.

As a data/serialization format (the original intended use of JSON), I think no comments is the right choice, since adding comments introduces a bunch of questions about how comments ought to be parsed into a datastructure (or if they should be sent/(de)serialized at all). But for config files the lack of comments is the wrong choice, since typically you want to explain why things are set the way they are. The lack of ordering of entries also makes total sense for data/(de)serialization, but makes no sense for a config. I think the problem is people are lazy and just want to JSON.parse() everything, and used JSON in places it doesn't belong, like config files.

Seems more like the opposite vein, JSON's lack of comments or other affordances has kept it safe from footguns

I've seen people put "//" keys in their json lol

The YAML spec/parse _itself_ does interpolation and logic - incorrectly in some cases. YAML is pretty much never the right solution.

Assigning an env var to an empty variable (env: { myvar: ${{unsetfoo}} }) should trigger an error, not silently pass an empty string.

> It’s find for actions and workflows as long as you do no interpolation and logic.

How do you specify actions and workflows without interpolation and logic kind sir?

I don't get it either. There was a point where I had to write YAML, but it wasn't intuitive to begin with, and months in I was still accidentally setting the wrong number of indents or some nonsense.

In accordance with the prophecy.

I must be too tired because I cannot figure out what happened in that pull request. The PR/source branch was over a year old with none of the commits adding up to the full diff. There is [1], which introduced the vulnerability but didn't remove the environment variables above, then master is merged into it via [2] (but still doesn't show the variables being removed), yet in the full PR diff they're gone.

In any case, I'm pretty sure you misattributed the vulnerability to Copilot because the PR got squash-merged and _all_ of the changes were then attributed to every contributor in that PR, despite Copilot only appearing on one of the commits.

[1] https://github.com/snowflakedb/snowflake-connector-net/commi...

[2] https://github.com/snowflakedb/snowflake-connector-net/commi...

“There is absolutely no way Bitcoin will ever trade for more than $200.. Impossible!” he said.

And now the "AI" industry is doubling down on it - with hatbot prompt injection.

> It's like in-band signalling in the telephone network...

The major LLM providers claim that they are very committed to security and that their products are very dangerous and capable of great harm.

Given that their tools do what Ma Bell's systems did in the mid-1900s, [0] -which the entire software world relearned was a terrible idea by the early 1990s- they are definitely

1) Lying about the extent of their commitment to security

2) Lying about the extent of the harm that their tools are capable of

3) Both

My money is on #3.

Because of the fact that -in the absence of unambiguous laws that require meaningfully-severe punishment- even the most fucknasty and amateur hour security failures nearly always have little to no impact on the company that causes them, the major LLM providers have absolutely done the smart thing by providing commercial tools that have remote code execution vulns that would automatically give them a Critical CVSS score.

To put it another way: "the market" has no idea how to evaluate computer security claims. Because of this, every dollar you spend on proactively fixing security problems is nearly always a dollar wasted... it's better to wait until someone important gets Big Mad before spending the money. Does this make the world worse? Absolutely! Does this make companies selling software and software services much more money? Definitely!

[0] If the major LLM providers did separate unsanitized data from program instructions and ensure that the two are never mixed, things like [1] would not be possible.

[1] <https://www.schneier.com/blog/archives/2026/08/prompt-inject...>

No. A Snowflake maintainer opened a PR, Copilot suggested a change (introducing a vulnerability), the maintainer accepted and committed it to their PR, and another Snowflake maintainer approved and merged the PR.

What made you make that assessment?

I'm all for using a council of LLMs, I wrote a tool for it https://github.com/joelio/owl - but you still need to read through PRs yourself, at the very least.

It's not actually, thats just shoving more shit into the shit pipeline.

Humans need to review this stuff yall there's no way around that, apparently to some, very inconvenient reality.

Tests would have caught it = https://github.com/rhysd/actionlint injection check

I have been talking to people who want to autoreview and autoapprove "minor" AI prs. For security especially, I think if the models weren't enough to prevent the issues, they aren't enough to judge what is minor.

^^

Absolutely.

Nothing in the PR jumps out as a red flag. Unless you know how the internals work, I suppose.