Gitea: Учетная запись Giteabot была взломана

А пока будьте осторожны при загрузке наших выпущенных двоичных файлов, особенно для Windows, до дальнейшего уведомления. Например, следите за размером двоичных файлов или двойным окончанием файла .exe .
Мы обнаружили, что наши двоичные файлы .exe в версии 1.4.2 также были изменены.

Мы прилагаем все усилия, чтобы пройти по всем тропам, очистить их и как можно скорее вернуться к повседневным делам.

@daviian Может тогда стоит подписывать релизы?

@Mauladen Спасибо за ваш вклад. Мы обязательно это обсудим.

Ой! Да, подписанные двоичные файлы были бы идеальными.

@Mauladen Мы перестроили двоичные файлы для выпуска 1.4.2, чтобы убедиться, что мы предоставляем безопасные.

Или вы имели в виду что-то другое?

Это нормально. Мы повторно запустили версию 1.4.2, чтобы перезапустить CI для восстановления двоичных файлов, поскольку двоичный файл Windows для этого выпуска был удален и был добавлен новый вредоносный.

@daviian , возможно, @Mauladen означало, что релиз версии 1.4.2 был зафиксирован без подписи GPG, но 1.4.1 был

Еще нужно отредактировать список изменений

@axifive commit, где не gpg, подписанный пользователем, а github, который делает это автоматически (с ключом github), когда слияние совпадает с автором PR. Я бы не стал считать его более безопасным, потому что, если учетная запись github была скомпрометирована, я также буду отмечен как «проверенный». Но мы могли бы начать подписывать теги с этого момента (будет обсуждаться). Для информации, мы работаем над подписанием двоичного файла, поскольку его проще исправить как дерево коммитов git.

Вы должны загрузить tarball, созданный git-archive (в дополнение к тем, которые github генерирует автоматически), который вы подписываете с помощью signify . Вы можете получить представление о том, как это работает / выглядит здесь:

• 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://send.firefox.com/download/a5dc9a9335/#_k9e4Cu2r4pPNDrsS1T2CA. Если нужно, я положу их где-нибудь на более постоянное место.

Вопрос - были ли затронуты только двоичные файлы на веб-сайте или репозитории также были затронуты? Я спрашиваю, потому что вчера я услышал о Gitea и клонировал и построил ветку v1.4.

Хотелось бы получить дополнительную информацию, если сам источник скомпрометирован или только двоичные файлы. Я запускаю скрипт для проверки обновлений / сборки от git каждую ночь, и мне посчастливилось пропустить это из-за времени.

Проверена ли текущая версия 1.4.2 на чистоту? Если мы знаем, что это испорчено, мы должны извлечь это как можно скорее и поместить в другое место для анализа, иначе люди все равно будут загружать это, если не увидят этой проблемы. Я согласен с @CountMurphy , можем ли мы добавить что-нибудь в README, чтобы это действительно было видно?

Можем ли мы получить хэши, чтобы проверить, не затронуты ли наши двоичные файлы? Моя gitea 1.4.1 (linux amd64) выглядит так:
$ sha256sum gitea
d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851 gitea

Я только что загрузил gitea 1.4.1 linux-amd-64 и получил d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851 как sha256.

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

Чтобы сделать это предельно ясно: никто ничего не знает, и единственные безопасные хэши - это те, которые в настоящее время находятся здесь: https://github.com/go-gitea/gitea/releases

Для Gitea 1.4.2 на amd64 это означает:

Извините, я неправильно понял https://github.com/go-gitea/gitea/issues/4167#issuecomment -395576229, что означает, что оба двоичных файла были скомпрометированы.

Я отредактировал этот пост, чтобы устранить двусмысленность в том, что мы на самом деле знаем.

Держитесь: в соответствии с этим комментарием (https://github.com/go-gitea/gitea/issues/4167#issuecomment-395576229), есть два шас e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 от 4 июня и c843d462b5edb0d64572b148a0e814e41d069d196c3b3ee491449225e1c39d7d с 7 июня.

Мы говорим, что оба они скомпрометированы или только один из них? Для справки, на моем сервере - e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 с 5 июня.

@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

С sha256sum c843d462b5edb0d64572b148a0e814e41d069d196c3b3ee491449225e1c39d7d который соответствует предоставленному файлу .sha256: 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 была перестроена, ее следует подписать и проверить, как и другие действующие версии. Невыполнение этого только добавляет путаницы.

@xcolour

Загрузил двоичные файлы здесь: https://send.firefox.com/download/a5dc9a9335/#_k9e4Cu2r4pPNDrsS1T2CA

Единственная разница между этими двумя двоичными файлами заключается в том, что около 2000 экземпляров movabsq $63663754793, %rcx были заменены на movabsq $63663969431, %rcx . Я не могу точно сказать, что это меняет в поведении, но я думаю, что этого очень маловероятно, чтобы быть злым.

Может быть, выпустить новую (подписанную?) Версию 1.4.3 с заведомо безопасным кодом, или это еще больше запутает ситуацию?

@justinclift Мне нравится эта идея, также сообщение в блоге и кое-что в README о ситуации помогли бы прояснить ситуацию.

@ spaghetti2514

С одной стороны, вы правы - различия между этими двумя двоичными файлами легко увидеть.

С другой стороны, команда Gitea на самом деле не опубликовала, какие двоичные файлы были затронуты, не опубликовала какие-либо хэши SHA256 и действительно не сказала что-нибудь, что могло бы помочь нам понять компромисс. Как указывали другие, у нас недостаточно информации, чтобы определить что случилось и кто пострадал.

Я с разочарованием отмечаю, что нам, вероятно, следует просто предположить худшее и дождаться диагностических шагов от основной группы. С учетом сказанного, я ценю, что вы разместили разобранный diff.

Это то, что вы ищете? https://github.com/go-gitea/gitea/issues/4167#issuecomment -395579466

Спасибо за обновление @lafriks !

Я обновил описание проблемы, добавив дополнительную информацию. Это было не так плохо, как могло бы быть. Мы хотели быть максимально прозрачными, поэтому создали эту проблему, как только мы все очистили и исправили, и, поскольку это было впервые, поэтому, вероятно, нам следовало предоставить больше информации быстрее, извините за путаницу.

@lafriks Спасибо за обновление! Не могли бы вы опубликовать свой ключ PGP, который мы сможем использовать в будущем для проверки коммитов?

Теги @ 4oo4 подписаны одним из собственных ключей GPG одного из слияний, поскольку все PR объединены с использованием Squash & Merge, они не подписаны (или, возможно, подписаны магией GitHub :))

Релизы будут подписаны ключом GPG, который будет создан до выпуска 1.5.0, мы опубликуем его на README.md, gitea docs и в блоге.

Как пользователь 386, я могу подтвердить, что бинарный файл gitea-1.4.1-linux-386 доступный в настоящее время на странице «Релизы», соответствует версии, которую я загрузил 4 июня ( cf6344b4 ).

поскольку все PR объединены с использованием Squash & Merge, они не подписаны (или, возможно, подписаны магией GitHub :))

Не используйте кнопку слияния, это небезопасно и случайный ключ gpg. Выполните локальное слияние и нажмите на слияние.

@mappu gitea v1.4.1 не была затронута, и теперь v1.4.2 была повторно выпущена.

Вы должны загрузить tarball, созданный git-archive (в дополнение к тем, которые github генерирует автоматически), который вы подписываете с помощью signify.

Собственно, вам даже не нужно создавать архивы и загружать их заново. Вы можете подписать один созданный GitHub, потому что это можно сделать воспроизводимо.

Вот небольшой сценарий для этого: https://github.com/rugk/gittools/blob/master/signrelease.sh

@rugk Полезный на вид скрипт. :улыбка:

Получил ли кто-либо из участников команды архив 1.4.2 до обнаружения нарушения?

Вы, кажется, оставили много людей в неведении относительно того, был ли этот двоичный файл изменен для каких-либо выпусков Linux, что является довольно важной информацией, учитывая:

1) Большинство развертываний будет в стеках Linux

2) Стеки Linux не привыкли к двоичным троянам и обычно не подходят для использования с лучшими инструментами для программного обнаружения подозрительного кода, уже запущенного в системе.

Хотя мне хотелось бы верить, что это была простая атака, нацеленная на Windows, и ничего более, тот факт, что они нацелены на этот конкретный репозиторий всего за несколько дней до резкого всплеска роста пользовательской базы, кажется показателем для более хорошо организованных усилий. Я очень сомневаюсь, что кто-то, кто знал, на что они нацелены и как это осуществить, просто упустил бы такую ​​удобную возможность заразить как можно больше хостов.

@stanier dl.gitea.io не пострадал, и мы убедились, что никакие другие двоичные файлы не были изменены

Это объясняет, почему наш веб-прокси отказался загрузить последний образ gitea с hub.docker.com ...

@lafriks Итак, можете ли вы подтвердить, что c843d462 и e14e54f3 оба безопасны? Если CI предоставил сборку с другой подписью, то должно быть что-то изменилось либо в исходном коде, либо в параметрах, которые компилятор использовал для сборки. Само по себе это мелкая техническая деталь, но здесь никогда прямо не говорилось, изменил ли злоумышленник двоичные файлы 1.4.2 Linux, а только соответствующие двоичные файлы .exe, упомянутые в комментарии @daviian.

Чтобы уточнить, я спрашиваю о двоичных файлах страницы выпуска репозитория GH, а не о dl.gitea.io, я понимаю, что ничего не было изменено за пределами репозитория GH.

Стекы Linux не привыкли к двоичным троянам и обычно не подходят для использования с лучшими инструментами для программного обнаружения подозрительного кода, уже запущенного в системе.

Хммм, разве в большинстве менеджеров пакетов (и подобных) не предусмотрена проверка хотя бы sha * контрольных сумм? Не обязательно только для обнаружения вредоносных программ, но как «позволяет убедиться, что загрузка не повреждена».

@justinclift - да, но это применимо только к двоичным

Аааа. Термин «стеки Linux» сбил меня с толку, поскольку я больше привык к тому, что прямые загрузки являются упрощенными одноразовыми вещами (например, при создании прототипов), а не чем-то автоматическим. Не стоит беспокоиться. :улыбка:

@stanier сборка была переделана дроном, чтобы очистить все. Go не предоставляет один и тот же двоичный файл каждый раз, когда вы создаете двоичный файл, поскольку некоторые переменные могут измениться (например, время сборки), поэтому хеширование может быть другим.
Я получил все двоичные файлы во время расследования и могу предоставить хеши, как только доберусь до своего персонального компьютера.

Для всех, пожалуйста, прекратите спорить со слухами и внесите конструктивный вклад.
Я понимаю, что вы беспокоитесь о своей безопасности, и мы очень заботимся об этом (поскольку мы также находимся у вас в качестве пользователя gitea). В настоящее время доступ был изменен, и мы больше не наблюдали никакой подозрительной активности. Мы сделали эту проблему, чтобы информировать как можно скорее, чтобы быть прозрачными и иметь возможность получать вводные данные из любых данных, полезных для исследования или пропущенного места, поскольку никто не идеален.
Мы проведем вскрытие, чтобы объяснить, что произошло, и окончательно продумаем меры, чтобы предотвратить это в будущем.
Если этот вопрос разрастется, я думаю, нам нужно будет закрыть, чтобы сохранить только полезную и краткую информацию, и направить дебаты в разногласия, куда они должны пойти.

Чтобы избежать подобной ситуации в будущем, мы начнем подписывать все двоичные файлы следующей версией. Я создал плагин для Drone, который вы можете найти по адресу https://github.com/drone-plugins/drone-gpgsign (необходимо подготовить документацию для этого плагина), который будет подписывать все двоичные файлы, открытый ключ будет загружен на сервер загрузки и на сервер ключей, чем вы всегда сможете проверить двоичные файлы надежным способом.

Чтобы показать вам пример, как это будет выглядеть и каковы результаты, вы можете взглянуть на https://github.dronehippie.de/webhippie/ldap-proxy/49/18 и https://dl.webhippie.de / misc / ldap-proxy / master / , аналогичные файлы будут загружены на страницу загрузки Gitea и в выпуски GitHub.

Если вы думаете, что в этом плагине отсутствует что-то действительно важное, не стесняйтесь открывать проблему в репозитории плагинов, и я могу ее решить.

@sapk Спасибо за разъяснения. Прошу прощения, мне совершенно не приходило в голову, что проект был основан на Голанге - большинство проблем, подобных этой, связано с более старым программным обеспечением, поэтому я думаю, что у меня в голове возникло ложное отношение. Виноват.

Я начал смотреть на загруженный двоичный файл install.exe : https://grh.am/2018/a-look-at-the-compromised-gitea-release/

Похоже, это коснулось не только Gitea, но и https://github.com/opencompany/www.opencompany.org/releases.

Спасибо за четкое объяснение.

Я думаю, что эта проблема - основная причина, по которой нужно разрабатывать пакеты для конкретного дистрибутива. Это привлекает больше внимания к упаковке и потенциальному вредоносному коду / двоичному файлу (особенно в случае такой грубой попытки). Было бы здорово иметь хотя бы пакеты Debian / RedHat / Archlinux для Gitea: это помешало бы многим людям запускать произвольный двоичный файл на своем производственном сервере :)

Достаточно ли подписывать релизы PGP? Наверное. Просто обязательно рекламируйте свой открытый ключ на многих различных платформах, чтобы компрометация, например, вашего веб-сайта, не заставила всех загрузить неправильные ключи. (Но пакет Debian в бэкпортах будет <3)

(Кроме того, воспроизводимые сборки ?)

Поскольку вы начнете подписывать двоичные выпуски, не могли бы вы также подумать о подписании образов Docker, помещенных в реестр?

Похоже, это коснулось не только Gitea, но и https://github.com/opencompany/www.opencompany.org/releases.

Просто отправили электронное письмо своим контактным лицам, если они еще не изучают свои проблемы с GitHub.

@graystevens Следует ли

Всем спасибо .. Я бы повторно скачала и восстановила мой сервер

@justinclift Я сейчас

Честно говоря, у go теперь есть воспроизводимая сборка: https://blog.filippo.io/reproroduction-go-binaries-byte-by-byte/
Это, возможно, cgo для sqlite и некоторые сборки env, которые делают их невоспроизводимыми.

Просто для информации, предыдущий перестроенный и незатронутый хеш- список. Если у вас есть этот хеш, это означает, что у вас есть двоичный файл до перестройки, которую мы выполнили для сброса версии 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%. : frowning:

@jvanraaij @yaggytter спасибо.

Поскольку после нашего расследования больше ничего не изменилось, и GitHub больше не предоставил никакой информации, я думаю, что эту проблему можно закрыть. Кто-нибудь может написать об этом в блоге?

@lafriks Я опубликовал это сообщение в блоге через пару дней после того, как все это началось - это больше взгляд на вредоносное ПО, чем на проблему, но я рад обновить его, если вы чувствуете, что что-то стоит задокументировать 👍

Думаю, он хочет написать посмертный пост в блоге gitea :)

@graystevens Кстати, ссылка на уведомление вашего

Поскольку после нашего расследования больше ничего не изменилось, и GitHub не предоставил больше информации ...

Что касается данных, то, хотя GitHub ничего не сказал об этом публично, в частном порядке они ответили (по электронной почте), чтобы сказать: «Спасибо, мы расследуем».

Вышеупомянутые комментарии @jvanraaij и @yasuokav, похоже, тоже помогли, поскольку (как ни странно, из моего PoV) GitHub, похоже, не обнаружил эти конкретные экземпляры вредоносного ПО до этого.

Например, во всех репозиториях , перечисленных здесь https://github.com/crossoverJie/SSM/issues/36

Я снова напишу сотрудникам GitHub письмо, чтобы указать на это. Кажется, что они решают все в течение нескольких дней, если напрямую связаться с ними и предоставить точный список для просмотра.

Это печально для всех других проектов, но, по крайней мере, для Gitea мы решили проблемы должным образом, надеюсь ... :)

Закрытие этой проблемы, так как двоичные файлы теперь подписаны и реализована 2FA.