Selfhosted
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:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
Yea. But did you read the security.md?
Use an encrypted email to security@forgejo.com. If you can't, tell them and they will set one up.
Seems very assholeish to not at least do that.
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.
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?"
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.
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.
I don’t think you read the article.
Did you miss this part
Sounds like him being lazy.
Your comment said Forgejo has a disclosure process. The article says the author went with a carrot disclosure after reading the disclosure process and making a value judgement. Because your comment only mentioned Forgejo having a disclosure process, not an evaluation of the author’s evaluation of the disclosure process, it made you appear as if you had not read the article.
In your response to me calling that out, you offer an analysis. The author is lazy for using carrot disclosure over the defined disclosure process. That’s a valid take. I’m not going to disagree with that.