> 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?
Yes it has improved, mostly thanks to Cloudflare network. From my machine (gigabit fiber), for
git clone https://github.com/torvalds/linux --depth=1 --no-checkout
a warmed clone through gitdelivr.net took ~5s versus ~18 directly from GitHub (Github seems to cap clones at around 30 MB/s or 250 mbit/s) so about 3x faster in that case.
> 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?
How does this compare to GitHub? Are there benchmarks?
If the problem is performance how much has it improved?
Yes it has improved, mostly thanks to Cloudflare network. From my machine (gigabit fiber), for git clone https://github.com/torvalds/linux --depth=1 --no-checkout a warmed clone through gitdelivr.net took ~5s versus ~18 directly from GitHub (Github seems to cap clones at around 30 MB/s or 250 mbit/s) so about 3x faster in that case.