Readit NewsThis sort of seems like saying IF an attacker gets the keys to your car, they could install a module that would allow them to come back and steal the car with a push of a button. Technically true, but they could also just steal the car straight up, or do any number of other things.
I once merely mentioned the words “Heart Attack” on a plane and was kicked off by the flight attendants. No context, they just heard the words and forced me off.
There are things that trigger them because of laws and regulations like mentioning “bomb” (even if you’re describing something fantastic).
So messing with the gogo flight entertainment is up there with flirting with terrorism charges.
Well now you have a chance to tell your side - were you merely sitting and just uttered the words "heart attack" for no externally apparent reason?
Kinda feels like Discord is lying by omission.
Edit: Actually my bet is their support staff just sold them out.
> they were able to compromise Discord Zendesk by compromising a "BPO Agent" (outsourced support).
> Of course, as is tradition, it is also entirely possible they're lying
Is that possible? I thought the lock files restricted to a specific version with an integrity check hash. Is it possible that it would install a newer version which doesn't match the hash in the lock file? Do they just mean package.json here?
This comes up every time npm install is discussed. Yes, npm install will "ignore" your lockfile and install the latest dependancies it can that satisfy the constraints of your package.json. Yes, you should use npm clean-install. One shortcoming is the implementation insists on deleteing the entire node_modules folder, so package installs can actually take quite a bit of time, even when all the packages are being served from the npm disk cache: https://github.com/npm/cli/issues/564
There are ways to detect a replaced/proxied global window function too, and that's another arms race.
> Our package-lock.json specified the stable version 1.3.2 or newer, so it installed the latest version 1.3.3
As far as I've always understood, the lockfile always specifies one single, locked version for each dependency, and even provides the URL to the tarball of that version. You can define "x version or newer" in the package.json file, but if it updates to a new patch version it's updating the lockfile with it. The npm docs suggest this is the case as well: https://arc.net/l/quote/cdigautx
And with that, packages usually shouldn't be getting updated in your CI pipeline.
Am I mistaken on how npm(/yarn/pnpm) lockfiles work?
The npm team eventually seemed to settle on requiring someone to bring an RFC for this improvment, and the RFC someone did create I think has sat neglected in a corner ever since.
SimpleFIN is fast and a quick Plaid alternative for just $1.50 a month or $15 for the year. I created my SimpleFIN account, copied the API token, and added a bank account. Then I jumped back to Actual Budget, entered the API token, and linked the account from Actual to SimpleFIN. You can link as many bank, credit card accounts as you want with one SimpleFIN account.
The website says "Connect up to 25 institutions and 25 apps"
The challenge with those systems is that they’re tightly coupled with the tools, infrastructure, and even developer distros used internally at Google and Meta, which makes them hard to generalize. SourceFS aims to bring that “Piper-like” experience to teams outside Google - but in a way that works with plain Git, Repo, and standard Linux environments.
Also, if I’m not mistaken, neither SrcFS nor EdenFS directly accelerate builds - most of that speed comes from the build systems themselves (Blaze/Buck). SourceFS goes a step further by neatly and simply integrating with the build system and caching/replay pretty much any build step.
The Android example we’ve shown is just one application - it’s a domain we know well and one where the pain is obvious - but we built SourceFS in a way where we can easily integrate with a new build system and speed up other big codebases.
Also you’re spot on that this problem mostly affects big organizations with complex codebases. Here without the infrastructure and SRE support the magic does not work (e.g. think the Redis CVE 10.0 of last week or the AWS downtime of this week) - and hence the “talk to us”.
We plan to gradually share more interesting details about how SourceFS works. If there’s something specific you’d like us to cover - let us know - and help us crowd source our blogpost pipeline :-).