Giteabot account was compromised | Hacker News Reader

Giteabot account was compromised

github.com

134 pointssarif60 comments

Funny to see this news posted on github, after people having suggested gitea as a viable platform to migrate your github projects to ever since the MS buyout.

Good thing on them being open about it though, despite it probably costing them some potential traction.

Many projects are ironically this way. Gitea, gogs, yunohost, sandstorm to name a few.

I think they solve different problems. Gogs is amazing for a self hosted git repo. Not so much for collaborating with thousands of people around the world. Centralization can be a very good thing if done by an ethical company with the right incentives. The only reason decentralization is useful is when you can't trust anyone for anything. I'd rather live in, and work towards, a world where that's not the case.

Would decentralization's value also hold true as technical barriers fall?

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 some (like Gitea) are working on it to start hosting it on their own. Gitea will also get federation features to make contributions between independent Gitea instances possible.

But even when it starts to host, it will get GitHub OAuth2, just to keep the barrier small to receive contributions.

Perfect time to attack, really. Take advantage of the MS+Github hysteria and hunt for some exploits while people are scrambling around to migrate elsewhere.

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.

I'm probably out of the loop, but are people really scrambling to migrate away from GitHub? Why? Any reason other than irrational MS hatred?

Rational MS hatred?

Shitty OSes, naff late to the party phones and music players, convicted monopolists, tend to have arseholes running the company and are now paying 7 billion dollars to buy a company purely for the reputation, and it's people who are leaving GitHub who are not rational?

Does the product still work and provide the advertised service? If yes, then yes, it’s irrational. It isn’t like leaving GitHub is a multi-month process. It could be done in an instant.

It’s evacuating a house because there might be a fire in the future.

If it can be done in an instant, why wait?

I think of it more like leaving a planet because the galactic empire just bought it and is about to hollow it out to build starkiller 2.

> 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.

I don't think it's irrational.

I actively choose not to support such an organization. If Microsoft got serious about being moral and then I'd play ball.

https://www.theguardian.com/world/2013/jul/11/microsoft-nsa-...

Even if only 2% of projects have an irrational hatred of MS and are scrambling to migrate away, that's still a huge influx to Gitea/Gitlab/etc in a short space of time.

In the grand scheme of things likely not, it's just a vocal minority that can dominate the perspective on social media and places like Reddit, talking about exodus and betrayal and who knows what. Sadly, it works...and it twists the narrative.

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.

Twist's whose narrative? MS' history is written plainly for all the world to see. https://en.wikipedia.org/wiki/Microsoft_litigation

Fake news :-)

Creates a false perception that significant amount of projects are moving away from GitHub.

Out of curiosity, why would BitBucket be out of question?

Atlassian's not really an "underdog", presumably. As for me, I would hate to have my source code in the hands of the people responsible for "JIRA".

To be fair, Bitbucket is loads more pleasant to use than Jira.

A little careless and embarrassing to admit on my part... but I migrated away because the Microsoft purchase reminded me I was paying for a service I no long used. GitLab has free private repos. GitHub does not.

Other than what I would consider perfectly rational dislike of Microsoft (they have a long history of making the world a worse place), some people are old enough to remember what has happened to some of Microsoft's other acquisitions†, like Skype (which went from a promising p2p client to a funnel for the NSA which still doesn't work well or reliably). And consider what they've done with Windows 10: ads in the 'free' solitaire game (unless you pay a monthly fee), ads in the start menu, &c. &c.

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.

> old enough to remember what has happened to some of Microsoft's other acquisitions†, like Skype

But that was only 7 years ago.

That was a touch of sarcasm. But there must be some pretty young people on HN too.

There is few scrambling and lots of people ensuring they have viable exit strategies for when we enter the timeline where Github goes down the drain.

Gitea isn't meant to replace Github... it's meant to be a self-hosted alternative to it. That's subtly different.

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:

  [Unit]
  Description=Gitea (Git with a cup of tea)
  After=syslog.target
  After=network.target

  [Service]
  RestartSec=2s
  Type=simple
  WorkingDirectory=/home/me/gitea
  ExecStart=/home/me/gitea/gitea web
  Restart=always

  [Install]
  WantedBy=default.target

Then just systemctl --user daemon-reload && systemctl --user enable gitea. Then visit localhost:3000 and add it to your remotes (git remote add local ...) and you can push your changes to your own gitea instance.

> Then visit localhost:3000 and add it to your remotes (git remote add local ...) and you can push your changes to your own gitea instance.

Why would you want to run a git server on your personal computer?

If you have ssh enabled with an accessible git repo; you already do!

Just don't forget to create `--bare` repositories on the server.

For me it has the following advantages:

- 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.

> Gitea isn't meant to replace Github... it's meant to be a self-hosted alternative to it. That's subtly different.

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.

"I get all my news from facebook. Look, a Trending story about a facebook competitor. hheheheheh"

Italics doesn't make your comment any less circular or beside the point for people looking to move away from github.

I haven't actually done cryptographically signed continuously released applications before. I was just thinking about how it should work, and it seems a little complicated. I'm not sure how to safely sign the build.

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?

> 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.

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.

You need reproducible builds, a trusted compiler, or an audit of the compiled binaries. Most of us go for the “trusted compiler” approach, and just really hope we’re right.

GitHub's permission system is quite brittle here: Anyone with write access to a repository can silently swap out binaries on the releases page, which are then still listed as "Verified" if the commit is signed. It's a complex problem, but the current approach feels subpar.

Sounds like a good opportunity for integration with GPG, keybase, and other signing tools.

I was surprised that there was no gitlab integration with keybase when I signed up last night to check it out. Not just to save me manually copying my key but for the cross-platform identity verification.

It's not that easy to solve in general. Usually these artifacts are built by CI so it'd have to sign them too (if they are not reproducible the you can't build them locally and check if they are the same). So a person that has admin access in CI can do that too.

Of course current design leaves much to be desired.

Has anyone taken a look at the binaries themselves to see what they do and how they differ from the official releases?

Far as I know, no. Asked this question on the issue page. Really want to find out as I have at least one server that could have been affected. Kind of frustrating that this is all the information there is.

This comment links to them:

https://github.com/go-gitea/gitea/issues/4167#issuecomment-3...

The creator of the GitHub issue said the binary contains a cryptocurrency miner.

Where does he say that?

It's in the issue body, first bullet point. https://github.com/go-gitea/gitea/issues/4167#issue-33011407...

> 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)

I've started to take a look at the binary that was uploaded - it seems it wasn't just Gitea that got hit by this, but also https://github.com/opencompany/www.opencompany.org which too has a strange release associated with the repository.

My findings as they go are being shoved into a blog post: https://grh.am/2018/a-look-at-the-compromised-gitea-release/

ouch, this is a case where things like red october by cloudflare could be a great idea. Having to have a minimum number of signers to agree to sign a package would be a good way to prevent this.

Even simpler, have the releases performed by a human account. It can still be compromised but you're not going to be storing your own GitHub credentials on a server or inside a CI flow so it can automatically write on your behalf. You probably shouldn't be releasing so often that it's a pain in the ass to perform it manually (in terms of tagging in git rather than doing a full on deploy to a server or something).

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.

This approach is probably an overkill, but this project called Cothority[0] can be used to verify binaries by semi-independent authorities to be released. One of the applications referenced in their dotSecurity talk[1] was this usecase.

[0] https://github.com/dedis/cothority

[1] https://www.youtube.com/watch?v=YostyJRwqVU

Yikes, no code signing certificate, no details filled out for details or even a copyright, at least on the exe I examined.

Was thinking to install Gitea earlier and saw this on hackernews, is it safe to install using binary yet?

Yeah, it should be safe now. They re-released the binaries and set up 2FA.

Why is it possible to even create a group that doesn't mandate all users have 2FA?

Linux version has always been safe as far as I understand it. Not sure what platform you would have downloaded. Some distributions also have it in their repositories, and those were not affected either. It was really just the Windows binary hosted there.

Anyone have the known bad .exe.exe? I'd like to take a shot at analysis on it.

dabbler's HN comment a few below yours has a link to them.

https://github.com/go-gitea/gitea/issues/4167#issuecomment-3...

Haha, I appreciate your typo in my username. When I created this account a little over two years ago I mistakenly dropped the "l" and didn't realize for a few months (having only copied it from a pw manager.) By that point what was done was done. Years later it makes me a bit happy to think people may actually be reading it as it was intended.

Heh Heh Heh

Didn't even realise I'd gotten it wrong until you mentioned it. :)

Reply on news.ycombinator.com