Gitea: A conta do Giteabot foi comprometida

Nesse ínterim, tenha cuidado ao baixar nossos binários lançados, especialmente os do Windows, até novo aviso. Por exemplo, fique de olho no tamanho dos binários ou no final duplo de um arquivo .exe .
Descobrimos que nossos binários .exe na versão 1.4.2 também foram alterados.

Trabalhamos muito para seguir todas as trilhas, limpar e voltar ao trabalho diário o mais rápido possível.

@daviian Talvez então seja necessário assinar releases?

@Mauladen Obrigado por sua contribuição. Definitivamente vamos discutir isso.

Ai! Sim, binários assinados seriam ideais.

@Mauladen Nós reconstruímos os binários para a versão 1.4.2 apenas para garantir que fornecemos os mais seguros.

Ou você quis dizer outra coisa?

Isto é normal. Retivemos 1.4.2 para reativar o CI para reconstruir os binários, pois o binário do Windows para essa versão foi removido e foi adicionado um novo malicioso

@daviian , Maybe @Mauladen significava que 1.4.2 release commit sem assinatura GPG, mas 1.4.1 era

Ainda preciso editar a lista de mudanças

@axifive commit onde não gpg assinado pelo usuário, mas github que faz isso automaticamente (com chave github) quando a fusão é do mesmo autor PR. Eu não consideraria mais seguro porque se a conta do github fosse comprometida, eu também serei mostrado como "verificado". Mas poderíamos começar a assinar tag a partir de agora (para ser discutido). Para mais informações, estamos trabalhando na assinatura do binário, já que é mais fácil corrigir o binário do thzan como a árvore de commit do git.

Você deve enviar um tarball criado por git-archive (além daqueles que o github gera automaticamente) que você assina com signify . Você pode ter uma ideia de como isso funciona / parece aqui:

• https://github.com/nicklan/pnmixer/blob/master/MAINTAINING.md#releasing
• https://github.com/nicklan/pnmixer/releases/tag/v0.7.2

Libressl usa a mesma tecnologia.

Existe mais informação sobre isso? Qual era a carga útil do binário? Os usuários serão informados sobre isso por meio de uma postagem no blog ou algo assim? Algum dos binários do Linux foi comprometido? Estou bastante preocupado com o que essas coisas podem ter feito aos meus servidores. Estou duplamente preocupado porque só descobri isso navegando na página do problema por acaso, em vez de um aviso oficial na página / blog do projeto

A versão Gitea 1.4.2 é segura para atualizar a partir do código-fonte neste momento?

Neste ponto, não está claro para mim se apenas os binários foram afetados. Como você verificou isso? Suas filiais estão protegidas?

Os shasums diferem nos binários que baixei em 6/4 e 6/7, embora tenham o mesmo número de bytes:

$ sha256sum gitea-1.4.2-linux-amd64*
e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9  gitea-1.4.2-linux-amd64
c843d462b5edb0d64572b148a0e814e41d069d196c3b3ee491449225e1c39d7d  gitea-1.4.2-linux-amd64.1

$ ls --color=tty -l gitea-1.4.2-linux-amd64*
-rwxr-xr-x 1 matt matt 53674800 Jun  4 20:39 gitea-1.4.2-linux-amd64
-rwxr-xr-x 1 matt matt 53674800 Jun  7 08:18 gitea-1.4.2-linux-amd64.1

Quer hospedá-los em algum lugar para que as pessoas possam separá-los?

Carregado os binários aqui: https://send.firefox.com/download/a5dc9a9335/#_k9e4Cu2r4pPNDrsS1T2CA. Vou colocá-los em algum lugar mais permanente, se necessário.

Pergunta - foram apenas os binários do site que foram afetados ou os repositórios também foram afetados? Eu pergunto porque ontem eu ouvi falar do Gitea e clonei e construí o branch v1.4.

Realmente gostaria de mais algumas informações se a própria fonte estiver comprometida ou apenas os binários. Eu executo um script para verificar se há atualizações / build do git todas as noites e tive a sorte de perder isso por causa do tempo.

A versão 1.4.2 atual está limpa? Se soubermos que está contaminado, devemos retirá-lo o mais rápido possível e colocá-lo em outro lugar para análise, caso contrário, as pessoas ainda farão o download se não virem esse problema. Eu concordo com @CountMurphy , podemos adicionar algo ao README para que

Podemos obter hashes para verificar se nossos binários são afetados? Meu gitea 1.4.1 (linux amd64) é assim:
$ sha256sum gitea
d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851 gitea

Acabei de baixar gitea 1.4.1 linux-amd-64 e também obtive d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851 como sha256

@mikedilger Consulte: https://github.com/go-gitea/gitea/issues/4167#issuecomment -395576229

Para deixar claro: ninguém sabe de nada e os únicos hashes seguros são os encontrados atualmente aqui: https://github.com/go-gitea/gitea/releases

Para Gitea 1.4.2 em amd64, isso significa:

Desculpe, não entendi https://github.com/go-gitea/gitea/issues/4167#issuecomment -395576229 como significando que ambos os binários foram comprometidos.

Eu editei este post para remover quaisquer ambigüidades sobre o que realmente sabemos.

Segure-se: de acordo com este comentário (https://github.com/go-gitea/gitea/issues/4167#issuecomment-395576229), há duas shas e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 partir de 4 de junho e c843d462b5edb0d64572b148a0e814e41d069d196c3b3ee491449225e1c39d7d de 7 de Junho.

Estamos dizendo que ambos estão comprometidos ou apenas um deles? Para registro, o que está em meu servidor é e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 de 5 de junho.

@christianbundy , por favor, não tire conclusões precipitadas, aguarde uma resposta do membro da equipe

Por favor, não tire conclusões precipitadas, aguarde uma resposta do membro da equipe

Desculpe por isso, pensei que os hashes do arquivo seriam postados por um membro da equipe imediatamente e não percebi que a informação vinha de outra pessoa que _também_ estava no escuro. Este é o canal correto para acompanhar os últimos desenvolvimentos? Desliguei meu servidor e preciso de mais informações para saber se fui infectado.

Vejo suas edições riscando a entrada que apontei. NO ENTANTO, não é muito cedo para tirar uma conclusão? Como podemos saber com certeza e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 está bem?

Ainda faltam algumas informações (provavelmente não exaustivas):

• [] Quais binários foram comprometidos e quais são suas somas de verificação?
• [] Quando a conta do bot foi comprometida?
• [] O repositório de origem está comprometido (pode ser fácil verificar se você tem uma versão do repo clonada de algum tempo atrás, então você pode verificar diffs ou evidências de push push).

Eu obtive:

# ls -la gitea-1.4.1-linux-amd64
-rwxr-xr-x 1 gitea gitea 53663640 May  3 08:02 gitea-1.4.1-linux-amd64

Com sha256sum d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851

e acabei de baixar gitea-1.4.2-linux-amd64 :

# ls -la gitea-1.4.2-linux-amd64
-rwxr-xr-x 1 root root 53674800 Jun  7 14:18 gitea-1.4.2-linux-amd64

Com sha256sum c843d462b5edb0d64572b148a0e814e41d069d196c3b3ee491449225e1c39d7d que corresponde ao arquivo .sha256 fornecido: gitea-1.4.2-linux-amd64: OK que deve ser seguro. (direito?)

[...] Nós reconstruímos os binários para a versão 1.4.2 apenas para ter certeza de que fornecemos os seguros. [...]

Eu carreguei gitea-1.4.2-linux-amd64 para análise aqui , mas realmente não diz nada óbvio.

Vou assistir a este problema e manter minha instalação do gitea offline por enquanto.

Como podemos saber com certeza e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 está bem?

@shuhaowu Eu disse que c843d462 estava bem, não e14e54f3 . Sabemos disso porque esse é o arquivo que está sendo disponibilizado no GitHub, que eles reconstruíram recentemente.

Se 1.4.2 foi reconstruído, isso deve ser assinado e verificado como as outras liberações válidas. Não fazer isso só aumenta a confusão.

@xcolour

Carregou os binários aqui: https://send.firefox.com/download/a5dc9a9335/#_k9e4Cu2r4pPNDrsS1T2CA

A única diferença entre esses dois binários é que cerca de 2.000 instâncias de movabsq $63663754793, %rcx foram substituídas por movabsq $63663969431, %rcx . Não posso dizer exatamente o que muda em termos de comportamento, mas acho muito improvável que seja o suficiente para ser malicioso.

Talvez lançar uma nova versão 1.4.3 (assinada?) Com o código seguro conhecido ou isso confundiria mais as coisas?

@justinclift Gosto dessa ideia, também uma postagem no blog e algo no README sobre a situação ajudaria a esclarecer as coisas.

@ spaghetti2514

Por um lado, você está certo - as diferenças entre os _aqueles_ dois binários são fáceis de ver.

Por outro lado, a equipe Gitea não postou realmente quais binários foram afetados, postou nenhum hash SHA256 ou realmente disse _algo_ que nos ajudaria a entender o comprometimento. Como outros apontaram, não temos informações suficientes para determinar o que aconteceu e quem foi afetado.

Estou frustrado em apontar que provavelmente deveríamos apenas presumir o pior e aguardar as etapas de diagnóstico da equipe principal. Dito isso, agradeço a postagem do diff desmontado.

É isso que você está procurando? https://github.com/go-gitea/gitea/issues/4167#issuecomment -395579466

Obrigado pela atualização @lafriks !

Eu atualizei a descrição do problema com informações adicionais. Não foi tão ruim quanto poderia ter sido. Queríamos ser o mais transparentes possível, então criamos esse problema assim que limpamos e corrigimos tudo e como esta foi a primeira vez que algo assim aconteceu, então provavelmente deveríamos ter fornecido mais informações mais rapidamente, desculpe por causar confusão.

@lafriks Obrigado pela atualização! Você poderia postar sua chave PGP que possamos usar daqui para frente para verificar os commits?

As tags

As versões serão assinadas pela chave GPG que será criada antes da versão 1.5.0, iremos publicá-la em README.md, documentos gitea e na postagem do blog.

Como um usuário 386, posso confirmar que o binário gitea-1.4.1-linux-386 atualmente disponível na página Releases corresponde a uma versão que baixei em 4 de junho ( cf6344b4 ).

como todos os PR são mesclados usando Squash & Merge, eles não são assinados (ou talvez assinados pela magia do GitHub :))

Não use o botão de mesclagem, que é basicamente inseguro e uma chave gpg aleatória. Merge localmente e empurra a mesclagem.

@mappu gitea v1.4.1 não foi afetado e agora a v1.4.2 foi relançada.

Você deve fazer o upload de um tarball criado por git-archive (além daqueles que o github gera automaticamente) que você assina com signify.

Na verdade, você não precisa nem mesmo construir os arquivos e carregá-los novamente. Você pode assinar o que o GitHub criou, porque isso pode ser feito de forma reproduzível.

Aqui está um pequeno script para isso: https://github.com/rugk/gittools/blob/master/signrelease.sh

@rugk Script de aparência útil. :sorriso:

Algum membro da equipe contribuinte obteve um arquivo de 1.4.2 antes da descoberta da violação?

Você parece ter deixado muitas pessoas sem saber se este binário foi alterado ou não para qualquer versão do Linux, o que é uma informação importante, considerando:

1) A maioria das implantações será para pilhas Linux

2) As pilhas do Linux não estão acostumadas a cavalos de Tróia binários e não costumam ter as melhores ferramentas para detectar programaticamente código suspeito já em execução no sistema.

Embora eu gostaria de acreditar que este foi um simples ataque direcionado ao Windows e nada mais, o fato de que eles direcionaram esse repositório específico apenas alguns dias em um aumento dramático no crescimento da base de usuários parece indicativo de um esforço mais bem orquestrado. Eu duvido muito que qualquer um que soubesse o que eles almejavam e como fazer esse tipo de coisa teria simplesmente perdido a oportunidade de infectar o maior número possível de hospedeiros.

@stanier dl.gitea.io não foi afetado e verificamos que nenhum outro binário foi adulterado

Isso explica por que nosso webproxy se recusou a baixar a imagem gitea mais recente de hub.docker.com ...

@lafriks Então você pode confirmar que c843d462 e e14e54f3 são ambos seguros? Se o CI forneceu um build com uma assinatura diferente, então algo deve ter mudado no código-fonte ou nos parâmetros que o compilador usou para o build. É um detalhe técnico menor por si só, mas nunca foi declarado diretamente aqui se o adversário alterou ou não os binários do Linux 1.4.2, apenas os respectivos binários .exe mencionados no comentário de @daviian.

Só para esclarecer, estou perguntando sobre os binários da página de lançamento do repositório GH, não dl.gitea.io, entendo que nada foi adulterado fora do repositório GH.

As pilhas do Linux não estão acostumadas a cavalos de Tróia binários e geralmente não são adequadas com as melhores ferramentas para detectar programaticamente código suspeito já em execução no sistema.

Hmmm, a maioria dos gerenciadores de pacotes (e similares) não tem provisão para verificar pelo menos sha * checksums? Não necessariamente apenas para detectar malware, mas como um "vamos verificar se o download não está corrompido".

@justinclift sim, mas isso só se aplica a binários instalados por meio do gerenciador de pacotes. O problema em questão aqui diz respeito a um download direto do GitHub, que não tem nenhuma detecção de malware incorporada, até onde eu sei.

Ahhh. O termo "pilhas do Linux" me confundiu, já que estou mais acostumado a direcionar downloads, sendo coisas simples e pontuais (por exemplo, durante a criação de protótipos), em vez de algo que uma solução automatizada faria. Sem problemas. :sorriso:

@stanier a construção foi refeita por drone para limpar tudo. Go não fornece o mesmo binário cada vez que você constrói o binário, já que alguma variável pode mudar (como o tempo de construção), então é normal que o hash seja diferente.
Peguei todos os binários durante a investigação e posso fornecer hashs assim que chegar ao meu computador pessoal.

Para todos, por favor, pare de discutir rumores e forneça contribuições construtivas.
Eu entendo que você se preocupa com sua segurança e nos preocupamos muito com isso (já que também estamos em sua casa como usuário do gitea). Atualmente o acesso foi alterado e não vimos mais nenhuma atividade suspeita. Fizemos este problema para informar o mais rápido possível para sermos transparentes e podermos receber dados de quaisquer dados úteis para investigar ou perder pontos já que ninguém é perfeito.
Faremos uma autópsia para explicar o que aconteceu e definitivamente pensamos em ações para prevenir isso no futuro.
Se essa questão for selvagem, acho que precisaremos fechar para manter apenas informações úteis e concisas e enviar o debate para a discórdia para onde ele deve ir.

Para evitar uma situação como essa no futuro, começaremos a assinar todos os binários com a próxima versão. Eu construí um plugin para Drone que você pode encontrar em https://github.com/drone-plugins/drone-gpgsign (a documentação para este plugin tem que ser feita) que irá assinar todos os binários, a chave pública será carregada para o servidor de download e para um servidor de chaves, então você sempre poderá verificar os binários de uma forma confiável.

Apenas para mostrar um exemplo de como isso ficará e quais são os resultados, você pode dar uma olhada em https://github.dronehippie.de/webhippie/ldap-proxy/49/18 e https://dl.webhippie.de / misc / ldap-proxy / master / , arquivos semelhantes serão carregados na página de download do Gitea e nas versões do GitHub.

Se você acha que está faltando algo realmente importante neste plug-in, sinta-se à vontade para abrir um problema no repositório de plug-ins e posso resolvê-lo.

@sapk Obrigado pelo esclarecimento. Peço desculpas, esqueci completamente que o projeto era baseado em Golang - a maioria dos problemas como esse trata de softwares mais antigos, então acho que minha mente saltou para uma falsa relação. Meu erro.

Comecei a dar uma olhada no binário install.exe que foi carregado: https://grh.am/2018/a-look-at-the-compromised-gitea-release/

Parece que não foi apenas o Gitea que foi atingido por isso, mas também https://github.com/opencompany/www.opencompany.org/releases

Obrigado pela explicação clara.

Acho que esse problema é o principal motivo para passarmos pelo empacotamento específico da distro. Ele chama mais atenção para o pacote e o código / binário malicioso em potencial (especialmente no caso de uma tentativa grosseira). Seria ótimo ter pelo menos pacotes Debian / RedHat / Archlinux para Gitea: isso evitaria que muitas pessoas executassem um binário arbitrário em seu servidor de produção :)

A assinatura de PGP dos lançamentos é suficiente? Provavelmente. Apenas certifique-se de anunciar sua chave pública em muitas plataformas diferentes para que comprometer seu site, por exemplo, não faça com que todos baixem as chaves erradas. (Mas um pacote Debian nos backports seria <3)

(Além disso, compilações reproduzíveis ?)

Já que você vai começar a assinar versões binárias, também pode considerar a assinatura das imagens do Docker enviadas para o registro?

Parece que não foi apenas o Gitea que foi atingido por isso, mas também https://github.com/opencompany/www.opencompany.org/releases

Acabei de enviar um e-mail diretamente para seus contatos, caso eles ainda não estejam analisando os problemas do GitHub.

@graystevens A equipe do pastebin deve ser contatada para eliminar o endereço do pastebin ou é melhor analisar totalmente o malware primeiro para que ele seja bem compreendido?

Obrigado a todos .. Baixaria novamente e colocaria meu servidor de volta no ar

@justinclift Vou relatar a colagem ao PasteBin agora - tenho uma cópia do conteúdo para que possamos recriar a saída para o malware, se precisarmos. Bom grito

Para ser justo, go agora tem uma versão reproduzível: https://blog.filippo.io/reproducing-go-binaries-byte-by-byte/
Isso pode ser cgo para sqlite e algum ambiente de construção que os torna não reproduzíveis.

Apenas para informação, a lista de hash anterior reconstruída e intacta . Se você tiver esse hash, significa que tem o binário antes da reconstrução que fizemos para redefinir a versão 1.4.2 e também antes do ataque. Se for o caso, você pode ficar com eles.

156655506d373241fea6b8955acbe6fdc148f06b49b4f6e46d11cadcd00d7316  gitea-1.4.2-darwin-10.6-386
5730c1a471dfc2c055442360d431c950b3a4f266403c5f327c94a68b88e67a10  gitea-1.4.2-darwin-10.6-amd64
8c3cc2127161695dea512176cd4282711e8c57972f333253cc89597dfab002ef  gitea-1.4.2-linux-386
e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9  gitea-1.4.2-linux-amd64
bca75d81c52b9aa57fd05b8f7ce0572abae3e1a008d8ab77840ca08c53975867  gitea-1.4.2-linux-arm-5
3aa791afce2e3450461038e09622fe04f34b891c47db641be50b6cc3f772645e  gitea-1.4.2-linux-arm64
fc73d06621fc23a944a2a8ee3b19fbd8edb972b0cdaefa67248eb885aa4d6240  gitea-1.4.2-linux-arm-6
5b76cd9b84846c09ba3627219a6cad99542a53d8eec71a427a433ab82eaabacf  gitea-1.4.2-linux-arm-7
4fafeabfa069066fd624364b47b5729f8f068545d4cd8a3620774a982937ac16  gitea-1.4.2-linux-mips64le
7d9e0afcd315f0efbfb26cab303b3fee3939fa0e081b0d3f4f480f950d0a9870  gitea-1.4.2-linux-mips64
7f2e3c1163823889bec1fdd34b4135149c83d53b6dc86f186821e51e0f839e53  gitea-1.4.2-linux-mipsle
a1b8338113d4fdb0360582ba18f6fce97722c779493e7d7e07594d78c7c3f003  gitea-1.4.2-linux-mips
82ad50932bd927ead2e7da4e4c575d94f88e0105a82eda4cce1df7c9fc5ba0dc  gitea-1.4.2-windows-4.0-386.exe
86d7332894390ccaedd39be891044d829f54d4cd71fa21fce5dbd9bc3abbce44  gitea-1.4.2-windows-4.0-amd64.exe

O passo de limpeza install.exe parece ter perdido alguns repositórios:

• go-gitea / gitea-darkmode
• go-gitea / lgtm-cli
• go-gitea / yaml
• go-gitea / bolt
• go-gitea / lgmt-go
• go-gitea / lgmt-docs

A maioria deles é antiga e não é exatamente relevante, mas provavelmente não é uma boa ideia manter malware por perto.

@lunny

• https://github.com/lunny/html2md/releases
• https://github.com/lunny/tango/releases
• https://github.com/lunny/nodb/releases

• https://github.com/go-xorm/dbweb/releases
• https://github.com/go-xorm/xorm/releases
• https://github.com/go-xorm/builder/releases
• https://github.com/go-xorm/ql/releases
• https://github.com/go-xorm/go-xorm.github.io/releases
• https://github.com/go-xorm/blog/releases
• https://github.com/go-xorm/website/releases
• https://github.com/go-xorm/cachestore/releases
• https://github.com/go-xorm/tidb/releases
• https://github.com/go-xorm/xorm-redis-cache/releases
• https://github.com/go-xorm/manual-zh-CN/releases
• https://github.com/go-xorm/manual-en-US/releases
• https://github.com/go-xorm/cmd/releases
• https://github.com/go-xorm/core/releases
• https://github.com/go-xorm/tests/releases
  

• https://github.com/go-tango/gos/releases
• https://github.com/go-tango/social-auth/releases
• https://github.com/go-tango/wego/releases
• https://github.com/go-tango/manual-en-US/releases
• https://github.com/go-tango/manual-zh-CN/releases
  

• https://github.com/go-xweb/xrun/releases
• https://github.com/go-xweb/log/releases
• https://github.com/go-xweb/docs-zh-CN/releases
• https://github.com/go-xweb/httpsession/releases
• https://github.com/go-xweb/xweb/releases
• https://github.com/go-xweb/uuid/releases
  

• https://github.com/goftp/leveldb-auth/releases
• https://github.com/goftp/xorm-auth/releases
• https://github.com/goftp/xorm-perm/releases
• https://github.com/goftp/posixfs-driver/releases
• https://github.com/goftp/ftp/releases
• https://github.com/goftp/qiniu-driver/releases
• https://github.com/goftp/multiple-driver/releases
• https://github.com/goftp/ftpd/releases
• https://github.com/goftp/file-driver/releases
  

• https://github.com/gobook/gobook/releases
• https://github.com/gobook/bookserver/releases
• https://github.com/gobook/blackfriday/releases
  

• https://github.com/tango-contrib/bind/releases
• https://github.com/tango-contrib/jwt/releases
• https://github.com/tango-contrib/cache-ledis/releases
• https://github.com/tango-contrib/cache-memcache/releases
• https://github.com/tango-contrib/cache-mysql/releases
• https://github.com/tango-contrib/cache-nodb/releases
• https://github.com/tango-contrib/cache-postgres/releases
• https://github.com/tango-contrib/cache-redis/releases
• https://github.com/tango-contrib/counting/releases
• https://github.com/tango-contrib/session-redis/releases
• https://github.com/tango-contrib/session-ssdb/releases
• https://github.com/tango-contrib/session-ledis/releases
• https://github.com/tango-contrib/authz/releases
• https://github.com/tango-contrib/basicauth/releases
• https://github.com/tango-contrib/binding/releases
• https://github.com/tango-contrib/cache/releases
• https://github.com/tango-contrib/captcha/releases
• https://github.com/tango-contrib/debug/releases
• https://github.com/tango-contrib/session/releases
• https://github.com/tango-contrib/xsrf/releases
• https://github.com/tango-contrib/dispatch/releases
• https://github.com/tango-contrib/tpongo2/releases
• https://github.com/tango-contrib/events/releases
• https://github.com/tango-contrib/rbac/releases
• https://github.com/tango-contrib/flash/releases
• https://github.com/tango-contrib/notify-discord/releases
• https://github.com/tango-contrib/renders/releases
• https://github.com/tango-contrib/session-nodb/releases
• https://github.com/tango-contrib/websocket/releases
  

• https://github.com/gobuild/goyaml/releases
• https://github.com/gobuild/got/releases
• https://github.com/gobuild/log/releases
• https://github.com/gobuild/oauth2/releases
• https://github.com/gobuild/gobuild/releases
• https://github.com/gobuild/gopack/releases
• https://github.com/gobuild/travis-autobuild/releases
• https://github.com/gobuild/awesome-go-tools/releases
  

Ugh, obrigado. Qual é a abordagem que você está usando para localizá-los? Parece que qualquer abordagem que a equipe do GitHub tenha usado não foi realmente 100% eficaz. : carrancudo:

@jvanraaij @yaggytter obrigado.

Como após nossa investigação, nada mais foi afetado e nenhuma outra informação foi fornecida pelo GitHub, acho que este problema pode ser resolvido. Alguém para escrever uma postagem no blog sobre isso?

@lafriks Eu postei esta postagem no

Acho que ele quer escrever uma postagem post-mortem no blog gitea :)

@graystevens BTW, o link de aviso do seu

Como após nossa investigação, nada mais foi afetado e nenhuma outra informação foi fornecida pelo GitHub ...

Como ponto de dados, embora o GitHub não tenha dito nada sobre isso em público, em particular eles responderam (via e-mail) para dizer efetivamente "Obrigado, estamos investigando."

Os comentários acima de @jvanraaij e @yasuokav pareceram ajudar também, já que (estranhamente, no meu PoV) o GitHub não parece ter encontrado essas instâncias específicas do malware antes disso.

Por exemplo, todos os repo's listados por @yasuokav aqui ainda têm o malware: https://github.com/crossoverJie/SSM/issues/36

Enviarei um e-mail para a equipe do GitHub novamente para apontar isso. Eles parecem cuidar das coisas em poucos dias quando contatados diretamente com uma lista exata para examinar.

Isso é triste para todos os outros projetos, mas pelo menos para Gitea nós resolvemos os problemas adequadamente, espero ... :)

Fechando este problema, pois os binários agora estão assinados e 2FA está implementado.