Gitea: Giteabot 계정이 손상되었습니다.

그 동안에는 추후 공지가 있을 때까지 릴리스된 바이너리, 특히 Windows 바이너리를 다운로드할 때 주의하시기 바랍니다. 예를 들어 바이너리의 크기나 이중 .exe 파일 끝을 주시하십시오.
릴리스 1.4.2 내의 .exe 바이너리도 변경된 것으로 나타났습니다.

우리는 모든 흔적을 추적하고 청소하고 가능한 한 빨리 일상 업무로 돌아가기 위해 열심히 노력합니다.

@daviian 그렇다면 릴리스에 서명해야 합니까?

@Mauladen 귀하의 의견에 감사드립니다. 우리는 확실히 이것에 대해 논의할 것입니다.

아야! 예, 서명된 바이너리가 이상적입니다.

@Mauladen 안전한 것을 제공하기 위해 1.4.2 릴리스용 바이너리를 재구축했습니다.

아니면 다른 뜻이었나요?

이것은 정상입니다. 해당 릴리스에 대한 Windows 바이너리가 제거되고 새로운 악성 바이너리가 추가되었기 때문에 바이너리를 재구축하기 위해 CI를 다시 트리거하기 위해 1.4.2의 리타이징을 수행했습니다.

@daviian , 어쩌면 @Mauladen 은 GPG 서명이 없는 1.4.2 릴리스 커밋을 의미했지만 1.4.1은

여전히 변경 목록을 편집해야 합니다.

@axifive 커밋은 사용자가 서명한 gpg가 아니라 병합이 PR 작성자와 동일한 경우 자동으로(github 키를 사용하여) 수행하는 github입니다. github 계정이 손상되면 "확인됨"으로 표시되기 때문에 더 안전하다고 생각하지 않습니다. 그러나 지금부터 태그 서명을 시작할 수 있습니다(토론 예정). 정보를 위해 thzan 바이너리를 git 커밋 트리로 손상시키는 것이 더 쉽기 때문에 바이너리 서명 작업을 하고 있습니다.

signify 서명한 git-archive (github이 자동으로 생성하는 것 외에)에 의해 생성된 tarball을 업로드해야 합니다. 여기에서 작동/모양에 대한 아이디어를 얻을 수 있습니다.

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

Libressl은 동일한 기술을 사용합니다.

이에 대한 정보가 더 이상 있습니까? 바이너리의 페이로드는 무엇이었습니까? 사용자가 블로그 게시물 등을 통해 이에 대한 정보를 받을 예정입니까? Linux 바이너리가 손상되었습니까? 나는 이러한 것들이 내 서버에 어떤 영향을 미쳤는지에 대해 우려하고 있습니다. 프로젝트 페이지/블로그의 공식 공지와 비교하여 우연히 이 문제 페이지를 탐색하고 있다는 사실을 알게 된 것이 두 배로 걱정됩니다.

이 시점에서 Gitea 1.4.2 릴리스는 소스 코드에서 업데이트하기에 안전합니까?

이 시점에서 바이너리만 영향을 받았는지 여부는 명확하지 않습니다. 이것을 어떻게 확인 했습니까? 당신의 가지가 보호되고 있습니까?

shasums는 6/4 및 6/7에 다운로드한 바이너리에서 다르지만 동일한 바이트 수입니다.

$ 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

사람들이 그들을 찢을 수 있도록 어딘가에 호스팅하고 싶습니까?

여기에 바이너리를 업로드했습니다: https://send.firefox.com/download/a5dc9a9335/#_k9e4Cu2r4pPNDrsS1T2CA. 필요한 경우 더 영구적인 위치에 둘 것입니다.

질문 - 웹사이트의 바이너리만 영향을 받았습니까? 아니면 리포지토리도 영향을 받았습니까? 어제 Gitea에 대해 듣고 v1.4 분기를 복제하고 구축했기 때문에 질문합니다.

소스 자체가 손상되었거나 바이너리만 손상된 경우 더 많은 정보를 원합니다. 나는 밤마다 git에서 업데이트/빌드를 확인하기 위해 스크립트를 실행하고 타이밍 때문에 이것을 놓칠만큼 운이 좋았습니다.

현재 1.4.2 릴리스가 깨끗한 것으로 확인되었습니까? 우리가 그것이 오염되었다는 것을 안다면 우리는 그것을 최대한 빨리 가져와서 분석을 위해 다른 곳에 놓아야 합니다. 그렇지 않으면 사람들이 이 문제를 보지 못한다면 여전히 그것을 다운로드하게 될 것입니다. @CountMurphy에 동의합니다. 실제로 보이도록 README에 무언가를 추가할 수 있습니까?

바이너리가 영향을 받는지 확인할 수 있도록 해시를 얻을 수 있습니까? 내 gitea 1.4.1(linux amd64)은 다음과 같습니다.
$ sha256sum 기테아
d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851 지테아

방금 gitea 1.4.1 linux-amd-64를 다운로드했고 sha256으로도 d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851을 얻었습니다.

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

압도적으로 명확하게 하기 위해: 아무도 아무것도 모르고 현재 여기에서 발견되는 유일한 안전한 해시입니다: https://github.com/go-gitea/gitea/releases

amd64의 Gitea 1.4.2는 다음을 의미합니다.

죄송합니다. https://github.com/go-gitea/gitea/issues/4167#issuecomment -395576229를 두 바이너리가 모두 손상되었다는 의미로 오해했습니다.

우리가 실제로 알고 있는 것에 대한 모호성을 제거하기 위해 이 게시물을 편집했습니다.

중립 :이 댓글 (https://github.com/go-gitea/gitea/issues/4167#issuecomment-395576229)에 따르면, 두의 SHA가 6 월 7 일부터 6 월 4와 c843d462b5edb0d64572b148a0e814e41d069d196c3b3ee491449225e1c39d7d에서 e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9.

이 두 가지가 모두 손상되었다는 말입니까 아니면 하나만 손상되었다는 말씀입니까? 기록을 위해 내 서버의 서버는 6월 5일의 e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9입니다.

@christianbundy , 성급한 결론을 내리지 말고 팀원의 응답을 기다리십시오.

성급한 결론을 내리지 마시고 팀원의 답변을 기다려주세요.

죄송합니다. 파일 해시가 즉시 팀 구성원에 의해 게시될 것이라고 생각했고 정보가 _역시_ 어둠 속에 있던 다른 사람에게서 온 것임을 깨닫지 못했습니다. 이 채널이 최신 개발 정보를 시청하기에 올바른 채널입니까? 서버의 전원을 끄고 감염 여부를 확인하기 위해 추가 정보가 필요합니다.

내가 지적한 항목을 가로지르는 편집 내용이 보입니다. 그러나 결론을 내리기에는 너무 이르지 않습니까? e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9가 괜찮은지 어떻게 압니까?

우리는 여전히 몇 가지 정보를 놓치고 있습니다(완벽하지 않을 수 있음):

• [ ] 어떤 바이너리가 손상되었으며 체크섬은 무엇입니까?
• [ ] 봇 계정은 언제 손상되었습니까?
• [ ] 소스 리포지토리가 손상되었습니까(이것은 이전에 복제된 리포지토리 버전이 있는지 확인하기 쉬울 수 있으며, diff 또는 강제 푸시의 증거를 확인할 수 있음).

나는 얻었다:

# 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

sha256sum d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851

방금 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

제공된 .sha256 파일과 일치하는 sha256sum c843d462b5edb0d64572b148a0e814e41d069d196c3b3ee491449225e1c39d7d : gitea-1.4.2-linux-amd64: OK 안전해야 합니다. (오른쪽?)

[...] 안전한 것을 제공하기 위해 1.4.2 릴리스용 바이너리를 재구축했습니다. [...]

여기 에 분석을 위해 gitea-1.4.2-linux-amd64 를 업로드했지만 분명한 것은 없습니다.

이 문제를 보고 당분간 내 gitea 설치를 오프라인으로 유지하려고 합니다.

e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9가 괜찮은지 어떻게 압니까?

@shuhaowu c843d462 가 e14e54f3 아니라 괜찮다고 했습니다. 그것이 최근에 다시 빌드한 GitHub에서 현재 제공되고 있는 파일이기 때문에 우리는 이것을 알고 있습니다.

1.4.2가 다시 빌드된 경우 다른 유효한 릴리스처럼 서명하고 확인해야 합니다. 그렇게 하지 않으면 혼란만 가중됩니다.

@xcolor

여기에 바이너리를 업로드했습니다: https://send.firefox.com/download/a5dc9a9335/#_k9e4Cu2r4pPNDrsS1T2CA

이 두 바이너리 사이의 유일한 차이는 2000에 대한 인스턴스이다 movabsq $63663754793, %rcx 교환되었다 movabsq $63663969431, %rcx . 그것이 행동적으로 어떻게 변화하는지 정확히 말할 수는 없지만 악의적일 정도로 충분할 가능성은 거의 없다고 생각합니다.

새로운(서명된?) 1.4.3 릴리스를 알려진 안전한 코드로 밀어낼 수 있습니까? 아니면 더 혼란스러울까요?

@justinclift 저는 그 아이디어가 마음에

@spaghetti2514

한편으로는 당신이 옳습니다. _그_ 두 바이너리의 차이점은 쉽게 볼 수 있습니다.

반면에 Gitea 팀은 실제로 어떤 바이너리가 영향을 받았는지 게시하지 않았거나, SHA256 해시를 게시하지 않았거나, 타협을 이해하는 데 도움이 되는 _아무것도_ 언급하지 않았습니다. 다른 사람들이 지적했듯이, 우리는 결정할 정보가 거의 없습니다. 무슨 일이 일어났고 누가 영향을 받았는지.

나는 우리가 아마도 최악의 상황을 가정하고 핵심 팀의 진단 단계를 기다려야 한다는 점을 지적하기 위해 좌절했습니다. 그런 의미에서 분해된 diff를 게시해 주셔서 감사합니다.

이것이 당신이 찾고있는 것입니까? https://github.com/go-gitea/gitea/issues/4167#issuecomment -395579466

@lafriks 업데이트 감사합니다!

추가 정보로 문제 설명을 업데이트했습니다. 될 수 있을 정도로 나쁘지 않았습니다. 저희는 최대한 투명하게 정리하고 수정한 후 바로 이 문제를 생성했고 이런 일은 처음이었기에 더 많은 정보를 더 빨리 제공했어야 했을 것입니다. 혼란을 드려 죄송합니다.

@lafriks 업데이트 감사합니다! 앞으로 커밋을 확인하는 데 사용할 수 있는 PGP 키를 게시할 수 있습니까?

@4oo4 태그는 Squash&Merge를 사용하여 PR이 모두 병합되므로 병합 자체 GPG 키 중 하나로 서명됩니다.

릴리스는 1.5.0 릴리스 이전에 생성될 GPG 키로 서명되며 README.md, gitea 문서 및 블로그 게시물에 게시됩니다.

386 사용자로서 현재 릴리스 페이지에서 사용할 수 있는 gitea-1.4.1-linux-386 바이너리가 6월 4일에 다운로드한 버전( cf6344b4 )과 일치하는지 확인할 수 있습니다.

PR은 모두 Squash&Merge를 사용하여 병합되므로 서명되지 않습니다(또는 GitHub의 마법으로 서명될 수 있음 :))

기본적으로 안전하지 않고 임의의 gpg 키인 병합 버튼을 사용하지 마십시오. 로컬에서 병합하고 병합을 푸시합니다.

@mappu gitea v1.4.1은 영향을 받지 않았으며 이제 v1.4.2가 다시 릴리스되었습니다.

signify 로 서명한 git-archive에서 생성한 tarball(github이 자동으로 생성하는 tarball 외에)을 업로드해야 합니다.

실제로 아카이브를 구축하고 다시 업로드할 필요조차 없습니다. 생성된 GitHub는 재현 가능하므로 서명할 수 있습니다.

다음은 이에 대한 작은 스크립트입니다. https://github.com/rugk/gittools/blob/master/signrelease.sh

@rugk 유용한 스크립트. :웃다:

기여한 팀원 중 침해 발견 이전에 1.4.2 아카이브를 받은 적이 있습니까?

이 바이너리가 Linux 릴리스에 대해 변경되었는지 여부에 대해 많은 사람들을 어둠 속에 남겨둔 것 같습니다. 이는 다음을 고려하는 매우 중요한 정보입니다.

1) 대부분의 배포는 Linux 스택입니다.

2) Linux 스택은 바이너리 트로이 목마에 익숙하지 않으며 일반적으로 시스템에서 이미 실행 중인 의심스러운 코드를 프로그래밍 방식으로 감지하는 최고의 도구에 적합하지 않습니다.

나는 이것이 단순한 Windows 표적 공격이라고 믿고 싶지만, 그들이 이 특정 리포지토리를 단 며칠 만에 사용자 기반 성장의 극적인 급증으로 표적으로 삼았다는 사실은 더 잘 조직된 노력을 나타내는 것 같습니다. 나는 그들이 무엇을 목표로 삼고 이런 종류의 일을 해낼 수 있는지 아는 사람이 가능한 한 많은 호스트를 감염시킬 수 있는 그런 무르익은 기회를 그냥 지나쳤을지 매우 의심스럽습니다.

@stanier dl.gitea.io는 영향을 받지 않았으며 다른 바이너리가 변조되지 않았음을 확인했습니다.

그래서 우리 webproxy가 hub.docker.com에서 최신 gitea 이미지 다운로드를 거부한 이유를 설명합니다...

@lafriks c843d462 및 e14e54f3 모두 안전한지 확인할 수 있습니까? CI가 다른 서명이 있는 빌드를 제공했다면 소스 코드나 컴파일러가 빌드에 사용한 매개변수에서 무언가가 변경되었을 것입니다. 그 자체로는 사소한 기술이지만, 공격자가 1.4.2 Linux 바이너리를 변경했는지 여부는 여기에 직접 언급되지 않았으며 @daviian의 의견에 언급된 해당 .exe 바이너리만 있습니다.

명확히하기 위해 dl.gitea.io가 아닌 GH repo의 릴리스 페이지 바이너리에 대해 묻고 있습니다. GH repo 외부에서 아무 것도 변조되지 않았음을 이해합니다.

Linux 스택은 바이너리 트로이 목마에 익숙하지 않으며 일반적으로 시스템에서 이미 실행 중인 의심스러운 코드를 프로그래밍 방식으로 감지하는 최고의 도구에 적합하지 않습니다.

흠, 대부분의 패키지 관리자(및 이와 유사한 것)에는 최소한 sha* 체크섬을 확인하기 위한 규정이 있지 않습니까? 반드시 맬웨어를 감지하기 위한 것이 아니라 "다운로드가 손상되지 않았는지 확인할 수 있습니다".

@justinclift 예, 하지만 패키지 관리자를 통해 설치된 바이너리에만 적용됩니다. 여기서 문제의 문제는 내가 아는 한 내장된 맬웨어 감지 기능이 없는 GitHub에서 직접 다운로드하는 것과 관련이 있습니다.

아아. 자동화된 솔루션이 하는 것보다 다운로드가 단순한 일회성(예: 프로토타이핑할 때)이 되도록 지시하는 데 더 익숙하기 때문에 "Linux 스택"이라는 용어가 저를 실망시켰습니다. 걱정 마. :웃다:

@stanier 빌드는 모두 지우기 위해 드론으로 다시 실행되었습니다. Go는 일부 변수(예: 빌드 시간)가 변경될 수 있으므로 바이너리를 빌드할 때마다 동일한 바이너리를 제공하지 않으므로 해시가 다른 것이 정상입니다.
조사하는 동안 모든 바이너리를 얻었고 개인용 컴퓨터에 도착하자마자 해시를 제공할 수 있습니다.

모두를 위해 소문에 대한 논쟁을 중단하고 건설적인 의견을 제공하십시오.
나는 당신이 당신의 보안에 대해 걱정하고 있다는 것을 이해하고 우리는 그것에 대해 크게 걱정합니다(우리도 gitea 사용자로서 당신의 입장에 있기 때문에). 현재 액세스가 변경되었으며 더 이상 의심스러운 활동을 보지 못했습니다. 우리는 가능한 한 빨리 투명하게 알리고 조사에 유용한 데이터 또는 완벽한 사람이 없기 때문에 누락된 부분에서 입력을 받을 수 있도록 이 문제를 수행했습니다.
우리는 무슨 일이 일어 났는지 설명하기 위해 부검을 할 것이며 우리는 미래에 이것을 방지하기 위한 조치를 확실히 생각하고 있습니다.
이 문제가 난리를 치면 유용하고 간결한 정보만 유지하고 토론을 불화의 방향으로 보내기 위해 닫아야 한다고 생각합니다.

앞으로 그런 상황을 피하기 위해 우리는 다음 버전에서 모든 바이너리에 서명하기 시작할 것입니다. https://github.com/drone-plugins/drone-gpgsign (이 플러그인에 대한 문서를 작성해야 함)에서 찾을 수 있는 Drone용 플러그인을 만들었습니다. 이 플러그인은 모든 바이너리에 서명하고 공개 키가 업로드됩니다. 다운로드 서버와 키 서버에 연결하면 항상 신뢰할 수 있는 방식으로 바이너리를 확인할 수 있습니다.

이것이 어떻게 보이고 결과는 무엇인지 예를 보여주기 위해 https://github.dronehippie.de/webhippie/ldap-proxy/49/18 및 https://dl.webhippie.de를 볼 수 있습니다.

이 플러그인에 정말 중요한 것이 누락되어 있다고 생각되면 언제든지 플러그인 저장소에서 문제를 여십시오. 그러면 제가 해결할 수 있습니다.

@sapk 설명 감사합니다. 죄송합니다. 이 프로젝트가 Golang 기반이라는 생각이 완전히 사라졌습니다. 이와 같은 대부분의 문제는 이전 소프트웨어와 관련된 것이므로 잘못된 관계로 마음이 급한 것 같습니다. 내 실수.

업로드된 install.exe 바이너리를 살펴보기 시작했습니다. https://grh.am/2018/a-look-at-the-compromised-gitea-release/

이것으로 타격을 받은 것은 Gitea뿐만 아니라 https://github.com/opencompany/www.opencompany.org/releases 이기도 합니다.

명쾌한 설명 감사합니다.

이 문제가 배포판별 패키징을 진행하는 주된 이유라고 생각합니다. 패키징 및 잠재적인 악성 코드/바이너리(특히 그러한 총체적인 시도의 경우)에 더 많은 주의를 기울입니다. 적어도 Gitea용 Debian/RedHat/Archlinux 패키지가 있으면 좋을 것입니다. 이렇게 하면 많은 사람들이 프로덕션 서버에서 임의의 바이너리를 실행하는 것을 방지할 수 있습니다. :)

PGP 서명으로 릴리스가 충분합니까? 아마. 예를 들어 웹 사이트가 손상되어 모두가 잘못된 키를 다운로드하지 않도록 다양한 플랫폼에서 공개 키를 광고하십시오. (그러나 백포트의 데비안 패키지는 <3)

(또한, 재현 가능한 빌드 ?)

바이너리 릴리스 서명을 시작할 것이므로 레지스트리에 푸시된 Docker 이미지에 서명하는 것도 고려해 볼 수 있습니까?

이것으로 타격을 받은 것은 Gitea뿐만 아니라 https://github.com/opencompany/www.opencompany.org/releases 이기도 합니다.

아직 GitHub 문제를 보고 있지 않은 경우를 대비하여 담당자에게 직접 이메일을 보냈습니다.

@graystevens 그 pastebin 주소를 죽이기 위해 pastebin 직원에게 연락해야 합니까, 아니면 제대로 이해할 수 있도록 먼저 맬웨어를 완전히 분석하는 것이 더 낫습니까?

모두 감사합니다. 다시 다운로드하고 서버를 백업하겠습니다.

@justinclift 지금 붙여넣기를 PasteBin에 보고하겠습니다. 필요한 경우 맬웨어에 대한 출력을 다시 만들 수 있도록 내용의 복사본을 얻었습니다. 좋은 소리

공정하게 말하면 go는 이제 재현 가능한 빌드를 갖습니다. https://blog.filippo.io/reproducing-go-binaries-byte-by-byte/
아마도 sqlite용 cgo와 그것들을 재현할 수 없게 만드는 일부 빌드 환경일 수 있습니다.

참고로 이전 재구축 및 변경되지 않은 해시 목록입니다. 해당 해시가 있는 경우 1.4.2 릴리스를 재설정하기 위해 수행한 재구축 전과 공격 전에 바이너리가 있다는 의미입니다. 만약 그렇다면 당신은 그들과 함께 있을 수 있습니다.

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

install.exe 정리 단계에서 꽤 많은 저장소가 누락된 것 같습니다.

• go-gitea/gitea-darkmode
• go-gitea/lgtm-cli
• go-gitea/얌
• 고기티/볼트
• go-gitea/lgmt-go
• go-gitea/lgmt-docs

이들 중 대부분은 오래되었고 정확히 관련이 없지만 맬웨어를 주변에 두는 것은 좋은 생각이 아닙니다.

@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
  

감사합니다. 이들을 찾기 위해 어떤 접근 방식을 사용하고 있습니까? GitHub 직원이 사용한 접근 방식이 100% 효과적이지는 않은 것 같습니다. :찡긋:

@jvanraaij @yaggytter 감사합니다.

조사 후 GitHub에서 더 이상 영향을 받지 않았고 더 이상 정보를 제공하지 않았기 때문에 이 문제를 종료할 수 있다고 생각합니다. 이것에 대해 블로그 게시물을 작성할 사람이 있습니까?

@lafriks 이 모든 후 며칠 이내에 했습니다. 당면한 문제보다 맬웨어를 살펴보는 것이 더 중요하지만 문서화할 가치가 있다고 생각되면 업데이트하겠습니다. 👍

gitea 블로그에 사후 블로그 포스트를 쓰고 싶은 것 같아요 :)

@graystevens BTW 사이트 공지 링크 는 404

조사 후 GitHub에서 더 이상 영향을 받지 않았고 더 이상 정보를 제공하지 않았기 때문에 ...

데이터 포인트로서 GitHub는 공개적으로 이에 대해 아무 말도 하지 않았지만 비공개적으로는 (이메일을 통해) 효과적으로 "고맙습니다. 조사 중입니다."라고 응답했습니다.

@jvanraaij 및 @yasuokav 의 위 댓글도 도움이 되는 것 같았습니다. (이상하게도 내 PoV에서) GitHub가 그 이전에 특정 맬웨어 인스턴스를 찾지 못한 것 같습니다.

예를 들어 @yasuokav가 여기에 나열된 모든 저장소에는 여전히 멀웨어가 있습니다: https://github.com/crossoverJie/SSM/issues/36

GitHub 직원에게 다시 이메일을 보내 지적하겠습니다. 정확한 목록을 보고 직접 연락하면 며칠 이내에 처리되는 것 같습니다.

이것은 다른 모든 프로젝트에서 슬픈 일이지만 적어도 Gitea의 경우 문제를 적절하게 해결했기를 바랍니다. :)

이제 바이너리가 서명되고 2FA가 구현되므로 이 문제를 종료합니다.