Gitea: Le compte Giteabot a été compromis

En attendant, soyez prudent lorsque vous téléchargez nos binaires publiés, en particulier ceux de Windows, jusqu'à nouvel ordre. Par exemple, gardez un œil sur la taille des binaires, ou une double fin de fichier .exe .
Nous avons découvert que nos binaires .exe dans la version 1.4.2 ont également été modifiés.

Nous travaillons dur pour suivre toutes les pistes, nettoyer et reprendre nos activités quotidiennes dès que possible.

@daviian Peut-être décharges ?

@Mauladen Merci pour votre contribution. Nous allons certainement en discuter.

Aie! Oui, des binaires signés seraient l'idéal.

@Mauladen Nous avons reconstruit les binaires pour la version 1.4.2 juste pour être sûrs de fournir des binaires sûrs.

Ou vouliez-vous dire autre chose ?

C'est normal. Nous avons modifié la version 1.4.2 pour redéclencher CI afin de reconstruire les binaires, car le binaire Windows pour cette version a été supprimé et un nouveau malveillant a été ajouté.

@daviian , Peut-être que @Mauladen signifiait que la validation de la version 1.4.2 sans signature GPG, mais 1.4.1 était

Encore faut-il éditer la liste des changements

@axifive commit où pas gpg signé par l'utilisateur mais github qui le fait automatiquement (avec la clé github) lorsque la fusion est le même que l'auteur des relations publiques. Je ne considérerais pas plus sûr car si le compte github était compromis, je serai également affiché comme "vérifié". Mais nous pourrions commencer à signer le tag à partir de maintenant (à discuter). Pour information, nous travaillons sur la signature du binaire car il est plus facile de corrompre le binaire thzan que l'arbre de validation git.

Vous devez télécharger une archive créée par git-archive (en plus de celles que github génère automatiquement) que vous signez avec signify . Vous pouvez avoir une idée de la façon dont cela fonctionne/ressemble ici :

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

Libressl utilise la même technologie.

Y a-t-il plus d'informations à ce sujet? Quelle était la charge utile du binaire? Les utilisateurs vont-ils en être informés via un article de blog ou autre ? L'un des binaires Linux a-t-il été compromis ? Je suis plutôt préoccupé par ce que ces choses ont pu faire à mes serveurs. Je suis doublement inquiet de ne l'avoir découvert que par hasard en parcourant la page du problème par rapport à un avis officiel sur la page/le blog du projet

La version Gitea 1.4.2 peut-elle être mise à jour en toute sécurité à partir du code source à ce stade ?

À ce stade, je ne sais pas si seuls les binaires ont été affectés. Comment as-tu vérifié cela ? Vos branches sont-elles protégées ?

les shasums diffèrent sur les binaires que j'ai téléchargés le 6/4 et le 6/7 bien qu'ils aient le même nombre d'octets :

$ 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

Envie de les héberger quelque part pour que les gens puissent les séparer?

Téléchargé les binaires ici : https://send.firefox.com/download/a5dc9a9335/#_k9e4Cu2r4pPNDrsS1T2CA. Je les mettrai dans un endroit plus permanent si nécessaire.

Question : seuls les binaires du site Web ont-ils été affectés ou les référentiels ont-ils également été affectés ? Je demande parce qu'hier j'ai entendu parler de Gitea et j'ai cloné et construit la branche v1.4.

J'aimerais vraiment plus d'informations si la source elle-même est compromise ou simplement les binaires. J'exécute un script pour vérifier les mises à jour/build de git tous les soirs et j'ai eu la chance de rater cela à cause du timing.

La version 1.4.2 actuelle est-elle vérifiée comme étant propre ? Si nous savons que c'est entaché, nous devrions retirer cela dès que possible et le mettre ailleurs pour analyse, sinon les gens continueront de le télécharger s'ils ne voient pas ce problème. Je suis d'accord avec @CountMurphy , pouvons-nous ajouter quelque chose au README pour que ce soit vraiment visible ?

Pouvons-nous obtenir des hachages pour vérifier si nos binaires sont affectés ? Mon gitea 1.4.1 (linux amd64) ressemble à ceci :
$ sha256sum gitea
d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851 gitea

Je viens de télécharger gitea 1.4.1 linux-amd-64 et j'ai d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851 comme sha256 aussi

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

Pour être extrêmement clair : personne ne sait rien et les seuls hachages sûrs sont ceux actuellement trouvés ici : https://github.com/go-gitea/gitea/releases

Pour Gitea 1.4.2 sur amd64, cela signifie :

Désolé, j'ai mal compris https://github.com/go-gitea/gitea/issues/4167#issuecomment -395576229 pour signifier que les deux binaires ont été compromis.

J'ai édité ce post pour supprimer toute ambiguïté sur ce que nous savons réellement.

Attendez : selon ce commentaire (https://github.com/go-gitea/gitea/issues/4167#issuecomment-395576229), il y a deux shas e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 à partir du 4 juin et c843b462e4

Sommes-nous en train de dire que ces deux éléments sont compromis ou que l'un d'entre eux est unique ? Pour mémoire celui sur mon serveur est e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 à partir du 5 juin.

@christianbundy , S'il vous plaît, ne

S'il vous plaît, ne tirez pas de conclusions hâtives, attendez une réponse du membre de l'équipe

Désolé à ce sujet, je pensais que les hachages de fichiers seraient immédiatement publiés par un membre de l'équipe et je ne me suis pas rendu compte que l'information provenait de quelqu'un d'autre qui était _également_ dans le noir. Est-ce la bonne chaîne pour suivre les derniers développements ? J'ai éteint mon serveur et j'ai besoin de plus d'informations pour savoir si j'ai été infecté.

Je vois que vos modifications barrent l'entrée que j'ai indiquée. CEPENDANT, n'est-ce pas trop tôt pour tirer une conclusion ? Comment savons-nous avec certitude que e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 va bien ?

Il nous manque encore quelques informations (probablement non exhaustives) :

• [ ] Quels binaires ont été compromis et quelles sont leurs sommes de contrôle ?
• [ ] Quand le compte du bot a-t-il été compromis ?
• [ ] Le référentiel source est-il compromis (cela peut être facile à vérifier si vous avez une version du référentiel clonée depuis quelque temps, alors vous pouvez peut-être vérifier les différences ou les preuves de poussées forcées).

J'ai eu:

# 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

Avec sha256sum d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851

et je viens de télécharger 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

Avec sha256sum c843d462b5edb0d64572b148a0e814e41d069d196c3b3ee491449225e1c39d7d qui correspond au fichier .sha256 fourni : gitea-1.4.2-linux-amd64: OK qui devrait être sûr. (droit?)

[...] Nous avons reconstruit les binaires pour la version 1.4.2 juste pour être sûrs de fournir des binaires sûrs. [...]

J'ai téléchargé gitea-1.4.2-linux-amd64 pour analyse ici , mais cela ne dit rien d'évident.

Je vais regarder ce problème et garder mon installation Gitea hors ligne pour le moment.

Comment savons-nous avec certitude que e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 va bien ?

@shuhaowu J'ai dit que c843d462 était bien, pas e14e54f3 . Nous le savons car c'est le fichier actuellement servi sur GitHub, qu'ils ont récemment reconstruit.

Si 1.4.2 a été reconstruit, cela devrait être signé et vérifié comme les autres versions valides. Ne pas le faire ne fait qu'ajouter à la confusion.

@xcolor

Téléchargé les binaires ici : https://send.firefox.com/download/a5dc9a9335/#_k9e4Cu2r4pPNDrsS1T2CA

La seule différence entre ces deux binaires est qu'environ 2000 instances de movabsq $63663754793, %rcx ont été remplacées par movabsq $63663969431, %rcx . Je ne peux pas dire exactement ce que cela change dans le comportement, mais je pense qu'il est très peu probable qu'il suffise d'être malveillant.

Peut-être sortir une nouvelle version (signée ?) 1.4.3 avec le code connu comme sûr, ou cela embrouillerait-il davantage les choses ?

@justinclift J'aime cette idée, aussi un article de blog et quelque chose dans le README sur la situation aiderait à clarifier les choses.

@spaghetti2514

D'un côté, vous avez raison -- les différences entre _ces_ deux binaires sont faciles à voir.

D'un autre côté, l'équipe Gitea n'a pas réellement posté quels binaires ont été affectés, posté des hachages SHA256, ou vraiment dit quoi que ce soit qui nous aiderait à comprendre le compromis Comme d'autres l'ont souligné, nous n'avons pas assez d'informations pour déterminer ce qui s'est passé et qui est affecté.

Je suis frustré de souligner que nous devrions probablement simplement supposer le pire et attendre les étapes de diagnostic de l'équipe de base. Cela dit, je vous remercie de poster le diff démonté.

C'est ça que tu cherches ? https://github.com/go-gitea/gitea/issues/4167#issuecomment-395579466

Merci pour la mise à jour @lafriks !

J'ai mis à jour la description du problème avec des informations supplémentaires. Ce n'était pas si mal qu'il aurait pu l'être. Nous voulions être aussi transparents que possible, nous avons donc créé ce problème dès que nous avons tout nettoyé et corrigé et comme c'était la première fois que quelque chose comme cela se produisait, nous aurions probablement dû donner plus d'informations plus rapidement, désolé d'avoir causé de la confusion.

@lafriks Merci pour la mise à jour ! Pourriez-vous publier votre clé PGP que nous pourrons utiliser à l'avenir pour vérifier les commits ?

Les balises

Les versions seront signées par la clé GPG qui sera créée avant la version 1.5.0, nous la publierons sur README.md, gitea docs et dans un article de blog.

En tant qu'utilisateur 386, je peux confirmer que le binaire gitea-1.4.1-linux-386 actuellement disponible sur la page Releases correspond à une version que j'ai téléchargée le 4 juin ( cf6344b4 ).

comme les PR sont tous fusionnés à l'aide de Squash&Merge, ils ne sont pas signés (ou peut-être signés par la magie de GitHub :) )

N'utilisez pas le bouton de fusion, c'est fondamentalement peu sûr et une clé gpg aléatoire. Fusionner localement et pousser la fusion.

@mappu gitea v1.4.1 n'a pas été affecté et maintenant v1.4.2 a été réédité.

Vous devez télécharger une archive créée par git-archive (en plus de celles que github génère automatiquement) que vous signez avec signify .

En fait, vous n'avez même pas besoin de créer les archives et de les télécharger à nouveau. Vous pouvez signer celui créé par GitHub, car cela peut être fait de manière reproductible.

Voici un petit script pour ça : https://github.com/rugk/gittools/blob/master/signrelease.sh

@rugk Script à la recherche utile. :le sourire:

Un membre de l'équipe contributeur a-t-il obtenu une archive de 1.4.2 avant la découverte de la violation ?

Vous semblez avoir laissé beaucoup de gens dans l'ignorance quant à savoir si ce binaire a été modifié pour les versions de Linux, ce qui est une information assez importante compte tenu de :

1) La plupart des déploiements se feront sur des piles Linux

2) Les piles Linux ne sont pas habituées aux chevaux de Troie binaires et ne sont généralement pas adaptées aux meilleurs outils pour détecter par programmation le code suspect déjà exécuté sur le système.

Bien que j'aime croire qu'il s'agissait d'une simple attaque ciblée sur Windows et rien de plus, le fait qu'ils aient ciblé ce référentiel spécifique quelques jours seulement après une augmentation spectaculaire de la croissance de la base d'utilisateurs semble indiquer un effort plus bien orchestré. Je doute fort que quiconque savait ce qu'il visait et comment réussir ce genre de chose aurait simplement laissé passer une occasion aussi mûre d'infecter autant d'hôtes que possible.

@stanier dl.gitea.io n'a pas été affecté et nous avons vérifié qu'aucun autre binaire n'a été falsifié

Cela explique donc pourquoi notre proxy Web a refusé de télécharger la dernière image gitea de hub.docker.com ...

@lafriks Alors, pouvez-vous confirmer que c843d462 et e14e54f3 sont tous les deux sûrs ? Si le CI a fourni une construction avec une signature différente, alors quelque chose doit avoir changé dans le code source ou les paramètres que le compilateur a utilisés pour la construction. C'est un détail technique mineur en soi, mais il n'a jamais été directement indiqué ici si l'adversaire avait modifié ou non les binaires Linux 1.4.2, seulement les binaires .exe respectifs mentionnés dans le commentaire de @daviian.

Juste pour clarifier, je pose des questions sur les binaires de la page de publication du référentiel GH, pas sur dl.gitea.io, je comprends que rien n'a été falsifié en dehors du référentiel GH.

Les piles Linux ne sont pas habituées aux chevaux de Troie binaires et ne sont généralement pas adaptées aux meilleurs outils pour détecter par programmation le code suspect déjà exécuté sur le système.

Hmmm, la plupart des gestionnaires de paquets (et similaires) ne permettent-ils pas de vérifier au moins les sommes de contrôle sha* ? Pas nécessairement uniquement pour détecter les logiciels malveillants, mais en tant que "vérifiez que le téléchargement n'a pas été corrompu".

@justinclift oui, mais cela ne s'applique qu'aux binaires installés via le gestionnaire de packages. Le problème en question ici concerne un téléchargement direct depuis GitHub, qui, à ma connaissance, n'a aucune détection de malware intégrée.

Ahhh. Le terme "piles Linux" m'a déconcerté, car je suis plus habitué à ce que les téléchargements directs soient des choses uniques simplistes (par exemple lors du prototypage), plutôt que quelque chose qu'une solution automatisée ferait. Pas de soucis. :le sourire:

@stanier le build a été refait par drone pour tout effacer. Go ne fournit pas le même binaire à chaque fois que vous construisez le binaire car certaines variables peuvent changer (comme le temps de construction), il est donc normal que le hachage diffère.
J'ai obtenu tout le binaire pendant l'enquête et je peux fournir des hachages dès que j'arrive sur mon ordinateur personnel.

Pour tous, s'il vous plaît arrêtez les discussions sur les rumeurs et fournissez une contribution constructive.
Je comprends que vous vous souciez de votre sécurité et nous y tenons beaucoup (puisque nous sommes aussi chez vous en tant qu'utilisateur de gitea). Actuellement, l'accès a été modifié et nous n'avons plus vu d'activité suspecte. Nous avons fait ce numéro pour informer le plus tôt possible pour être transparent et pouvoir recevoir des données utiles pour enquêter ou un endroit manqué car personne n'est parfait.
Nous ferons un post-mortem pour expliquer ce qui s'est passé et nous avons définitivement pensé à des actions pour empêcher cela à l'avenir.
Si cette question devient folle, je pense que nous devrons fermer pour ne garder que des informations utiles et concises et envoyer le débat à la discorde où il devrait aller.

Pour éviter une telle situation à l'avenir, nous commencerons à signer tous les binaires avec la prochaine version. J'ai construit un plugin pour Drone que vous pouvez trouver sur https://github.com/drone-plugins/drone-gpgsign (la documentation pour ce plugin doit être faite) qui signera tous les binaires, la clé publique sera téléchargée au serveur de téléchargement et à un serveur de clés, vous pourrez toujours vérifier les binaires de manière fiable.

Juste pour vous montrer un exemple à quoi cela ressemblera et quels sont les résultats, vous pouvez jeter un œil à https://github.dronehippie.de/webhippie/ldap-proxy/49/18 et https://dl.webhippie.de /misc/ldap-proxy/master/ , des fichiers similaires seront téléchargés sur la page de téléchargement Gitea et sur les versions GitHub.

Si vous pensez que ce plugin manque quelque chose de vraiment important, n'hésitez pas à ouvrir un problème sur le référentiel de plugins et je pourrai le résoudre.

@sapk Merci pour la précision. Je m'excuse, il m'a complètement échappé que le projet était basé sur Golang - la plupart des problèmes comme celui-ci traitent avec des logiciels plus anciens, donc je pense que mon esprit est passé à une fausse relation. Mon erreur.

J'ai commencé à jeter un œil au binaire install.exe qui a été téléchargé : https://grh.am/2018/a-look-at-the-compromised-gitea-release/

Il semble que ce ne soit pas seulement Gitea qui en ait été touché, mais aussi https://github.com/opencompany/www.opencompany.org/releases

Merci pour l'explication claire.

Je pense que ce problème est la principale raison de passer par un emballage spécifique à la distribution. Il apporte plus d'attention à l'emballage et au code/binaire malveillant potentiel (en particulier dans le cas d'une tentative aussi grossière). Ce serait bien d'avoir au moins des packages Debian/RedHat/Archlinux pour Gitea : cela empêcherait de nombreuses personnes d'exécuter un binaire arbitraire sur leur serveur de production :)

Est-ce que PGP-signer les versions est suffisant ? Probablement. Assurez-vous simplement de publier votre clé publique sur de nombreuses plates-formes différentes afin que la compromission de votre site Web, par exemple, ne fasse pas que tout le monde télécharge de mauvaises clés. (Mais un paquet Debian dans les rétroportages serait <3)

(Aussi, des builds reproductibles ?)

Puisque vous allez commencer à signer des versions binaires, pourriez-vous également envisager de signer les images Docker transmises au registre ?

Il semble que ce ne soit pas seulement Gitea qui en ait été touché, mais aussi https://github.com/opencompany/www.opencompany.org/releases

Je viens d'envoyer directement un e-mail à leurs personnes de contact, au cas où elles ne se pencheraient pas encore sur leurs problèmes GitHub.

@graystevens Le personnel de pastebin doit-il être contacté pour supprimer cette adresse de pastebin, ou vaut-il mieux d'abord analyser complètement le malware afin qu'il soit bien compris ?

Merci à tous.. Je re-téléchargerais et remettrais mon serveur en service

@justinclift Je vais signaler la pâte à PasteBin maintenant - j'ai une copie du contenu afin que nous puissions recréer la sortie du logiciel malveillant si nous en avons besoin. Bon cri

Pour être juste, go a maintenant une version reproductible : https://blog.filippo.io/reproduce-go-binaries-byte-by-byte/
C'est peut-être cgo pour sqlite et certains env de build qui les rendent non reproductibles.

Juste pour information, la précédente reconstruction et la liste de

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

La passe de nettoyage install.exe semble avoir manqué un certain nombre de référentiels :

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

La plupart d'entre eux sont anciens et pas tout à fait pertinents, mais ce n'est probablement pas une bonne idée de garder les logiciels malveillants à portée de main.

@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
  

Euh, merci. Quelle est l'approche que vous utilisez pour les localiser ? Il semble que quelle que soit l'approche utilisée par le personnel de GitHub, elle n'a pas vraiment été efficace à 100%. :renfrogné:

@jvanraaij @yaggytter merci.

Comme après notre enquête, rien d'autre n'a été affecté et aucune autre information n'a été fournie par GitHub, je pense que ce problème peut être clos. Quelqu'un pour écrire un article de blog à ce sujet ?

@lafriks J'ai posté cet article de blog quelques jours après le début de tout cela - il s'agit plus d'un regard sur le malware que sur le problème en question, mais je suis heureux de le mettre à jour si vous pensez que quelque chose mérite d'être documenté 👍

Je pense qu'il veut écrire un article post-mortem sur le blog gitea :)

@graystevens BTW, le lien de votre

Comme après notre enquête, rien d'autre n'a été affecté et aucune autre information n'a été donnée par GitHub ...

En tant que point de données, bien que GitHub n'ait rien dit à ce sujet en public, ils ont répondu en privé (par e-mail) pour dire efficacement "Merci, nous enquêtons".

Les commentaires ci-dessus de @jvanraaij et @yasuokav semblaient également aider, car (bizarrement, d'après mon point de vue) GitHub ne semble pas avoir trouvé ces instances particulières du malware avant cela.

Par exemple, tous les dépôts répertoriés par contiennent toujours le malware : https://github.com/crossoverJie/SSM/issues/36

J'enverrai à nouveau un e-mail au personnel de GitHub pour le signaler. Ils semblent régler les problèmes en quelques jours lorsqu'ils sont contactés directement avec une liste exacte à consulter.

C'est triste pour tous les autres projets, mais au moins pour Gitea nous avons résolu les problèmes correctement, espérons-le... :)

Fermeture de ce problème car les binaires sont maintenant signés et 2FA est implémenté.