4 ms·
> As it turns out, we only run repacks on a repository network level, which means that repacks need to consider objects from all forks of a given repository.
by oauea 4y ago
> As it turns out, we only run repacks on a repository network level, which means that repacks need to consider objects from all forks of a given repository.
> Repacking entire repository networks will always lead to less optimal pack sizes compared to repacking just objects from a single fork. For GitHub, disk space is not the only thing we optimize for, but also performance across forks and client performance.
So the lesson here is you can DoS existing open source projects somehow by forking them and increasing the forked repo size >2GB?
- tagraves 4y agoHow would the DoS work? As I understand it the issue here only occurs if you try to push the entire project to a _new_ repo. It doesn't affect existing repos.
- pointlessone 4y agoI'm almost certain it affects all repos. It's just more unusual to push huge packs into exiting repos. If for whatever reason you happen to have a huge branch clicking in over 2GB you'd get the same error.
- deleted 4y ago[deleted]
- mayli 4y agoTrue, for github.
- pointlessone 4y agoI don't think that's the case. The issue is that GH doesn't accept too big packs. git by default pack everything into a single pack. Maximum pack size can be specified either in config or as an argument to repack. The way I read the error message a user can push a huge repo by making sure it's packed into a few packs under 2GB limit. It doesn't seem like there's an easy way to turn this into a DoS. GH would repack the fork network on its own schedule. A user probably can not trigger repacks. The repacks on GH side would probably be smaller then their limit, too. packs are probably scoped to a fork and the server is an active client so it most likely wouldn't return objects from other forks. I don't think it would be easy to DoS GH just by pushing big packs (either under or over the limit).