News for hackers. Stuff that matters.
Re:Embedded Malware in Coa by _wldu on Friday November 05, 2021 @07:57AM (#29117982)
It seems that all of these should be cryptographically signed by a developer's private key before publication and then verified by others before use. Is that not the case?
Re:Embedded Malware in Coa by smhg on Friday November 05, 2021 @08:02AM (#29118019)
There seems to be a call for action [0] directed at NPM.

[0] https://www.change.org/p/npm-please-secure-package-releasing

Re:Embedded Malware in Coa by jacques_chester on Friday November 05, 2021 @08:36AM (#29118306)
I agree that all software package repositories -- NPM, Rubygems, PyPI, Maven, NuGet, Crates, etc -- should have two minimum baseline security policies:

1. All accounts are MFA, no exceptions.

Only CI/CD usecases justify some laxity. Only push tokens should be non-MFA-able for CI/CD purposes, and they should only be usable for push. Tokens should only be obtainable with MFA.

Ideally these too would be part of a multi-step OAuth2 or OIDC refresh token to access token flow, so that any given access token is only used once and CI/CD jobs never get to see the refresh token.

And while we're on tokens: they should all expire, after a short period of time, without exception.

2. Signing packages is opt-out, not opt-in.

The two reasons package signing is relatively rare are that (1) in most ecosystems it is unwieldy, (2) not actually that effective at providing guarantees (self-signed certs are no better than a pinky promise).

But once these are solved, and I believe they can be, making signing opt-out means that we'd see signing rate percentages in the 90s, instead of languishing in single digits as they do today.

If you work on NPM and would like to swap notes, I would love to talk to you with my professional hat on -- email in profile.

Re:Embedded Malware in Coa by qwerty2021 on Friday November 05, 2021 @09:31AM (#29118930)
and who is going to actually audit all that garbage? lmao