This is a very good writeup.

Zooming way out (perhaps to the point of useless observation), it's a pity that the web embedded VSCode editor is signed into GitHub at all. Defense-in-depth or not, a huge vulnerability surface arises from that original sin. It'd be like if you had a god-permissioned GitHub API token stored in world-readable plaintext on your workstation for the malicious-NPM-package-of-the-week to find.

In a perfect world, it'd be awesome if the in-browser IDE launched with a temporary per-repo permission scope or token that allowed only pull and push to the repo in question; no github.com web session whatsoever. If you want the full GitHub web UI experience, well .... go back to github.com; make github.dev a single-repo service.

I'm assuming that's a) inconvenient for users, b) hard to implement, and c) a historical assumption baked into a lot of the github.dev tooling, though. Ah well.

▲

ammar2 4 hours ago | parent | next [-]

> it'd be awesome if the in-browser IDE launched with a temporary per-repo permission scope

That's actually exactly what they do for codespaces. The token only has read/write on the repo you activated for the codespace [1]. They should definitely consider doing that for github.dev as well.

[1] https://orca.security/resources/blog/hacking-github-codespac...

▲

amluto 3 hours ago | parent | prev | next [-]

> temporary per-repo permission scope or token that allowed only pull and push to the repo in question

How about pull from the repo but only push to a staging area from which the user, but not the token, can push for real?

Frankly, LLM agents should do this too. Letting your LLM push seems foolhardy to me.

	▲	namibj an hour ago \| parent \| next [-]
		Jules is heavily restricted in what it can do to your repos.
	▲	alostpuppy an hour ago \| parent \| prev \| next [-]
		Exe.dev has an integrations feature which is similar allowing you to grant access to specific repos without having give the VMs credentials. I think it’s a similar pattern to iron.sh. I have been thinking more and more about how I might use this pattern.
	▲	moi2388 2 hours ago \| parent \| prev [-]
		That makes so much more sense.

▲

owl57 4 hours ago | parent | prev [-]

If the malicious-npm-package-of-the-week is reading arbitrary files on your workstation, isn't it usually able to run git clone/push/whatever with your current credentials anyway?

	▲	digi59404 4 hours ago \| parent \| next [-]
		Yes, but also no. For example in GitLab a user who’s infected could push code to a branch. Then it could even make a merge request to pull that branch into main (if main is protected). But then someone else on the team should have to manually approve that MR to allow it to be merged to main. This kind of defeats the ability of malware to push stuff out automatically.
	▲	ikiris 2 hours ago \| parent \| prev [-]
		Not if they're touch required in a secure enclave like a yubikey