> You don't have to trust us. Git itself verifies every object by hash on the client side. If we flip a byte, git fsck rejects the entire pack.
If I were to run 'git clone https://gitdelivr.net/$repoUrl` then I would also be getting the Git repository metadata through GitDelivr. You could return any valid git repo, eg. just add one commit on top of the real main with a malicious buildscript. I dont see how this security model works at all?
You're right, that line was overstated in the homepage. I guess security model as with any public mirror in FOSS world?
Git hash checks protect object integrity, so GitDelivr can't silently corrupt a packfile without Git noticing, but that still doesn't make it fully trusted.
Yes the code could still lie about refs/HEAD and serve a different but internally valid history, and Git would accept it. The endgame here is if this is something Cloudflare would pick up (or any other big player) to offer it for free, then you'd trust it because it's a big name (and not a new domain bought yesterday after a weekend project heh)
So the accurate security model is a) GitDelivr preserves Git object integrity b) it does not by itself guarantee authenticity of refs in a way you can verify it c) in that sense it's as close to using any other HTTPS Git mirror or CDN?
Look at the wikipedia page for any given country, and I guarantee you that it cites the CIA World Factbook at least once (and probably several times [1] ). Saying "we don't need the world factbook because we have Wikipedia" is completely ridiculous.
Wikipedia is an encyclopaedia, meaning it's not a primary source of facts but rather an aggregate of information published elsewhere.
irrelevant. thy cite the CIA fact book because it expect, not because its the only source. they’ll just start citing something else like the country’s official stats, or the UN, or something else
This was a great read. I've used the naive approach shown in the first example before and its always felt a bit clunky, but I wasnt aware of most of these language features. I'm definitely going to try this out next time I have to write C bindings
> To me, any software engineer who tries an LLM, shrugs and says “huh, that’s interesting” and then “gets back to work” is completely failing at their actual job, which is using technology to solve problems.
I would argue that the "actual job" is simply to solve problems. The client / customer ultimately do not care what technology you use. Hell, they don't really care if there's technology at all.
And a lot of software engineers have found that using an LLM doesn't actually help solve problems, or the problems it does solve are offset by the new problems it creates.
What you described isn't a shallow dismissal. They tried it, found it to not be useful in solving the problems they face, and moved on. That's what any reasonable professional should do if a tool isn't providing them value. Just because you and they disagree on whether the tool provides value doesn't mean that they are "failing at their job".
OP is the developer & maintainer of the affected packages, so the attacker was able to use their phished credentials to upload compromised versions to NPM.
