
Giteabot account was compromised - sarif
https://github.com/go-gitea/gitea/issues/4167
======
josteink
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.

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

~~~
hk__2
> 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?

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

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

------
peterwwillis
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?

~~~
aaron_m04
> 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](https://github.com/devrandom/gitian-builder) It's probably
troublesome to setup for a new project of significant size.

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

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

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

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

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

~~~
saagarjha
Where does he say that?

~~~
rmsaksida
It's in the issue body, first bullet point. [https://github.com/go-
gitea/gitea/issues/4167#issue-33011407...](https://github.com/go-
gitea/gitea/issues/4167#issue-330114075)

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

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

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

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

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

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

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

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

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

[https://github.com/go-
gitea/gitea/issues/4167#issuecomment-3...](https://github.com/go-
gitea/gitea/issues/4167#issuecomment-395579466)

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

~~~
justinclift
Heh Heh Heh

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

