Gitea: تم اختراق حساب Giteabot

تم إنشاؤها على ٧ يونيو ٢٠١٨  ·  75تعليقات  ·  مصدر: go-gitea/gitea

نحن نحقق حاليًا في نشاط مشبوه من حساب له حق الوصول للكتابة إلى مؤسسة go-gitea. تمت إضافة ثنائي إلى الإصدارات عبر مستودعات go-gitea المتعددة. قمنا بتنظيف جميع الإصدارات وإسقاط الوصول مؤقتًا من الحساب. سنحقق المزيد لفهم ما يحدث بالفعل لمنعه في المستقبل ولنتحلى بالشفافية معك خلال هذه العملية. في غضون ذلك ، إذا وجدت أي نشاط مريب ، فيرجى الإبلاغ عنه في إطار هذه المشكلة.

تحديث: لم تتأثر أي شفرة مصدر أو بنية أساسية أخرى من Gitea ، بما في ذلك https://dl.gitea.io/ لذلك من الآمن استخدامها لتنزيل ثنائيات Gitea.

حساب GitHub الذي تم اختراقه تحت السيطرة الكاملة وقد تم أيضًا تعيين 2FA لذا لا ينبغي أن يحدث هذا في المستقبل مرة أخرى.

ما تم إنجازه:

  • تم إنشاء الإصدار الجديد والعلامة من مستودعات المؤسسة go-gitea باسم 0 وإضافة install.exe ثنائي (بحجم 13 كيلوبايت) إلى هذا الإصدار الذي كان ضارًا (من تحليلنا احتوى على عامل منجم العملة المشفرة ). تم حذف جميع هذه الإصدارات والثنائيات في غضون 2-3 ساعات من وقت إضافتها.
  • 1.4.2 أيضًا تم استبدال Windows Gitea. exe binary على GitHub بنفس 13K الثنائي كما هو مذكور أعلاه. لذلك إذا كانت Gitea تعمل ، فأنت في أمان.
  • فقط في حالة قيامنا بإعادة تحديد 1.4.2 لتشغيل CI لإعادة بناء الثنائيات ، لذا فإن sha256 سيكون مختلفًا الآن كما كان من قبل.

لقد اتصلنا بـ GitHub ولكن لم نتلق أي إجابة منهم حتى الآن

تحديث 2:
لم يتم اختراق أي ثنائيات gitea فعلية ، لذا فإن جميع التجزئات المذكورة في التعليقات أدناه آمنة.

SHA256 لملف ضار .exe :
bfc5a0358b1ad76ffbc1e1f4670bd3240536e2fbac88272cee3003322a15fffe

تحديث 3:
تمت إعادة إصدار v1.4.2 في حوالي 2018-06-07 20:00:00 UTC + 08

kinsecurity prioritcritical

التعليق الأكثر فائدة

daviian ربما إذن من الضروري التوقيع على النشرات؟

ال 75 كومينتر

في غضون ذلك ، يرجى توخي الحذر عند تنزيل الثنائيات التي تم إصدارها ، وخاصة تلك التي تعمل بنظام windows ، حتى إشعار آخر. على سبيل المثال ، راقب حجم الثنائيات ، أو نهاية ملف مزدوج .exe .
لقد اكتشفنا أن ثنائيات. exe الخاصة بنا في الإصدار 1.4.2 تم تغييرها أيضًا.

نحن نعمل بجد لمتابعة جميع المسارات والتنظيف والعودة إلى الأعمال اليومية في أسرع وقت ممكن.

daviian ربما إذن من الضروري التوقيع على النشرات؟

Mauladen شكرا لك على

أوتش! نعم ، ستكون الثنائيات الموقعة مثالية.

default
1
2

Mauladen لقد أعدنا بناء الثنائيات للإصدار 1.4.2 فقط للتأكد من أننا نقدم ثنائيات آمنة.

او هل قصدت شئ اخر؟

هذا امر طبيعي. لقد أعدنا تعديل 1.4.2 لإعادة إنشاء CI لإعادة بناء الثنائيات حيث تمت إزالة ملف windows binary لهذا الإصدار وتمت إضافة واحدة ضارة جديدة

daviian ، ربما يعني Mauladen أن الإصدار 1.4.2 يلتزم بدون توقيع GPG ، لكن 1.4.1 كان كذلك

لا تزال بحاجة إلى تحرير قائمة التغييرات

axifive الالتزام حيث لم يتم توقيع gpg بواسطة المستخدم ولكن github يقوم بذلك تلقائيًا (باستخدام مفتاح github) عندما يكون الدمج هو نفسه مؤلف العلاقات العامة. لن أعتبر أكثر أمانًا لأنه إذا تم اختراق حساب github ، فسوف أعرض أيضًا على أنه "تم التحقق منه". لكن يمكننا البدء في توقيع العلامة من الآن (للمناقشة). للحصول على معلومات ، نحن نعمل على توقيع ثنائي لأنه من الأسهل تحليل ملف thzan الثنائي باعتباره شجرة git الالتزام.

يجب عليك تحميل كرة تار تم إنشاؤها بواسطة git-archive (بالإضافة إلى تلك التي ينشئها github تلقائيًا) والتي تقوم بالتوقيع عليها بـ signify . يمكنك الحصول على فكرة عن كيفية عمل ذلك / مظهره هنا:

يستخدم Libressl نفس التقنية.

هل هناك المزيد من المعلومات حول هذا؟ ما هي حمولة البرنامج الثنائي؟ هل سيتم إعلام المستخدمين بهذا من خلال منشور مدونة أو أي شيء آخر؟ هل تم اختراق أي من ثنائيات لينكس؟ أنا مهتم بالأحرى بشأن ما قد تفعله هذه الأشياء بخوادمي. أنا قلق بشكل مضاعف لأنني اكتشفت فقط هذا التصفح لصفحة المشكلة عن طريق الصدفة مقابل إشعار رسمي على صفحة المشروع / المدونة

هل إصدار 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 gitea
d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851 gitea

لقد قمت للتو بتنزيل Gitea 1.4.1 linux-amd-64 وحصلت على d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851 باسم sha256 أيضًا

لتوضيح الأمر بشكل ساحق: لا أحد يعرف أي شيء والتجزئة الآمنة الوحيدة هي تلك الموجودة حاليًا هنا: 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 من الخامس من يونيو.

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 ، فيجب توقيعه والتحقق منه مثل الإصدارات الصالحة الأخرى. عدم القيام بذلك يزيد من الارتباك.

تضمين التغريدة

قم بتحميل الثنائيات هنا: https://send.firefox.com/download/a5dc9a9335/#_k9e4Cu2r4pPNDrsS1T2CA

الاختلاف الوحيد بين هذين الثنائيين هو أنه تم استبدال حوالي 2000 نسخة من movabsq $63663754793, %rcx بـ movabsq $63663969431, %rcx . لا أستطيع أن أقول بالضبط ما الذي يتغير من الناحية السلوكية ، لكنني أعتقد أنه من غير المرجح أن يكون ذلك كافيًا ليكون ضارًا.

ربما يتم طرح إصدار 1.4.3 جديد (موقّع؟) مع الكود المعروف الآمن ، أم أن ذلك سيؤدي إلى إرباك الأمور أكثر؟

justinclift تعجبني هذه الفكرة ، كما أن مشاركة مدونة وشيء في README حول الموقف من شأنه أن يساعد في توضيح الأمور.

@ spaghetti2514

من ناحية ، أنت على حق - من السهل رؤية الاختلافات بين هذين الثنائيين.

من ناحية أخرى ، لم ينشر فريق Gitea في الواقع الثنائيات التي تأثرت ، أو نشر أي تجزئات SHA256 ، أو قال بالفعل _أي شيء_ من شأنه أن يساعدنا في فهم الحل الوسط كما أشار آخرون ، ليس لدينا معلومات كافية تقريبًا لتحديد ماذا حدث ومن تأثر.

أشعر بالإحباط للإشارة إلى أنه من المحتمل أن نفترض الأسوأ وننتظر خطوات التشخيص من الفريق الأساسي. مع ذلك ، أقدر لك نشر فرق مفككة.

هل هذا ما تبحث عنه؟ https://github.com/go-gitea/gitea/issues/4167#issuecomment -395579466

شكرا لك على التحديث lafriks !

لقد قمت بتحديث وصف المشكلة بمعلومات إضافية. لم يكن سيئا كما كان يمكن أن يكون. أردنا أن نتحلى بأكبر قدر ممكن من الشفافية ، لذا أنشأنا هذه المشكلة بمجرد قيامنا بتنظيف وإصلاح كل شيء ولأن هذه كانت المرة الأولى التي يحدث فيها شيء كهذا ، لذلك ربما كان علينا تقديم المزيد من المعلومات بشكل أسرع ، آسف للتسبب في حدوث ارتباك.

lafriks شكرا على التحديث! هل يمكنك نشر مفتاح PGP الخاص بك والذي يمكننا استخدامه من الآن فصاعدًا للتحقق من الالتزامات؟

يتم توقيع علامات @ 4oo4 بواسطة مفتاح GPG الخاص بأحد الاندماجات ، حيث تم دمج جميع العلاقات العامة باستخدام Squash & Merge ، فهي غير موقعة (أو ربما موقعة بواسطة GitHub's magic :))

سيتم توقيع الإصدارات بواسطة مفتاح GPG الذي سيتم إنشاؤه قبل إصدار 1.5.0 ، وسننشره على README.md ومستندات gitea وفي منشور المدونة.

بصفتي مستخدم 386 ، يمكنني أن أؤكد أن ثنائي gitea-1.4.1-linux-386 المتوفر حاليًا في صفحة الإصدارات يطابق الإصدار الذي قمت بتنزيله في 4 يونيو ( cf6344b4 ).

نظرًا لأن العلاقات العامة تم دمجها جميعًا باستخدام Squash & Merge ، فهي غير موقعة (أو ربما موقعة بواسطة سحر GitHub :))

لا تستخدم زر الدمج ، فهو في الأساس غير آمن ومفتاح gpg عشوائي. ادمج محليًا وادفع عملية الدمج.

لم يتأثر

يجب عليك تحميل كرة تار تم إنشاؤها بواسطة أرشيف git (بالإضافة إلى تلك التي ينشئها github تلقائيًا) والتي تقوم بالتوقيع عليها.

في الواقع ، ليس عليك حتى إنشاء الأرشيف وتحميله مرة أخرى. يمكنك التوقيع على 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 الخاص بنا تنزيل أحدث صورة gitea من hub.docker.com ...

lafriks هل يمكنك التأكد من أن c843d462 و e14e54f3 كلاهما آمنان؟ إذا قدم CI بناءًا بتوقيع مختلف ، فلا بد أن شيئًا ما قد تغير إما في الكود المصدري أو في المعلمات التي استخدمها المترجم للبناء. إنها تقنية بسيطة في حد ذاتها ، ولكن لم يُذكر هنا بشكل مباشر ما إذا كان الخصم قد غير ثنائيات 1.4.2 Linux أم لا ، فقط ثنائيات exe ذات الصلة المذكورة في التعليق بواسطةdaviian.

فقط للتوضيح ، أنا أسأل عن ثنائيات صفحة إصدار GH repo ، وليس dl.gitea.io ، أفهم أنه لم يتم العبث بأي شيء خارج GH repo.

لا تعتاد مكدسات Linux على ثنائي طروادة ولا تتلاءم عادةً مع أفضل الأدوات للكشف البرمجي عن التعليمات البرمجية المشبوهة التي تعمل بالفعل على النظام.

حسنًا ، ألا يمتلك معظم مديري الحزم (وما شابه) شرطًا للتحقق على الأقل من المجاميع الاختبارية؟ ليس بالضرورة لاكتشاف البرامج الضارة ، ولكن "دعنا نتحقق من أن التنزيل لم يكن تالفًا".

justinclift نعم ، ولكن هذا ينطبق فقط على الثنائيات المثبتة من خلال مدير الحزم. تتعلق المشكلة المعنية هنا بالتنزيل المباشر من GitHub ، والذي لا يحتوي على أي اكتشاف للبرامج الضارة المضمنة على حد علمي.

أهه. لقد أفلتني مصطلح "مكدسات Linux" ، لأنني معتاد أكثر على توجيه التنزيلات لكونها أشياء مبسطة لمرة واحدة (على سبيل المثال عند إنشاء النماذج الأولية) ، بدلاً من شيء يمكن أن يفعله الحل الآلي. لا داعى للقلق. :ابتسامة:

stanier تم إعادة
لقد حصلت على جميع الملفات الثنائية أثناء التحقيق ويمكنني توفير التجزئة بمجرد وصولي إلى جهاز الكمبيوتر الشخصي الخاص بي.

للجميع ، يرجى التوقف عن الجدل حول الشائعات وتقديم مدخلات بناءة.
أتفهم أنك قلق على أمنك ونحن نهتم به كثيرًا (لأننا أيضًا في مكانك كمستخدم لـ 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 شكرا للتوضيح. أعتذر ، لقد فكرت تمامًا في أن المشروع كان يستند إلى Golang - معظم المشكلات مثل هذه الصفقة مع البرامج القديمة ، لذلك أعتقد أن ذهني قفز إلى علاقة خاطئة. غلطتي.

لقد بدأت في إلقاء نظرة على ثنائي 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 على الإصدارات؟ المحتمل. فقط تأكد من الإعلان عن مفتاحك العام على العديد من المنصات المختلفة بحيث لا يؤدي التنازل عن موقع الويب الخاص بك ، على سبيل المثال ، إلى تحميل الجميع مفاتيح خاطئة. (لكن حزمة دبيان في backports ستكون <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 والبعض الآخر الذي يبني البيئة التي تجعلها غير قابلة للتكرار.

فقط للحصول على معلومات ، إعادة البناء السابقة وقائمة

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-xorm


go-tango


go-xweb


goftp


جوبوك


رقصة التانغو


غوبيلد

آه ، شكرًا. ما هو الأسلوب الذي تستخدمه لتحديد موقع هؤلاء؟ يبدو أن أي نهج استخدمه موظفو GitHub لم يكن فعالًا بنسبة 100٪. :عابس:

تضمين التغريدة

نظرًا لأنه بعد التحقيق الذي أجريناه ، لم يتأثر أي شيء آخر ولم يتم تقديم مزيد من المعلومات بواسطة GitHub ، أعتقد أنه يمكن إغلاق هذه المشكلة. أي شخص يكتب بلوق وظيفة حول هذا؟

lafriks لقد نشرت منشور المدونة هذا في غضون يومين من بدء كل هذا - إنها نظرة على البرامج الضارة أكثر من المشكلة المطروحة ، لكنني سعيد بتحديثها إذا شعرت أن شيئًا ما يستحق التوثيق 👍

أعتقد أنه يريد كتابة منشور مدونة بعد الوفاة على مدونة gitea :)

graystevens راجع رابط إشعار موقعك هو 404 واحد. :ابتسامة:

كما هو الحال بعد تحقيقنا ، لم يتأثر أي شيء آخر ولم يتم تقديم المزيد من المعلومات بواسطة GitHub ...

كنقطة بيانات ، على الرغم من أن GitHub لم تقل أي شيء عن هذا علنًا ، فقد ردوا بشكل خاص (عبر البريد الإلكتروني) ليقولوا بشكل فعال "شكرًا ، نحن نحقق".

يبدو أن التعليقات أعلاه من jvanraaij و yasuokav تساعد أيضًا ، حيث (بشكل غريب ، من PoV الخاص بي) لا يبدو أن GitHub قد عثر على تلك الحالات المعينة من البرامج الضارة قبل ذلك.

على سبيل المثال ، لا تزال جميع ملفات الريبو المدرجة بواسطة yasuokav هنا تحتوي على البرامج الضارة: https://github.com/crossoverJie/SSM/issues/36

سأرسل بريدًا إلكترونيًا إلى موظفي GitHub مرة أخرى للإشارة إلى ذلك. يبدو أنهم يعتنون بالأشياء في غضون أيام قليلة عند الاتصال مباشرة بقائمة محددة للنظر فيها.

هذا أمر محزن لجميع المشاريع الأخرى ، ولكن على الأقل بالنسبة لـ Gitea قمنا بحل المشكلات بشكل صحيح ، ونأمل ... :)

إغلاق هذه المشكلة حيث يتم الآن توقيع الثنائيات وتنفيذ المصادقة الثنائية (2FA).

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات