this post was submitted on 29 Apr 2026
70 points (90.7% liked)

Selfhosted

60951 readers
880 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Detailed Rules Post

  1. Be civil.

  2. No spam.

  3. Posts are to be related to self-hosting.

  4. Don't duplicate the full text of your blog or readme if you're providing a link.

  5. Submission headline should match the article title.

  6. No trolling.

  7. Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.

  8. AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] irotsoma@piefed.blahaj.zone 1 points 2 months ago (2 children)

They explained that due to the systemic nature of the issues, many of which are across all forks of gitea, and the complex nature of the policy meaning disclosing each one individually and following the separate policies depending on the specifics of each issue, would require a very significant amount of time. Probably a day job worth for a while.

So, they could either drop it and give up, spend all of their free time for the foreseeable future properly disclosing each defect, or use the method they chose to get some level of attention on it without exposing details or breaking the security policy, but still letting both developers and users that there are issues.

[–] notabot@piefed.social 9 points 2 months ago (1 children)

Alternatively, they could have sent the security team an email with the 'carrot' and saying "There seems to be fundamental, systemic, security issues in Forgejo; here's some proof. There's too much for me to raise individual reports, what are we going to do about it?"

[–] hendrik@palaver.p3x.de 3 points 2 months ago* (last edited 2 months ago)

I think there's pros and cons to everything. That way would have been less of a dickhead move towards the Forgejo developers. But a big letdown to admins as they don't know what's up with the software they're running on their servers. The way the author chose gives some new intelligence to admins, and they can now act on it, since it's public knowledge. But it's annoying to the devs.

I guess I as a Forgejo user am kinda greatful they did it this way. Now I got to learn the story and can allocate 2h on the weekend to see if my personal Forgejo container is isolated enough and whether the backups still work.

(But that's just my opinion after reading one side of the story. Maybe there's more to the story and they're being a dick nonetheless...)

Edit: And regarding just dropping the security team an informal mail... I don't know if that's clever. You'd normally either follow some security policy, or don't engage. Sending them other kinds of mails which violate their policy (an internal carrot) might not be the best choice.

[–] irotsoma@piefed.blahaj.zone -2 points 2 months ago* (last edited 2 months ago)

I believe they were already frustrated by the responses to the fixes they did submit.

I get the frustration. It is how many big companies avoid responsibility, but that's usually to avoid cost on actually fixing stuff. In a FOSS project, what's the point of rejecting a simple fix because some complex process meant for complex issues in proprietary software that the security researcher can't suggest specific fixes for wasn't followed. Why fill out a bunch of "paperwork" and initiate a long embargo period before a fix is considered when the fix is already submitted and is simple enough and low risk and impact enough to not require more that a cursory review. It's like asking a road engineer who sees a small pothole that only damages a few cars a year and offers to fill it because they are often affected by it to file a superior court case in order to report it, much less fix it.

So, it's a matter of, give up because it's too much of a burden to report, or announce in the most ethical way possible to incentivize fixes actually happening.

Edit: based on replies I guess my analogy was better in my head than on paper without explaining. Rather than try a new analogy let me explain a bit.

I wasn't saying the city should let the engineer fix it. I'm saying they shouldn't have let it get that far and should have followed normal pothole patching processes that probably would have been resolved weeks before despite the potholes having caused damage/bug being "security" related rather than feature related. But despite filing detailed bug reports and patches they were told they had to follow a complex policy of notifications and do it separately for each defect of which there were likely to be many, individually, that include triggering an embargo that would not allow them to write or submit those patches for 90 days at which point this engineer would likely have moved on to other issues and forgotten all of the details of how to fix the issues. Heck I often forget and have to start over after a few days much less months.