491–500 of 894 posts
Earlier quoted context omitted.
What do you base that on? Threat researchers (and their automated agents) will still keep analyzing new releases as soon as they’re published.
> What do you base that on? The entire history of malware lol
PSA: npm/bun/pnpm/uv now all support setting a minimum release age for packages. I also have `ignore-scripts=true` in my ~/.npmrc. Based on the analysis, that alone would have mitigated the vulnerability. bun and pnpm do not execute lifecycle scripts by default. Here's how to set global configs to set min release age to 7 days: ~/.config/uv/uv.toml exclude-newer = "7 days" ~/.npmrc min-release-age=7 # days ignore-scr…
min release age to 7 days about patch releases exposes you to the other side of the coin, you have an open 7 days window on zero-day exploits that might be fixed in a security release
Setting min-release age to 7 days is great, but the only true way to protect from supply chain attacks is restricting network access. This needs to be done (as we've seen from these recent attacks) in your devenv, ci/cd and prod environments. Not one, or two, but all of these environments. The easiest way is via using something like kubernetes network policies + a squid proxy to allow limited trusted domains through,…
> Setting min-release age to 7 days is great, but the only true way to protect from supply chain attacks is restricting network access. Getting zero day patches 7 days later if no proper monitoring about important patches or if this specific patch is not in the important list. Always a tradeoff.
Is this Jia Tan 5.0? I've lost count. You really should stop trusting packages (implicitly). Or don't. It's your funeral, not mine. See you at Jia Tan 6.0 April?
Not at all, it was a regular maintainer account that was hijacked (probably through phishing) and used to push a malicious payload, not a threat actor posing as a contributor and adding a backdoor like in the Jia Tan case.
Earlier quoted context omitted.
OP should be glad a new time unit wasn't invented
Workdays! Think about it, if you set the delay in regular days/seconds the updated dependency can get pulled in on a weekend with only someone maybe on-call. (Hope your timezones and tzdata correctly identifies Easter bank holiday as non-workdays)
Earlier quoted context omitted.
This is a rather superlative and tunnel vision, "everything is a nail because I'm a hammer" approach. The truth is this is an exceedingly difficult problem nobody has adequately solved yet.
I think the AI tooling is, if not completely solving sandboxing, at least making the default much better by asking you every time they want to do something and providing files to auto-approve certain actions. Package managers should do the same thing
Earlier quoted context omitted.
> What do you base that on? The entire history of malware lol
Can you elaborate? Why do you believe that motivated threat hunters won’t continue to analyze and find threats in new versions of open source software in the first week after release?
> Why do you believe that motivated threat hunters won’t continue to analyze and find threats in new versions of open source software in the first week after release?
I'm sure they will, but attackers will adapt. And I'm really unconvinced that these delays are really going to help in the real world. Imagine you rely on `popular-dependency` and it gets compromised. You have a cooldown, but I, the attacker, issue "CVE-1234" for `popular-dependency`. If you're at a company you now likely have a compliance obligation to patch that CVE within a strict timeline. I can very, very easily pressure you into this sort of thing.
I'm just unconvinced by the whole idea. It's fine, more time is nice, but it's not a good solution imo.
So this and litellm one would’ve been preventable by proper config of OIDC Trusted Publishers.
Earlier quoted context omitted.
In this case, the author's NPM account was taken over, email address changed to one the attacker controls, and the package was manually published. Since the attacker had full control of the NPM account, it is game over - the attacker can login to NPM and could, if they wanted, configure Trusted Publishing on any repo they control. Axios IS using trusted publishing, but that didn't do anything to prevent the attack si…
Yeah, NPM should be enforcing 2FA and likely phishing resistant 2FA for some packages/ this should be a real control, issuing public audit events for email address changes, and publish events should include information how it was published (trusted publishing, manual publish, etc).
Scaling security with the popularity of a repo does seem like a good idea.
Earlier quoted context omitted.
I actually think it is not too bad a design, because seconds are the SI base unit for time. Putting something like "x days" requires additional parsing steps and therefore complexity in the implementation. Either knowing or calculating how many seconds there are in a day can be expected of anyone touching a project or configuration at this level of detail.
Seconds are also unambiguous. Depending on your chosen definition, "X days" may or may not be influenced by leap seconds and DST changes. I doubt anyone cares about an hour more or less in this context. But if you want multiple implementations to agree talking about seconds on a monotonic timer is a lot simpler