Kitchenowl creator has been flagged without warning making all of their repositories return 404, while in their settings all of the repositories still look normal with public visibility.
from iByteABit@lemmy.ml to selfhosted@lemmy.world on 05 Apr 18:09
https://lemmy.ml/post/45529249

cross-posted from: lemmy.ml/post/45529149

Here is the message where he found out what happened:

I didn’t receive any information about it but when creating a support ticket I was told my account has been flagged and I had to do some extra verification. I’ve created a support ticket now and will keep you posted. I’ll believe it’s nothing major though, I use 2FA everywhere, the last commit on all repos is what I expect, and all sessions and usages look fine

Absolutely fuck Github and Microslop, they can just vanish your projects without notice whenever they want with barely any justification for it, and then take their sweet time to fix it too.

#selfhosted

threaded - newest

TomAwezome@lemmy.world on 05 Apr 19:19 next collapse

Centralization strikes again

aksdb@lemmy.world on 06 Apr 11:51 collapse

There are forks and they are still accessible. So decentralization works.

cecilkorik@lemmy.ca on 05 Apr 19:24 next collapse

Self host your own code repo. Forgejo is adding activitypub and federation features, not sure how far long they are, but someday if enough people start self-hosting we might have a viable decentralized way to collaborate on and contribute to each others’ projects.

TheHolm@aussie.zone on 05 Apr 20:11 next collapse

With AI search engines hosting public repo is very expensive.

litchralee@sh.itjust.works on 05 Apr 21:16 collapse

Because of the AI-induced scraping traffic? While not perfect, Anubis and similar are coarse-but-effective solutions for self-hosting repos.

And if it it were acceptable to outsource such protection to a CDN (eg Cloudflare) in order to retain firm control over the repo, then that’s a choice that’s also available. Not everyone agrees that CDNs have a role in self-hosting – fair enough – but when a project’s very repo and existence can be wiped off the internet, owning a domain name and the affirmative upstream repository is a tractable and intermediate goal, even if it doesn’t achieve full independence.

Self hosting is an exercise in harm reduction.

vegetaaaaaaa@lemmy.world on 06 Apr 11:41 collapse

The scraping/bandwidth abuse problem can easily be worked around.

But there still are actual good reasons to not host a public forge.

For example, as long as pull requests are allowed (which is required for actual contributors), anyone can abuse the PR feature to fork your repository, then start pushing random shit into their fork (since the fork is an actual separate git repository).

Bad actors can do it on github all they want, it’s not my storage, not my server used to host potentially illegal content.

Self-hosting public services where you are the only authenticated user and sole publisher of content is easy (using your public forge as a mirror with account creation disabled is fine), hosting other’s people content is another can of worms. Think twice before you do that.

WhyJiffie@sh.itjust.works on 06 Apr 15:24 collapse

The scraping/bandwidth abuse problem can easily be worked around.

how?

anubis does not protect the APIs, and it cannot protect against bot traffic coming from many different residential proxies

vegetaaaaaaa@lemmy.world on 07 Apr 15:02 collapse

It can protect APIs as much as any other URL. Or more simply you could disallow any unauthenticated API access in gitea or at the reverse proxy level?

cannot protect against bot traffic coming from many different residential proxies

It can block anything that doesn’t pass the proof-of-work/JS challenge. Most bots don’t interpret JS.

JustGottaWhippet@quokk.au on 05 Apr 22:36 next collapse

Honestly as much as people hate the complexity sometimes replicating the repo from Github to Codeberg or other places is great for redundancy. Or maybe use a local repo for all development and releases and push out to public VSC.

dust_accelerator@discuss.tchncs.de on 05 Apr 23:02 collapse

VLLM litellm supply chain attack.

Creator possibly was compromised and likely a security measure.

Affected versions were not pushed IMO, but the owners machine may have been compromised.

frongt@lemmy.zip on 06 Apr 04:29 next collapse

How do you know that?

dust_accelerator@discuss.tchncs.de on 06 Apr 04:49 collapse

I do not know for sure, but the repo did contain the dependency litellm with version specifier >=1.65.0 (if I recall correctly) and an early march build did use the version 1.81.0 per the uv.lock (version before the compromised litellm==1.82.7 and litellm==1.82.8 )

docs.litellm.ai/blog/security-update-march-2026

Not saying that the Dev was compromised, but it is possible, and it could be some Github precaution to disable repos with that dependency where a pip install at the wrong time could have compromised all the Devs credentials.

t0mxd@feddit.org on 06 Apr 13:00 collapse

No, my whole account has been set to private. KitchenOwl never contained the malicious versions of litellm. The last pinned versions in the lock file on the dev branch were 1.82 and with the latest release 1.83. Sadly, GitHub just decided to flag my account and set it to private without notifying me… I’m waiting for a support response.

dust_accelerator@discuss.tchncs.de on 06 Apr 21:20 collapse

Glad to hear! Thanks for giving some info.

Still could be some half baked github response. Not saying it’s actually the case, but a possibility.

Hoping you can get a timely response and your account back!