The feedback was that we gave too many details too soon, and so we solicited feedback from the community and peertube's approach was given as a suggestion for us to try. But to be clear, this decision was discussed and made by the maintainers, including the elected leadership team. I'd say that this is a successful example of governance, as it isn't a unilateral decision, and everyone was involved in making.
(bias note: I am a project lead of Gitea) this approach is based on what peertube has been doing, and is being attempted as an alternative approach to what we've been doing previously due to feedback we've been receiving from the community.
Only posting here because I've been asked about it. Gitea is protected against both of these issues.
(bias note: part of project leadership of Gitea)
Edit: As a note, security incidents happen to everyone and we shouldn't shame anyone for reporting them, especially as that'd otherwise cause less issues to be reported overall.
I was one of the members who was a part of the initial grant for federation in Gitea, but sadly due to illness and other similar neither I nor my teammate were able to work on the grant (so no funding ended up being released), however the work we did start was completed, and we have continued to work on foundations since. Since spam/moderation/limitations are so significant we are focused on that portion first, since we don't want to open up another vector for it without having at least the minimum of protections in place. We have also been extremely fortunate to have experienced developers who do work on existing federated software share so much of their time, expertise, and experiences with us to help shape our work.
I'm one of the project leads of Gitea and we've put a ton of work into Gitea Actions, I'd be interested in any compatibility gaps that you've run into.
I'm one of the project leads of Gitea. I'd be interested in knowing which features you are missing from Gitea compared to Gitlab? We are doing some backlog grooming right now, and input is very appreciated:)
I'm a project lead of Gitea, and former elected board member of Codeberg. Gitea remains opensource (feel free to check out the repo and you can see that the license remiains as is), and maintains yearly community elections. The codeberg board was informed a full year prior to their "we just found out blog post", and so "catching the whole community by surprise" is very much not accurate since they very much knew. As well, we (the company) were very public with our activities prior to our blog post announcing things, including working to support other open source projects migrate, and posting about it through various channels (social media, chat, etc..).
I'm one of the project leads of Gitea (and am paid for some of my work on Gitea), and here are some more details around the specific incident you are talking about:
We were alerted to an issue, and investigated provided a patch, and then waited until the end of the embargo to release the next version with the fix. It turns out they had sent a follow up after our response to them that, due to their usage of an email relay that gets blocked for spam often, went into the spam box for all of the maintainers on the security team (across multiple mail providers). We informed them of this and they still haven't corrected the record on their blog post. This is after previously giving us 10 and 2 day "embargoes" on "severe" issues and a multi-hundred line patch that rewrote core portions of the codebase and introduced issues in itself, we notified them of this and provided them with out patch. In our interactions with them we have also followed our documented approach, that we have followed with codeberg previously (that we were thanked and applauded), but they have changed their stance and claimed we are now acting improperly (and when we asked for how we could adjust our approach to something that works for their adjusted expectations we never received a response, even after receiving multiple emails from multiple non-company maintainers and even messages in multiple chatrooms).
Disclaimer: I was also previously an elected member of Codeberg's board (presidium), where before the company that was founded to support Gitea's community maintainers was created, I had asked for assistance with multiple matters to aid in project development and was denied.
Gitea would have SAML too (I'm the main author on the SAML PR to the Gitea project), but it's been held up by community reviews requiring esentially an entire re-write with another library. We'd love some help to get it across the finish line :) In open-source, money isn't the only thing that can be spent; we can also use our time.
Gitea has SSO using many different ways, such as LDAP, OAuth2/OIDC, OpenID, SMTP, etc.., and it would have SAML too (I'm the main author on the SAML PR to the Gitea project), but it's been held up by community reviews requiring esentially an entire re-write with another library. We'd love some help to get it across the finish line :) In open-source, money isn't the only thing that can be spent; we can also use our time.
The difference between the Gitea project and the Gitea Enterprise software offering is with Gitea Enterprise we are able to include code written that was rejected by maintainers (eg. mandatory 2FA as an example) as there was still a desire for it. Luckily it was since rewritten in a way that was acceptable for the project and now it's been accepted/merged. The company has also written code that was under contract from other companies, and so they own the IP and thus cannot be accepted by the project due to not being able to be DCO compliant. Those companies are receptive to open-source, and we are working with their legal teams to be able to have them release their claim to the code so we can submit it to the project (large corpos are not known for their speed and understandably want to do their due diligence to ensure that all i's are dotted and t's crossed). There are around ~50 community maintainers that have exactly equal say over PR reviews, etc.., and that process has always been strictly adhered to.
Edit: Gitea has LDAP, OAuth2/OIDC, OpenID, SMTP, reverse proxy, and others as SSO options.
Yes there are :) You can use the Package limit setting to change it (search the config docs for `LIMIT_SIZE_CONTAINER`), by default there is no limit, but if you are running into a 413 due to container uploads being so large, then it could be a reverse proxy configuration you might be running into.
Yup, this is the case. I'm the main author on that PR. It sadly stalled due to reviews from other maintainers requiring it to be rewritten using another library, but hopefully I'll be able to get back to it, or someone else will be able to pick it up. We've been able to get other functionality into Gitea already, and I've personally funded maintainers and others' work for the project, which goes directly into the project itself.
I'm the main author of the PR to implement SAML in Gitea, and it sadly has stalled due to reviews from maintainers requiring it to be rewritten entirely using another library. Our governance charter requires a certain process for PRs going into Gitea, and cannot be side-stepped by anyone. As for some of the others, we've been able to merge them in already.
Thanks so much for saying so. Not sure if you are on the latest major release yet, but hopefully you've seen that resource usage is much lower and response times are even faster.
We are shipping ~300 PRs monthly (plus more getting reviewed), so there are always new things :) I have a few big PRs for longstanding feature requests that should go in soon that I'm pretty excited for.
edit: Im also pretty excited about the anti-crawler enhancements that went in the latest major release
I'm on the Gitea TOC. The fork does still merge from upstream. The Gitea project has 4x'd the number of monthly PRs we handle (~400) and have increased the maintainers teams, and the number of contributors. I'd say we have a lot of momentum.