confused deputies in github?

[Raoul Duke]

https://news.ycombinator.com/item?id=46092220

[Matt Rice]

On Sun, Nov 30, 2025 at 2:25 AM Raoul Duke <rao...@gmail.com> wrote:
>
> https://news.ycombinator.com/item?id=46092220
>

I guess I struggle to see how this is a confused deputy exactly,
because it feels like the attacker has been deputized and is given the
secrets directly, and the ability to perform arbitrary code execution.

Where the traditional confused deputy doesn't involve the attacker modifying the
deputy, just confusing it. Unless you mean something like the whole
CI infrastructure is the deputy
and is intended to run when the code changes, but is configured in
such a way that it also runs when
the CI scripts change (thus confusing it?). Giving direct access to
secrets via environment variables
always seems like it should be closely held in favor of holding
secrets and referring to them via proxy
so you can only exfiltrate the index bits of a secret at worst...

About the worm propagation aspect of this attack. I've seen a lot of
arguments that c
and c++'s compilation models by following a "worse is better"
philosophy are "more secure" than newer package oriented models. When
it's basically the exact same `exec` model as `make`,
with the packaging concept more convenient to attack. Because it does
not actually involve any
formal distribution layer. I feel like there is a very direct analogy
"shooting the messenger" in blaming the distribution layer.

I tend to feel like we don't really need to toss out the convenient
packaging, if the compilers themselves
used a capability model, and actually isolated builds from the host system.

Anyhow I find it somewhat astounding how quickly people want to blame
the packaging model without
any reevaluation of the underlying os security model that is actually at fault.
Some argue as though it were a dilemma "security or convenience, pick one."

Apologies if this is too long of a rant, it seems like native
capability os compilation models really
cover both these attacks using straightforward and well known
patterns. Yet every tool in the toolchain is written
under the assumption of only accepting trusted input. I find it
particularly frustrating.