Gitea: Giteabotアカウントが侵害されました

それまでの間、リリースされたバイナリ、特にWindowsのバイナリをダウンロードするときは、追って通知があるまで注意してください。 たとえば、バイナリのサイズ、またはダブル.exeファイルの終わりに注意してください。
リリース1.4.2内の.exeバイナリも変更されていることがわかりました。

私たちはすべての道をたどり、片付けをし、できるだけ早く日常業務に戻るように一生懸命働いています。

@daviianたぶん、リリースに署名する必要がありますか？

@Mauladenご

痛い！ ええ、署名されたバイナリが理想的です。

@Mauladen安全なものを提供するために、1.4.2リリース用にバイナリを再構築しました。

それとも何か他のことを意味しましたか？

これは正常です。 そのリリースのWindowsバイナリが削除され、新しい1つの悪意のあるものが追加されたため、バイナリを再構築するためにCIを再トリガーするように1.4.2のタグを付け直しました。

@daviian 、たぶん@Mauladenは、GPG署名なしで1.4.2リリースコミットを意味しましたが、1.4.1は

変更のリストを編集する必要があります

@axifive commitは、ユーザーが署名したgpgではなく、マージがPR作成者と同じ場合に自動的に（githubキーを使用して）それを行うgithubです。 githubアカウントが侵害された場合、「確認済み」としても表示されるため、より安全だとは思いません。 しかし、私たちは今からタグに署名し始めることができます（議論するために）。 参考までに、git commitツリーとしてthzanバイナリを修正する方が簡単なので、バイナリの署名に取り組んでいます。

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リリースをソースコードから更新しても安全ですか？

現時点では、バイナリのみが影響を受けたかどうかはわかりません。 これをどのように確認しましたか？ あなたの枝は保護されていますか？

シャサムは、バイト数は同じですが、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 ：

質問-影響を受けたのはWebサイトのバイナリだけですか、それともリポジトリも影響を受けましたか？ 昨日Giteaのことを聞いて、v1.4ブランチのクローンを作成してビルドしたので、私は尋ねます。

ソース自体が危険にさらされている場合、またはバイナリのみが危険にさらされている場合は、さらに情報が必要です。 私は毎晩gitからの更新/ビルドをチェックするスクリプトを実行しましたが、タイミングが原因でこれを見逃すことができて幸運でした。

現在の1.4.2リリースはクリーンであることが確認されていますか？ それが汚染されていることがわかっている場合は、できるだけ早くプルして分析のために別の場所に配置する必要があります。そうしないと、この問題が発生しない場合でも、ダウンロードされます。 @CountMurphyに同意します

バイナリが影響を受けているかどうかを確認できるように、ハッシュを取得できますか？ 私のgitea1.4.1（linux amd64）は次のようになります。
$ sha256sum gitea
d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851 gitea

gitea 1.4.1 linux-amd-64をダウンロードしたところ、sha256としてd8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851も入手しました。

@mikedilger参照： https ：

圧倒的に明確にするために：誰も何も知らず、安全なハッシュは現在ここにあるものだけです： https ：

amd64上のGitea1.4.2の場合、これは次のことを意味します。

申し訳ありませんが、 https： //github.com/go-gitea/gitea/issues/4167#issuecomment -395576229を、両方のバイナリが侵害されたと誤解しました。

私はこの投稿を編集して、私たちが実際に知っていることについての曖昧さを取り除きました。

待ってください：このコメント（https://github.com/go-gitea/gitea/issues/4167#issuecomment-395576229）によると、6月4日からの2つのsha e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9とc843d462b5ed

これらの両方が危険にさらされていると言っているのですか、それとも一方だけですか？ 記録として、私のサーバーにあるのは6月5日からのe14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9です。

@christianbundy 、お願いします、急いで結論を出さないでください、チームメンバーからの応答を待ってください

急いで結論を出さないでください。チームメンバーからの返答を待ってください。

申し訳ありませんが、ファイルハッシュはチームメンバーによってすぐに投稿されると思いましたが、情報が暗闇の中で他の誰かからのものであることに気づいていませんでした。 これは最新の開発を監視するための正しいチャネルですか？ サーバーの電源を切ったので、感染したかどうかを確認するための詳細情報が必要です。

あなたの編集が私が指摘したエントリに取り消し線を引いているのがわかります。 しかし、これは結論を出すには早すぎませんか？ e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9が正常であることをどのようにして確実に知ることができますか？

まだいくつかの情報が不足しています（網羅的ではない可能性があります）。

• []どのバイナリが侵害され、それらのチェックサムは何ですか？
• []ボットアカウントが侵害されたのはいつですか？
• []ソースリポジトリが危険にさらされていますか（これは、あるバージョンのリポジトリのクローンが作成されているかどうかを簡単に確認できる可能性があります。その後、差分や強制プッシュの証拠を確認できます）。

私が得た：

# 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 e14e54f3ではなく、 c843d462で問題ないと言った。 これは、GitHubで現在提供されているファイルであり、最近再構築されたためです。

1.4.2が再構築された場合は、他の有効なリリースと同様に署名および検証する必要があります。 そうしないと、混乱が増すだけです。

@xcolour

ここにバイナリをアップロードしました： https ：

これら二つのバイナリの唯一の違いは、の約2000のインスタンスということですmovabsq $63663754793, %rcx置き換えられたmovabsq $63663969431, %rcx 。 それが何を振る舞うのか正確に言うことはできませんが、それが悪意のあるものである可能性は非常に低いと思います。

たぶん、新しい（署名された？）1.4.3リリースを既知の安全なコードでプッシュするのでしょうか、それとももっと混乱させるのでしょうか？

@justinclift私はそのアイデアが好きです。また、ブログ投稿やREADMEの状況に関する何かが、問題を解決するのに役立ちます。

@ spaghetti2514

一方で、その通りです。2つのバイナリの違いは簡単にわかります。

一方、Giteaチームは、影響を受けたバイナリを実際に投稿したり、SHA256ハッシュを投稿したり、妥協点を理解するのに役立つ情報を実際に投稿したりしていません。他の人が指摘しているように、判断するのに十分な情報がありません。何が起こったのか、誰が影響を受けたのか。

おそらく最悪の事態を想定して、コアチームからの診断手順を待つ必要があることを指摘するのはイライラします。 そうは言っても、分解された差分を投稿していただきありがとうございます。

これはあなたが探しているものですか？ https://github.com/go-gitea/gitea/issues/4167#issuecomment -395579466

@lafriksを更新していただきありがとうございます！

問題の説明を追加情報で更新しました。 それほど悪くはなかった。 できるだけ透明性を高めたかったので、すべてをクリーンアップして修正したらすぐにこの問題を作成しました。このようなことが初めて発生したため、混乱を招いて申し訳ありませんが、より多くの情報をより早く提供する必要がありました。

@lafriks更新してくれてありがとう！ 今後、コミットを確認するために使用できるPGPキーを投稿していただけますか？

@ 4oo4タグは、合併独自のGPGキーのいずれかによって署名されます

リリースは、1.5.0リリースより前に作成されるGPGキーによって署名されます。これは、README.md、gitea docs、およびブログ投稿で公開されます。

386ユーザーとして、[リリース]ページで現在利用可能なgitea-1.4.1-linux-386バイナリが、6月4日にダウンロードしたバージョン（ cf6344b4 ）と一致することを確認できます。

PRはすべてSquash＆Mergeを使用してマージされるため、署名されていません（または、GitHubの魔法によって署名されている可能性があります:)）

マージボタンは使用しないでください。これは基本的に安全ではなく、ランダムなgpgキーです。 ローカルでマージし、マージをプッシュします。

@mappu gitea v1.4.1は影響を受けておらず、v1.4.2が再リリースされました。

（githubが自動的に生成するものに加えて）git-archiveによって作成されたtarballをアップロードし、signifyで署名する必要があります。

実際には、アーカイブを作成して再度アップロードする必要はありません。 再現性のある方法で作成できるため、GitHubで作成したものに署名できます。

そのための小さなスクリプトは次のとおりです： https ：

@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リポジトリのリリースページバイナリについて質問しています。GHリポジトリの外部で改ざんされたものは何もないことを理解しています。

Linuxスタックは、バイナリトロイの木馬に慣れておらず、通常、システムですでに実行されている疑わしいコードをプログラムで検出するための最適なツールには適していません。

うーん、ほとんどのパッケージマネージャー（および同様のもの）には、少なくともsha *チェックサムを検証するためのプロビジョニングがありませんか？ 必ずしもマルウェアを検出するためだけでなく、「ダウンロードが破損していないことを確認しましょう」として。

@justincliftはい。ただし、これはパッケージマネージャーを介してインストールされたバイナリにのみ適用されます。 ここで問題となっているのは、GitHubからの直接ダウンロードに関するものです。GitHubには、私の知る限り、マルウェア検出が組み込まれていません。

ああ。 「Linuxスタック」という用語は、自動化されたソリューションが行うことよりも、単純な1回限りのこと（プロトタイピングなど）でダウンロードを指示することに慣れているため、私を思いとどまらせました。 心配ない。 ：笑顔：

@stanierビルドは、すべてをクリアするためにドローンによって再実行されました。 一部の変数（ビルド時間など）が変更される可能性があるため、Goはバイナリをビルドするたびに同じバイナリを提供しないため、ハッシュが異なるのが普通です。
調査中にすべてのバイナリを取得し、パソコンにアクセスするとすぐにハッシュを提供できます。

すべての人にとって、噂についての議論をやめ、建設的な意見を提供してください。
あなたがあなたのセキュリティを心配していることを理解しています、そして私たちはそれを大いに気にかけています（私たちはgiteaのユーザーとしてあなたの場所にもいるので）。 現在、アクセスが変更されており、疑わしいアクティビティは発生していません。 この問題は、透明性を確保し、完璧な人はいないため、調査や見逃したスポットに役立つデータから入力を受け取ることができるように、できるだけ早く通知するために行いました。
私たちは何が起こるかを説明するために事後分析を行い、将来これを防ぐための行動を明確に考えています。
この問題が深刻化した場合、有用で簡潔な情報のみを保持し、それがどこに行くべきかを不和にするために議論を送るために、私たちは閉じる必要があると思います。

将来そのような状況を回避するために、次のバージョンですべてのバイナリに署名し始めます。 https://github.com/drone-plugins/drone-gpgsign （このプラグインのドキュメントを作成する必要があります）にあるDroneのプラグインを作成しました。このプラグインは、すべてのバイナリに署名します。公開鍵がアップロードされます。ダウンロードサーバーとキーサーバーに対して、信頼できる方法でバイナリを常に検証できるようになります。

これがどのように見えるか、そしてどのような結果になるかの例を示すために、 https：//github.dronehippie.de/webhippie/ldap-proxy/49/18とhttps://dl.webhippie.deを見てください。 / misc / ldap-proxy / master / 、同様のファイルがGiteaダウンロードページとGitHubリリースにアップロードされます。

このプラグインに本当に重要なものが欠けていると思われる場合は、プラグインリポジトリで問題を開いてください。対処できます。

@sapk説明してくれてありがとう。 申し訳ありませんが、プロジェクトがGolangベースであることに完全に気が狂いました。このような問題のほとんどは古いソフトウェアを扱っているため、私の心は誤った関係に飛びついたと思います。 私の間違い。

アップロードされたinstall.exeバイナリを確認し始めました： https ：

これに見舞われたのはGiteaだけではなく、 https：//github.com/opencompany/www.opencompany.org/releasesのようです。

わかりやすい説明ありがとうございます。

この問題が、ディストリビューション固有のパッケージングを実行する主な理由だと思います。 それはパッケージングと潜在的な悪意のあるコード/バイナリにもっと注意を向けさせます（特にそのような大規模な試みの場合）。 少なくともGitea用のDebian / RedHat / Archlinuxパッケージがあれば素晴らしいでしょう：それは多くの人々が彼らの本番サーバーで任意のバイナリを実行するのを防ぐでしょう:)

PGP-リリースへの署名は十分ですか？ 多分。 たとえば、Webサイトを危険にさらしても、誰もが間違ったキーをダウンロードしないように、さまざまなプラットフォームで公開キーをアドバタイズするようにしてください。 （ただし、バックポートのDebianパッケージは<3になります）

（また、再現可能なビルド？）

バイナリリリースへの署名を開始するので、レジストリにプッシュされたDockerイメージへの署名も検討できますか？

これに見舞われたのはGiteaだけではなく、 https：//github.com/opencompany/www.opencompany.org/releasesのようです。

GitHubの問題をまだ確認していない場合に備えて、連絡先に直接メールを送信するだけです。

@graystevensそのペーストビンアドレスを殺すためにペーストビンスタッフに連絡する必要がありますか、それともマルウェアが正しく理解されるように最初にマルウェアを完全に分析する方が良いですか？

みんなありがとう..再ダウンロードしてサーバーをバックアップします

@justinclift今すぐPasteBinに貼り付けを報告します-必要に応じてマルウェアの出力を再作成できるように、コンテンツのコピーを取得しました。 良い叫び

公平を期すために、goは再現可能なビルドになりました： https ：
それはおそらく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 / yaml
• go-gitea / Bolt
• 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ところであなたのサイトの通知リンクは404のものです。 ：笑顔：

調査後、他に影響はなく、GitHubからの情報提供もありませんでした...

データポイントとして、GitHubはこれについて公の場では何も言っていませんが、個人的には（メールで）「ありがとう、調査中です」と効果的に答えています。

@jvanraaijと@yasuokavによる上記のコメントも

たとえば、 @ yasuokavによってここにリストされているすべてのリポジトリにはまだマルウェアがあります： https ：

それを指摘するために、GitHubのスタッフにもう一度メールを送ります。 正確なリストを直接連絡してみると、数日以内に問題が解決するようです。

これは他のすべてのプロジェクトにとっては悲しいことですが、少なくともGiteaについては、問題を適切に解決しました。うまくいけば... :)

バイナリが署名され、2FAが実装されたため、この問題を解決します。