Good thing on them being open about it though, despite it probably costing them some potential traction.
I use it for as my local git server on Debian 9. Binary is in the /home/me/gitea directory. Run the usual gitea setup, then copy this to /home/me/.config/systemd/user/gitea.service:
Description=Gitea (Git with a cup of tea)
Furthermore it is not unusual to see people run Gitea, GitLab, or just stock git, for their main repository and use GitHub as a public mirror. This takes advantage of GitHub's inertia, and acts as an extra backup.
The way git is design to be distributed makes this easy to achieve for the actual repositories. Issue tracking, CI, and everything else that isn't actually git (the core source control feature-set) isn't as easy of course, as that is more product specific.
Why would you want to run a git server on your personal computer?
- In-browser viewing of diffs and code
- Issues management
- Showing code to clients/other devs is simpler and prettier.
- Can push to local and run tests on a fresh repo pulled in a VM
Honestly as with mostly everything, it can be achieved by other means. It's just what feels good to me. It's extremely lightweight but robust and fits well in my work environment. That is all code editing is done in Emacs with millions of opened tabs in Chrome. I make extensive use of workspaces in xfce and I just Ctrl-Alt-(Right/Left) my way around going back and forth Emacs/Chrome. I could just have a file manager opened and double click on every file, or open them in Emacs, but that isn't always necessarily faster (for me).
Tldr: Personal preference.
Probably a bit of exaggeration there, but there's a good chance that whatever was used to exploit Gitea has been there for quite a long time. A leaked personal access token for the bot account that was there for the taking all the time, if someone cared to scan their CI logs. Something like that.
Anyway, I think for lots of people it's just an impetus to move, a final push: Github is closed source, and there are competitors which are open source or at least 'open core'.
† Linkedin admittedly still seems pretty much the same, but even Microsoft would presumably have a hard time making Linkedin worse.
But that was only 7 years ago.
I actively choose not to support such an organization. If Microsoft got serious about being moral and then I'd play ball.
The reports from Gitlab that they've had a significant uptick in signups can't be ignored though. Probably people in search of a new underdog since Atlassian and Bitbucket are out of the equation there.
It’s evacuating a house because there might be a fire in the future.
Which is a perfectly rational thing to do, if the risk is close enough to 1. Even in actual housing, they preemptively condemn and evacuate buildings that have become too unsafe to trust, before a disaster occurrs.
The costs of centralized organization must continue to fall (even "negative" costs) to compete against any advantage decentralized solution realize as the cost of the technology falls.
But even when it starts to host, it will get GitHub OAuth2, just to keep the barrier small to receive contributions.
Italics doesn't make your comment any less circular or beside the point for people looking to move away from github.
1) You have to sign your code, obviously. If the code isn't signed, none of the resulting build artifacts can be trusted, because where did the code come from?
2) Once your code is signed, you can run a build on verified-only code artifacts, which can produce a build artifact. But if the server doing the build is compromised, you can just put anything at all in the built artifact before it's signed. Sure, you had signed code, but if I can inject my own code into the compiler (or whatever) or just take over the build process and give it my own code, then I can make any kind of build artifact I want.
The only way I can think to "confirm" this build artifact is genuine is to get multiple hosts to independently build the artifact identically and compare them. So you have to have reproducible builds. Which I don't think many people have.
So, what part of the pipeline am I missing?
This is an excellent idea, and has been done for Bitcoin and other projects: https://github.com/devrandom/gitian-builder
It's probably troublesome to setup for a new project of significant size.
Of course current design leaves much to be desired.
My findings as they go are being shoved into a blog post: https://grh.am/2018/a-look-at-the-compromised-gitea-release/
> Most of go-gitea organization repositories new release&tag was created with name 0 and added install.exe binary (13KB in size) to that release that was malicious (from our analysis contained crypto currency miner)
It also means that maintainers are accountable for each release and if something like this happens, you know exactly who you need to talk to to get the situation resolved, which might be something as simple as setting a stronger password or not committing a GitHub token into their public dotfiles.
Didn't even realise I'd gotten it wrong until you mentioned it. :)