Do not ignore repository sizes #145

New Issue

fkobi · 2025-12-29T13:05:29Z

fkobi commented

2025-12-29 13:05:29 +00:00

Right now we ignore the size of the repositories and treat <1 MB ones the same as >600 MB ones (ex openui).

We do not check the sizes at all:
One can add a nGB repo and update it constantly to waste our resources.

Right now we ignore the size of the repositories and treat <1 MB ones the same as >600 MB ones (ex openui). We do not check the sizes at all: One can add a *n*GB repo and update it constantly to waste our resources.

fkobi added the enhancement

prio

low

labels 2025-12-29 13:05:29 +00:00

max.mehl commented

2026-01-05 10:40:23 +00:00

I'd recommend to set the bar quite high to avoid that legitimate repos (e.g. Linux Kernel) are excluded.

Perhaps it would make sense to add an Admin API route that checks the repo sizes, e.g. via the GitHub API, to regularly assess potential abuses.

I'd recommend to set the bar quite high to avoid that legitimate repos (e.g. Linux Kernel) are excluded. Perhaps it would make sense to add an Admin API route that checks the repo sizes, e.g. via the GitHub API, to regularly assess potential abuses.

fkobi commented

2026-01-07 09:58:47 +00:00

e.g. via the GitHub API

I think we should not closely tie our logic to a specific remote proprietary API.
In my opinion a much better solution would be to store the du -s of a repository that we have already cloned for analysis.

> e.g. via the GitHub API I think we should not closely tie our logic to a specific remote proprietary API. In my opinion a much better solution would be to store the `du -s` of a repository that we have already cloned for analysis.

👍 1

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: reuse/api#145